Termos mais procurados:
A GN sugere esta:
server {
#
# ...
#
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate server_ssl.crt.pem;
ssl_certificate_key server_ssl.key.pem;
ssl_client_certificate /root/chain-pix-webhooks-prod.crt;
ssl_verify_client optional;
#
# ...
#
location /webhook {
if ($ssl_client_verify != SUCCESS) {
return 403;
}
rewrite ^(.)$ /webhook;
}
}
O problema é que com o meu .pem posso notifcar o pix.magno.pinheiro.com
CURLOPT_SSLCERT => 'developmentCertificate.pem',
Bom dia!
"Unknown SSL protocol error in connection to api-pix-h.gerencianet.com.br:443 "
Alguma previsão?
com o exemplo disponibilizado em php do pix, é possível gerar em homologação no localhost? ou somente se estiver em hospedagem com ssl ?
O certificado .pem gerado com o comando "openssl pkcs12...". pode ser utilizado em outra máquina ou na outra máquina eu preciso subir o p12 e rodar o comando "openssl pkcs12..." novamente?
Tem as duas opções (Se for APache) ## Diretório onde hosts virtuais estão armazenados.
SSLCertificateFile /caminho_certificado/server_ssl.crt.pem
SSLCertificateKeyFile /caminho_certificado/server_ssl.key.pem
SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile /caminho_certificado/chain-pix-prod.crt
## Se preferir deixar apenas uma rota de sua url para notificações você pode adicionar:
SSLVerifyClient none
SSLVerifyClient require
SSLVerifyDepth 3
se fosse problema "descer" a validação do mTLS pra dentro do location, então eu poderia argumentar que o ssl_verify_client deveria subir pra dentro do http {} no seu caso. e aí vc teria que ter um servidor nginx só pra isso 😄
Rafael, se o seu hostname é webhook.example.com (e ele tem o ssl_verify_client on) enquanto o host example.com não tem nenhuma exigência, eu posso dizer que é "quase mTLS"? Acho que não. Vc vai argumentar "são hosts diferentes, com regras diferentes".
Então se eu tenho um único server {} para o hostname example.com, que aceita requests com/sem mTLS, e valida dentro de um location /webhook, por que o request para /webhook é um "quase mTLS" enquanto o "/" aceita requests sem mTLS? O meu argumento contrário é que "são locations diferentes, com regras diferentes" 😉
Voltando ao assunto do mTLS em relação ao Nginx. <@!440035527127990273> Não seria legal na documentação da GN estar igual ao do Apache por exemplo? Na documentação do Apache (vide acima), há exemplos tanto para um vHost só para o Webhook como também para um Location só para o Webhook. Assim poderia ser implementado o ssl_verify_client on; e ssl_verify_client optional; a preferir pelo usuário.
<@!671762828046106646> No exemplo de vocês o qual eu citei o SSLVerifyDepth, só foi alterado por parte do exemplo e o outro ainda continua.
coloca assim:
Talvez colocar na documentação uma versão recomendada, com ssl_verify_client mandatório e server name único, e uma para isso em path específico com optional e aí checagem só no path do webhook.
mas acho que vc não entendeu o sentido da coisa, Rafael. se é optional, significa que o nginx não vai barrar sozinho o request. ele vai jogar o resultado do mTLS na variavel $ssl_client_verify. aí você rejeita se o mTLS não foi fechado (se não for SUCCESS, dá um 403). o processo é exatamente o mesmo, só muda que a regra não é absoluta (se o mTLS não for fechado, você ainda pode receber requests em outros locations(!)...
