Erros de SSL: o que são e como corrigi-los

Um erro de SSL é o que um navegador exibe quando não consegue abrir uma conexão criptografada confiável com um site. Em vez da página solicitada, você recebe uma tela de aviso e um código curto em letras maiúsculas pequenas, algo como NET::ERR_CERT_AUTHORITY_INVALID ou SSL_ERROR_NO_CYPHER_OVERLAP.

Esse código é a parte útil, e a maioria dos guias o ignora. “Erro de SSL” não é um termo técnico, e nenhum padrão define um. É o nome popular para toda uma família de falhas diferentes, motivo pelo qual conselhos genéricos como limpar o cache resolvem alguns deles e não fazem absolutamente nada para os demais.

O Que Realmente É um Erro de SSL

Quando você carrega um endereço que começa com https://, seu navegador e o servidor executam uma breve negociação chamada handshake TLS antes de qualquer conteúdo da página ser transmitido. O handshake acorda uma versão de protocolo e um conjunto de algoritmos de criptografia, e o servidor comprova sua identidade com um certificado. Se qualquer parte disso falhar, o navegador se recusa a continuar e exibe um erro em vez da página.

Vale a pena separar SSL e TLS aqui, porque a nomenclatura causa uma confusão real. SSL é o protocolo original, e todas as suas versões estão obsoletas há anos. O que seu navegador realmente utiliza é o TLS. A palavra “SSL” sobrevive em nomes de produtos, em diretivas de configuração e em códigos de erro, motivo pelo qual você ainda a vê em toda parte. Quando uma página ou um navegador diz SSL, quase sempre quer dizer TLS.

Isso importa para a solução de problemas porque a definição popular de erro de SSL é restrita demais. Você lerá frequentemente que um erro de SSL significa que o navegador não conseguiu verificar o certificado do site. Isso é verdade para um grupo desses erros e falso para os demais. Um servidor que responde na porta HTTPS com texto simples não criptografado produz um erro de SSL e nunca envia nenhum certificado. Duas máquinas que não conseguem concordar sobre um conjunto de cifras produzem um erro antes mesmo de o certificado ser examinado. Começar pelo certificado quando o certificado nunca foi o problema é o motivo mais comum pelo qual as pessoas gastam horas em uma correção de cinco minutos.

Qual Estágio da Conexão Falhou

Toda conexão HTTPS segue a mesma sequência, e um erro de SSL é simplesmente o ponto em que essa sequência parou. Determinar o estágio reduz imediatamente a causa, porque cada estágio tem um conjunto completamente diferente de explicações.

1. A conexão nunca se tornou TLS. Seu navegador abriu uma conexão e o que retornou não era TLS, ou o outro lado encerrou a conexão antes que o handshake terminasse. Nenhum certificado está envolvido, e nenhum certificado precisa ser substituído.
2. O handshake falhou durante a negociação. Ambos os lados falavam TLS, mas não conseguiram concordar sobre uma versão de protocolo, um conjunto de cifras ou qual site estava sendo solicitado. O handshake para antes de o certificado ser validado, e muitas vezes antes mesmo de ser enviado.
3. O certificado foi recebido e rejeitado. Este é o grupo ao qual as pessoas se referem quando dizem “erro de SSL”. Expiração, cobertura de nome de host, cadeia de confiança, revogação e força de assinatura estão todos aqui.
4. O handshake foi bem-sucedido e algo depois dele falhou. A conexão criptografada foi estabelecida corretamente, e depois uma camada posterior falhou. O certificado é confirmado como bom até esse ponto, então substituí-lo não muda nada.

Você não precisa adivinhar em qual estágio está. O código de erro informa isso, e a próxima seção mapeia todos os códigos ao seu estágio correspondente.

Encontre Seu Erro

Leia o código impresso abaixo da mensagem de aviso. No Chrome e no Edge, ele fica em letras maiúsculas pequenas sob “Sua conexão não é particular”. No Firefox, talvez seja necessário abrir os detalhes avançados na página de aviso. Depois, encontre-o abaixo.

Estágio 1: a conexão nunca se tornou TLS

• SSL_ERROR_RX_RECORD_TOO_LONG no Firefox significa que o servidor respondeu a uma solicitação HTTPS com algo que não é TLS, quase sempre HTTP simples servido na porta 443. É um problema de configuração do servidor.
• PR_END_OF_FILE_ERROR no Firefox significa que o outro lado encerrou a conexão antes de o handshake ser concluído. A causa frequentemente está entre você e o servidor, e não em nenhuma das extremidades.

Estágio 2: o handshake falhou durante a negociação

• ERR_SSL_PROTOCOL_ERROR é o código genérico do Chrome para um handshake que falhou por um motivo que ele não conseguiu identificar com precisão. Comece por aqui se o seu código for este, porque a primeira tarefa é reduzir as possibilidades.
• SSL_ERROR_NO_CYPHER_OVERLAP é o equivalente do Firefox, igualmente amplo: aparece para qualquer falha fatal de handshake que o servidor relate, independentemente do motivo real do servidor.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH é o código do Chrome para a mesma classe de falha, gerado para uma lista curta e específica de condições de negociação.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT significa que o servidor encerrou o handshake propositalmente porque o nome de host solicitado não corresponde a nenhum site configurado nele. Nenhum certificado é enviado, portanto o certificado não é a falha.
• ERR_BAD_SSL_CLIENT_AUTH_CERT ocorre na direção oposta a todos os outros erros aqui: o site pediu um certificado ao seu navegador e rejeitou o que recebeu, ou não recebeu nenhum. Este realmente é corrigido em sua máquina.
• Erro 525 do Cloudflare é uma falha de handshake em um trecho diferente do percurso: entre o Cloudflare e o servidor de origem por trás dele, não entre seu navegador e o Cloudflare. Os visitantes não podem agir sobre isso.

Estágio 3: o certificado foi recebido e rejeitado

Sua conexão não é particular é a tela de aviso do Chrome para todo esse grupo, e não uma causa em si, então, se é tudo o que você tem, leia primeiro o código abaixo dela.

A cadeia de confiança não pôde ser construída. O navegador não conseguiu vincular o certificado do site a uma raiz confiável, geralmente porque o servidor envia seu próprio certificado e omite o intermediário acima dele.

• NET::ERR_CERT_AUTHORITY_INVALID no Chrome e no Edge.
• SEC_ERROR_UNKNOWN_ISSUER no Firefox, a mesma condição com outro nome.
• Um certificado intermediário expirado, onde a cadeia existe, mas um elo acima do seu certificado venceu.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, onde não há cadeia porque o certificado assinou a si mesmo.

As datas ou o nome não correspondem. O certificado é confiável, mas não se aplica a este momento ou a este nome de host.

• NET::ERR_CERT_DATE_INVALID, onde o certificado expirou ou ainda não é válido. Vale saber que um relógio incorreto no seu próprio dispositivo também produz isso.
• NET::ERR_CERT_COMMON_NAME_INVALID, onde o nome de host não está listado no certificado.
• DLG_FLAGS_SEC_CERT_CN_INVALID, o mesmo problema de nome de host relatado por softwares construídos sobre a pilha web mais antiga do Windows, principalmente o modo Internet Explorer no Edge e aplicativos corporativos.

O certificado é confiável e atual, mas não permitido por outro motivo.

• NET::ERR_CERT_REVOKED, onde a Autoridade Certificadora o cancelou antes da data de expiração.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, onde o certificado não chegou com prova pública suficiente de emissão.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, onde algo na cadeia está assinado com SHA-1. As versões atuais do Chrome podem relatar o mesmo certificado sob um código diferente, mas a condição e a correção permanecem as mesmas.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL, uma colisão dentro do próprio repositório de certificados do Firefox, e não uma falha na conexão.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, que se aplica a um conjunto muito pequeno de domínios embutidos no navegador, de forma que um site comum não pode produzi-lo.

O próprio arquivo do certificado está errado. Esses dois são encontrados no servidor, e não em um navegador, e geralmente impedem que um site sirva HTTPS de forma alguma.

• ERR_SSL_SERVER_CERT_BAD_FORMAT, onde o navegador não conseguiu decodificar o certificado enviado pelo servidor.
• Uma incompatibilidade de módulo, onde o certificado instalado não pertence à chave privada instalada.

Estágio 4: o handshake foi bem-sucedido e algo depois dele falhou

Esses são classificados como erros de SSL por hábito. Em cada caso, a conexão criptografada já estava funcionando, então o certificado já foi validado com sucesso e reemiti-lo não ajudará.

• ERR_SSL_BAD_RECORD_MAC_ALERT significa que o servidor recebeu dados criptografados que não conseguiu verificar, o que acontece após o handshake, sob as chaves da sessão. Algo no caminho está corrompendo ou reescrevendo o tráfego.
• ERR_QUIC_PROTOCOL_ERROR é uma falha do QUIC, o transporte por baixo do HTTP/3. Não é um problema de certificado, e a causa habitual é um firewall ou VPN filtrando UDP.
• ERR_SPDY_PROTOCOL_ERROR é uma falha na camada HTTP/2, que fica acima de um handshake TLS já concluído.
• Conteúdo misto é o caso peculiar: a página carregou perfeitamente via HTTPS e depois solicitou um recurso via HTTP simples. Não produz nenhuma página de erro, apenas um cadeado rebaixado e scripts ou imagens ausentes.

Erros nomeados por um dispositivo, e não por um estágio

Duas plataformas produzem peculiaridades próprias suficientes para valer a pena tratá-las separadamente, porque a mesma condição subjacente se comporta de forma diferente nelas.

• Erros de SSL no iPhone e no iPad, incluindo a mensagem “Ocorreu um erro de SSL e não foi possível estabelecer uma conexão segura com o servidor”. A configuração de data e hora é a primeira coisa a verificar.
• Erros de conexão SSL no Android, onde o Chrome e outros aplicativos consultam repositórios de confiança diferentes, e um certificado intermediário ausente causa mais problemas do que em um computador de mesa.

Códigos que não aparecem mais

Três códigos ainda são amplamente documentados, mas foram removidos dos navegadores que os produziam, então, se você estiver lendo conselhos sobre um deles, verifique a data. As condições por trás de dois deles ainda existem sob outros nomes.

• NET::ERR_CERT_SYMANTEC_LEGACY foi removido no Chrome 136, lançado em abril de 2025.
• ERR_SSL_VERSION_INTERFERENCE foi removido no Chrome 76 em 2019, embora a interferência que ele descrevia ainda ocorra e agora se manifeste de forma diferente.
• ERR_SPDY_PROTOCOL_ERROR foi renomeado para ERR_HTTP2_PROTOCOL_ERROR no Chrome 77, também em 2019. A falha que ele descreve ainda ocorre atualmente, motivo pelo qual está listada no estágio quatro acima.

Se Você Está Visitando o Site

A maioria dos erros de SSL deve ser corrigida pelo próprio site, e nenhuma quantidade de trabalho no seu próprio dispositivo os alterará. Existe uma lista curta de exceções genuínas, e vale a pena percorrê-la antes de concluir que o site está com problemas.

• Verifique seu relógio. A validação do certificado compara as datas do certificado com o horário do seu próprio dispositivo. Um relógio errado por meses ou anos faz com que todo certificado pareça inválido, e essa é a causa mais comum do lado do visitante.
• Tente uma segunda rede. Mudar do Wi-Fi para dados móveis, ou o contrário, informa em segundos se algo na rede está interceptando o tráfego. Wi-Fi público e de hotéis são frequentemente os culpados.
• Desative a inspeção de HTTPS temporariamente. Produtos antivírus e proxies corporativos inspecionam o tráfego criptografado substituindo-o por seus próprios certificados. Quando fazem isso mal, você recebe um erro de SSL em sites que funcionam bem em outros lugares.
• Tente uma janela privada e outro navegador. Se o erro aparecer em um navegador e não em outro, a causa geralmente é local, em uma extensão ou em dados armazenados. Se aparecer em todos, o problema é do site.

Se nada disso ajudar, o problema está no servidor, e a resposta honesta é que você não pode corrigi-lo. Isso se aplica completamente ao erro 525 do Cloudflare, onde a falha ocorre em uma conexão da qual o seu navegador não faz parte.

Os navegadores oferecem uma forma de continuar apesar da maioria dos avisos de certificado, e vale a pena esclarecer o que isso custa. Prosseguir informa ao navegador que ele deve aceitar uma conexão cuja identidade não conseguiu verificar, o que significa que você não tem garantia de estar falando com o site que digitou, e não com algo intermediário. Essa é uma troca aceitável em um servidor de testes que você controla. Não é aceitável em nada onde você digitará uma senha ou dados de pagamento. Alguns erros não oferecem forma alguma de prosseguir, e isso é intencional, não uma falha.

Se Você Administra o Site

Diagnostique antes de mudar qualquer coisa. Reinstalar um certificado que nunca foi o problema é a forma habitual pela qual uma hora se transforma em uma tarde inteira.

Comece com uma verificação externa

Execute o domínio pelo nosso SSL Checker. Ele relata o que o servidor está realmente enviando ao mundo exterior, o que frequentemente não é o que está no arquivo de configuração. Uma cadeia que parece completa no disco, mas chega incompleta ao navegador, é a constatação mais comum, e é a causa por trás tanto do NET::ERR_CERT_AUTHORITY_INVALID quanto do SEC_ERROR_UNKNOWN_ISSUER.

Você pode ver a mesma coisa pela linha de comando. Isso imprime cada certificado que o servidor oferece, na ordem em que os oferece:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Leia a lista de certificados nessa saída, não a linha Verify return code no final. Essa linha é muito menos informativa do que parece: relata apenas o veredito do OpenSSL sobre a cadeia, ignora o nome de host a menos que você solicite essa verificação explicitamente, e imprime 0 (ok) mesmo quando o servidor não enviou certificado algum porque o handshake foi abortado. Se a saída disser no peer certificate available em vez de mostrar uma linha subject=, nada foi verificado e a falha ocorreu antes.

Verifique as datas e o nome de host

Esses dois fatores respondem por uma grande parte das rejeições de certificado. Para ler a janela de validade do certificado que o servidor está servindo:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

Os navegadores comparam o nome de host com a extensão subjectAltName e ignoram totalmente o Common Name, então esse é o campo a inspecionar em um arquivo de certificado local:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

Para fazer o OpenSSL aplicar a verificação de nome de host que um navegador aplica, adicione a flag em vez de presumir que um resultado limpo já cobre isso:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

No macOS, esses comandos exigem atenção. O openssl que acompanha o macOS é o LibreSSL, e ele rejeita -verify_hostname completamente e relata um resultado saudável em algumas cadeias genuinamente quebradas. Instale o OpenSSL pelo Homebrew e execute openssl version novamente para confirmar qual binário você está realmente chamando. Se ainda relatar LibreSSL, seu PATH está encontrando primeiro a cópia do sistema, então chame /opt/homebrew/bin/openssl pelo caminho completo.

Depois corrija e verifique

O que mudar depende do estágio, e os guias individuais linkados acima trazem as etapas específicas para cada plataforma. Três correções cobrem a maioria dos casos:

• Sirva a cadeia completa. Concatene seu certificado e os certificados intermediários fornecidos pela sua Autoridade Certificadora no arquivo para o qual seu servidor aponta. Não coloque a chave privada nesse arquivo.
• Renove antes da expiração, e automatize isso. A validade dos certificados está diminuindo, então tudo que for renovado manualmente acabará sendo renovado com atraso em algum momento. A automação ACME elimina esse prazo.
• Cubra todos os nomes de host que você realmente serve. Um certificado para um domínio não cobre seus subdomínios, a menos que seja um certificado curinga ou os liste explicitamente.

Sempre teste a configuração antes de recarregar o serviço, e execute a verificação novamente depois, a partir de fora da sua própria rede. Uma correção confirmada apenas no navegador em que você estava testando não está confirmada, porque esse navegador pode estar guardando um resultado em cache.

Como Prevenir Erros de SSL

Quase todo erro de SSL em um site funcional vem de uma dessas três coisas: um certificado que expirou, uma cadeia que nunca esteve completa, ou uma configuração que se desviou. Todas as três são evitáveis.

• Automatize a renovação. A validade máxima dos certificados está sendo reduzida gradualmente nos próximos anos, e a renovação manual deixa de ser prática bem antes disso. Automatize agora, e não quando algo quebrar.
• Monitore a expiração de forma independente. Um lembrete de calendário falha quando a pessoa sai da empresa. Uma verificação externa que alerta com semanas de antecedência não falha.
• Verifique novamente após cada mudança. Migrações de servidor, mudanças de CDN e atualizações de painel de controle reescrevem silenciosamente a configuração do certificado. Verifique de fora depois disso.
• Teste em um celular, não apenas em um computador. As plataformas móveis são mais rigorosas com cadeias incompletas, então um problema de cadeia frequentemente aparece em um celular enquanto o computador de mesa parece funcionar bem.
• Instale corretamente desde a primeira vez. Nossos tutoriais de instalação cobrem a cadeia e as etapas de vinculação para cada plataforma, e a maioria dos erros de cadeia se origina no momento da instalação.

Perguntas Frequentes