Certificado SSL caducado: qué hacer y cómo evitar que se repita

Un certificado caducado deja un sitio fuera de servicio con la misma eficacia que un servidor caído. Los navegadores muestran un aviso a pantalla completa (NET::ERR_CERT_DATE_INVALID en Chrome, SEC_ERROR_EXPIRED_CERTIFICATE en Firefox), y si el sitio usa HSTS ni siquiera aparece el enlace para "continuar de todos modos". Los clientes de API, las aplicaciones móviles, los webhooks y las notificaciones de pago simplemente fallan. Esta guía cubre qué hacer en la primera media hora y cómo asegurarse de que no vuelva a ocurrir.

Paso 1: confirme qué es lo que falla de verdad

No todo error de fecha es un certificado vencido en su servidor. Compruébelo desde una máquina cuyo reloj sea de fiar:

$ openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates
subject=CN = example.com
issuer=C = XX, O = Example CA, CN = Example CA R3
notBefore=Jun 20 08:00:00 2026 GMT
notAfter=Sep 18 08:00:00 2026 GMT

Un notAfter en el pasado lo confirma. Cosas que se le parecen pero no lo son:

Reloj equivocado en el cliente. Un portátil con la pila agotada que cree estar en 2019 rechaza todos los certificados. Si solo un visitante informa del error, pregunte primero por el reloj.
Un certificado intermedio caducado en la cadena que envía el servidor, mientras el certificado final está bien.
Solo uno de varios servidores tiene el certificado antiguo. Detrás de un balanceador de carga o de una CDN, compruebe cada nodo, y compruebe el origen por separado del borde.
Otro servicio bajo el mismo nombre. El puerto 443 se renovó, pero el correo (:465, :993, :587 con STARTTLS) sigue con el archivo antiguo:

$ openssl s_client -connect mail.example.com:587 -starttls smtp </dev/null 2>/dev/null \
    | openssl x509 -noout -enddate

La opción -servername importa: sin SNI, muchos servidores devuelven un certificado por defecto que no es el que ven los navegadores.

Paso 2: renueve, según cómo obtuvo el certificado

ACME (Let's Encrypt y similares)

El certificado debería haberse renovado solo; averigüe por qué no lo hizo.

$ sudo certbot certificates          # lo que certbot conoce y cuándo caduca cada uno
$ sudo certbot renew --dry-run       # probar el proceso de renovación
$ sudo certbot renew                 # renovar todo lo que esté pendiente
$ systemctl list-timers | grep -i certbot

Causas habituales: el temporizador o la tarea cron desapareció tras una migración de servidor; el puerto 80 está cerrado o redirigido de un modo que rompe el desafío HTTP-01; se rotó el token de la API de DNS que se usaba para DNS-01; un registro AAAA apunta a una máquina que no responde al desafío; un registro CAA restrictivo no incluye a la CA, o el dominio apunta ahora a un servidor completamente distinto.

Certificado de una CA comercial

Genere una clave nueva y una CSR. No reutilice la clave antigua por costumbre.

$ openssl req -new -newkey rsa:2048 -nodes \
    -keyout example.com.key -out example.com.csr \
    -subj "/CN=example.com" \
    -addext "subjectAltName=DNS:example.com,DNS:www.example.com"

Envíe la CSR, complete la validación del dominio (correo, registro DNS o archivo HTTP) y descargue el certificado y la cadena de intermedios.
Incluya en el campo SAN todos los nombres de host que necesite. example.com no cubre www.example.com, y un comodín *.example.com no cubre ni el dominio sin prefijo ni a.b.example.com.

Gestionado por un proveedor de hosting, una CDN o un balanceador

Mire en el panel del proveedor. Los certificados gestionados suelen dejar de renovarse por una sola razón: el dominio ya no se valida. Se cambió el registro DNS que apuntaba al proveedor, se borró un CNAME necesario para la validación o un registro CAA bloquea a la CA del proveedor.

Paso 3: instálelo con la cadena completa

Los servidores deben enviar el certificado final seguido del intermedio o los intermedios. La raíz no se envía. Con certbot, eso es fullchain.pem:

# nginx
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Un intermedio ausente es traicionero, porque los navegadores de escritorio suelen disimularlo obteniendo los intermedios por su cuenta o sacándolos de su caché, mientras que curl, las aplicaciones Android y otros servidores fallan. Pruebe con un cliente estricto:

$ curl -sSI https://example.com >/dev/null && echo chain ok

Compruebe que el certificado y la clave se corresponden:

$ openssl x509 -noout -pubkey -in fullchain.pem | openssl sha256
$ openssl pkey -pubout -in privkey.pem | openssl sha256

Los dos hashes deben ser idénticos.

Paso 4: recargue el servicio

El motivo más frecuente de "lo he renovado y sigue caducado": el servidor web conserva el certificado antiguo en memoria.

$ sudo nginx -t && sudo systemctl reload nginx
$ sudo apachectl configtest && sudo systemctl reload apache2

Con los clientes ACME, haga que la recarga forme parte de la renovación, por ejemplo con certbot renew --deploy-hook "systemctl reload nginx". Haga lo mismo con Postfix, Dovecot, HAProxy y cualquier otra cosa que lea el archivo.

Paso 5: verifique desde fuera

Repita el comando openssl s_client del paso 1 y mire el nuevo notAfter. Después compruebe:

tanto example.com como www.example.com, y cualquier otro nombre en uso
IPv4 e IPv6 por separado (openssl s_client -4 / -6) si publica ambos
cada nodo detrás del balanceador de carga
el correo y los demás puertos TLS

Los navegadores pueden mantener abierta una conexión durante un rato; pruebe en una ventana privada nueva antes de concluir que no ha funcionado.

Por qué pasa una y otra vez: la vigencia es cada vez más corta

Los certificados de confianza pública están limitados a 398 días desde septiembre de 2020, y Let's Encrypt ha emitido certificados de 90 días desde el principio. En abril de 2025, el CA/Browser Forum aprobó un calendario que reduce aún más el máximo: 200 días a partir del 15 de marzo de 2026, 100 días a partir del 15 de marzo de 2027 y 47 días a partir del 15 de marzo de 2029. El periodo durante el cual puede reutilizarse una validación de dominio ya completada también se acorta.

El significado práctico: un recordatorio en el calendario y una renovación manual una vez al año es un proceso con fecha de caducidad. Con certificados de 47 días, nadie renueva a mano. Tenga en cuenta además que Let's Encrypt dejó de enviar correos de aviso de vencimiento en 2025, así que esa red de seguridad también ha desaparecido.

Lista de prevención

Automatice la emisión y la renovación con ACME allí donde la plataforma lo permita. Muchas CA comerciales también admiten ACME.
Renueve pronto. Los clientes ACME renuevan por defecto cuando queda aproximadamente un tercio de la vigencia, lo que deja semanas para detectar un fallo.
Supervise desde fuera, con independencia del mecanismo de renovación. La comprobación debe mirar el certificado que el servidor presenta, no el archivo en disco. Alerte a 21, 14 y 7 días.
Haga inventario de todos los puntos de conexión: subdominios, servidores de correo, pasarelas VPN, herramientas internas, el origen detrás de la CDN. El olvidado es el que caduca.
Pruebe el deploy hook. Una renovación sin recarga es una caída simplemente aplazada.
Mantenga la validación en funcionamiento: puerto 80 accesible para HTTP-01, credenciales de la API de DNS válidas para DNS-01, registros CAA que incluyan a las CA que usa.
Envíe las alertas a una dirección de equipo, no al buzón de una sola persona.

Errores frecuentes

Renovar el certificado y no recargar el servidor.
Instalar el certificado final sin el intermedio.
Olvidar www, o el dominio sin prefijo, en la lista SAN.
Renovar el certificado del borde (CDN) mientras el del origen caduca en silencio; según el modo de la CDN, esto produce errores 5xx desde el borde en lugar de un aviso del navegador.
Decir a los usuarios que ignoren el aviso y continúen. Enseña exactamente el hábito del que se aprovechan los atacantes.
Desactivar "temporalmente" la verificación de certificados en un cliente de API.
Dar por hecho un problema de certificado cuando la causa real es un cambio de DNS que envió a los usuarios a otro servidor. Si el certificado presentado pertenece a otro, compruebe primero adónde apunta el nombre.

Compruébelo con OrbitProbe

El comprobador SSL de OrbitProbe se conecta a su nombre de host e informa del certificado que realmente se presenta: emisor, fechas de validez y días restantes, los nombres de host que cubre, el protocolo TLS negociado, si la cadena es de confianza y HSTS. Ejecútelo después de cada renovación, una vez para el dominio sin prefijo y otra para www. Si el correo forma parte del mismo incidente, la lista de comprobación DNS para correos que llegan a spam cubre la parte de TLS y DNS de la entrega del correo. Y si un cambio de DNS interviene en el arreglo, recuerde que tarda lo que marque el TTL.