ERR_SSL_PROTOCOL_ERROR: o que significa e como corrigir

O que significa ERR_SSL_PROTOCOL_ERROR

Uma conexão TLS começa com um handshake: o cliente envia um ClientHello listando as versões de protocolo e os conjuntos de cifra que suporta, e o servidor deveria responder com um ServerHello escolhendo um deles, seguido do seu certificado. O ERR_SSL_PROTOCOL_ERROR aparece quando essa troca quebra antes de chegar à etapa do certificado, quase sempre porque o que respondeu na porta não estava falando TLS de jeito nenhum, ou os dois lados não conseguiram concordar em como conversar. Esse é o termo de busca de código de erro com mais tráfego no Chrome, e o volume reflete quantas causas diferentes colapsam na mesma mensagem genérica, em vez de uma única falha comum.

Como o erro aparece

Chrome e Edge mostram ERR_SSL_PROTOCOL_ERROR sem nenhum detalhe de certificado, porque nenhum certificado chegou a ser apresentado. O Firefox costuma mostrar "Secure Connection Failed" com um código como SSL_ERROR_RX_MALFORMED_HANDSHAKE ou SSL_ERROR_PROTOCOL_VERSION_ALERT, dependendo de como o handshake quebrou.

Na linha de comando, tanto o curl quanto o openssl identificam a falha com precisão, o jeito mais rápido de sair do achismo:

curl -v https://example.com/
...
* TLSv1.3 (OUT), TLS handshake, Client hello
* OpenSSL/3.x: error:0A000126:SSL routines::unexpected eof while reading
* OpenSSL SSL_connect: SSL_ERROR_SYSCALL

openssl s_client -connect example.com:443 -servername example.com
...
140... error:1408F10B:SSL routines:ssl3_get_record:wrong version number

"Wrong version number" quase sempre significa que a porta 443 respondeu com HTTP simples, não com TLS, já que os primeiros bytes de uma resposta HTTP parecem lixo para um parser TLS esperando um ServerHello. Uma conexão que trava e estoura o tempo sem nenhum erro, em vez de falhar rápido, geralmente significa que um firewall ou proxy está descartando os pacotes silenciosamente, em vez de o servidor recusar ativamente.

O que causa o ERR_SSL_PROTOCOL_ERROR

• A porta 443 está servindo HTTP simples, ou outro serviço completamente diferente. Um proxy reverso mal configurado, um serviço que caiu e deixou um listener alternativo no lugar, ou uma regra de NAT apontando para o backend errado, todos produzem uma resposta sem TLS na porta de TLS.
• Incompatibilidade de versão ou de cifra do TLS. Um servidor travado em TLS 1.0 ou 1.1 por exigência legada não compartilha protocolo nenhum com um navegador que exige TLS 1.2 ou superior, então o handshake falha direto.
• Server Name Indication (SNI) ausente ou mal configurado. Num servidor que hospeda vários certificados num só IP, uma falta de correspondência de SNI pode fazer o servidor apresentar o certificado errado ou recusar o handshake.
• Experimentos com QUIC e HTTP/3. O Chrome às vezes tenta QUIC primeiro e cai para TLS sobre TCP; uma rede que lida mal com o tráfego UDP do QUIC pode aparecer como erro de protocolo na tentativa de fallback.
• Inspeção de HTTPS por antivírus ou proxy corporativo. Um software que intercepta o TLS para inspecionar o tráfego inicia o próprio handshake no lugar do real, e um certificado de interceptação quebrado derruba esse substituto.
• HSTS forçando HTTPS num host cujo TLS está quebrado. Depois que o navegador armazena em cache uma política de HSTS para um domínio, ele não tenta mais HTTP simples, então um host que antes caía graciosamente para HTTP agora falha direto na camada TLS.
• Uma cadeia de certificado antiga ou quebrada, num cliente antigo. Sistemas operacionais e navegadores muito antigos, anteriores a uma raiz ou intermediário mais novo, podem falhar o handshake de um jeito indistinguível de uma incompatibilidade de versão.
• O relógio do cliente está muito errado. Um relógio suficientemente fora pode fazer o cliente recusar negociar uma sessão, e não só rejeitar o certificado depois.

Como saber de quem é a culpa

Repita a mesma requisição a partir de uma segunda rede, por exemplo um celular no dados móveis em vez do Wi-Fi do escritório. Se o site carrega normalmente lá, o problema é local: um proxy corporativo, inspeção de antivírus, ou um portal cativo naquela primeira rede. Se o handshake falha igual em todo lugar que você testar, a configuração de TLS do servidor é a causa. Uma verificação de SSL rodada a partir de vários lugares ao mesmo tempo responde isso numa única requisição, sem precisar pegar emprestado um segundo dispositivo, e mostra o protocolo e a cifra exatos que o servidor negociou (ou recusou) em cada ponto.

Como corrigir o ERR_SSL_PROTOCOL_ERROR

Se você é o visitante

1. Limpe o estado de TLS do Chrome em chrome://net-internals/#hsts e chrome://restart, ou simplesmente limpe os dados de navegação de "imagens e arquivos armazenados em cache" mais "cookies e dados de sites" para o site afetado, o que também limpa o HSTS e o estado de sessão SSL em cache.
2. Desative o experimento do QUIC em chrome://flags/#enable-quic, mude para Disabled e reinicie o navegador. Se o site carregar depois disso, uma rede ou proxy incompatível com QUIC era a causa.
3. Confira a data e o horário do sistema e configure para sincronizar automaticamente; um relógio suficientemente errado pode quebrar o handshake direto, não só a checagem de certificado que vem depois.
4. Desligue a inspeção de HTTPS no seu antivírus (geralmente numa configuração chamada "proteção web" ou "inspeção SSL/TLS") e tente de novo. Se resolver, atualize o antivírus ou adicione o site à lista de exceções, em vez de deixar a inspeção desligada de vez.
5. Tente outra rede, como dados móveis. Um proxy corporativo ou um hardware de rede com defeito que afeta só uma conexão é uma causa comum que não tem nada a ver com o site em si.

Se você administra o site

1. Confirme que a porta 443 é realmente TLS com o comando openssl acima. "Wrong version number" ou uma resposta em texto puro significa que o serviço errado está preso naquela porta; corrija o proxy ou a configuração do listener antes de mexer em certificado nenhum.
2. Defina explicitamente as versões de protocolo suportadas. No nginx:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers HIGH:!aNULL:!MD5;

   Derrubar TLS 1.0 e 1.1 corrige os handshakes de clientes modernos, mas vai quebrar o acesso de clientes muito antigos que ainda dependem deles; decida essa troca de forma deliberada, não por acidente.
3. Confirme que o bloco do servidor está de fato escutando TLS na porta esperada: listen 443 ssl; (ou listen 443 ssl http2;) e que as diretivas de certificado e chave apontam para arquivos que existem e combinam entre si.
4. Verifique a ordem da cadeia de certificado. O certificado folha precisa vir primeiro, seguido dos intermediários em ordem até (sem incluir) a raiz; uma cadeia servida fora de ordem ou faltando um intermediário causa falhas de handshake em alguns clientes enquanto funciona em outros que guardam o intermediário faltante em cache em outro lugar.
5. Se o domínio estiver atrás do Cloudflare, confira o modo de SSL/TLS. O modo Flexible encerra o TLS na borda e conversa HTTP simples com a origem, o que falha completamente se a origem só aceita HTTPS; o modo Full exige qualquer certificado na origem; o Full (strict) exige um certificado válido e confiável na origem e falha se encontrar um autoassinado ou expirado.
6. Recarregue, não só edite, depois de qualquer mudança de configuração: nginx -t && systemctl reload nginx valida a configuração antes de aplicá-la.

ERR_SSL_PROTOCOL_ERROR contra erros parecidos

• ERR_CERT_DATE_INVALID acontece depois de um certificado ser recebido e lido; o handshake chegou até ali e falhou numa comparação de data. O ERR_SSL_PROTOCOL_ERROR nunca chega tão longe.
• ERR_CERT_AUTHORITY_INVALID também acontece depois de um certificado ser recebido; o navegador o leu e não confiou em quem assinou. De novo, um erro de protocolo significa que nenhum certificado chegou a ser avaliado.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH é o irmão mais específico desse erro: aparece quando o handshake avançou o suficiente para comparar versões e cifras suportadas, e não encontrou nenhuma sobreposição, tipicamente um servidor antigo oferecendo só SSLv3 ou TLS 1.0 contra um navegador moderno que os recusa. O ERR_SSL_PROTOCOL_ERROR é a falha mais ampla e menos específica, que cobre tudo o mais, incluindo uma resposta sem TLS na porta, dados de handshake malformados e software de interceptação com defeito.

Como prevenir o ERR_SSL_PROTOCOL_ERROR

Uma falha de handshake causada por uma mudança de configuração, uma atualização de proxy ou uma troca no modo de SSL do Cloudflare não aparece numa checagem HTTP comum, já que a conexão nunca chega perto o suficiente para produzir uma. Uma verificação de SSL dedicada lê o protocolo e a cifra negociados diretamente e, rodada a partir de mais de 300 pontos de verificação em 158 cidades, mostra se o handshake falha em todo lugar ou só numa rede, a mesma divisão que este guia percorre na mão. Rode uma verificação de certificado SSL contra o domínio, e configure o monitoramento contínuo de SSL e expiração de domínio para que um handshake quebrado alerte antes de os visitantes reclamarem.

Perguntas frequentes

O ERR_SSL_PROTOCOL_ERROR significa que meu certificado está ruim?

Não necessariamente. O erro aparece antes de o navegador chegar ao certificado, então o certificado em si pode estar perfeitamente bem enquanto a negociação de TLS por baixo ainda falha.

Por que isso só acontece num computador ou numa rede específica?

Inspeção de HTTPS por antivírus, um proxy corporativo, ou um caminho de QUIC quebrado naquela rede são os motivos mais comuns para um handshake falhar num lugar e funcionar em todos os outros. Testar numa segunda rede é o jeito mais rápido de confirmar.

Acabei de colocar meu site atrás do Cloudflare e agora os visitantes veem isso. O que mudou?

Confira o modo de SSL/TLS no painel. O modo Flexible espera que a origem aceite HTTP simples e falha se ela só serve HTTPS; o Full (strict) espera um certificado válido e confiável na origem e falha se achar um autoassinado ou expirado.

Desativar TLS 1.0 e 1.1 no meu servidor quebra alguma coisa?

Pode quebrar, para visitantes com navegadores muito antigos que nunca receberam uma atualização para TLS 1.2. Para a maior parte do tráfego atual, isso corrige mais handshakes do que quebra, mas confira antes o perfil de clientes do seu próprio tráfego.

Por que o curl disse "wrong version number"?

Essa mensagem significa que o curl enviou um ClientHello de TLS e recebeu de volta bytes que não fazem sentido como um ServerHello de TLS, quase sempre porque a porta está servindo HTTP simples ou outro protocolo sem TLS.