ERR_CERT_DATE_INVALID: qué significa y cómo solucionarlo

NET::ERR_CERT_DATE_INVALID es la forma en que Chrome avisa de que el certificado del sitio web no es válido en este momento: o bien el certificado ha caducado (o aún no es válido), o bien el reloj de tu propio dispositivo está mal ajustado y un certificado perfectamente correcto parece caducado. Los datos del propio Google muestran que la segunda causa es mucho más frecuente de lo que la mayoría cree: en Windows, un reloj del sistema incorrecto está detrás del 33,5 % de todos los avisos de certificado de Chrome, frente al 4,23 % de certificados realmente caducados (Acer et al., ACM CCS 2017). Esta guía te enseña a distinguir ambos casos en menos de un minuto, a corregir cada uno como visitante o como propietario del sitio, y a evitar que el error vuelva.

Qué significa realmente NET::ERR_CERT_DATE_INVALID

Todo certificado TLS lleva dos marcas de tiempo: una fecha de inicio (notBefore) y una fecha de fin (notAfter). Cuando Chrome, Edge o cualquier navegador basado en Chromium abre una conexión HTTPS, compara esas dos fechas con la hora actual según tu dispositivo. Si "ahora" queda fuera de esa ventana, el navegador se niega a confiar en el certificado y muestra un aviso a página completa con el código NET::ERR_CERT_DATE_INVALID.

Solo hay tres maneras de quedar fuera de la ventana, y cada una señala a personas distintas:

Otros navegadores informan de la misma condición con otros nombres. Firefox usa SEC_ERROR_EXPIRED_CERTIFICATE para un certificado caducado y MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE para uno cuya fecha de inicio todavía está en el futuro. Safari muestra "Esta conexión no es privada" y solo menciona la caducidad en los detalles. Las soluciones de abajo sirven para todos.

¿Visitante o propietario del sitio? Averígualo en 30 segundos

Antes de cambiar nada, determina qué lado de la conexión falla:

1. Abre dos o tres sitios HTTPS distintos. Si todos muestran el mismo aviso, el problema está en tu dispositivo, casi con seguridad en su reloj. Si solo falla un sitio, el problema está en ese servidor.
2. Mira la fecha en la barra de tareas o la barra de menús. Un dispositivo al que acaban de cambiarle la batería o que ha estado meses sin usarse arranca a menudo con una fecha de años atrás. Si el año está mal, ya tienes la causa.
3. Prueba el sitio desde otro dispositivo u otra red. Si tu móvil con datos abre el sitio sin aviso, el ordenador es el que falla.
4. Si el sitio es tuyo, comprueba el certificado desde fuera. Un análisis gratuito de FortifyNet lee el certificado activo desde internet y muestra sus fechas exactas de notBefore y notAfter, sin depender del reloj de ningún dispositivo.

Por qué este error suele ser tu reloj y no el sitio web

Investigadores de Google y Carnegie Mellon estudiaron más de 300 millones de informes de avisos de certificado de Chrome para saber qué los provoca realmente. El resultado, publicado como "Where the Wild Warnings Are" en ACM CCS 2017, es llamativo: en Windows, un reloj del sistema incorrecto causó el 33,5 % de todos los avisos de certificado, ocho veces más que los certificados realmente caducados. En macOS el reparto fue de 8,71 % frente a 4,39 %, y en Android de 8,46 % frente a 2,73 %.

Porcentaje de informes de avisos de certificado de Chrome causados por un reloj del dispositivo incorrecto frente a un certificado del servidor realmente caducado o aún no válido, por sistema operativo. Fuente: Acer et al., "Where the Wild Warnings Are", ACM CCS 2017, tabla 1.

Dos detalles más del mismo estudio importan para la solución. Casi todos los relojes incorrectos estaban en el pasado, no en el futuro: el reloj del cliente iba más de 24 horas atrasado en el 6,7 % de los informes y más de 24 horas adelantado solo en el 0,05 %. Y cuando un certificado había caducado de verdad, solía ser reciente: el 57 % de los certificados caducados lo habían hecho hacía menos de 30 días, la firma de una renovación que alguien olvidó, no de un sitio abandonado.

El equipo de Chrome usó estos datos para crear la pantalla "Tu reloj está atrasado" que quizá hayas visto. Al principio se basaba en una heurística simple que comparaba la hora del sistema con la fecha de compilación del navegador, y solo detectaba el 68 % de los errores de reloj. En mayo de 2017 Chrome lanzó un servicio de hora segura que consulta a un servidor de Google la hora real cuando detecta un error de fecha, elevando la detección al 96 %. Cuando Chrome muestra la pantalla específica de reloj, el 53 % de los usuarios corrigió su reloj antes de cerrarla, frente al 3,9 % cuando solo veían el aviso genérico. Esa pantalla no tiene, a propósito, ningún enlace de "continuar de todos modos": la única forma de pasar es corregir el reloj.

Corregir ERR_CERT_DATE_INVALID como visitante

Windows 10 y 11

Abre Configuración, ve a Hora e idioma y luego a Fecha y hora. Activa "Establecer la hora automáticamente" y "Establecer la zona horaria automáticamente" y pulsa "Sincronizar ahora" en Configuración adicional. Si el reloj vuelve a desajustarse tras cada reinicio, la pila CMOS de la placa base probablemente está agotada; los investigadores señalaron las pilas CMOS agotadas como una causa probable de que tantos relojes de Windows estén mal. Desde un símbolo del sistema con permisos de administrador también puedes forzar la sincronización con w32tm /resync.

macOS

Abre Ajustes del Sistema, luego General y Fecha y hora, y activa "Ajustar fecha y hora automáticamente". Asegúrate de que la zona horaria también se ajusta automáticamente. Si la opción aparece atenuada, desconecta cualquier VPN y vuelve a intentarlo.

Android y iPhone

En Android, abre Ajustes, luego Sistema y Fecha y hora, y activa "Fecha y hora automáticas" (algunos fabricantes lo llaman "Usar la hora de la red"). En iPhone y iPad, ve a Ajustes, General, Fecha y hora, y activa "Ajuste automático". Un dispositivo que ha estado mucho tiempo apagado o sin tarjeta SIM puede arrancar con una fecha antigua.

Si el reloj es correcto y el error persiste

• Dispositivos antiguos y raíces caducadas. Los certificados se validan a través de una cadena que termina en un certificado raíz de tu dispositivo, y las raíces también caducan. Cuando la cadena con firma cruzada de Let's Encrypt caducó el 30 de septiembre de 2024, los dispositivos con Android 7.0 o anterior dejaron de confiar en los sitios con certificados de Let's Encrypt, mientras que Android 7.1 y posteriores, que ya confiaban directamente en ISRG Root X1, no se vieron afectados (Let's Encrypt). En un dispositivo que no puede actualizarse, Firefox suele ser la solución, porque incluye su propio almacén de raíces en lugar de usar el del sistema operativo.
• Antivirus con inspección HTTPS. Los productos de seguridad que inspeccionan el tráfico HTTPS instalan su propio certificado raíz y vuelven a firmar cada sitio que visitas. El estudio de CCS 2017 rastreó una oleada de errores de fecha en sitios bien configurados hasta un antivirus cuyo propio certificado raíz había caducado. Desactivar temporalmente la inspección HTTPS o el "escudo web" te dice si esa es la causa; actualizar el producto suele resolverlo.
• Actualiza el navegador y borra el estado SSL. Un navegador desactualizado puede carecer de raíces nuevas. En Windows, Opciones de Internet, Contenido, "Borrar estado SSL" elimina los certificados en caché que Chrome y Edge comparten con el sistema.

Corregir ERR_CERT_DATE_INVALID como propietario del sitio

Si los visitantes informan del error y el sitio falla desde más de un dispositivo, el problema es el propio certificado. Sigue estos pasos:

Paso 1: lee las fechas reales. Consulta el certificado que el servidor sirve realmente con OpenSSL:

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

La salida muestra notBefore y notAfter. Si notAfter está en el pasado, el certificado ha caducado. Si notBefore está en el futuro, aún no es válido.

Paso 2: renueva y recarga. Con un cliente ACME como Certbot, sudo certbot renew obtiene un certificado nuevo, pero el servidor web sigue sirviendo el antiguo desde memoria hasta que lo recargas (sudo systemctl reload nginx o el equivalente en Apache). Nuestra guía de renovación cubre todas las plataformas y CDN principales.

Paso 3: revisa toda la cadena. Tu certificado puede ser válido mientras un intermedio de la cadena ha caducado. Instala la cadena completa que te dio la CA (fullchain.pem, no cert.pem) y revisa cada punto que termina TLS: el servidor de origen, el balanceador de carga y el borde del CDN pueden tener cada uno una copia distinta.

Paso 4: cuidado con la trampa del "aún no válido". Un certificado que se vuelve válido en el mismo minuto en que se emite fallará para todo visitante cuyo reloj vaya aunque sea un poco atrasado. El estudio de CCS registró un pico de avisos relacionados con el reloj en Windows en septiembre de 2016, cuando Google desplegó certificados recién emitidos con poco margen. La mayoría de las CA públicas retrasan ahora ligeramente la fecha de inicio por esta razón, pero si gestionas una CA privada, fija notBefore al menos una hora en el pasado.

Paso 5: verifica desde fuera. Los certificados no tienen retardo de propagación. En cuanto el servidor se recarga, un análisis externo muestra las fechas nuevas.

Por qué los errores de fecha serán más frecuentes, no menos

La vida útil de los certificados se acorta. Según la votación SC-081v3 del CA/Browser Forum, la vida máxima de un certificado TLS público bajó de 398 a 200 días el 15 de marzo de 2026, baja a 100 días en marzo de 2027 y a 47 días en marzo de 2029 (CA/Browser Forum). Let's Encrypt está pasando su valor por defecto de 90 a 45 días (Let's Encrypt). Cada renovación es una oportunidad de fallar el plazo, así que un sitio que renueva a mano se encontrará con NET::ERR_CERT_DATE_INVALID varias veces al año. Automatizar la emisión con ACME, configurar el gancho de recarga y vigilar la caducidad desde fuera ya no es opcional.

Guías relacionadas

• "La conexión no es privada": qué significa y cómo solucionarlo describe la página de aviso en la que aparece este error.
• Certificado SSL caducado: qué ocurre y cómo solucionarlo rápido profundiza en la causa del lado del servidor.
• Cómo renovar un certificado SSL recorre la renovación en todas las plataformas principales.
• ERR_CERT_AUTHORITY_INVALID: causas y soluciones trata los errores de cadena que suelen seguir a una renovación apresurada.

Preguntas frecuentes

¿Es peligroso NET::ERR_CERT_DATE_INVALID? Normalmente no, pero Chrome no puede distinguir un error de reloj inofensivo de un ataque, así que bloquea la página. Corrige el reloj o espera a que el sitio renueve en lugar de saltarte el aviso, sobre todo en páginas bancarias o de inicio de sesión.

¿Por qué Chrome dice "Tu reloj está atrasado" en un sitio y "la conexión no es privada" en otro? Chrome solo muestra la pantalla específica de reloj cuando su comprobación de hora segura confirma que tu reloj está mal. Si la comprobación no termina en tres segundos, o la diferencia es pequeña, ves el aviso genérico con el mismo código de error.

¿Puedo saltarme el error? En el aviso genérico puedes pulsar Configuración avanzada y continuar, salvo que el sitio use HSTS, que elimina esa opción. En la pantalla "Tu reloj está atrasado" no hay atajo por diseño; corregir el reloj es la única salida.

Mi reloj es correcto y solo falla un sitio. ¿Y ahora? El certificado del sitio ha caducado o su cadena está rota. Nada en tu dispositivo lo arreglará; avisa al propietario del sitio, o comprueba tú mismo las fechas del certificado con un análisis externo.

¿Cómo evito que pase en mi propio sitio? Automatiza la renovación con ACME, configura el gancho de despliegue que recarga el servidor y vigila la caducidad desde fuera con alertas a 30, 14 y 7 días.

Comprueba las fechas de tu certificado antes que tus visitantes

Un reloj mal ajustado es problema del visitante; un certificado caducado es tuyo. Ejecuta un análisis gratuito de FortifyNet para ver las fechas exactas de validez de tu certificado, la cadena completa, la configuración de protocolos, las cabeceras de seguridad, el DNS y la autenticación de correo en unos 60 segundos. Sin registro.

---

Fuentes: Acer et al., "Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors", ACM CCS 2017; Let's Encrypt, Shortening the Chain of Trust; CA/Browser Forum, Ballot SC-081v3; Let's Encrypt, From 90 to 45.