Qué significa ERR_SSL_PROTOCOL_ERROR, y por qué no dice de quién es la culpa

Alguien le dice que su sitio no carga y le manda un código: ERR_SSL_PROTOCOL_ERROR. A usted le funciona. A todos en la oficina les funciona. La página que esa persona está mirando es gris, tiene unas dos frases y no ofrece nada más.

Esta es la descripción que Chromium da de ese error, en el archivo donde se define cada error de red de Chrome:

An SSL protocol error occurred.

Ese es el comentario completo. Cinco palabras, para el error número -107. No es una versión recortada de algo más largo; es todo lo que el navegador tiene.

Es el código que Chrome usa cuando no puede ser más concreto

Lo que hace que eso importe es lo que lo rodea en esa misma lista.

Unas líneas más abajo está ERR_SSL_VERSION_OR_CIPHER_MISMATCH, el número -113, y su descripción es precisa: “The client and server don’t support a common SSL protocol version or cipher suite.” Más allá hay todo un rango para certificados, donde ERR_CERT_COMMON_NAME_INVALID, el número -200, lleva cuatro causas con nombre, incluida aquella en la que la persona está en una red inalámbrica y la están redirigiendo a la página de acceso de la red.

Así que Chrome tiene códigos más concretos para los fallos que puede atribuir. Recibir -107 en su lugar significa que el handshake falló de una forma a la que el navegador no supo poner nombre.

Esto es lo contrario de cómo se trata este error habitualmente. Toda guía sobre él es una lista de ocho cosas que probar, y la longitud de la lista es la señal: nadie que escriba una sabe cuál de las ocho se aplica, porque el error no lo dice.

Qué falla en realidad, y qué poco de eso es suyo

La propia página de resolución de problemas de Cloudflare para este error enumera lo que ellos ven detrás. Su resumen es que el handshake falló, y las razones que nombran son:

• Un problema de certificado, como un certificado que todavía no está activo, o un subdominio de varios niveles que el certificado presente no cubre.
• Una suite de cifrado que no coincide, donde, en sus palabras, los clientes antiguos pueden no admitir las suites de cifrado modernas.
• HTTP/3 y QUIC bloqueados, por una red, un cortafuegos o un dispositivo que no transporta QUIC sobre UDP.
• TLS 1.3 no admitido del todo por dispositivos de seguridad de red que hacen inspección SSL.
• Interferencia en la red: inspección profunda de paquetes, proxies que interceptan, controles parentales, NAT de operador.

Esa es la visión de un CDN desde su propia cola de soporte y no una taxonomía completa, y sigue siendo la lista más útil que hay, por cómo se reparte.

Cuente de quién es cada una. La primera es suya. La segunda es del navegador o del sistema operativo de quien informa. La tercera, la cuarta y la quinta son de equipos y software que están entre esa persona y usted: su router, el aparato de inspección de su empresa, su antivirus, su proveedor de internet.

Una de cinco está de su lado, y el texto del error es idéntico en todas.

Por eso el informe llega inservible

“Su sitio está roto, ERR_SSL_PROTOCOL_ERROR” es una descripción completa de lo que esa persona puede ver y no le dice casi nada. La siguiente pregunta obvia, si le pasa solo a ella, es justamente la que usted no puede responder desde donde está: su máquina está en otra red, detrás de otro hardware, con otro software de seguridad, y negociando posiblemente con otro nodo de borde.

Es el mismo problema que distinguir su error de la caída de otro, y tiene la misma propiedad: la prueba que lo resolvería existe solo en la máquina de esa persona y solo mientras está pasando.

No es el aviso de certificado, y la diferencia es grande

Si quien informa describe una página roja que le advierte de que la conexión no es privada, con un código que empieza por ERR_CERT_, ese es otro error y mucho más manejable: esos códigos dicen su motivo, y cuál de los cinco es se puede resolver en un minuto.

ERR_SSL_PROTOCOL_ERROR no tiene esa página ni ese motivo. Vale la pena establecer cuál de los dos vio en realidad antes de gastar una tarde en el equivocado, y la vía más rápida es pedir la captura en lugar de la descripción.

Las dos pruebas que reparten el problema

La página de Cloudflare cierra su propio consejo diciendo que hay que recoger datos de diagnóstico de los visitantes afectados, que es la forma honesta de la respuesta. Antes de eso, hay dos cosas que quien informa puede hacer en un minuto y que acotan más que cualquier cosa que usted pueda ejecutar.

Pídale que lo pruebe con datos móviles, con el wifi apagado. Si carga, el problema está entre su red y usted, y ningún cambio en su servidor lo va a arreglar para esa persona. Si sigue fallando, su red no es la causa.

Pídale que pruebe otro navegador en la misma máquina. Si ahí carga, la causa es su navegador: su soporte de protocolos, su propio almacén de certificados, o una extensión que se le pone delante. Si falla en los dos, está implicada la máquina o su red, y no el navegador.

Esas dos respuestas juntas cubren cuatro de las cinco causas de arriba y le cuestan a quien informa unos noventa segundos. Lo que conviene tener anotado al lado: la URL completa, si se escribió http o https, el código exacto, la hora, y si algo más estaba fallando en ese mismo momento.

El caso que es suyo y parece de ellos

Hay un patrón que merece conocerse porque produce exactamente este error de su lado mientras parece un problema del cliente. Un certificado válido pero que todavía no está activo, porque su fecha de inicio está en el futuro, hace fallar el handshake en lugar de producir una página de aviso, y falla para todo el mundo que tenga el reloj en hora. Lo mismo ocurre con un host que está un nivel más abajo de lo que cubre el certificado: app.eu.example.com contra un certificado emitido para *.example.com no está cubierto, porque un comodín coincide con una etiqueta.

Las dos cosas son su arreglo, las dos llegan como este error, y ninguna se distingue de un problema de dispositivo intermedio sin comprobar el certificado que su borde está sirviendo de verdad.

Qué quedarse de todo esto

ERR_SSL_PROTOCOL_ERROR no es un diagnóstico. Es su ausencia, y Chromium dice exactamente eso en cinco palabras. Tómelo como el navegador diciéndole que un handshake falló y que no pudo averiguar por qué, y ponga entonces su esfuerzo en las dos preguntas que reparten las causas, en vez de en la lista de ocho arreglos de los que siete nunca iban a aplicarse.