ERR_SSL_PROTOCOL_ERROR: qué significa y cómo solucionarlo

Qué significa ERR_SSL_PROTOCOL_ERROR

Una conexión TLS empieza con un handshake: el cliente envía un ClientHello listando las versiones de protocolo y los conjuntos de cifrado que admite, y se supone que el servidor responde con un ServerHello eligiendo uno de ellos, seguido de su certificado. ERR_SSL_PROTOCOL_ERROR salta cuando ese intercambio se rompe antes de llegar al paso del certificado, casi siempre porque lo que respondió en el puerto no hablaba TLS en absoluto, o porque las dos partes no lograron ponerse de acuerdo en cómo hablarlo. Este es el término de búsqueda de código de error con más tráfico de Chrome, y ese volumen refleja cuántas causas raíz distintas colapsan en el mismo mensaje genérico en lugar de tratarse de un único fallo habitual.

Cómo aparece el error

Chrome y Edge muestran ERR_SSL_PROTOCOL_ERROR sin ningún detalle de certificado, porque nunca llegó a presentarse ninguno que mostrar. Firefox suele mostrar "Secure Connection Failed" con un código como SSL_ERROR_RX_MALFORMED_HANDSHAKE o SSL_ERROR_PROTOCOL_VERSION_ALERT según cómo se haya roto el handshake.

Desde la línea de comandos, tanto curl como openssl identifican el fallo con precisión, que es la forma más rápida de dejar de adivinar:

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" casi siempre significa que el puerto 443 respondió con HTTP plano, no con TLS, ya que los primeros bytes de una respuesta HTTP parecen basura a un analizador TLS que espera un ServerHello. Una conexión que se queda colgada y agota el tiempo de espera sin ningún error, en lugar de fallar rápido, suele significar que un firewall o un proxy está descartando los paquetes en silencio en lugar de que el servidor los rechace activamente.

Qué causa ERR_SSL_PROTOCOL_ERROR

• El puerto 443 está sirviendo HTTP plano, o directamente el servicio equivocado. Un proxy inverso mal configurado, un servicio caído que dejó atrás un listener de reserva, o una regla NAT que apunta al backend equivocado, todos producen una respuesta que no es TLS en el puerto TLS.
• Desajuste de versión de TLS o de cifrado. Un servidor bloqueado en TLS 1.0 o 1.1 por compatibilidad heredada no comparte ningún protocolo común con un navegador que exige TLS 1.2 o superior, así que el handshake falla directamente.
• Falta o está mal configurado el Server Name Indication (SNI). En un servidor que aloja varios certificados en una sola IP, una coincidencia de SNI ausente puede hacer que presente el certificado equivocado o rechace el handshake.
• Experimentos con QUIC y HTTP/3. Chrome a veces prueba QUIC primero y cae de vuelta a TLS sobre TCP; una red que gestiona mal el tráfico UDP de QUIC puede manifestarse como un error de protocolo en el intento de reserva.
• Escaneo HTTPS de un antivirus o un proxy corporativo. El software que intercepta TLS para inspeccionar el tráfico inicia su propio handshake en lugar del real, y un certificado de interceptación roto rompe ese sustituto.
• HSTS forzando HTTPS en un host cuyo TLS está roto. Una vez que un navegador ha guardado en caché una política HSTS para un dominio, no intentará HTTP plano, así que un host que antes caía de vuelta con elegancia ahora falla directamente y sin remedio.
• Una cadena de certificados vieja o rota, en un cliente antiguo. Sistemas operativos y navegadores muy antiguos, anteriores a una raíz o un intermedio más nuevos, pueden fallar el handshake de formas indistinguibles de un desajuste de versión.
• El reloj del cliente está muy desviado. Un reloj lo bastante desajustado puede hacer que un cliente se niegue a negociar sesión alguna, no solo a rechazar el certificado después.

Cómo saber de quién es la culpa

Ejecuta la misma petición desde una segunda red, por ejemplo un teléfono con datos móviles en lugar del wifi de la oficina. Si el sitio carga sin problemas ahí, el problema es local: un proxy corporativo, la interceptación de un antivirus, o un portal cautivo en la primera red. Si el handshake falla igual en todos los sitios donde lo pruebas, la causa es la configuración TLS del servidor. Una comprobación SSL ejecutada desde varias ubicaciones a la vez responde a esto en una sola petición en lugar de tener que pedir prestado un segundo dispositivo, y reporta el protocolo y el cifrado exactos que negoció (o rechazó) el servidor desde cada punto de vista.

Cómo corregir ERR_SSL_PROTOCOL_ERROR

Si eres un visitante

1. Borra el estado TLS de Chrome en chrome://net-internals/#hsts y chrome://restart, o simplemente borra los datos de navegación de "imágenes y archivos en caché" más "cookies y datos de sitios" para el sitio afectado, lo que también borra el estado en caché de HSTS y de sesión SSL.
2. Desactiva el experimento de QUIC en chrome://flags/#enable-quic, ponlo en Disabled, y reinicia el navegador. Si el sitio carga después, la causa era una red o un proxy poco compatibles con QUIC.
3. Comprueba la fecha y la hora del sistema y configúralas para que se sincronicen automáticamente; un reloj lo bastante desviado puede romper el handshake directamente, no solo la comprobación del certificado que viene después.
4. Desactiva el escaneo HTTPS en tu antivirus (habitualmente en un ajuste tipo "protección web" o "escaneo SSL/TLS") y vuelve a intentarlo. Si eso lo arregla, actualiza el antivirus o añade el sitio a su lista de exclusiones en lugar de dejar el escaneo desactivado por completo.
5. Prueba otra red, como datos móviles. Un proxy corporativo o una pieza de hardware de red rota que solo afecta a una conexión es una causa habitual que no tiene nada que ver con el propio sitio.

Si administras el sitio

1. Confirma que el puerto 443 realmente es TLS con el comando openssl de arriba. "Wrong version number" o una respuesta en texto plano significan que el servicio equivocado está enlazado a ese puerto; arregla el proxy o la configuración del listener antes de tocar siquiera los certificados.
2. Fija explícitamente las versiones de protocolo admitidas. En nginx:

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

   Eliminar TLS 1.0 y 1.1 arregla los handshakes de clientes modernos pero romperá el acceso de clientes muy antiguos que todavía dependen de ellos; decide esa compensación de forma deliberada y no por accidente.
3. Confirma que el bloque de servidor realmente escucha TLS en el puerto que esperas: listen 443 ssl; (o listen 443 ssl http2;) y que las directivas de certificado y clave apuntan a archivos que existen y coinciden entre sí.
4. Revisa el orden de la cadena de certificados. El certificado hoja debe ir primero, seguido de los intermedios en orden hasta (sin incluirla) la raíz; una cadena servida desordenada o a la que le falta un intermedio causa fallos de handshake en algunos clientes mientras funciona en otros que tienen el intermedio que falta en caché desde otro sitio.
5. Si el dominio está detrás de Cloudflare, revisa el modo SSL/TLS. El modo Flexible termina TLS en el borde y habla HTTP plano con el origen, lo que falla directamente si el origen solo acepta HTTPS; el modo Full exige cualquier certificado en el origen; el modo Full (strict) exige un certificado válido y de confianza en el origen y él mismo producirá fallos de handshake si el certificado del origen es autofirmado o ha caducado.
6. Recarga, no te limites a editar, después de cualquier cambio de configuración: nginx -t && systemctl reload nginx valida la configuración antes de aplicarla.

ERR_SSL_PROTOCOL_ERROR frente a errores de aspecto similar

• ERR_CERT_DATE_INVALID ocurre después de recibir y leer un certificado; el handshake llegó hasta ahí y luego falló una comparación de fecha. ERR_SSL_PROTOCOL_ERROR nunca llega tan lejos.
• ERR_CERT_AUTHORITY_INVALID también ocurre después de recibir un certificado; el navegador lo leyó y no confió en quien lo firmó. De nuevo, un error de protocolo significa que nunca se llegó a juzgar ningún certificado.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH es el hermano más específico de este error: salta cuando el handshake sí avanzó lo suficiente como para comparar versiones y cifrados admitidos, y no encontró ningún solapamiento en absoluto, típicamente un servidor antiguo que solo ofrece SSLv3 o TLS 1.0 frente a un navegador moderno que los rechaza. ERR_SSL_PROTOCOL_ERROR es el fallo más amplio y menos específico que cubre todo lo demás, incluida una respuesta que no es TLS en el puerto, datos de handshake mal formados, y software de interceptación que se ha estropeado.

Cómo prevenir ERR_SSL_PROTOCOL_ERROR

Un fallo de handshake introducido por un cambio de configuración, una actualización de un proxy, o un cambio de modo SSL en Cloudflare no aparece en una comprobación normal de estado HTTP, ya que la conexión nunca llega lo bastante lejos como para producir una. Una comprobación SSL dedicada lee directamente el protocolo y el cifrado negociados y, ejecutada desde más de 300 puntos de control en 158 ciudades, muestra si el handshake falla en todas partes o solo desde una red, la misma distinción que esta guía recorre a mano. Ejecuta una comprobación de certificado SSL contra el dominio, y configura la monitorización continua de SSL y caducidad de dominio para que un handshake roto alerte antes de que los visitantes lo reporten.

Preguntas frecuentes

¿ERR_SSL_PROTOCOL_ERROR significa que mi certificado está mal?

No necesariamente. El error salta antes de que el navegador llegue al certificado, así que el certificado en sí puede estar perfectamente bien mientras la negociación TLS subyacente sigue fallando.

¿Por qué ocurre esto solo en un ordenador o en una red?

El escaneo HTTPS de un antivirus, un proxy corporativo, o una ruta QUIC rota en esa red concreta son los motivos habituales de que un handshake falle en un sitio y funcione en todos los demás. Probar desde una segunda red es la forma más rápida de confirmarlo.

Acabo de poner mi sitio detrás de Cloudflare y ahora los visitantes ven esto. ¿Qué cambió?

Revisa el modo SSL/TLS en el panel. El modo Flexible espera que el origen acepte HTTP plano y falla si solo sirve HTTPS; el modo Full (strict) espera un certificado de origen válido y de confianza y falla ante uno autofirmado o caducado.

¿Desactivar TLS 1.0 y 1.1 en mi servidor rompe algo?

Puede hacerlo, para visitantes con navegadores muy antiguos que nunca recibieron una actualización a TLS 1.2. Para la mayoría del tráfico actual arregla más handshakes de los que rompe, pero revisa primero tu propia mezcla de clientes.

¿Por qué curl dijo "wrong version number"?

Ese mensaje significa que curl envió un ClientHello TLS y recibió bytes que no se interpretan como un ServerHello TLS, casi siempre porque el puerto está sirviendo HTTP plano u otro protocolo que no es TLS.