ERR_SSL_PROTOCOL_ERROR: a conexão segura falha antes do certificado

O que o erro significa

Uma conexão HTTPS começa com um cumprimento: o navegador propõe versões do TLS e cifras, o servidor escolhe e apresenta o certificado. ERR_SSL_PROTOCOL_ERROR quer dizer que esse cumprimento quebrou. O Chrome mostra “Este site não pode fornecer uma conexão segura”; o Firefox, “Falha na conexão segura” com SSL_ERROR_RX_RECORD_TOO_LONG ou SSL_ERROR_NO_CYPHER_OVERLAP. Diferente de “Sua conexão não é particular”, o navegador nem chegou a avaliar o certificado: não entendeu o que o servidor enviou, ou não encontrou nenhuma versão nem cifra em comum.

As causas estão quase sempre no servidor; os poucos casos do lado do visitante se descartam em um minuto.

Causas frequentes

1. Só TLS antigo. O servidor aceita apenas TLS 1.0 ou 1.1, que os navegadores atuais não negociam mais.
2. Cifras obsoletas. A lista de cifras exclui tudo o que o navegador propõe, por exemplo depois de copiar uma configuração antiga.
3. Certificado e chave não batem. Depois de uma renovação, ssl_certificate aponta para o certificado novo e ssl_certificate_key para a chave antiga. O nginx em geral se recusa a subir; o Apache às vezes sobe e falha em cada conexão.
4. A porta 443 fala HTTP. Falta ssl na linha listen, ou um serviço sem TLS ficou na 443. O navegador recebe texto puro onde esperava TLS.
5. Proxy ou CDN no modo errado. Um proxy na frente encaminha para a origem em HTTPS, mas a origem só fala HTTP (ou o contrário), ou o modo SSL do CDN não corresponde ao servidor.
6. SNI ou vhost errado. O servidor não tem nenhum bloco com certificado para aquele nome e responde com o de outro site, ou com nenhum.

Se você é visitante

1. Confira a data e a hora do aparelho.
2. Desative por um momento a inspeção HTTPS do antivírus, o proxy ou a VPN.
3. Limpe o cache SSL e os dados do site no navegador, e tente em uma janela anônima sem extensões.
4. Tente http:// no lugar de https://. Se assim abrir, a falha está no HTTPS do site e só o dono corrige.
5. Se o erro aparece também em outro aparelho e em outra rede, não depende de você.

Se o site é seu: verifique primeiro

Abra o SSL checker: se nem de fora é possível estabelecer uma conexão TLS, o problema está no servidor. Depois consulte com o openssl, com o domínio como SNI:

# o que o servidor negocia?
openssl s_client -connect example.com:443 -servername example.com </dev/null

# aceita TLS 1.2?
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

# há um servidor web escutando na 443, e qual?
sudo ss -tlnp | grep ':443 '
curl -sI http://example.com:443/ --max-time 5

Como ler a saída: wrong version number ou packet length too long quer dizer que a 443 responde em HTTP (causa 4); no protocols available ou handshake failure, que não há versão nem cifra em comum (causas 1 e 2); key values mismatch no log do nginx, que certificado e chave não batem (causa 3).

Soluções no seu servidor

1. Ativar só TLS 1.2 e 1.3 com cifras atuais

No nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

No Apache (mod_ssl):

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

Depois, sempre, testar e recarregar:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

2. Fazer certificado e chave baterem

openssl x509 -noout -modulus -in /etc/letsencrypt/live/example.com/fullchain.pem | openssl md5
openssl rsa  -noout -modulus -in /etc/letsencrypt/live/example.com/privkey.pem  | openssl md5

As duas somas precisam coincidir. Se não, aponte ssl_certificate e ssl_certificate_key para a mesma pasta live/ do certbot (fullchain.pem e privkey.pem) e recarregue.

3. Fazer a porta 443 falar TLS

O bloco server que escuta na 443 precisa de ssl na linha listen e de um certificado:

listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Se ss -tlnp mostra outro programa na 443 (uma aplicação Node, um painel, um túnel), mova-o para outra porta ou coloque-o atrás do nginx.

4. Acertar proxy ou CDN

Com um reverse proxy na frente, o pedido para a origem precisa usar o protocolo que a origem entende: proxy_pass http://127.0.0.1:8080; se a aplicação não tem TLS. Em um CDN, o modo SSL precisa corresponder ao servidor: com certificado válido na origem, modo completo e estrito. Verifique primeiro a origem pelo IP dela com -servername, depois o caminho pelo CDN.

5. Um bloco com certificado para cada nome

Cada nome pelo qual chegam visitantes (example.com, www.example.com, subdomínios) precisa de um bloco server com server_name e certificado, ou de um certificado que cubra todos:

sudo certbot --nginx -d example.com -d www.example.com --expand

Defina também um bloco padrão para a 443 com certificado, para que um nome desconhecido receba um erro de certificado claro, e não um cumprimento quebrado.

Se o problema está na sua hospedagem

Em uma hospedagem compartilhada, a configuração TLS é da hospedagem. Se o painel do cliente mostra um certificado ativo e o erro continua de fora, envie esta mensagem:

Prezados, desde aproximadamente 7h (UTC) os navegadores mostram ERR_SSL_PROTOCOL_ERROR no meu site example.com e openssl s_client não completa o handshake TLS na porta 443. O painel do cliente mostra um certificado ativo e não alterei nada. Vocês poderiam verificar a configuração TLS do servidor e o certificado atribuído ao meu domínio?

Para não acontecer de novo

Um erro de protocolo aparece quase sempre depois de uma mudança: uma renovação, uma atualização do servidor web, uma configuração copiada. Uma verificação vinda de fora vê na primeira tentativa, antes dos seus visitantes. O monitoramento de certificados SSL acompanha também vencimento, cadeia e nomes, para que o próximo aviso não venha do navegador.

Fora do ar? Nós resolvemos. No seu servidor ou em uma hospedagem compartilhada com acesso SSH, o Quick Fix, o reparo automático a preço fixo, renova o certificado onde o certbot está configurado e recarrega o servidor web, 24 horas por dia, inclusive nos fins de semana; o Deep Fix corrige a configuração TLS, o proxy ou os vhosts, em blocos de 15 minutos; a estimativa é o valor máximo.