Todo certificado SSL/TLS tiene una fecha de fin. Cuando esa fecha pasa, los navegadores dejan de confiar en el sitio y muestran a los visitantes una página de advertencia. El sitio web en sí sigue funcionando, así que las comprobaciones de disponibilidad (uptime) que solo piden un código de estado pueden no darse cuenta en absoluto. La caducidad de un certificado es una de las causas de caída más evitables, y esta guía te muestra cómo prevenirla.

Qué hace un certificado SSL/TLS

Un certificado cumple dos funciones cuando un navegador abre una dirección https://:

  • Demuestra la identidad. Dice que este servidor está autorizado para responder por este nombre de dominio, avalado por una autoridad de certificación en la que confía el navegador.
  • Permite el cifrado. Contiene la clave pública que el navegador y el servidor usan para establecer una conexión cifrada.

El término SSL es antiguo. Las conexiones modernas usan TLS, pero la gente sigue diciendo «certificado SSL», y esta guía también.

Un certificado contiene una fecha de inicio (notBefore) y una fecha de fin (notAfter). Fuera de esa ventana, no es válido. Esto lo define el estándar X.509, la RFC 5280.

Por qué importa la caducidad

Cuando un certificado caduca:

  • Los navegadores muestran una advertencia a pantalla completa y dificultan continuar.
  • Los rastreadores de los buscadores, los proveedores de pago y los clientes de API pueden rechazar la conexión.
  • Las aplicaciones móviles y las integraciones que hablan con tu servidor pueden fallar sin ningún mensaje visible.
  • Los visitantes suelen suponer que el sitio ha sido hackeado.

El servidor no tiene ningún problema. Por eso el fallo es fácil de pasar por alto y puede causar un daño real rápidamente.

Cómo comprobar el período de validez de un certificado

Puedes comprobar cualquier sitio público tú mismo, sin herramientas especiales.

En un navegador

Los nombres exactos de los menús varían entre navegadores y versiones. En la mayoría de los navegadores de escritorio:

  1. Abre el sitio web.
  2. Haz clic en el icono a la izquierda de la barra de direcciones (un candado o un icono de conexión).
  3. Elige la entrada sobre la conexión o el certificado y abre los detalles del certificado.
  4. Lee las fechas «Valid from» y «Valid to».

Con OpenSSL

En Linux y macOS, OpenSSL suele estar instalado. Este comando se conecta al sitio e imprime las fechas:

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

Sustituye example.com por tu dominio. El resultado tiene este aspecto (las fechas son ejemplos):

notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT

Qué hace cada parte:

  • openssl s_client -connect example.com:443 abre una conexión TLS al puerto 443 e imprime lo que envía el servidor.
  • -servername example.com envía el nombre de host durante el intercambio inicial (SNI, Server Name Indication). Muchos servidores alojan varios sitios en una misma dirección y usan el nombre para elegir qué certificado presentar. Sin él, puede que te muestren el certificado de otro sitio.
  • </dev/null cierra la entrada de inmediato, de modo que el comando termina en lugar de quedarse esperando.
  • 2>/dev/null oculta los detalles de la conexión, que van al flujo de errores.
  • openssl x509 -noout -dates lee el certificado de la tubería e imprime solo sus fechas de inicio y de fin.

Para hacer una pregunta de sí o no, usa -checkend con un número de segundos. Este comando pregunta si el certificado seguirá siendo válido dentro de 30 días (2 592 000 segundos):

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

Imprime Certificate will not expire y termina con 0 si el certificado seguirá siendo válido entonces. Si para entonces habrá caducado, termina con un estado distinto de cero. Eso lo hace fácil de usar en un script.

Note

Este comando muestra las fechas del certificado que presenta el servidor en ese puerto. No es una prueba completa. No comprueba que la cadena esté completa, que el nombre coincida ni que un navegador confíe en el resultado. Tampoco dice nada sobre si el propio sitio está disponible.

Cómo funciona la renovación de certificados

Un certificado no se puede ampliar. Renovar significa obtener de la autoridad de certificación un certificado nuevo para los mismos nombres, con fechas nuevas, y luego instalarlo donde el servidor pueda usarlo.

Importan dos pasos, y la gente suele acordarse solo del primero:

  1. Emitir. La autoridad comprueba que controlas el dominio y te da un certificado nuevo.
  2. Desplegar. El certificado nuevo y la clave se colocan donde los lee el servidor web, y se le indica al servidor que los cargue.

Hasta que se hace el segundo paso, el servidor sigue sirviendo el certificado antiguo, y la fecha de fin antigua sigue vigente. Un archivo renovado en disco no es un certificado renovado en producción.

Renovación automática

La mayoría de las autoridades de certificación esperan hoy que la renovación esté automatizada. Let's Encrypt, por ejemplo, emite certificados que duran 90 días por defecto, y su guía de integración recomienda renovar cuando queda aproximadamente un tercio de la vida útil, para poder reintentar si un intento falla.

Las herramientas típicas, como Certbot y los clientes ACME integrados en muchos paneles de alojamiento y servidores web, hacen esto según un calendario. Intentan la renovación con regularidad, reemplazan los archivos del certificado cuando toca y pueden ejecutar un comando después, como recargar el servidor web.

Uses lo que uses, configúralo de modo que puedas ver que funciona:

  • Ten claro dónde se ejecuta y con qué frecuencia.
  • Ten claro a quién se avisa cuando falla.
  • Haz una ejecución de prueba, si la herramienta lo admite. Certbot tiene certbot renew --dry-run.

Los certificados son cada vez más cortos

La vida útil de los certificados se está reduciendo en toda la industria, lo que hace cada vez menos práctica la renovación manual:

  • El CA/Browser Forum, el organismo que fija las reglas de los certificados públicos, aprobó un calendario que reduce la validez máxima de 398 días a 47 días. Los certificados emitidos a partir del 15 de marzo de 2026 pueden durar hasta 200 días; a partir del 15 de marzo de 2027, hasta 100 días; y a partir del 15 de marzo de 2029, hasta 47 días.
  • Let's Encrypt ha anunciado que su perfil predeterminado pasará a 64 días en febrero de 2027 y a 45 días en febrero de 2028.

Si renuevas a mano una vez al año, planifica automatizar. Comprueba las reglas vigentes de tu propia autoridad, porque los calendarios pueden cambiar.

Note

Let's Encrypt ya no envía correos de recordatorio de caducidad. Si los usabas como red de seguridad, necesitas un monitor propio.

Por qué puede fallar la renovación automática

Automático no significa fiable. Estos son los motivos habituales por los que las renovaciones fallan sin que nadie se dé cuenta:

  • La tarea programada se detuvo. Se reconstruyó el servidor, se perdió el temporizador o la tarea nunca se activó.
  • Falla la verificación del dominio. La autoridad debe llegar a tu sitio o a tus registros DNS para confirmar el control. Un cortafuegos modificado, una zona DNS trasladada, una redirección que ahora intercepta el desafío o una CDN delante pueden romperlo.
  • No se carga el certificado nuevo. El archivo se reemplaza, pero el servidor web nunca se recarga, así que conserva el antiguo en memoria.
  • Otro servidor tiene el certificado. Un balanceador de carga, una CDN o un segundo host sirve su propia copia, que ninguna tarea actualiza.
  • Se añadió o se quitó un nombre. El certificado ya no cubre todos los nombres de host en uso.
  • La cuenta o las credenciales caducaron. Se revocó un token de API para la validación por DNS, o el correo de contacto de la cuenta ya no existe.
  • Límites de frecuencia o cambios de la autoridad. Demasiados intentos, o un cambio en las reglas del emisor, pueden hacer que se rechace una solicitud.

El segundo y el tercero son los más comunes en la práctica, y ninguno de los dos aparece en las fechas del certificado hasta que es demasiado tarde.

Cadenas de certificados y problemas de despliegue

Un servidor debe enviar su propio certificado (el de hoja) y los certificados intermedios que lo enlazan con una raíz de confianza. Si falta un intermedio, algunos clientes aún pueden construir el camino y otros no. Entonces el sitio se ve bien en tu navegador y falla en una aplicación, en una herramienta de línea de comandos o en un teléfono antiguo.

Señales de este problema:

  • El sitio funciona en un navegador de escritorio pero falla con curl o desde un script.
  • openssl s_client termina con un mensaje sobre no poder verificar el primer certificado.
  • Solo se quejan algunos dispositivos.

Para ver la cadena que envía el servidor, añade -showcerts:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Al final de la salida, busca la línea que empieza por Verify return code. 0 (ok) significa que OpenSSL pudo construir un camino de confianza.

Otros descuidos de despliegue que conviene buscar: el certificado y la clave no coinciden, se sirve un certificado antiguo en uno de varios servidores, o se accede al sitio con un nombre que el certificado no incluye.

Monitoriza la caducidad del certificado

Incluso con automatización, vigilar la fecha de fin es la red de seguridad. Detecta todos los fallos anteriores, porque mira lo que se sirve, no lo que debería servirse.

Una buena comprobación de caducidad:

  • Lee el certificado que reciben los visitantes, en la dirección real.
  • Avisa con tiempo suficiente para actuar, con días de margen, no horas.
  • Avisa a la persona que puede arreglarlo.
  • Vuelve a avisar si el problema no se arregla, o al menos no deja que el aviso se pierda.

En UptimeWire

Para cada sitio web cuya dirección empiece por https://, UptimeWire comprueba el certificado por separado de la comprobación de disponibilidad. Así se comporta:

  • Calendario propio. Las comprobaciones de certificado se ejecutan cada pocas horas, con su propio calendario, no con el intervalo de la comprobación de disponibilidad. Por eso un aviso puede llegar horas después de haber cruzado el umbral, y no en el momento exacto.
  • Antelación del aviso. Tú eliges con cuántos días de antelación al vencimiento quieres recibir el aviso. El valor predeterminado es de 30 días, y el ajuste es por sitio web. Se envía un aviso cuando al certificado le quedan menos días que esos.
  • Se envía una vez. El aviso se envía cuando la comprobación entra en el estado de aviso, no en cada comprobación posterior.
  • Certificados no válidos. Si el certificado no se puede validar en absoluto (por ejemplo, porque ha caducado o es para otro nombre), se te avisa de inmediato, sin esperar al umbral.
  • Canales. Los avisos de certificado van por correo y, si lo has conectado, por Telegram. Los canales de chat y de webhook no los llevan.

UptimeWire no renueva ni sustituye certificados. Te dice que ha llegado el momento de actuar.

Important

La monitorización no sustituye a la renovación. Un aviso que nadie lee, o que va a un canal que no lo transporta, no protege nada. Asegúrate de que la dirección de correo es una que alguien revisa.

Qué hacer cuando un certificado ha caducado

  1. Confírmalo. Comprueba las fechas con un navegador o con el comando de OpenSSL de arriba, en la dirección real.
  2. Averigua dónde se sirve el certificado. Puede ser tu servidor web, un balanceador de carga, una CDN o un panel de alojamiento.
  3. Renuévalo. Ejecuta la herramienta de renovación o solicita un certificado nuevo a tu autoridad. Si falló la automatización, lee su registro para saber por qué.
  4. Despliégalo. Instala el certificado nuevo y recarga el servicio que lo sirve.
  5. Vuelve a comprobar desde fuera. Lee las fechas en la dirección real y comprueba la cadena.
  6. Encuentra la causa. Arregla por qué falló la automatización, o ocurrirá lo mismo en la próxima renovación.
  7. Avisa a la gente, si hace falta. Si los clientes vieron la advertencia, vale la pena una nota breve en una página de estado o por correo.

Lista de comprobación de prevención

  • Cada nombre de host público está listado, con el certificado que lo cubre y dónde se sirve.
  • La renovación es automática y sabes dónde se ejecuta.
  • Alguien recibe el mensaje de fallo de la tarea de renovación.
  • El servidor web se recarga después de reemplazar el certificado.
  • La cadena está completa (Verify return code: 0 (ok)).
  • La fecha de fin se monitoriza desde fuera, con un aviso con al menos dos semanas de antelación.
  • El correo de aviso va a un buzón que lee una persona.
  • Compruebas las fechas después de cualquier cambio de servidor, CDN o alojamiento.
  • El registro del dominio y el DNS también se monitorizan, ya que fallan de la misma manera silenciosa. Consulta la Guía completa de monitorización de la disponibilidad de sitios web.

Para el otro lado del problema, darte cuenta de cuándo un sitio es inalcanzable por cualquier motivo, lee Cómo monitorizar la disponibilidad de un sitio web.