ERR_SSL_PROTOCOL_ERROR: la conexión segura falla antes del certificado

Qué significa el error

Una conexión HTTPS empieza con un saludo: el navegador propone versiones de TLS y cifrados, el servidor elige y presenta su certificado. ERR_SSL_PROTOCOL_ERROR significa que ese saludo se rompió. Chrome muestra « Este sitio no puede proporcionar una conexión segura »; Firefox, « Error de conexión segura » con SSL_ERROR_RX_RECORD_TOO_LONG o SSL_ERROR_NO_CYPHER_OVERLAP. A diferencia de « La conexión no es privada », el navegador ni siquiera llegó a evaluar el certificado: no entendió lo que el servidor envió, o no encontró ninguna versión ni cifrado en común.

Las causas están casi siempre en el servidor; los pocos casos del visitante se descartan en un minuto.

Causas frecuentes

1. Solo TLS antiguo. El servidor acepta únicamente TLS 1.0 o 1.1, que los navegadores actuales ya no negocian.
2. Cifrados obsoletos. La lista de cifrados excluye todo lo que el navegador propone, por ejemplo tras copiar una configuración antigua.
3. Certificado y clave no coinciden. Tras una renovación, ssl_certificate apunta al certificado nuevo y ssl_certificate_key a la clave vieja. nginx suele negarse a arrancar; Apache a veces arranca y falla en cada conexión.
4. El puerto 443 habla HTTP. Falta ssl en la línea listen, o un servicio sin TLS se quedó en el 443. El navegador recibe texto plano donde esperaba TLS.
5. Proxy o CDN en el modo equivocado. Un proxy delante reenvía al origen por HTTPS, pero el origen solo habla HTTP (o al revés), o el modo SSL del CDN no corresponde al servidor.
6. SNI o vhost incorrecto. El servidor no tiene ningún bloque con certificado para ese nombre y responde con el de otro sitio, o con ninguno.

Si eres visitante

1. Comprueba la fecha y la hora del dispositivo.
2. Desactiva un momento la inspección HTTPS del antivirus, el proxy o la VPN.
3. Vacía la caché SSL y los datos del sitio en el navegador, y prueba en una ventana privada sin extensiones.
4. Prueba http:// en lugar de https://. Si así entra, el fallo está en el HTTPS del sitio y solo el propietario puede corregirlo.
5. Si el error aparece desde otro dispositivo y otra red, no es cosa tuya.

Si es tu sitio: comprobar primero

Abre el SSL Checker: si tampoco desde fuera se logra una conexión TLS, el problema está en el servidor. Después pregunta con openssl, con el dominio como SNI:

# ¿qué negocia el servidor?
openssl s_client -connect example.com:443 -servername example.com </dev/null

# ¿acepta TLS 1.2?
openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

# ¿hay un servidor web escuchando en el 443, y cuál?
sudo ss -tlnp | grep ':443 '
curl -sI http://example.com:443/ --max-time 5

Cómo leer la salida: wrong version number o packet length too long significa que el 443 responde con HTTP (causa 4); no protocols available o handshake failure, que no hay versión ni cifrado en común (causas 1 y 2); key values mismatch en el log de nginx, que certificado y clave no coinciden (causa 3).

Soluciones en tu propio servidor

1. Activar solo TLS 1.2 y 1.3 con cifrados actuales

En nginx:

ssl_protocols TLSv1.2 TLSv1.3;
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;

En Apache (mod_ssl):

SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLHonorCipherOrder off

Después, siempre probar y recargar:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

2. Hacer coincidir certificado y clave

openssl x509 -noout -modulus -in /etc/letsencrypt/live/example.com/fullchain.pem | openssl md5
openssl rsa  -noout -modulus -in /etc/letsencrypt/live/example.com/privkey.pem  | openssl md5

Las dos sumas deben coincidir. Si no, apunta ssl_certificate y ssl_certificate_key a la misma carpeta live/ de certbot (fullchain.pem y privkey.pem) y recarga.

3. Hacer que el 443 hable TLS

El bloque server que escucha en el 443 necesita ssl en la línea listen y un certificado:

listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Si ss -tlnp muestra otro programa en el 443 (una aplicación Node, un panel, un túnel), muévelo a otro puerto o ponlo detrás de nginx.

4. Ajustar el proxy o el CDN

Con un proxy inverso delante, la petición al origen debe usar el protocolo que el origen entiende: proxy_pass http://127.0.0.1:8080; si la aplicación no tiene TLS. En un CDN, el modo SSL debe corresponder al servidor: con certificado válido en el origen, modo completo y estricto. Comprueba primero el origen por su IP con -servername, después el camino por el CDN.

5. Un bloque con certificado para cada nombre

Cada nombre por el que llegan visitantes (example.com, www.example.com, subdominios) necesita un bloque server con server_name y certificado, o un certificado que los cubra todos:

sudo certbot --nginx -d example.com -d www.example.com --expand

Define además un bloque por defecto para el 443 con certificado, para que un nombre desconocido reciba un error de certificado claro y no un saludo roto.

Si el problema está en tu proveedor de hosting

En un hosting compartido, la configuración de TLS es del proveedor. Si el panel de cliente muestra un certificado activo y el error persiste desde fuera, envía esto:

Hola, desde las 7:00 (UTC) aproximadamente los navegadores muestran ERR_SSL_PROTOCOL_ERROR en mi sitio example.com y openssl s_client no completa el saludo TLS en el puerto 443. El panel de cliente muestra un certificado activo y no cambié nada. ¿Pueden comprobar la configuración TLS del servidor y el certificado asignado a mi dominio?

Para que no vuelva a pasar

Un fallo de protocolo aparece casi siempre tras un cambio: una renovación, una actualización del servidor web, una configuración copiada. Una comprobación desde fuera lo ve en el primer intento, antes que tus visitantes. El monitoring de certificados SSL vigila además la expiración, la cadena y los nombres, para que el siguiente aviso no sea el del navegador.

¿Caído? Intervenimos. En tu propio servidor o en un hosting compartido con acceso SSH, la intervención rápida renueva el certificado donde certbot está configurado y recarga el servidor web, a precio fijo, las 24 horas, todos los días; la intervención a fondo corrige la configuración de TLS, el proxy o los vhosts, en bloques de 15 minutos; la estimación es el precio máximo.