ERR_SSL_PROTOCOL_ERROR

O que este erro significa e como reconhecê-lo

• O Chrome ou o Edge informa “Este site não pode fornecer uma conexão segura” com ERR_SSL_PROTOCOL_ERROR.
• A falha pode afetar o site inteiro, um subdomínio ou apenas um hostname atrás de um proxy ou load balancer.
• O HTTP simples na porta 80 pode funcionar enquanto o HTTPS falha, indicando um problema no caminho TLS, e não necessariamente na aplicação.
• O erro pode começar após uma renovação de certificado, migração de servidor, alteração na configuração do servidor web, mudança de CDN ou mudança no serviço que escuta na porta 443.
• Um teste direto na origem e um teste usando o hostname público podem produzir resultados diferentes quando há uma CDN, um reverse proxy ou um load balancer envolvido.

Causas principais, por probabilidade

1. A porta 443 está servindo HTTP simples ou outro protocolo que não é TLS. O listener HTTPS pode estar ausente ou o serviço errado pode ter sido associado à porta 443. Nesse caso, o navegador recebe dados que não correspondem a um handshake TLS.
2. O virtual host HTTPS ou o server block está incorreto. O servidor pode estar escutando no endereço errado, selecionando o hostname incorreto ou não ter as diretivas TLS exigidas pelo servidor web.
3. Há uma incompatibilidade na origem de uma CDN, reverse proxy ou load balancer. O proxy pode estar usando HTTP enquanto a origem espera HTTPS, ou pode estar se conectando à porta ou ao backend errados.
4. A configuração TLS é incompatível ou está malformada. Versões de protocolo não compatíveis, configurações restritivas de cipher, problemas de roteamento SNI ou um dispositivo que termina TLS configurado incorretamente podem interromper o handshake antes da validação do certificado.
5. O certificado ou a cadeia não pode ser usado. Um certificado expirado, um certificado intermediário ausente ou um certificado que não cobre o hostname solicitado pode impedir uma conexão segura. Alguns navegadores e caminhos de conexão exibem, em vez disso, um aviso de certificado mais específico.
6. Um certificado renovado não foi carregado pelo serviço. Atualizar os arquivos do certificado no disco não altera o certificado apresentado por um servidor web em execução até que sua configuração seja recarregada ou reiniciada de acordo com o procedimento documentado do serviço.

Como corrigir

1. Determine se a falha é pública, específica da origem ou local

Tente acessar o hostname exato que falha a partir de outra rede ou dispositivo. Se apenas um computador falhar, verifique o software de segurança local, os proxies de interceptação e o horário do sistema. Se todos os clientes falharem, prossiga com a investigação do servidor, proxy, CDN ou load balancer.

Se o HTTP funciona, mas o HTTPS não, concentre-se no listener TLS, na porta 443, na seleção do certificado e em qualquer proxy entre o cliente e a origem. Não presuma que o funcionamento do HTTP comprova que a configuração HTTPS está correta.

2. Teste o handshake TLS sem alterar o estado do servidor

Em um terminal administrativo com acesso de rede ao endpoint, execute:

openssl s_client -connect [your-hostname]:443 -servername [your-hostname] -showcerts

A opção -servername é importante quando o SNI seleciona certificados ou virtual hosts. Registre se o handshake é iniciado, qual certificado é retornado, a data de expiração do certificado, os hostnames do Subject Alternative Name e se os certificados intermediários estão incluídos.

• Se a conexão retornar HTTP simples ou falhar antes que qualquer certificado apareça, inspecione o listener da porta 443 e o roteamento do proxy.
• Se um certificado for retornado, compare-o com o hostname solicitado e verifique suas datas de validade e sua cadeia.
• Se um teste direto na origem funcionar, mas o hostname público falhar, inspecione a CDN, o reverse proxy, o load balancer ou o caminho DNS, em vez de alterar a aplicação.

3. Verifique o listener HTTPS e o roteamento do hostname

Com acesso e autorização apropriados ao servidor, inspecione a configuração ativa do servidor web e confirme que:

• o serviço pretendido está escutando na porta 443;
• o server block ou virtual host HTTPS está habilitado;
• o hostname solicitado está incluído nas configurações relevantes de server_name ou ServerName/ServerAlias;
• o TLS está habilitado para esse listener; e
• os caminhos do certificado e da chave privada apontam para os arquivos pretendidos.

No Nginx, verifique o server block habilitado e sua configuração listen 443 ssl. No Apache, verifique a configuração <VirtualHost *:443> e SSLEngine on. Não copie diretivas entre produtos sem verificar a sintaxe e a versão compatíveis com o servidor instalado.

4. Valide o certificado e a cadeia

Confirme que o certificado apresentado:

• não está expirado nem inválido por ainda não estar vigente;
• cobre o hostname exato nas entradas de Subject Alternative Name;
• corresponde à chave privada associada; e
• vem acompanhado da cadeia de certificados intermediários necessária.

Um certificado para o domínio raiz não cobre automaticamente todos os subdomínios. O subdomínio deve estar listado explicitamente ou ser coberto por um certificado wildcard apropriado. Se o servidor apresentar apenas o certificado leaf, instale o arquivo de cadeia fornecido pela autoridade certificadora no formato exigido pelo servidor web.

5. Verifique a renovação e o carregamento do certificado

Em uma implantação gerenciada pelo Certbot, um administrador pode executar certbot renew --dry-run para testar o fluxo de renovação sem emitir um certificado de produção. Revise a saída, a configuração de renovação, as permissões e o hook de reload do serviço.

Se a renovação tiver sido concluída, mas os clientes ainda receberem o certificado antigo, confirme se o servidor web ou o proxy que termina TLS carregou os novos arquivos. Um reload ou restart altera o estado do serviço e deve ser realizado somente durante uma janela de manutenção aprovada, com um plano de rollback e seguindo o procedimento documentado do produto. Mantenha essa ação operacional separada dos diagnósticos somente de leitura.

6. Inspecione as configurações TLS da CDN, do proxy e do load balancer

Identifique onde o TLS termina: na CDN, no proxy de borda, no load balancer ou no servidor de origem. Verifique se o protocolo e a porta de origem configurados correspondem ao que a origem realmente oferece.

Se uma CDN oferecer modos como Flexible, Full ou Full (strict), selecione o modo que corresponda à configuração real da origem e à validade do certificado. Um modo menos rigoroso pode ocultar o problema subjacente ou criar uma falha diferente; ele não substitui de forma duradoura um certificado de origem válido. Faça alterações de configuração somente com autorização e, em seguida, teste novamente o hostname público e o caminho até a origem, quando possível.

7. Verifique interferências de protocolo, SNI ou dispositivos de rede

Se o endpoint apresentar um certificado válido e correspondente, mas o handshake ainda falhar, compare os resultados de redes e clientes TLS diferentes. Revise as configurações do firewall, load balancer, web application firewall e inspeção TLS em busca de versões de protocolo bloqueadas, políticas de cipher não compatíveis, roteamento SNI incorreto ou tráfego alterado. Preserve a saída do handshake e os logs relevantes do servidor para o provedor de hospedagem ou administrador da rede.

Prevenção e como verificar a correção

• Monitore a expiração dos certificados independentemente do mecanismo de renovação e emita alertas antes que eles se tornem inválidos.
• Teste a renovação em um fluxo de não produção ou dry run e verifique se o hook de reload do serviço realmente apresenta o novo certificado.
• Mantenha um inventário documentado de cada hostname, ponto de terminação TLS, certificado, chave privada e cadeia intermediária.
• Após alterações em certificados, proxies, load balancers ou mapeamentos de portas, teste o hostname público e cada subdomínio importante.
• Revise as alterações de configuração TLS quanto à compatibilidade de SNI, versão de protocolo, cipher e porta de origem antes da implantação.
• Guarde detalhes recentes do servidor, proxy e certificado para que um handshake com falha possa ser comparado com a última configuração conhecida como funcional.

Perguntas frequentes