Certificados TLS de 200 días: lo que hay que comprobar

Un certificado TLS protege los portales VPN, la interfaz de administración de un firewall, un proxy inverso, un controlador inalámbrico, un equilibrador de carga e incluso la página de administración web de un dispositivo. Estos certificados de confianza pública utilizados por esos servicios ya no pueden seguir siendo válidos durante aproximadamente un año. El período de validez máximo se está reduciendo por etapas, y la primera reducción ya está en vigor.

Desde el 15 de marzo de 2026, un certificado TLS de confianza pública de nueva emisión no puede tener una validez superior a 200 días. Los primeros certificados emitidos con ese límite alcanzarán su vencimiento a finales de septiembre o principios de octubre de 2026. El máximo volverá a caer a 100 días el 15 de marzo de 2027, y a 47 días el 15 de marzo de 2029.

Qué está sucediendo ahora, y qué viene después

El calendario fue establecido por el Foro de CA/Navegadores, en una decisión de 2025 llamada votación SC-081v3. Esta decisión reduce la validez máxima de un certificado TLS de confianza pública en cuatro pasos:

• 398 días, el máximo anterior
• 200 días, a partir del 15 de marzo de 2026
• 100 días, a partir del 15 de marzo de 2027
• 47 días, a partir del 15 de marzo de 2029

El efecto práctico es un reemplazo más frecuente. Con el máximo anterior, un certificado se reemplazaba normalmente una vez al año. A los 200 días es cerca de dos veces al año, a los 100 días aproximadamente cuatro veces, y a los 47 días aproximadamente ocho veces.

Este cambio se aplica a los certificados de confianza pública, del tipo que un navegador o cliente coteja con un almacén de confianza público. Los certificados de una autoridad de certificación (CA) interna y privada no están cubiertos directamente, aunque muchos equipos también los están acortando.

Por qué se están reduciendo los ciclos de vida de los certificados

Hay principalmente dos razones detrás de esta medida. En primer lugar, un certificado lleva información que fue verificada cuando se emitió, y esa verificación es una instantánea en el tiempo. Cuanto más tiempo permanece válido un certificado, más margen hay para que esa instantánea se aleje de la realidad, o para que una clave o certificado comprometido siga siendo útil para un atacante. Un período de validez más corto mantiene esa ventana pequeña.

En segundo lugar, los períodos de validez más cortos empujan a todo el ecosistema hacia la automatización. Cuando un certificado duraba un año, renovarlo a mano era manejable. A los pocos meses, y más tarde a las pocas semanas, el manejo manual deja de ser realista, por lo que las herramientas tienen que tomar el relevo. El Foro de CA/Navegadores señala que los datos de validación más actualizados son uno de los beneficios de tener períodos más cortos de validez y de reutilización de datos.

La parte que los equipos pasan por alto: la renovación no es implementación

Aquí está el punto que hace tropezar a los equipos: emitir un nuevo certificado y ponerlo a funcionar son dos tareas distintas. Un flujo de trabajo completo de reemplazo de certificado consta de varios pasos:

1. La CA emite el certificado de reemplazo.
2. El certificado de reemplazo y su cadena deben llegar al sistema correcto, donde la clave privada correspondiente debe estar disponible.
3. El portal, el listener (oyente), el servidor virtual o el servicio correcto debe apuntar al nuevo certificado.
4. El sistema puede necesitar una actualización de la vinculación (binding), una actualización de configuración, una recarga o un reinicio antes de que use el nuevo certificado.
5. Una conexión TLS nueva debe confirmar que el endpoint (punto final) presenta ahora el reemplazo.

Si te saltas los últimos pasos, el sistema de renovación puede seguir informando de éxito mientras el endpoint continúa presentando el certificado antiguo. Si el nuevo certificado se encuentra en un repositorio pero el portal VPN sigue presentando el antiguo, la renovación habría funcionado sobre el papel, pero el servicio seguiría encaminado a una interrupción.

Cómo verificar el endpoint después de la implementación

Vale la pena hacer ese último paso, la verificación, de manera deliberada. Puedes realizar estas tres comprobaciones para confirmar que el endpoint está sirviendo el nuevo certificado:

• Conéctate al nombre de host y al puerto que utilizan los clientes, que pueden diferir de la dirección de administración.
• Compara la huella digital, el número de serie, el emisor y el vencimiento que devuelve el endpoint con el reemplazo que implementaste.
• Utiliza el nombre de host correcto o el valor SNI, especialmente cuando un equilibrador de carga o un proxy inverso aloja varios servicios detrás de una misma dirección.

Comprueba ambos lados de un dispositivo cuando difieran. A menudo, un firewall o un equilibrador de carga sirve un certificado en su servicio público y otro distinto en su interfaz de administración, cada uno con su propia vinculación, por lo que confirmar uno no confirma el otro.

Una autoevaluación rápida de automatización

Puedes someter a pruebas de estrés tu proceso actual formulando estas cinco preguntas:

1. ¿Puedes encontrar cada certificado y el dispositivo que lo utiliza?
2. ¿Se puede solicitar un reemplazo sin que alguien lo rastree a mano?
3. ¿Se puede instalar en el endpoint correcto de forma automática?
4. ¿Puede el servicio cargarlo sin que un administrador inicie sesión?
5. ¿Puedes confirmar el certificado que presenta el endpoint después del cambio?

Si la respuesta es “no” en algún punto, esa etapa sigue siendo manual, incluso cuando la renovación en sí está automatizada.

Preparando el proceso

La preparación para el ciclo más corto no tiene que comenzar con una reconstrucción a gran escala. Empieza por convertir cada traspaso manual en un paso documentado y repetible:

• Escanea la red y construye un inventario de lo que tienes.
• Separa los certificados de confianza pública, los privados y los autofirmados.
• Registra el dispositivo, el servicio, el propietario y el método de implementación para cada uno.
• Configura la renovación a través de la CA correcta o la integración ACME.
• Mapea dónde está implementado cada certificado y cómo se activa.
• Verifica el certificado en el endpoint después de cada cambio.
• Crea alertas sobre el vencimiento, las operaciones fallidas y las discrepancias.

Cómo puede ayudar Key Manager Plus

Una plataforma de gestión del ciclo de vida de los certificados puede centralizar y automatizar gran parte de este flujo de trabajo. ManageEngine Key Manager Plus, por ejemplo:

• Descubre certificados en toda la red, incluidos dispositivos de red, servidores y servicios en la nube.
• Los renueva a través de integraciones compatibles de CA públicas y privadas y de ACME.
• Implementa los certificados renovados en dispositivos, servidores y almacenes en la nube compatibles.
• Ejecuta acciones posteriores a la implementación para flujos de trabajo de servidores compatibles, como un script o el reinicio de un servicio.
• Comprueba la sincronización para marcar las discrepancias entre el repositorio y lo que está implementado.
• Envía alertas de vencimiento y de operaciones por correo electrónico o syslog.

Prueba Key Manager Plus para coordinar el descubrimiento de certificados, la renovación y la implementación compatibles, las comprobaciones de sincronización y la supervisión del vencimiento en un solo flujo de trabajo.

La fase de 200 días es la primera prueba práctica. Antes de que llegue el límite de 100 días, rastrea un certificado a lo largo de todo el proceso, desde el descubrimiento hasta una conexión TLS nueva que confirme que el endpoint presenta el certificado de reemplazo. Esa es la diferencia entre la renovación automatizada y un ciclo de vida de certificados automatizado.