ERR_SSL_VERSION_OR_CIPHER_MISMATCH: como corrigir (todos os navegadores)

O que é ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH significa que seu navegador e o site não conseguiram combinar como criptografar a conexão. O Chrome mostra “Não foi possível estabelecer uma conexão segura com este site” e “example.com usa um protocolo incompatível.”; nos detalhes: “O cliente e o servidor não são compatíveis com uma versão do protocolo SSL comum ou com o pacote de criptografia.” O Chromium o lista como erro -113 (net_error_list.h).

Isso acontece na primeira etapa do handshake TLS. O navegador envia as versões de TLS e os conjuntos de cifras que suporta; o servidor precisa escolher uma versão e um conjunto. Se o servidor não tem nada em comum com essa lista, responde com uma versão que o navegador não aceita mais ou se recusa a continuar por não ter certificado para o nome pedido, o handshake para ali.

Como a falha ocorre antes de qualquer certificado ser verificado, um certificado expirado, com nome errado ou com cadeia incorreta mostra outro erro (veja a tabela no fim). O Firefox mostra SSL_ERROR_NO_CYPHER_OVERLAP quando há recusa por cifra ou certificado e SSL_ERROR_UNSUPPORTED_VERSION para um servidor que só fala TLS 1.0/1.1.

Como o erro aparece em cada navegador

Todos os navegadores baseados em Chromium (Chrome, Edge, Brave, Opera) mostram o mesmo código. Procure por estas mensagens:

O que causa o ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

Se o erro aparece em um único site, a causa é o servidor ou a CDN desse site. Se aparece em muitos sites, algo no seu dispositivo ou na sua rede está no caminho. As causas:

• O servidor só fala TLS 1.0 ou 1.1. Chrome, Edge e Firefox começaram a bloquear as duas versões em 2020 (Firefox 78, Chrome e Edge 84); desde o Chrome 98 (2022) não há como contornar, e o Chromium informa esse servidor como este erro (net_error_list.h).
• O servidor oferece só cifras antigas, como RC4, 3DES ou conjuntos de exportação. O código TLS do Chrome desativa o 3DES por completo, então um servidor que não oferece mais nada não pode ser acessado.
• Nenhum certificado para o nome digitado (em algumas CDNs). No Cloudflare e no CloudFront, um hostname sem certificado tem o handshake recusado logo na primeira etapa. No Cloudflare essa é a causa mais comum: o certificado ainda está sendo ativado, o registro não está com proxy, um certificado personalizado expirou sem nenhum outro de reserva ou o nome é um subdomínio de vários níveis (Cloudflare). Um servidor nginx ou Apache comum envia o certificado padrão dele, o que mostra um aviso de nome incompatível.
• Algo no meio do caminho: verificação HTTPS do antivírus, proxy da empresa ou uma VPN que criptografa seu tráfego de novo com configurações antigas de TLS.
• Um dispositivo ou navegador muito antigo: Windows XP, Android 4.x e navegadores sem atualização há anos não têm o TLS 1.2 nem as cifras que os servidores exigem hoje.

Testamos: servidores TLS antigos vs. cliente moderno

Para mostrar o que causa este erro, conectamos um cliente TLS moderno (OpenSSL 3.6) aos servidores de teste públicos do badssl.com em 27 de outubro de 2026. Os servidores TLS 1.0 e 1.1 responderam com uma versão que o cliente não aceita mais; os servidores RC4 e 3DES recusaram com um alerta handshake_failure. O Chrome informa os quatro como ERR_SSL_VERSION_OR_CIPHER_MISMATCH:

Abra https://tls-v1-0.badssl.com:1010/ no Chrome e você verá exatamente esta página de erro. Se o seu site se comporta como as quatro primeiras linhas, valem as correções para donos de sites abaixo.

Como corrigir ERR_SSL_VERSION_OR_CIPHER_MISMATCH (para usuários)

Você não pode mudar o servidor de um site, então primeiro veja de quem é o problema. Se só um site falha, vá para as correções para donos de sites: só o dono pode resolver. Se muitos sites falham, tente estas. (Desativar o QUIC, uma dica antiga, não ajuda aqui: falhas de QUIC mostram ERR_QUIC_PROTOCOL_ERROR.)

Correção 1: verifique se o problema é do site

Abra o mesmo site em outro dispositivo ou com dados móveis. Se falhar lá também, o problema é o servidor.

Para ter certeza, passe o site pelo SSL Checker do DNS Robot: para a maioria dos servidores ele lista as versões de TLS aceitas e, para um site no Cloudflare, mostra se algum certificado foi emitido para esse nome. Um site que aceita só TLS 1.0 ou 1.1 não abre no Chrome, no Edge nem no Firefox, e não há o que clicar para passar: o Chrome não oferece “continuar mesmo assim” para este erro.

Correção 2: atualize seu navegador e sistema operacional

Navegadores e sistemas muito antigos não têm TLS 1.2, TLS 1.3 nem as cifras que os servidores usam hoje. Atualize o Chrome em chrome://settings/help e o Edge em edge://settings/help e depois atualize o sistema operacional.

O Internet Explorer no Windows XP e no Vista e o navegador padrão do Android 4.0-4.3 não têm TLS 1.2 com as cifras atuais e falham na maioria dos sites HTTPS.

Correção 3: verifique a verificação HTTPS do antivírus

Antivírus que verificam HTTPS (Avast, Kaspersky, Bitdefender, ESET, Norton) ficam no meio de cada conexão e fazem a própria conexão TLS com o site. Se as configurações de TLS deles estão desatualizadas, os sites que exigem TLS moderno falham.

Desative somente a parte de verificação HTTPS, que cada programa chama de um jeito (verificação HTTPS do Web Shield no Avast, filtragem de protocolos SSL/TLS no ESET, verificação de web criptografada no Bitdefender, verificação de conexões criptografadas no Kaspersky), e recarregue a página. Se o erro sumir, atualize o antivírus ou adicione o site como exceção em vez de deixar a verificação desligada.

Correção 4: desconecte uma VPN ou proxy

Proxies de empresas e VPNs com recurso de proteção da web ou inspeção HTTPS fazem a própria conexão TLS com o site (um túnel VPN comum não faz). Desconecte e recarregue. Se o site abrir, desative esse recurso ou peça ao provedor (ou à sua equipe de TI) para atualizar as configurações de TLS.

Como corrigir ERR_SSL_VERSION_OR_CIPHER_MISMATCH (para donos de sites)

Se visitantes relatam este erro no seu site, o servidor ou a CDN que responde na porta 443 não consegue combinar o TLS com navegadores modernos. Verifique com o SSL Checker e depois:

Correção 1: garanta que todo nome tenha um certificado

No Cloudflare, no CloudFront e em outras CDNs, um hostname sem certificado tem o handshake recusado, e os navegadores mostram este erro em vez de um aviso de certificado. Um servidor nginx ou Apache comum geralmente envia o certificado padrão (ERR_CERT_COMMON_NAME_INVALID) ou, com o ssl_reject_handshake do nginx, um alerta unrecognized_name (ERR_SSL_UNRECOGNIZED_NAME_ALERT). Verifique todos os nomes que os visitantes usam: example.com, www.example.com e cada subdomínio.

Passe cada nome pelo SSL Checker ou teste pelo terminal (OpenSSL 1.1.1 ou posterior; se aparecer “Could not find certificate”, o servidor recusou o handshake para esse nome):

# Does the server present a certificate for this exact name?
openssl s_client -connect example.com:443 -servername www.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

# Which TLS versions and ciphers does it accept?
nmap --script ssl-enum-ciphers -p 443 example.com

Correção 2: ative TLS 1.2 e TLS 1.3

Todo navegador atual exige pelo menos TLS 1.2. Ative o TLS 1.2 e o TLS 1.3 e nada mais antigo:

# nginx (site config or nginx.conf)
ssl_protocols TLSv1.2 TLSv1.3;

# Apache (ssl.conf)
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Then check the config and reload
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

Depois de recarregar, teste de novo com o SSL Checker ou o Qualys SSL Labs para confirmar que só TLS 1.2 e 1.3 são oferecidos.

Correção 3: ofereça conjuntos de cifras modernos

Com o TLS 1.2 ativo, o servidor precisa de uma cifra que os navegadores ainda aceitem. Ofereça ECDHE com AES-GCM ou ChaCha20-Poly1305 (o conjunto da Mozilla); cifras RC4, 3DES, de exportação e NULL são recusadas.

# nginx (TLS 1.2 ciphers; TLS 1.3 ciphers are always on)
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;

# Apache
SSLCipherSuite 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
SSLHonorCipherOrder off

Correção 4: correções específicas para Cloudflare

O guia do próprio Cloudflare para este erro diz que ele ocorre quando o hostname não é coberto por um certificado (Cloudflare). Verifique, em ordem:

• O certificado está ativo? Um domínio novo recebe o certificado Universal SSL em 15 minutos a 24 horas. Veja SSL/TLS → Edge Certificates: o status deve ser Active.
• O registro DNS está com proxy? O certificado só é apresentado para registros com proxy (nuvem laranja). Um DNS Lookup de um nome com proxy retorna os endereços do Cloudflare, não os do seu servidor.
• Um certificado personalizado expirou? O Cloudflare o remove após a expiração; se nenhum outro certificado ativo (como o Universal SSL) cobre o nome, os visitantes recebem este erro em vez de um aviso de certificado.
• É um subdomínio de vários níveis? Na configuração completa, o Universal SSL cobre só example.com e *.example.com, não test.dev.example.com. Use um certificado Advanced ou personalizado, ou o Total TLS (que exige o Advanced Certificate Manager).

Correção 5: verifique outras CDNs e balanceadores de carga

Se uma CDN ou balanceador de carga (CloudFront, Fastly, Akamai, um balanceador de carga em nuvem) encerra a conexão TLS, as configurações dele decidem, não as do seu servidor:

• Um certificado para cada hostname, associado à distribuição ou ao listener certo
• TLS 1.2 no mínimo na política de segurança, com cifras modernas
• Suporte a SNI se vários domínios compartilham o mesmo endereço IP

Como testar sua configuração SSL

Depois de fazer as mudanças, confirme que a configuração SSL está correta. Estas ferramentas ajudam a achar problemas antes dos seus visitantes.

• DNS Robot SSL Checker: verificação rápida do status do certificado, validade, cadeia completa e emissor. Resultados em segundos.
• Qualys SSL Labs: varredura profunda de versões de TLS, conjuntos de cifras, suporte a protocolos e vulnerabilidades conhecidas. Dá uma nota em letra (busque A ou A+).
• OpenSSL CLI: teste pela linha de comando com openssl s_client -connect domain.com:443 para ver o handshake bruto, a cadeia de certificados e a cifra negociada.
• Chrome DevTools: em uma página que carrega, o painel Security (ou Privacy and security) mostra a versão do TLS e a cifra usadas.

# Quick check: protocol, cipher and certificate in a few lines
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -brief </dev/null

# Does it accept TLS 1.2? TLS 1.3?
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_2 -brief </dev/null
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -tls1_3 -brief </dev/null

Erros SSL/TLS relacionados

O Chrome tem vários erros de TLS e de certificado, cada um de uma etapa diferente:

Guias para os erros vizinhos: ERR_SSL_PROTOCOL_ERROR, ERR_CERT_AUTHORITY_INVALID e Sua conexão não é particular.