Histórico de mensagens sobre ssl em pix

quando tentei criar o webhoook me deu esse erro: Unknown SSL protocol error in connection to api-pix.gerencianet.com.br:443

curl_setopt_array($curl, array(
CURLOPT_URL => $_ENV["PIX_URL_AUTH"], // Rota base, desenvolvimento ou produção
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "POST",
CURLOPT_POSTFIELDS =>"{\r\n \"grant_type\": \"client_credentials\"\r\n}",
CURLOPT_SSLCERT => $arq_certificado, // Caminho do certificado
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_HTTPHEADER => array(
"Authorization: Basic $authorization",
"Content-Type: application/json",
),
));

Certo. No Postman utilizou o certificado .p12 mesmo?
Verifique se a verificação de SSL está ativa. Se sim, deixe OFF

A url deve ter o certificado SSL para HTTPS, onde foram geradas as chaves pública e privada?

eu simplificaria definindo SSLProtocol TLSv1.2 no vhost e, se ainda der exatamente o mesmo erro, desabilitaria o 1.3 no ssl-params.conf, adicionando -TLSv1.3 ao fim

vc precisa retirar, explicitamente, o TLSv1.3 para que não caia naquele bug relativo ao 1.3 + SSLClientVerify

no vhost está SSLProtocol -all +TLSv1.2, eu acho que esse "-all" não tá em conformidade. "All" (maiúsculo e sem sinal de +/-) adiciona todos. nesse caso aí, ou a diretiva tá sendo ignorada completa, ou ela tá apenas "adicionando TLSv1.2" ao que está definido no ssl-params.conf (que já permite 1.2 e, adicionalmente, permite 1.3, pois é All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1). Então TLSv1.3 continua ativo.

Uma coisa que eu tinha me atentado, foi que usando o certbot com o plugin do apache, ele adiciona nas ultimas linhas do vhost, um include do arquivo de configuracao de ssl do letsencrypt. isso sobreescrevia minhas definiçoes, então joguei ele pro topo do arquivo. e deu na mesma, também retirei o include. mesma coisa.

<@!440035527127990273> Sobre limitar o TLS, nada feito. continua retornando 403.

o resultado da busca por SSLProtocol

/etc/apache2/mods-enabled/ssl.conf: SSLProtocol all -SSLv3
/etc/apache2/conf-enabled/ssl-params.conf:SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
/etc/apache2/sites-enabled/autum-idelivery.conf: SSLProtocol -all +TLSv1.2
/etc/apache2/sites-available/autum-idelivery.conf: SSLProtocol -all +TLSv1.2
/etc/apache2/conf-available/ssl-params.conf:SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
/etc/apache2/mods-available/ssl.conf: SSLProtocol all -SSLv3

SSLProtocol all -SSLv2 -SSLv3 -TLSv1.3

hummm... nesse caso, o problema deve ser o TLSv1.3. ele tá com um bug afetando o recurso de SSLClientVerify optional

SSLProtocol all -SSLv2 -SSLv3

vc pode buscar com grep -Ri SSLProtocol /etc/apache2 (supondo que seja /etc/apache2 o diretório onde ficam todos os .conf)

vc pode conferir aqui: https://www.ssllabs.com/ssltest/

agora uma obs: se o seu novo vhost criado para o subdomínio funciona e o vhost primário não, significa que algum outro .conf (que pode estar sendo chamado por Include no vhost principal) tá definindo SSLProtocol não suportado

SSLProtocol TLSv1.2

<@!796521130038657045> veja no /etc/apache2/mods-enabled/ssl.conf se vc tem a diretiva SSLProtocol

https://ssl-config.mozilla.org/#server=apache&version=2.4.41&config=intermediate&openssl=1.1.1d&guideline=5.6

Na verdade, acho que falei besteira 😅
Usa-se o cert.pem (e CA do LE (ca.pem) vai no SSLCertificateChainFile) apenas em versões mais antigas do Apache; (e o SSLCACertificateFile fica sendo só o arquivo da GN mesmo, independente da versão do Apache)