Certificado SSL caducado: cómo evitarlo y cómo (no) asustar al cliente

· 8 min de lectura

Un certificado SSL caducado es una de las pocas averías que el cliente descubre siempre antes que tú. No hace ruido, no manda ningún aviso: simplemente, a partir de un minuto concreto, cualquiera que abra la web ve una pantalla roja. Es también una de las pocas averías que se pueden prever con meses de antelación — pero la forma en que la mayoría de las agencias se enteraba, el correo de recordatorio de la entidad que emite el certificado, desde 2025 ya no existe.

Qué ve realmente el cliente

No un error discreto en una esquina: una página a pantalla completa, con fondo rojo o un candado tachado, que dice "Tu conexión no es privada", y un botón para volver atrás mucho más visible que el de continuar.

El daño no es técnico — la web funciona, los datos no están comprometidos, nadie ha atacado nada. El daño es que el navegador, la autoridad en la que más confía el visitante, le está diciendo que no se fíe de esa web. A partir de ahí, lo que tu cliente te dice por teléfono es "vuestra web ha sido hackeada", y la conversación empieza ya perdida.

Por qué ocurre incluso con la renovación automática activa

La objeción más común es: "tengo Let's Encrypt, se renueva solo". Es cierto mientras es cierto. Las formas en que una renovación automática deja de funcionar son todas banales y todas frecuentes:

El punto en común: la renovación falla en silencio. Ninguno de estos escenarios genera una notificación. La primera señal es la pantalla roja.

Dos cambios recientes que hacen necesario el control externo

Let's Encrypt ya no envía correos de recordatorio. Lo anunció el 22 de enero de 2025 y dejó de hacerlo el 4 de junio de 2025, confirmándolo con un segundo comunicado el 26 de junio. Los motivos declarados son la privacidad y el coste del servicio, y en el anuncio la entidad sugiere explícitamente usar en su lugar un servicio de monitorización de terceros. Si tu sistema de alerta era "me llega el correo de Let's Encrypt", desde junio de 2025 ya no tienes sistema de alerta.

Los certificados duran cada vez menos. El CA/Browser Forum —el organismo en el que navegadores y autoridades de certificación deciden las reglas comunes— aprobó en abril de 2025 la votación SC-081v3, que reduce la duración máxima de un certificado TLS público según un calendario preciso: de 398 a 200 días desde el 15 de marzo de 2026, a 100 días desde el 15 de marzo de 2027, a 47 días desde el 15 de marzo de 2029.

Las dos cosas van en la misma dirección. Cada renovación es una oportunidad de fallar, y en 2029 un certificado habrá que renovarlo ocho veces más a menudo que un certificado anual de hace unos años — sin que nadie te avise cuando una de esas renovaciones se salte. La automatización pasa a ser obligatoria y, precisamente por eso, deja de ser suficiente: hace falta algo que compruebe que está funcionando.

Cómo se evita: mirar el certificado desde fuera

Controlar desde dentro significa fiarse del servidor: el estado del cron de renovación, la fecha del archivo del certificado, el log de certbot. Tiene un defecto estructural: solo ve lo que el servidor cree haber hecho. Un certificado renovado correctamente pero no recargado por el servidor web figura como válido en el disco y caducado para los visitantes.

Controlar desde fuera significa hacer lo mismo que hace un navegador: abrir una conexión HTTPS con la web, leer el certificado que el servidor presenta de verdad, mirar la fecha de caducidad. Es la única comprobación que responde a la pregunta correcta — no "la renovación se ha completado", sino "qué ve en este momento quien abre la web".

La versión manual es abrir la web y hacer clic en el candado: funciona, y tiene el límite de cualquier control a mano — aguanta mientras alguien se acuerde.

Los recordatorios: 14, 7 y 1 día

La cadencia correcta no es un único correo el día antes. Son tres momentos con tres funciones distintas: a los 14 días descubres que la renovación automática está rota, con todo el tiempo para entender por qué sin prisas; a los 7 días llegas a quien vio el primer aviso y lo aplazó, y es el momento de ponerlo en el calendario; a 1 día ya no es un recordatorio, es una alarma: algo ha ido mal dos veces y mañana la web se pone roja.

Tres avisos por certificado son además el tope adecuado: uno solo se pierde entre los correos, uno al día durante dos semanas se convierte en ruido que se aprende a ignorar.

Si caduca igualmente: qué hacer y qué decir

Técnicamente es una de las averías más rápidas de arreglar: casi siempre basta con forzar una renovación y recargar el servidor web, o sea, minutos, no horas. El tiempo de verdad se va en entender por qué se había parado la renovación, y eso se hace después de volver a poner la web en verde.

En cuanto a la comunicación, valen tres reglas. Avisa antes de haber resuelto: si el cliente recibe tu mensaje antes que el aviso de un cliente suyo, el problema es tuyo de gestionar; si lo recibe después, el problema pasa a ser tu fiabilidad. Explica lo que no ha pasado: nadie ha entrado en la web, no se ha tocado ningún dato. Da una hora, no un adjetivo: "antes de las 15:00" es una promesa verificable, "lo antes posible" es ruido.

Una plantilla para adaptar:

Hola [nombre], te aviso de que desde esta mañana la web muestra un aviso de seguridad a los visitantes: ha caducado el certificado que gestiona la conexión protegida (el candado junto a la dirección). La web está intacta y los datos no se han tocado en modo alguno — es una renovación técnica que no se ha completado. Estamos trabajando en ello ahora mismo y cuento con tenerlo resuelto antes de las [hora]. Te escribo en cuanto esté arreglado.

Y después — la parte que casi todos se saltan — escribe de verdad el mensaje de cierre. Un "resuelto, esto es lo que había pasado" de tres líneas vale, para la confianza del cliente, más que la intervención técnica que lo ha precedido.

El riesgo vecino: no es solo el SSL lo que puede hacer desaparecer una web

Dos caducidades se confunden a menudo, pero una es molesta y la otra es grave. El certificado SSL dura unos meses y, si caduca, la web sigue online: parece insegura, pero está. El registro del dominio se renueva una vez al año o más, y si caduca la web no es "no segura": simplemente deja de existir, normalmente junto con los correos de empresa que viajan por el mismo dominio. Y no depende de un cron que puedas arreglar tú: depende de una tarjeta de crédito caducada en el panel de un registrador al que a menudo solo accede el cliente. Un riesgo menos frecuente, mucho más costoso, y que se controla consultando los registros de dominios, no el servidor.

Cómo lo hace Statuo

En Statuo el control del certificado no es un control aparte: es la misma conexión HTTPS con la que las sondas comprueban que la web responde. Lo que se lee es el certificado que el servidor presenta de verdad a quien se conecta desde fuera — emisor, validez y fecha de caducidad —, no el estado de la renovación en el servidor. Está activo por defecto en cada sitio nuevo, y la comprobación de caducidades se ejecuta cada hora.

Los avisos siguen los tres umbrales descritos arriba — 14, 7 y 1 día —, uno por umbral y por sitio, es decir, como máximo tres correos por certificado. Llegan por correo, Telegram, Slack o Teams, en el idioma configurado para la agencia, y dicen lo justo: "El certificado SSL de [sitio] caduca el [fecha]. Renuévalo para evitar que el sitio aparezca como no seguro para los visitantes." La fecha de caducidad, en cualquier caso, está siempre a la vista en la lista de sitios del panel, sin esperar a un aviso.

Para la caducidad del dominio hay un control aparte, con umbrales a 30, 14 y 7 días: Statuo consulta directamente los registros (RDAP, con recurso al WHOIS clásico para las extensiones que no lo exponen, .it incluida), sin apoyarse en servicios de terceros. Está incluido en la prueba y en los planes Agency y Scale, no en el plan Starter.

Para ver al instante en qué estado está un certificado sin registrar nada, hay un control gratuito: pegas la dirección y te dice estado, tiempo de respuesta y días que faltan para la caducidad. Para hacerlo en todos los clientes y recibir el aviso de forma automática, la prueba dura 14 días, sin tarjeta de crédito.

Fuentes citadas, consultadas el 19 de agosto de 2026:

El sitio de un cliente está caído: qué hacer en los primeros 15 minutos

Checklist minuto a minuto para cuando se cae el sitio de un cliente: cómo aislar la causa, qué escribirle antes de 15 minutos y los errores que conviene evitar.

Excel, recordatorios y revisiones a mano: por qué la monitorización manual acaba fallando

Por qué revisar a ojo, la hoja de Excel y la instancia olvidada de Uptime Kuma fallan de la misma manera, y cómo pasar a una herramienta que te avisa.