ERR_SSL_PROTOCOL_ERROR

Qué significa este error y cómo reconocerlo

• Chrome o Edge muestra “Este sitio no puede proporcionar una conexión segura” con ERR_SSL_PROTOCOL_ERROR.
• El fallo puede afectar a todo el sitio, a un subdominio o únicamente a un hostname detrás de un proxy o load balancer.
• El HTTP plano en el puerto 80 puede funcionar mientras HTTPS falla, lo que indica un problema en la ruta TLS y no necesariamente en la aplicación.
• El error puede comenzar después de renovar un certificado, migrar el servidor, cambiar la configuración del servidor web, modificar la CDN o cambiar el servicio que escucha en el puerto 443.
• Una prueba directa contra el origen y una prueba con el hostname público pueden producir resultados distintos cuando intervienen una CDN, un reverse proxy o un load balancer.

Causas principales, ordenadas por probabilidad

1. El puerto 443 sirve HTTP plano u otro protocolo que no es TLS. Puede faltar el listener HTTPS o el puerto 443 puede estar ocupado por el servicio equivocado. El navegador recibe entonces datos que no corresponden a un handshake TLS.
2. El virtual host HTTPS o el server block es incorrecto. El servidor puede escuchar en la dirección equivocada, seleccionar el hostname incorrecto o no tener las directivas TLS necesarias para el servidor web.
3. La CDN, el reverse proxy o el load balancer tiene una discrepancia con el origen. El proxy puede usar HTTP mientras el origen espera HTTPS, o conectarse al puerto o backend equivocados.
4. La configuración TLS es incompatible o está mal formada. Las versiones de protocolo no compatibles, una configuración restrictiva de cifrados, problemas de enrutamiento SNI o un dispositivo que termina TLS configurado incorrectamente pueden detener el handshake antes de validar el certificado.
5. El certificado o la cadena no son utilizables. Un certificado caducado, la ausencia de un certificado intermedio o un certificado que no cubre el hostname solicitado pueden impedir una conexión segura. Algunos navegadores y rutas de conexión muestran en su lugar una advertencia de certificado más específica.
6. El servicio no cargó un certificado renovado. Actualizar los archivos de certificado en el disco no cambia el certificado presentado por un servidor web en ejecución hasta que su configuración se recarga o se reinicia conforme al procedimiento documentado del servicio.

Cómo solucionarlo

1. Determina si el fallo es público, específico del origen o local

Prueba el hostname exacto que falla desde otra red o dispositivo. Si solo falla un ordenador, comprueba el software de seguridad local, los proxies de interceptación y la hora del sistema. Si fallan todos los clientes, continúa investigando el servidor, el proxy, la CDN o el load balancer.

Si HTTP funciona pero HTTPS no, céntrate en el listener TLS, el puerto 443, la selección del certificado y cualquier proxy entre el cliente y el origen. No des por hecho que el funcionamiento de HTTP demuestra que la configuración HTTPS es correcta.

2. Prueba el handshake TLS sin cambiar el estado del servidor

Desde un terminal administrativo con acceso de red al endpoint, ejecuta:

openssl s_client -connect [your-hostname]:443 -servername [your-hostname] -showcerts

La opción -servername es importante cuando SNI selecciona certificados o virtual hosts. Registra si comienza el handshake, qué certificado se devuelve, la fecha de caducidad del certificado, los hostnames de Subject Alternative Name y si se incluyen certificados intermedios.

• Si la conexión devuelve HTTP plano o falla antes de que aparezca cualquier certificado, inspecciona el listener del puerto 443 y el enrutamiento del proxy.
• Si se devuelve un certificado, compáralo con el hostname solicitado y comprueba sus fechas de validez y su cadena.
• Si una prueba directa contra el origen funciona pero el hostname público falla, inspecciona la CDN, el reverse proxy, el load balancer o la ruta DNS en lugar de cambiar la aplicación.

3. Verifica el listener HTTPS y el enrutamiento del hostname

Con el acceso y la autorización adecuados al servidor, inspecciona la configuración activa del servidor web y confirma que:

• el servicio previsto está escuchando en el puerto 443;
• el server block o virtual host HTTPS está habilitado;
• el hostname solicitado está incluido en los ajustes relevantes de server_name o ServerName/ServerAlias;
• TLS está habilitado para ese listener; y
• las rutas del certificado y de la clave privada apuntan a los archivos previstos.

En Nginx, comprueba el server block habilitado y su configuración listen 443 ssl. En Apache, comprueba la configuración <VirtualHost *:443> y SSLEngine on. No copies directivas entre productos sin comprobar la sintaxis y la versión compatibles con el servidor instalado.

4. Valida el certificado y la cadena

Confirma que el certificado presentado:

• no ha caducado ni es inválido prematuramente;
• cubre el hostname exacto en sus entradas de Subject Alternative Name;
• coincide con la clave privada correspondiente; y
• está acompañado por la cadena de certificados intermedios necesaria.

Un certificado para el dominio raíz no cubre automáticamente todos los subdominios. El subdominio debe aparecer explícitamente o estar cubierto por un certificado wildcard adecuado. Si el servidor solo presenta el certificado leaf, instala el archivo de cadena proporcionado por la autoridad certificadora en el formato requerido por el servidor web.

5. Comprueba la renovación y la carga del certificado

En un despliegue gestionado con Certbot, un administrador puede ejecutar certbot renew --dry-run para probar el flujo de renovación sin emitir un certificado para producción. Revisa la salida, la configuración de renovación, los permisos y el hook de recarga del servicio.

Si la renovación se completó correctamente pero los clientes siguen recibiendo el certificado anterior, confirma que el servidor web o el proxy que termina TLS ha cargado los archivos nuevos. Una recarga o un reinicio cambia el estado del servicio y solo debe realizarse durante una ventana de mantenimiento aprobada, con un plan de reversión y siguiendo el procedimiento documentado del producto. Mantén esta acción operativa separada de los diagnósticos de solo lectura.

6. Inspecciona la configuración TLS de la CDN, el proxy y el load balancer

Identifica dónde termina TLS: en la CDN, el edge proxy, el load balancer o el servidor de origen. Verifica que el protocolo y el puerto de origen configurados coincidan con lo que realmente sirve el origen.

Si una CDN ofrece modos como Flexible, Full o Full (strict), selecciona el modo que coincida con la configuración real del origen y la validez de su certificado. Un modo menos estricto puede ocultar el problema subyacente o crear un fallo diferente; no es un sustituto duradero de un certificado de origen válido. Realiza cambios de configuración únicamente con autorización y vuelve a probar tanto el hostname público como la ruta al origen cuando sea posible.

7. Comprueba la interferencia de protocolos, SNI o dispositivos de red

Si el endpoint presenta un certificado válido que coincide, pero el handshake sigue fallando, compara los resultados desde distintas redes y con distintos clientes TLS. Revisa la configuración del firewall, el load balancer, el web application firewall y la inspección TLS para detectar versiones de protocolo bloqueadas, políticas de cifrado no compatibles, enrutamiento SNI incorrecto o tráfico alterado. Conserva la salida del handshake y los logs relevantes del servidor para el proveedor de hosting o el administrador de red.

Prevención y cómo verificar la solución

• Supervisa la caducidad de los certificados de forma independiente del mecanismo de renovación y genera alertas antes de que dejen de ser válidos.
• Prueba la renovación en un flujo que no sea de producción o mediante un dry run, y verifica que el hook de recarga del servicio realmente presente el certificado nuevo.
• Mantén un inventario documentado de cada hostname, punto de terminación TLS, certificado, clave privada y cadena intermedia.
• Después de cambiar certificados, proxies, load balancers o mapeos de puertos, prueba el hostname público y cada subdominio importante.
• Revisa los cambios de configuración TLS para comprobar la compatibilidad de SNI, versiones de protocolo, cifrados y puertos de origen antes del despliegue.
• Conserva los detalles recientes del servidor, el proxy y los certificados para poder comparar un handshake fallido con la última configuración conocida como correcta.

Preguntas frecuentes