Cómo arreglar un certificado SSL caducado, paso a paso

Qué significa en realidad «certificado caducado»

Todo certificado TLS lleva dos fechas: no antes de y no después de. El navegador compara el reloj con esas fechas en cada conexión. Pasada la fecha de no después de, el certificado ya no prueba nada, así que el navegador se niega a continuar y muestra un aviso a pantalla completa en lugar de tu sitio.

De ahí se derivan tres cosas, y son la razón de que esto sea urgente y no estético:

• No se ha roto nada en tu servidor. El sitio funciona, los archivos están bien, la base de datos está bien. Ha pasado una fecha.
• No es gradual. No hay modo degradado: el sitio funciona hasta el segundo en que caduca y después es una página de aviso para cada visitante.
• Afecta a más que a los navegadores. Los clientes de API, las apps móviles, los webhooks de las pasarelas de pago y cualquier cosa que use una librería HTTP estricta también rechazarán la conexión, y normalmente con un error mucho menos útil.

La solución siempre tiene la misma forma: consigue un certificado nuevo, instálalo y recarga el servicio que lo sirve. La mayor parte del tiempo que se pierde con este problema se va en el segundo y el tercer paso, no en el primero.

Primero, confirma que es realmente caducidad

Varios problemas distintos producen una página de aviso de aspecto parecido, y la solución de cada uno es completamente diferente. Lee el código de error, no el titular.

• NET::ERR_CERT_DATE_INVALID: esto es caducidad (o un reloj del servidor gravemente desajustado). Sigue con esta guía.
• NET::ERR_CERT_COMMON_NAME_INVALID: el certificado es válido pero no cubre el nombre que visitaste. Habitual cuando se dejó fuera www o un subdominio nuevo.
• NET::ERR_CERT_AUTHORITY_INVALID: autofirmado, o la autoridad emisora no es de confianza, o falta un certificado intermedio en lo que envía el servidor.
• SSL_ERROR_BAD_CERT_DOMAIN (la redacción de Firefox): la misma discrepancia de nombre que arriba.

Comprueba las fechas desde fuera de tu propia máquina y no desde el navegador que ya tienes delante, para que ni una caché local ni un proxy obsoleto te engañen. Un verificador de certificados SSL muestra el emisor, las fechas de validez, los días restantes y todos los nombres que cubre el certificado. Si la fecha final está en el pasado, lo has confirmado, y además sabes si los nombres que necesitas están en el certificado, lo que te ahorra una segunda ronda de todo esto.

Renovar e instalar: cuatro pasos

Estos cuatro pasos son todo el trabajo. El tercero es el que se salta la gente.

1. Consigue un certificado nuevo

Con Let's Encrypt o cualquier cliente ACME suele ser un solo comando —certbot renew o el botón de renovar de tu panel—. Si la renovación está fallando y no es solo que se te ha pasado la fecha, salta a la sección de fallos de renovación más abajo, porque volver a ejecutar el comando fallará igual.

Con un certificado de pago puede que tengas que generar una CSR nueva, completar otra vez la validación del dominio y descargar los archivos emitidos. Conserva la clave privada con la que generaste la CSR: sin ella el certificado no sirve para nada.

2. Instala la cadena completa, no solo el certificado

Tu servidor necesita enviar tu certificado y los certificados intermedios que lo conectan con una raíz de confianza. Una autoridad de certificación suele darte tanto el archivo de la hoja como un paquete o archivo de cadena; instalar solo la hoja produce un error de autoridad no válida en algunos clientes y una situación inexplicable de «en mi navegador funciona», porque los navegadores a menudo guardan intermedios de otros sitios mientras que un cliente recién llegado no.

Apunta tu configuración al archivo de cadena completa (Let's Encrypt lo llama fullchain.pem) y a la clave privada que le corresponde.

3. Recarga el servicio

Escribir los archivos por sí solo no cambia nada. El proceso en ejecución cargó el certificado antiguo en memoria al arrancar y seguirá sirviéndolo hasta que se le diga otra cosa. Recarga nginx, Apache, Caddy, HAProxy, el balanceador de carga o lo que termine el TLS. Esta es, de largo, la razón más común de que un certificado correctamente renovado siga apareciendo como caducado.

Si el TLS se termina en otro sitio —una CDN, un proxy inverso, un balanceador gestionado, el borde de una plataforma—, eso es lo que necesita el certificado nuevo, y los archivos de tu servidor de origen pueden ser irrelevantes.

4. Verifica desde fuera

Vuelve a comprobar el nombre de host en producción desde fuera de tu red y confirma la nueva fecha de validez y los nombres cubiertos. No te fíes de tu propio navegador, que puede seguir mostrándote una conexión en caché o una página intermedia. Comprueba www y el ápice por separado si ambos sirven el sitio: pueden tener certificados distintos.

Cuando la renovación automática se detuvo en silencio

Si tienes un cliente ACME, que el certificado caduque significa que la renovación lleva semanas fallando, normalmente en una tarea programada que nadie lee. Las causas habituales, más o menos por frecuencia:

• El desafío HTTP-01 ya no llega al servidor. Una redirección nueva que manda todo el tráfico HTTP a HTTPS, una regla de cortafuegos o una reescritura que captura /.well-known/acme-challenge/ rompen la validación. Esa ruta debe seguir accesible por HTTP en claro.
• El DNS ha cambiado. El nombre ahora apunta a otro sitio, así que el desafío lo sirve un host que no tiene el token. Si has movido el hosting hace poco, es casi seguro esto: consulta el nombre y mira a dónde resuelve de verdad con una herramienta de consulta DNS.
• Un nombre del certificado ya no existe. ACME renueva el conjunto completo de una vez, así que un subdominio retirado que ya no resuelve hace fallar toda la renovación, incluidos los nombres que siguen activos.
• El temporizador o la tarea programada no se está ejecutando. Tras migrar de servidor o actualizar el sistema, el temporizador de systemd o la entrada de cron a menudo simplemente han desaparecido.
• El cliente es demasiado antiguo. Los endpoints de ACME v1 llevan tiempo muertos; un cliente sin actualizar durante años no puede renovar nada.

Ejecuta la renovación a mano y lee el error en lugar de volver a programarla y cruzar los dedos. Una ejecución en seco te dice si el próximo intento automático funcionaría, que es la única pregunta que importa.

Cuando el certificado está bien pero la cadena no

A veces tu propio certificado tiene validez de sobra y el sitio sigue fallando. La explicación habitual es que ha caducado un certificado intermedio de la cadena, o que tu servidor envía una cadena obsoleta que incluye una raíz con firma cruzada ya caducada.

Esto provocó una caída famosa en 2021, cuando caducó una raíz muy utilizada y miles de sitios que servían una cadena antigua empezaron a fallar en clientes viejos mientras se veían perfectamente bien en los navegadores del momento. El síntoma es característico: los navegadores de escritorio modernos están contentos, mientras que los dispositivos antiguos, algunas apps móviles y los clientes HTTP de servidor rechazan la conexión.

La solución es reinstalar la cadena que tu autoridad de certificación publica ahora y no el archivo que descargaste hace años, y luego recargar. Inspecciona lo que tu servidor envía de verdad —no lo que crees que envía— y confirma cada certificado de la cadena, con su propia fecha de caducidad, con el verificador de certificados.

Por qué sigue diciendo caducado después de arreglarlo

Has renovado, has instalado, has recargado y el aviso sigue ahí. Repasa esto en orden:

• El TLS lo termina otra cosa. Una CDN o un proxy delante de tu origen sirve su propio certificado a los visitantes. Actualízalo ahí.
• Hay más de un servidor detrás del nombre. Con varios backends tras un balanceador, un certificado instalado en uno de ellos significa que aproximadamente la mitad de tus visitantes siguen viendo el antiguo, y que recargar la página a veces lo arregla, que es la pista.
• Tu navegador te muestra un estado en caché. Prueba una ventana privada, otro navegador o una comprobación desde fuera de tu red.
• Varios hosts virtuales y solo uno actualizado. El nombre que probaste no es el que usó el visitante. Comprueba cada nombre por separado.
• La recarga no llegó a ocurrir. Un fallo en la comprobación de configuración suele significar que el servicio sigue en marcha con la configuración y el certificado antiguos. Mira el estado del servicio, no solo el código de salida de tu comando.

Cómo asegurarte de que no vuelva a pasar

La caducidad es la caída más evitable que existe, porque la fecha límite se publica con meses de antelación.

• Automatiza la renovación y luego verifica la automatización. Un cliente ACME con su temporizador y una ejecución en seco que hayas visto funcionar de verdad. Una automatización sin probar no es automatización.
• Vigila los días restantes, no solo el uptime. Una comprobación de disponibilidad pasa hasta el mismo instante de la caducidad y no te dice nada antes. Avisa a 21 días y otra vez a 7.
• Mantén honesta la lista de nombres del certificado. Quita los subdominios retirados para que un nombre muerto no pueda tumbar la renovación completa.
• Atención a las vidas más cortas. La duración de los certificados lleva años acortándose y va a seguir acortándose. Cualquier proceso que dependa de que una persona se acuerde se va a romper; automatizar ya no es opcional.
• Revisa la cadena después de cada migración. Mudarse de hosting es el momento en que aparece un intermedio obsoleto o un terminador de TLS olvidado.

Si quieres el panorama completo de lo que contiene un certificado y de cómo leer una cadena, la guía para comprobar certificados SSL/TLS repasa cada campo.

Errores comunes

• Instalar el certificado nuevo y no recargar el servicio. La causa más común de «lo he arreglado y sigue roto».
• Instalar la hoja sin la cadena de intermedios. Funciona en tu navegador y falla para otros clientes.
• Repetir sin cambios una renovación que falla. Fallará igual; lee primero el error.
• Juzgar el arreglo desde el navegador que ya estabas usando. Verifica desde fuera de tu red.
• Arreglar el ápice y olvidar www, o al revés.
• Borrar la clave privada en plena prisa. Sin ella no se puede instalar el certificado nuevo.
• Confiar en un monitor de uptime para que te avise de la caducidad. No puede.

En resumen

Un certificado caducado es un problema de fechas, no del servidor: confirma que el error es de verdad NET::ERR_CERT_DATE_INVALID, emite un certificado nuevo, instala la cadena completa con su clave privada correspondiente, recarga el servicio que termina el TLS y después verifica la nueva fecha de caducidad desde fuera de tu red. Si la renovación debía ser automática, averigua por qué se detuvo —normalmente una ruta de desafío ACME bloqueada, un cambio de DNS o un subdominio retirado— antes de volver a programarla. Después vigila los días restantes para que el siguiente no llegue nunca a cero. Comprueba el certificado de cualquier dominio, su cadena y su fecha exacta de caducidad con el verificador gratuito de certificados SSL, y confirma a dónde apunta el nombre con la herramienta de consulta DNS.

Herramientas y guías relacionadas:

• Verificador de certificados SSL: Comprueba el certificado SSL de cualquier dominio: emisor, fecha de caducidad y días restantes.
• Verificador de cabeceras de seguridad: Comprueba HSTS, CSP, X-Frame-Options y otras cabeceras de seguridad clave.
• Verificador de certificados SSL: guía completa para comprobar certificados SSL/TLS: Aprende a usar un verificador de certificados SSL para inspeccionar el certificado SSL/TLS de cualquier dominio: emisor

Preguntas frecuentes