"Your connection is not private": un certificado TLS vencido

En el momento en que un certificado pasa su fecha notAfter, los navegadores muestran una pantalla de advertencia en tu sitio (NET::ERR_CERT_DATE_INVALID), los clientes de API lanzan CERT_HAS_EXPIRED, el monitoreo se pone en rojo y las apps móviles fallan de formas que los usuarios no pueden eludir. No se rompió nada de la clave privada ni del servidor: solo venció la ventana de validez.

Por qué ocurre

Con certificados de Let's Encrypt de 90 días, el vencimiento significa que la automatización de la renovación falló hace semanas y nadie lo notó. Los sospechosos habituales: el desafío ACME HTTP-01 se rompió tras un cambio de proxy o redirección; el token de la API para DNS-01 venció; el temporizador o cron de renovación sencillamente no se está ejecutando; o el certificado se renovó en disco pero el servicio nunca lo recargó (nginx y postfix conservan el archivo antiguo en memoria). Las configuraciones con comodín también fallan cuando se rotan las credenciales del proveedor de DNS.

Diagnostícalo

Ejecuta la verificación de HTTPS/TLS de abajo: muestra la fecha de vencimiento exacta, la cadena completa entregada (un intermedio ausente se ve parecido para los usuarios), qué nombres cubre el certificado y el protocolo negociado. Si la verificación muestra un certificado nuevo pero los navegadores siguen dando error, el servicio está entregando un archivo antiguo: recárgalo.

Corrígelo

1. Renueva ahora: certbot renew --force-renewal (o el equivalente de tu cliente ACME) y recarga el servicio.

2. Corrige la automatización de fondo: ejecuta certbot renew --dry-run hasta que pase sin errores.

3. Confirma el gancho de recarga: la renovación debe terminar con systemctl reload nginx (o la recarga del demonio que uses).

4. Agrega un monitor de vencimiento de certificados con alertas a 30/14/7/1 días para que, si la automatización vuelve a fallar, te avise a ti y no a tus usuarios.