ERR_CERT_DATE_INVALID: certificado caducado o reloj mal ajustado

Qué significa ERR_CERT_DATE_INVALID

Todo certificado TLS lleva dos marcas de tiempo, "Valid from" y "Valid to" (los campos X.509 notBefore y notAfter). Durante el handshake, el navegador compara esas marcas de tiempo con su propia idea de la hora actual. Si la ventana del certificado ya se cerró, o todavía no se ha abierto, o el reloj del navegador sitúa el "ahora" fuera de esa ventana por cualquier motivo, el handshake se detiene antes incluso de que el navegador llegue a comprobar quién emitió el certificado. Chrome y Edge muestran NET::ERR_CERT_DATE_INVALID. Firefox muestra SEC_ERROR_EXPIRED_CERTIFICATE para el caso de caducidad. Safari muestra "This certificate has expired" o "This certificate is not yet valid".

Dos situaciones distintas producen exactamente el mismo aviso, y el navegador no puede decirte cuál de las dos es: que el certificado realmente esté caducado o aún no sea válido, o que el certificado esté perfectamente bien y sea el reloj del cliente el que esté mal. Ambas fallan la misma comparación.

Cómo aparece el error

En un navegador, la página nunca llega a cargar y aparece un aviso de pantalla completa en lugar de un icono de error en el candado sobre una página ya cargada. Al pulsar "Advanced" se muestra el motivo concreto y, en Chrome, las propias fechas del certificado.

Desde la línea de comandos, curl reporta el mismo fallo con más precisión:

curl -v https://example.com/
...
* SSL certificate problem: certificate has expired
* Closing connection

Un certificado todavía no válido produce una línea similar que dice "certificate is not yet valid". Los registros del servidor y de la aplicación en el lado del propietario del sitio normalmente no muestran nada para este error, porque el handshake TLS falla antes de que se registre ninguna petición HTTP. La evidencia está en el certificado y en el cliente, no en el registro de acceso del servidor web.

Qué causa ERR_CERT_DATE_INVALID

• El certificado ha caducado. La renovación no ocurrió antes de la fecha "Valid to", casi siempre porque un trabajo de renovación automática dejó de ejecutarse en silencio.
• El certificado todavía no es válido. Menos habitual: un certificado se emitió o reemitió con una fecha "Valid from" ligeramente en el futuro, o un servidor empezó a servir un certificado nuevo antes de que se abriera su ventana.
• Un certificado intermedio de la cadena ha caducado. El certificado hoja puede estar perfectamente vigente mientras un intermedio que el servidor todavía envía ha superado su propia caducidad, y algunos clientes comprueban todos los certificados de la cadena.
• El reloj del dispositivo del visitante está mal. Un portátil que ha estado apagado durante meses, un teléfono con la sincronización horaria automática desactivada, o un dispositivo con la pila de la CMOS agotada pueden arrancar con una fecha desviada años en cualquier dirección.
• Una máquina virtual o un contenedor con un reloj desactualizado. Las VM a las que se les hizo un snapshot, se clonaron o se reanudaron tras una pausa larga arrancan con frecuencia con un reloj que no se pone al día hasta que se completa una sincronización NTP.
• Una zona horaria mal configurada o una fecha manual incorrecta, fijada por un usuario o por un dispositivo tipo quiosco que no tiene fuente de hora propia.

Cómo saber de quién es la culpa

La comprobación más rápida es revisar el certificado desde algún sitio distinto del dispositivo afectado. Si un segundo dispositivo con un reloj sabidamente correcto, o un punto de control fuera de tu propia red, carga el sitio sin aviso de fecha, el certificado está bien y el problema es local al reloj de ese único dispositivo. Si todos los puntos de vista reportan la misma fecha de caducidad o de no-validez, el propio certificado necesita atención. Ejecutar una comprobación SSL desde varias ubicaciones a la vez resuelve esto en un solo paso en lugar de tener que pedir prestado un segundo portátil para probar.

Cómo corregir ERR_CERT_DATE_INVALID

Si eres un visitante

1. Revisa primero la fecha, la hora y la zona horaria de tu dispositivo. Esta es, con diferencia, la causa autoinfligida más habitual, especialmente en dispositivos Android con la sincronización horaria automática desactivada, portátiles antiguos que llevaban tiempo sin usarse, y equipos con una pila de CMOS que falla. Activa "Set time automatically" y confirma que el año es correcto, no solo la esfera del reloj.
2. Prueba el sitio en otro dispositivo o red. Si carga sin problemas en otro sitio, la causa es el reloj de tu dispositivo original (o un portal cautivo interceptando la conexión), no el sitio.
3. Lee las fechas concretas en la página de aviso antes de hacer nada más. Tanto el panel "Advanced" de Chrome como el visor de certificados muestran "Valid from" y "Valid to" en texto plano, lo que te dice de inmediato si el certificado ha caducado, todavía no es válido, o el que está desajustado eres tú con tu reloj.
4. No continúes en un certificado que realmente ha caducado en un sitio que gestione algo sensible. Una vez corregido el reloj, recarga; no te limites a reintentar sobre el mismo estado roto.

Si administras el sitio

1. Lee directamente las propias fechas del certificado en lugar de fiarte de un recordatorio en el calendario:

   openssl s_client -connect example.com:443 -servername example.com /dev/null   | openssl x509 -noout -dates

   Esto imprime notBefore y notAfter directamente del certificado que el servidor está presentando ahora mismo.
2. Si usas Let's Encrypt, revisa el trabajo de renovación, no solo el certificado. Los certificados de Let's Encrypt duran 90 días por diseño y se renuevan automáticamente en torno a la marca de los 30 días, pero la automatización puede fallar en silencio durante semanas antes de que nadie se dé cuenta: systemctl status certbot.timer (o la entrada de cron equivalente) confirma que el timer sigue activado y disparándose, y certbot renew --dry-run ejecuta la ruta de renovación sin cambiar nada en producción. Lee /var/log/letsencrypt/letsencrypt.log para ver el fallo real, que casi siempre es uno de estos: un desafío DNS-01 cuyas credenciales de API caducaron, un cambio de firewall que bloquea la ruta del desafío HTTP-01, o haber alcanzado los límites de tasa de Let's Encrypt durante pruebas repetidas.
3. Revisa la cadena completa que envía tu servidor, no solo el certificado hoja:

   openssl s_client -connect example.com:443 -servername example.com -showcerts /dev/null   | openssl x509 -noout -dates -in -

   Algunos servidores siguen sirviendo desde disco un certificado intermedio antiguo después de haber sustituido la hoja. Cada certificado de la cadena necesita una ventana de validez vigente, ya que algunos clientes validan toda la ruta.
4. Verifica el propio reloj del sistema del servidor. Un servidor con la hora equivocada puede emitir renovaciones automáticas con una fecha "Valid from" incorrecta, y también puede fallar su propia validación OCSP y del handshake con independencia del certificado. Confirma que NTP está en marcha y sincronizado.
5. Renueva o reemite el certificado, y luego recarga el servidor web. Un certificado renovado que se queda en disco no hace nada hasta que el proceso que sirve TLS lo recoge: nginx -s reload, systemctl reload apache2, o el equivalente para un balanceador de carga o un borde de CDN que guarde su propia copia.
6. Confirma la solución desde fuera de tu propia infraestructura después de recargar, ya que un navegador o un sistema operativo en tu propia máquina puede tener en caché el certificado antiguo durante una sesión.

Cómo prevenir ERR_CERT_DATE_INVALID

Un certificado a punto de caducar no da ningún aviso a quien no esté vigilándolo específicamente: el sitio sigue funcionando hasta el segundo exacto en que se cierra la ventana, y entonces todos los visitantes ven el mismo aviso a la vez. Una comprobación SSL programada que lee las fechas del certificado y alerta antes del plazo, en lugar de después de que los visitantes empiecen a reportar un sitio roto, convierte un fallo de renovación silencioso en un ticket solucionable con días de margen. Las comprobaciones de SSL y caducidad de dominio de HostTracker siguen la ventana de validez real del certificado desde fuera de tu infraestructura y alertan por correo, SMS, llamada de voz, Slack, Telegram y más antes de que expire; ejecuta una ahora con la comprobación de certificado SSL. La guía complementaria sobre cómo comprobar la caducidad de un certificado SSL explica esa configuración con más detalle.

Errores relacionados

• ERR_CERT_AUTHORITY_INVALID - las fechas del certificado están bien, pero el navegador no confía en quien lo emitió.
• ERR_CERT_COMMON_NAME_INVALID - el certificado es válido y de confianza, pero no se emitió para el nombre de host de la barra de direcciones.
• ERR_SSL_PROTOCOL_ERROR - el handshake falló antes de llegar siquiera a ningún certificado, normalmente por un desajuste de versión de TLS, de puerto o de configuración.

Preguntas frecuentes

¿Es seguro continuar tras un aviso ERR_CERT_DATE_INVALID?

Solo si estás seguro de que la causa es el reloj de tu propio dispositivo, ya que eso lo puedes verificar de forma independiente. Si el certificado en sí ha caducado de verdad, continuar elimina la única comprobación que confirma que estás hablando con el servidor real por un canal cifrado y verificado.

¿Por qué ocurre esto justo después de resetear o desempaquetar un dispositivo?

Un reinicio de fábrica o un dispositivo que llevaba mucho sin usarse a menudo arranca con su reloj interno reseteado a una fecha por defecto, a veces años en el pasado. Hasta que se conecta a internet y sincroniza la hora automáticamente, cualquier sitio HTTPS puede fallar con un error de fecha, no solo uno.

¿Borrar la caché del navegador arregla ERR_CERT_DATE_INVALID?

Rara vez. Este error es una comparación en vivo entre las fechas del certificado y el reloj actual, evaluada de nuevo en cada conexión, así que borrar la caché no cambia el resultado. Corregir el reloj o el certificado sí.

¿Por qué caducó mi certificado de Let's Encrypt sin ningún aviso?

Porque la renovación está pensada para ser totalmente automática, nadie la revisa a mano, así que un cron roto, una credencial de API de DNS caducada, o un cambio de regla de firewall pueden detener las renovaciones en silencio durante semanas sin ningún síntoma visible hasta que el certificado realmente expira.

¿Puede un CDN o un balanceador de carga cambiar lo que ven los visitantes con este error?

Sí. Si el borde del CDN tiene un certificado caducado, todos los visitantes ven el error al margen del certificado que tenga el servidor de origen, así que revisa la capa que realmente termina TLS para la petición que falló.

¿Con qué frecuencia debería comprobar la fecha de caducidad de mi certificado?

Una comprobación automatizada diaria basta para detectar un fallo de renovación con semanas de margen, ya que los certificados de Let's Encrypt son válidos 90 días y la mayoría de los demás certificados duran entre 90 días y un año.