Qué significa «La conexión no es privada» y cómo solucionarlo

Qué significa el error

El navegador se conectó, el servidor presentó su certificado y el navegador se negó a confiar en él. Chrome muestra « La conexión no es privada » con un código de error (en versiones anteriores, « Tu conexión no es privada » o « Su conexión no es privada »); Firefox dice « Advertencia: riesgo potencial de seguridad a continuación »; Safari, « Esta conexión no es privada ». El sitio no está hackeado y tu dispositivo no está infectado: el certificado que envía el servidor no pasa las comprobaciones del navegador.

El código de error dice qué comprobación falló:

• NET::ERR_CERT_DATE_INVALID: el certificado expiró o todavía no es válido (o el reloj del visitante está mal).
• NET::ERR_CERT_COMMON_NAME_INVALID: el certificado sirve para otro nombre, por ejemplo www.example.com pero no example.com.
• NET::ERR_CERT_AUTHORITY_INVALID: ninguna autoridad de confianza lo respalda: autofirmado, emisor desconocido o certificado intermedio que falta.
• NET::ERR_CERT_REVOKED: el emisor revocó el certificado.
• SSL_ERROR_BAD_CERT_DOMAIN y SEC_ERROR_EXPIRED_CERTIFICATE: las variantes de Firefox para el nombre y la fecha.

Causas frecuentes

1. El certificado expiró. La renovación automática de Let's Encrypt llevaba semanas fallando sin que nadie lo viera, o el recordatorio del certificado comprado llegó a una dirección de correo antigua.
2. Renovado, pero sin recargar. certbot escribió el certificado nuevo en el disco, pero el servidor web sigue sirviendo el viejo porque falta el hook de recarga.
3. Nombre equivocado. El certificado cubre example.com, pero los visitantes llegan por www.example.com, o un subdominio no tiene certificado.
4. Falta el certificado intermedio. El servidor envía solo su propio certificado, no la cadena. Los navegadores de escritorio suelen completar el hueco; los teléfonos y las aplicaciones fallan.
5. Un problema de reloj. En el visitante, una fecha incorrecta hace que todos los certificados parezcan expirados. En el servidor, rompe la renovación.
6. Un CDN o un proxy delante, con su propio certificado expirado o sin el nombre correcto, mientras el servidor de origen está en orden.

Si eres visitante

Revisa primero la fecha y la hora de tu dispositivo; con la sincronización desactivada fallan todos los sitios. Prueba después desde otra red. Si el aviso aparece solo en un sitio, desde cualquier dispositivo, el problema es el certificado del sitio: el propietario tiene que corregirlo. Hacer clic en « Acceder a … (sitio no seguro) » sirve para un sitio que conoces, nunca para uno con contraseñas o pagos.

Si es tu sitio: comprobar primero

Abre el SSL Checker: fecha de expiración, nombres cubiertos y cadena completa o no, desde fuera y sin caché del navegador. Después, en tu propio servidor:

# ¿qué envía el servidor?
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# ¿qué hay en el disco?
sudo certbot certificates

# ¿va bien el reloj?
timedatectl

¿Fechas más recientes en el disco que en la respuesta del servidor? Estás en el caso 2: renovado, pero sin recargar.

Soluciones en tu propio servidor

1. Renovar con certbot

sudo certbot renew
# si renew responde « not yet due » mientras el servidor sirve un certificado viejo:
sudo certbot renew --force-renewal
sudo systemctl reload nginx     # o apache2

Si la renovación falla, el motivo está en la salida. Los clásicos: el puerto 80 está bloqueado o redirigido (el desafío HTTP-01 debe llegar a /.well-known/acme-challenge/ por HTTP simple), el DNS apunta a otro sitio, o se aplica un límite tras demasiados fallos. Corrige la causa y lanza sudo certbot renew --dry-run hasta que pase.

2. Automatizar la recarga

# certbot instala un temporizador; compruébalo
systemctl list-timers | grep certbot

# hook para que el servidor web tome el certificado nuevo
echo 'systemctl reload nginx' | sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-web.sh

3. Incluir el nombre que falta

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

--expand sustituye el certificado existente por uno que cubre todos los nombres indicados.

4. Reparar la cadena

Con certbot, el servidor web debe apuntar a fullchain.pem, nunca a cert.pem:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Apache: SSLCertificateFile con fullchain.pem. Para un certificado comprado, descarga el « CA bundle » del emisor y pégalo al final del archivo. Prueba con sudo nginx -t, recarga y verifica la cadena con el SSL Checker.

5. Poner el reloj en hora

sudo timedatectl set-ntp true
timedatectl

Un reloj que se desvía más de unos minutos hace fallar la verificación de los certificados en ambos sentidos.

6. Hosting compartido o creador de sitios

La mayoría de los proveedores de hosting emiten y renuevan los certificados de Let's Encrypt desde el panel de cliente. Comprueba ahí que el certificado cubre example.com y www.example.com, y haz clic en renovar. Si el panel muestra un certificado válido mientras los navegadores dicen lo contrario, el problema de recarga o de cadena está en el proveedor de hosting.

Si el problema está en tu proveedor de hosting

Hola, desde las 6:00 (UTC) aproximadamente los navegadores muestran « La conexión no es privada » (NET::ERR_CERT_DATE_INVALID) en mi sitio example.com. El panel de cliente muestra un certificado válido, así que el servidor parece servir el antiguo. ¿Pueden recargar el certificado y comprobar la renovación automática de mi dominio?

Para que no vuelva a pasar

Un certificado expirado es la única caída con fecha conocida de antemano. El monitoring de certificados SSL te avisa antes de que expire, y también si la cadena o el nombre no son correctos; el plan gratuito incluye comprobaciones SSL. ¿El navegador no llega ni a leer el certificado y muestra ERR_SSL_PROTOCOL_ERROR? Es otro caso: la conexión segura falla antes del certificado. ¿Y si el servidor rechaza directamente la conexión en el puerto 443? Entonces es un ERR_CONNECTION_REFUSED.

¿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 pone en marcha la renovación donde falta, en bloques de 15 minutos; la estimación es el precio máximo.