ERR_SSL_VERSION_OR_CIPHER_MISMATCH: cómo solucionarlo (todos los navegadores)

¿Qué es ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_VERSION_OR_CIPHER_MISMATCH significa que tu navegador y el sitio web no lograron acordar cómo cifrar la conexión. Chrome muestra «Este sitio web no puede proporcionar una conexión segura» y «La página example.com utiliza un protocolo no admitido»; en los detalles: «El cliente y el servidor no son compatibles con la misma versión de protocolo SSL o de cifrado.» Chromium lo registra como el error -113 (net_error_list.h).

Ocurre en el primer paso del handshake TLS. Tu navegador envía las versiones TLS y los conjuntos de cifrado que admite; el servidor tiene que elegir una de cada. Si el servidor no tiene nada en común con esa lista, responde con una versión que el navegador ya no acepta, o se niega a continuar porque no tiene certificado para el nombre solicitado, el handshake se detiene ahí mismo.

Como falla antes de comprobar ningún certificado, un certificado vencido, con un nombre incorrecto o con una cadena mal instalada muestra otro error (consulta la tabla del final). Firefox muestra SSL_ERROR_NO_CYPHER_OVERLAP cuando el rechazo es por el cifrado o el certificado, y SSL_ERROR_UNSUPPORTED_VERSION si el servidor solo habla TLS 1.0/1.1.

Cómo se ve el error en cada navegador

Todos los navegadores Chromium (Chrome, Edge, Brave, Opera) muestran el mismo código. Busca esto:

¿Qué causa ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

Si el error aparece en un solo sitio web, la causa es el servidor o el CDN de ese sitio. Si aparece en muchos sitios web, hay algo en tu dispositivo o en tu red que lo provoca. Las causas:

• El servidor solo habla TLS 1.0 o 1.1. Chrome, Edge y Firefox empezaron a bloquear ambas versiones en 2020 (Firefox 78, Chrome y Edge 84); desde Chrome 98 (2022) no hay forma de saltarse el bloqueo, y Chromium informa de un servidor así con este error (net_error_list.h).
• El servidor ofrece solo cifrados antiguos, como RC4, 3DES o suites de grado de exportación. El código TLS de Chrome desactiva 3DES por completo, así que un servidor que no ofrece nada más es inalcanzable.
• No hay certificado para el nombre que escribiste (en algunos CDN). En Cloudflare y CloudFront, el handshake de un nombre de host sin certificado se rechaza en el primer paso. En Cloudflare esta es la causa habitual: el certificado aún se está activando, el registro no está con proxy, un certificado personalizado venció sin otro de respaldo, o el nombre es un subdominio de varios niveles (Cloudflare). Un servidor nginx o Apache normal envía en su lugar su certificado predeterminado, lo que provoca una advertencia de nombre no coincidente.
• Algo en medio — el análisis HTTPS de un antivirus, un proxy de empresa o una VPN que vuelve a cifrar tu tráfico con ajustes TLS antiguos.
• Un dispositivo o navegador muy antiguo — Windows XP, Android 4.x y navegadores sin actualizar desde hace años carecen de TLS 1.2 o de los cifrados que ahora exigen los servidores.

Lo probamos: servidores TLS antiguos frente a un cliente moderno

Para mostrar qué provoca este error, el 27 de octubre de 2026 conectamos un cliente TLS moderno (OpenSSL 3.6) a los servidores de prueba públicos de badssl.com. Los servidores TLS 1.0 y 1.1 respondieron con una versión que el cliente ya no acepta; los servidores RC4 y 3DES rechazaron con una alerta handshake_failure. Chrome muestra ERR_SSL_VERSION_OR_CIPHER_MISMATCH en los cuatro:

Abre https://tls-v1-0.badssl.com:1010/ en Chrome y verás exactamente esta página de error. Si tu propio sitio se comporta como las cuatro primeras filas, te sirven las soluciones para propietarios de sitios web que siguen.

Cómo solucionar ERR_SSL_VERSION_OR_CIPHER_MISMATCH (para usuarios)

No puedes cambiar el servidor de un sitio web, así que primero comprueba de quién es el problema. Si falla un solo sitio, salta a las soluciones para propietarios de sitios web: solo el propietario puede resolverlo. Si fallan muchos sitios, prueba esto. (Desactivar QUIC, un consejo antiguo, no ayuda aquí: los fallos de QUIC muestran ERR_QUIC_PROTOCOL_ERROR.)

Solución 1: comprobar si el problema es del sitio

Abre el mismo sitio en otro dispositivo o con datos móviles. Si también falla allí, el problema es del servidor.

Para una respuesta definitiva, pasa el sitio por el SSL Checker de DNS Robot: en la mayoría de los servidores muestra las versiones TLS que aceptan y, en un sitio en Cloudflare, indica si se ha emitido algún certificado para ese nombre. Un sitio que solo acepta TLS 1.0 o 1.1 no se puede abrir en Chrome, Edge ni Firefox, y no hay nada en lo que hacer clic para saltarse el error: Chrome no ofrece ningún enlace para continuar con este error.

Solución 2: actualizar tu navegador y sistema operativo

Los navegadores y sistemas muy antiguos carecen de TLS 1.2, TLS 1.3 o de los cifrados que usan ahora los servidores. Actualiza Chrome en chrome://settings/help y Edge en edge://settings/help, y después el sistema operativo.

Internet Explorer en Windows XP y Vista, y el navegador de serie de Android 4.0 a 4.3, no tienen TLS 1.2 con los cifrados actuales y fallan en la mayoría de los sitios HTTPS.

Solución 3: revisar el escaneo HTTPS del antivirus

Los antivirus que escanean HTTPS (Avast, Kaspersky, Bitdefender, ESET, Norton) se colocan en medio de cada conexión y crean su propia conexión TLS con el sitio. Si sus ajustes TLS están desactualizados, fallan los sitios que exigen TLS moderno.

Desactiva solo la parte de escaneo HTTPS, que cada suite llama de forma distinta (el escaneo HTTPS del Web Shield de Avast, el filtrado de protocolo SSL/TLS de ESET, el análisis web cifrado de Bitdefender, el análisis de conexiones cifradas de Kaspersky), y recarga. Si el error desaparece, actualiza el antivirus o añade el sitio como excepción en lugar de dejar el escaneo desactivado.

Solución 4: desconectar una VPN o un proxy

Los proxies de empresa y las VPN con una función de protección web o de inspección HTTPS crean su propia conexión TLS con el sitio (un túnel VPN normal no lo hace). Desconéctate y recarga. Si el sitio funciona, desactiva esa función o pide al proveedor (o a tu equipo de TI) que actualice sus ajustes TLS.

Cómo solucionar ERR_SSL_VERSION_OR_CIPHER_MISMATCH (para propietarios de sitios web)

Si los visitantes te informan de este error en tu sitio, el servidor o CDN que responde en el puerto 443 no logra acordar TLS con los navegadores modernos. Compruébalo con el SSL Checker y después:

Solución 1: asegurarte de que cada nombre tenga certificado

En Cloudflare, CloudFront y otros CDN, el handshake de un nombre de host sin certificado se rechaza, y los navegadores muestran este error en lugar de una advertencia de certificado. Un servidor nginx o Apache normal suele enviar su certificado predeterminado (ERR_CERT_COMMON_NAME_INVALID) o, con ssl_reject_handshake de nginx, una alerta unrecognized_name (ERR_SSL_UNRECOGNIZED_NAME_ALERT). Comprueba cada nombre que usan los visitantes: example.com, www.example.com y cada subdominio.

Pasa cada nombre por el SSL Checker o prueba desde un terminal (OpenSSL 1.1.1 o posterior; si ves «Could not find certificate», el servidor rechazó el handshake para ese nombre):

# 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

Solución 2: habilitar TLS 1.2 y TLS 1.3

Todos los navegadores actuales necesitan como mínimo TLS 1.2. Habilita TLS 1.2 y TLS 1.3 y nada más antiguo:

# 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

Después de recargar, vuelve a probar con el SSL Checker o Qualys SSL Labs para confirmar que solo se ofrecen TLS 1.2 y 1.3.

Solución 3: ofrecer conjuntos de cifrado modernos

Con TLS 1.2 activado, el servidor necesita un cifrado que los navegadores aún acepten. Ofrece ECDHE con AES-GCM o ChaCha20-Poly1305 (la selección de Mozilla); los cifrados RC4, 3DES, de exportación y NULL se rechazan.

# 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

Solución 4: correcciones específicas de Cloudflare

La propia guía de Cloudflare sobre este error dice que ocurre cuando el nombre de host no está cubierto por un certificado (Cloudflare). Comprueba, por orden:

• ¿Está activo el certificado? Un dominio nuevo recibe su certificado Universal SSL entre 15 minutos y 24 horas. Mira SSL/TLS → Edge Certificates: debe indicar Active.
• ¿Está el registro DNS con proxy? El certificado solo se presenta en los registros con proxy (nube naranja). Un DNS Lookup de un nombre con proxy devuelve las direcciones de Cloudflare, no las de tu servidor.
• ¿Venció un certificado personalizado? Cloudflare lo elimina al vencer; si ningún otro certificado activo (como Universal SSL) cubre el nombre, los visitantes ven este error en lugar de una advertencia de certificado.
• ¿Es un subdominio de varios niveles? En una configuración completa, Universal SSL cubre solo example.com y *.example.com, no test.dev.example.com. Usa un certificado Advanced o personalizado, o Total TLS (que requiere Advanced Certificate Manager).

Solución 5: revisar otros CDN y balanceadores de carga

Si un CDN o balanceador de carga (CloudFront, Fastly, Akamai, un balanceador de la nube) termina la conexión TLS, mandan sus ajustes, no los de tu servidor:

• Un certificado para cada nombre de host, asociado a la distribución o al listener correctos
• TLS 1.2 como mínimo en su política de seguridad, con cifrados modernos
• Compatibilidad con SNI si varios dominios comparten una misma dirección IP

Cómo probar tu configuración SSL

Después de hacer cambios, comprueba que tu configuración SSL es correcta. Estas herramientas te ayudan a detectar problemas antes que tus visitantes.

• SSL Checker de DNS Robot — Comprobación rápida del estado del certificado, su vencimiento, lo completa que está la cadena y el emisor. Resultados en segundos.
• Qualys SSL Labs — Análisis a fondo de versiones TLS, conjuntos de cifrado, compatibilidad de protocolos y vulnerabilidades conocidas. Da una nota (apunta a A o A+).
• OpenSSL CLI — Prueba desde la línea de comandos con openssl s_client -connect domain.com:443 para ver el handshake en bruto, la cadena de certificados y el cifrado negociado.
• Chrome DevTools — en una página que carga, el panel Seguridad (o «Privacy and security») muestra la versión TLS y el cifrado utilizados.

# 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

Errores SSL/TLS relacionados

Chrome tiene varios errores de TLS y de certificado, cada uno de un paso distinto:

Guías de los errores vecinos: ERR_SSL_PROTOCOL_ERROR, ERR_CERT_AUTHORITY_INVALID y Tu conexión no es privada.