Validez del certificado SSL 2026–2029: de 398 a 47 días

Respuesta corta: desde el 15 de marzo de 2026, la validez de un certificado SSL/TLS de confianza pública es como máximo de 200 días. El 15 de marzo de 2027 el límite baja a 100 días y el 15 de marzo de 2029, a 47 días. El calendario sale de la votación SC-081v3 del CA/Browser Forum, aprobada el 11 de abril de 2025, y obliga a todas las autoridades de certificación (CA) públicas: de pago o gratuitas, DV, OV o EV. Si algún paso de tu renovación depende de una persona, de un recordatorio en el calendario o de un correo de tu CA, fallará en algún punto del camino.

Datos verificados el 14 de octubre de 2026 con la votación del CA/Browser Forum, el resumen de DigiCert y los anuncios de Let's Encrypt. Las fuentes están al final.

Calendario de validez del certificado SSL de un vistazo

La última columna es el mínimo teórico: renovar el último día. Nadie sensato lo hace. Con un margen de seguridad normal, la etapa de 47 días significa renovar más o menos cada mes: unas 12 renovaciones por certificado al año.

Hay un cambio más que entró en vigor el 15 de marzo de 2026: los datos de la organización que respaldan los certificados OV y EV (la llamada "subject identity information") ahora se pueden reutilizar durante 398 días en lugar de 825.

Cambiaron dos cifras, y la segunda importa más

La validez máxima determina cada cuánto instalas un certificado nuevo. La reutilización de la validación de dominio determina cada cuánto la CA tiene que volver a comprobar que controlas el dominio: con un registro DNS, un archivo de desafío HTTP o un correo electrónico.

Hoy una validación correcta se puede reutilizar durante meses, así que una configuración de validación frágil puede pasar desapercibida mucho tiempo. A partir de 2029 la ventana de reutilización es de 10 días, lo que en la práctica significa que cada renovación dispara una validación nueva. Un paso que antes se ejecutaba una vez al año, con alguien pendiente, se ejecutará cada mes y sin supervisión. Si el token de la API de DNS ha caducado o una regla del firewall bloquea el desafío, te enterarás cuando caduque el certificado.

¿Y Let's Encrypt? De 90 a 45 días

Los certificados de Let's Encrypt ya duran 90 días, muy por debajo de los nuevos límites. Pero Let's Encrypt también los está acortando:

• 13 de mayo de 2026: el perfil opcional tlsserver empezó a emitir certificados de 45 días.
• 10 de febrero de 2027: el perfil por defecto classic pasa a certificados de 64 días y a un periodo de reutilización de la autorización de 10 días.
• 16 de febrero de 2028: el perfil classic pasa a certificados de 45 días con un periodo de reutilización de la autorización de 7 horas.

La recomendación de Let's Encrypt es dejar que decida el cliente mediante ACME Renewal Information (ARI) o renovar aproximadamente a los dos tercios de la vida del certificado. Dice claramente que renovar con un intervalo fijo de 60 días dejará de ser suficiente. Si tu configuración renueva según un calendario fijo y no según el tiempo que le queda al certificado, tiene su propia fecha de caducidad.

Hay un segundo cambio, más discreto. El 4 de junio de 2025 Let's Encrypt dejó de enviar correos de aviso de caducidad. La red de seguridad en la que confiaban muchos equipos ("si la renovación falla, Let's Encrypt me avisará por correo") ya no existe.

Dónde fallan realmente las renovaciones

Un certificado caducado rara vez se debe a que nadie intentó renovarlo. Casi siempre viene de una renovación que funcionó a medias:

1. Renovado, pero nunca desplegado. El certificado nuevo está en el disco, pero nadie recargó el servidor web, así que sigue sirviendo el antiguo hasta que caduca.
2. Copias en otros sitios. El certificado se renovó en el servidor de origen, pero la CDN, el balanceador de carga, el servidor de correo o el API gateway siguen teniendo una copia subida a mano.
3. Una validación que solo funcionó una vez. Caducó el token de la API del proveedor DNS, el DNS se movió a otro proveedor, un registro CAA bloquea a la CA o un firewall frena el desafío HTTP.
4. Certificados manuales. Un certificado OV o EV de pago instalado a mano en un appliance o en un panel de hosting (cPanel, Plesk o el panel propio del proveedor). Con 47 días, eso supone hasta una docena de tareas manuales por certificado al año.
5. La tarea de renovación que desapareció. Una entrada de cron o un timer de systemd que se perdió en una migración de servidor, o un contenedor que se reconstruyó sin ella.

El denominador común: la herramienta de renovación informa de que todo fue bien, o no informa de nada, y nadie comprueba lo que reciben de verdad los visitantes.

Monitorear el certificado SSL: lo que ve internet, no lo que hay en el disco

Una comprobación externa del certificado se conecta a tu host igual que un navegador y lee el certificado que se sirve realmente. No le importa por qué algo salió mal, así que detecta los cinco fallos anteriores. Una comprobación útil revisa:

• cuántos días le quedan al certificado que se sirve;
• si cubre el nombre de host que estás comprobando;
• si la cadena llega a una raíz de confianza;
• si es autofirmado, si aún no es válido o si está firmado con un hash débil;
• cuándo aparece un certificado nuevo: la confirmación de que la renovación llegó a producción.

Los umbrales de alerta tienen que adaptarse a la vida del certificado. Un aviso de "quedan 30 días" tiene sentido con un certificado de un año, pero con uno de 47 días saltaría unas dos semanas después de la instalación, mientras tu automatización funciona perfectamente. Los umbrales fijos enseñan a la gente a ignorar las alertas, y una alerta ignorada es peor que ninguna.

Cómo gestiona AlertSleep los certificados más cortos

En AlertSleep, la monitorización de certificados forma parte de cada monitor HTTPS, no es un producto aparte. Para cada uno:

• el certificado se comprueba cada 6 horas;
• los avisos se envían 30, 14, 7, 3 y 1 día antes de la caducidad, pero un umbral se omite cuando equivale a un tercio de la vida del certificado o más, así que un certificado corto recién renovado nunca dispara una alarma;
• recibes una alerta cuando el certificado ha caducado, aún no es válido, no cubre el dominio, es autofirmado, usa un hash de firma débil, tiene la cadena rota o directamente no existe;
• se te avisa cuando se empieza a servir un certificado nuevo, para que veas que la renovación llegó a producción en lugar de suponerlo.

En la práctica, los umbrales quedan así:

Las alertas llegan por correo electrónico y al panel, y también por Slack, Telegram, Microsoft Teams y las demás integraciones en las que actives las notificaciones de certificados.

Comprueba un dominio ahora mismo: pásalo por el SSL Checker gratuito. Deja tu correo junto al resultado y seguiremos vigilando ese certificado por ti y te avisaremos antes de que caduque. Todo lo demás está explicado en la página de monitorización SSL.

Lista de tareas para terminar antes del 15 de marzo de 2027

1. Haz una lista de todos los nombres de host públicos con certificado: sitios web, APIs, servidores de correo, endpoints de la CDN, páginas de estado. Los registros de Certificate Transparency (por ejemplo, crt.sh) muestran todos los certificados emitidos para tu dominio, incluidos los que ya habías olvidado.
2. Para cada uno, anota qué lo renueva y si el proceso está automatizado de principio a fin, incluida la recarga del servidor o la subida a la CDN.
3. Sustituye la renovación a intervalo fijo por una renovación basada en la vida restante, o por ARI si tu cliente ACME lo admite.
4. Prueba el proceso de validación: las credenciales de la API de DNS, su fecha de caducidad, los registros CAA y las reglas del firewall para los desafíos HTTP.
5. Localiza los certificados manuales en appliances, paneles de hosting y configuraciones de CDN con certificados subidos a mano, y planifica automatizarlos o pasarlos a certificados gestionados.
6. Pon una comprobación externa en cada nombre de host del paso 1, para que el próximo fallo aparezca como una alerta y no como un aviso del navegador.

Preguntas frecuentes

¿Los certificados que ya tengo dejan de funcionar el 15 de marzo de 2027?

No. Los límites se aplican a los certificados emitidos en esa fecha o después. Un certificado SSL de 200 días emitido el 1 de marzo de 2027 sigue siendo válido hasta su propia fecha de caducidad.

¿Afecta a los certificados internos o privados?

No. Las reglas cubren los certificados TLS de confianza pública emitidos según los Baseline Requirements del CA/Browser Forum. Una CA privada que se usa dentro de tu empresa sigue tu propia política.

¿Puedo evitar el límite comprando un certificado OV o EV?

No. La validez máxima es la misma para los certificados DV, OV y EV. Los certificados de pago tienen más probabilidades de renovarse a mano, así que suelen ser los primeros en dar problemas.

¿Por qué se acorta la validez de los certificados SSL?

Una vida más corta limita el tiempo durante el que se puede abusar de un certificado comprometido o emitido por error, y reduce la dependencia de las comprobaciones de revocación, que los navegadores hacen de forma poco fiable. Además obliga a automatizar, lo que elimina el paso humano en el que fallan la mayoría de las renovaciones.

¿Cuántas veces al año tendré que renovar un certificado SSL de 47 días?

Al menos ocho veces por certificado, y unas doce con un margen de seguridad razonable. Con una automatización completa no supone más trabajo que una sola renovación; sin ella, es una tarea mensual por cada nombre de host.

Fuentes

• CA/Browser Forum — Votación SC-081v3: calendario de reducción de los periodos de validez y de reutilización de datos
• DigiCert — La vida de los certificados TLS se reducirá oficialmente a 47 días
• Let's Encrypt — Reducción de la vida de los certificados a 45 días
• Let's Encrypt — Fin de los correos de aviso de caducidad