La expiración de certificados es una de las causas más evitables de interrupciones en producción y, aun así, sigue ocurriendo a gran escala. El informe CyberArk 2025 State of Machine Identity Security Report revela que el 72% de las organizaciones sufrió al menos una interrupción relacionada con certificados en el último año, y el 34% experimentó varias. El informe Keyfactor 2024 PKI and Digital Trust Report eleva esa cifra aún más: el 88% de las empresas continúa sufriendo interrupciones no planificadas por certificados expirados. No son casos excepcionales. Son el resultado predecible de tratar la gestión de certificados como algo secundario.

Las consecuencias van de lo embarazoso a lo catastrófico. Un certificado expirado le costó a Microsoft Teams una interrupción global de aproximadamente tres horas en febrero de 2020. En diciembre de 2018, un certificado expirado en un nodo SMF de Ericsson dejó sin servicio a O2 UK y SoftBank durante casi un día completo, afectando a unos 32 millones de usuarios. Tras la brecha de Equifax en 2017, los investigadores encontraron un dispositivo de monitorización cuyo certificado SSL llevaba 19 meses expirado, período durante el cual 265 accesos no autorizados a datos pasaron desapercibidos, junto con otros 324 certificados expirados en la infraestructura. El patrón es constante: el certificado es conocido, la fecha de expiración es conocida, y la interrupción ocurre de todas formas.

Para los equipos de infraestructura que operan bajo NIS2 o DORA, las consecuencias están ahora explícitamente recogidas en la regulación. NIS2 (Directiva (EU) 2022/2555) exige el uso efectivo de criptografía y cifrado, y establece umbrales de incidente concretos: una indisponibilidad completa de más de 30 minutos activa obligaciones de notificación para proveedores de servicios cloud, CDN y servicios gestionados. DORA (Reglamento (EU) 2022/2554), que entró en vigor el 17 de enero de 2025, define incidente relacionado con TIC de forma suficientemente amplia como para incluir directamente las interrupciones por certificados expirados. Un certificado que deja fuera de servicio una plataforma de pagos es un incidente mayor notificable bajo el Artículo 3(8) de DORA, con una ventana de clasificación de 4 horas y un plazo de notificación a los supervisores de 72 horas. El coste operativo de gestionarlo mal incluye ahora la exposición regulatoria.

La presión está a punto de intensificarse aún más. En abril de 2025, el CA/Browser Forum aprobó la Ballot SC-081v3, propuesta originalmente por Apple, con 29 votos a favor y ninguno en contra. La propuesta establece una reducción escalonada de la validez de los certificados TLS: un máximo de 200 días a partir de marzo de 2026, 100 días a partir de 2027, y 47 días antes del 15 de marzo de 2029. Con el máximo actual de 398 días, un equipo que gestiona 100 certificados públicos realiza unas 100 renovaciones al año. Con una validez de 47 días, ese mismo conjunto requiere aproximadamente 800 renovaciones anuales. Cualquier equipo que siga renovando certificados manualmente encontrará la carga de trabajo insostenible mucho antes de que llegue 2029.

Por qué la automatización por sí sola no es suficiente

La respuesta instintiva es automatizar. Let’s Encrypt y el protocolo ACME han hecho que la renovación automatizada sea genuinamente accesible y, para servicios web de cara al público, constituyen una base razonable. Pero la automatización introduce sus propios modos de fallo, y los entornos regulados requieren algo más que un script de renovación que funciona hasta que deja de hacerlo en silencio.

Los fallos de renovación de Let’s Encrypt son un patrón real y recurrente. Los límites de tasa, los retrasos en la propagación de DNS, las reglas de firewall que bloquean el challenge HTTP-01 o DNS-01, y los hooks de renovación mal configurados provocan fallos silenciosos. El certificado no se renueva, la alerta no se dispara, y la expiración llega según lo previsto. Una dependencia única de una CA es también un riesgo de concentración: Let’s Encrypt ha experimentado incidentes de disponibilidad, y cualquier CA puede verse comprometida, considerada no confiable o temporalmente inaccesible. Depender de una sola CA para toda tu infraestructura es un punto único de fallo operacional.

La automatización elimina el problema del olvido humano. No elimina la necesidad de que las personas verifiquen que la automatización está funcionando.

El vacío que acaba con los equipos es la ausencia de monitorización independiente. La automatización de renovaciones y la monitorización de expiración son preocupaciones distintas y deben tratarse como sistemas separados. Si tu única señal de que un certificado está a punto de expirar es la propia herramienta de renovación, no tienes ninguna capa de verificación independiente. Para cuando un navegador o un balanceador de carga rechace el certificado, la interrupción ya habrá comenzado.

Un enfoque sistemático para la gestión del ciclo de vida de certificados

Un programa robusto de gestión del ciclo de vida de certificados tiene cuatro capas diferenciadas, y las cuatro deben estar en marcha antes de que el mandato de 47 días haga que los enfoques parciales sean inviables.

1. Inventario completo y descubrimiento continuo

No puedes gestionar lo que no has encontrado. Comienza con un inventario completo de cada certificado en tu infraestructura: de cara al público, internos, balanceadores de carga, API gateways, service meshes, conexiones de base de datos y todo lo que termine TLS. Las herramientas de descubrimiento automatizado que escanean tus rangos de red y analizan los logs de transparencia de certificados ofrecen una cobertura que las hojas de cálculo manuales no pueden mantener. Los certificados de PKI internos se pasan por alto con frecuencia porque no son visibles públicamente; son igual de capaces de causar interrupciones.

2. Estrategia multi-CA con herramientas compatibles con ACME

No concentres toda tu infraestructura de certificados en una única CA. Mantén al menos dos relaciones con CA para los servicios críticos y prueba la conmutación por error entre ellas antes de necesitarla. Las plataformas de gestión de certificados compatibles con ACME (cert-manager en Kubernetes es el ejemplo más ampliamente desplegado) admiten múltiples emisores y pueden configurarse para conmutar por error o alertar cuando un intento de renovación falla contra el emisor primario. Para los servicios internos, opera tu propia CA intermedia bajo una raíz de confianza, de modo que la emisión de certificados internos no dependa en absoluto de la disponibilidad de CA externas.

3. Monitorización independiente de expiración con umbrales de alerta estrictos

Monitoriza la expiración de certificados de forma independiente a tus herramientas de renovación. Los servicios de monitorización externos, los exportadores de Prometheus como ssl-exporter, o las plataformas de gestión de PKI especializadas ofrecen esta capacidad. Establece umbrales de alerta a 30 días, 14 días y 7 días, con severidad creciente. Con una validez de 47 días, una alerta a 30 días se dispara a los 17 días de la emisión: esa es tu señal de que algo en la cadena de renovación ya ha fallado y necesita atención humana inmediata. Integra estas alertas en tu flujo de gestión de incidentes, no solo en un panel que alguien consulta ocasionalmente.

4. Registros de renovación auditables para cumplimiento normativo

Tanto NIS2 como DORA exigen a las organizaciones demostrar prácticas efectivas de gestión de riesgos, no solo afirmarlas. Los eventos de renovación de certificados, los fallos y las intervenciones manuales deben registrarse con marcas de tiempo y conservarse de forma que permita la auditoría. Esto es especialmente relevante para las entidades financieras bajo DORA, donde el régimen de la EBA se aplica a más de 22.000 entidades financieras en la UE y los auditores buscarán evidencia de que los controles de riesgo TIC funcionan según lo documentado.

Cómo gestionamos esto en DIVERSITY

En nuestra infraestructura de MAD1, MUC1, HEL1 y AMS1, gestionamos la terminación TLS en múltiples capas: edge, balanceadores de carga, comunicación interna entre servicios y el plano de gestión en sí. Ejecutamos cert-manager en nuestros clústeres de Kubernetes con múltiples configuraciones de emisores, respaldado por una monitorización independiente que alerta de forma separada al flujo de renovación. Para nuestros servicios internos, operamos nuestra propia PKI en lugar de enrutar la emisión de certificados internos a través de CA públicas, lo que elimina las dependencias de disponibilidad externa de la ruta crítica.

Los clientes que ejecutan cargas de trabajo en nuestros entornos gestionados heredan la capa de monitorización y alertas como parte de la plataforma. Para los clientes que gestionan sus propias infraestructuras de certificados sobre nuestra infraestructura, especialmente los del sector financiero y sanitario donde la exposición a NIS2 y DORA es directa, recomendamos y podemos ayudar a implementar el enfoque completo de cuatro capas descrito anteriormente. El SLA contractual de disponibilidad del 99,9% que ofrecemos solo tiene sentido si los servicios que corren sobre nuestra infraestructura no se están dejando fuera de servicio con certificados expirados.

Qué hacer antes de marzo de 2026

La reducción escalonada del CA/Browser Forum comienza en marzo de 2026, lo que da a los equipos de infraestructura aproximadamente un año para alcanzar un estado en el que la renovación de certificados esté completamente automatizada, monitorizadas de forma independiente y sea auditable. Ese plazo parece cómodo hasta que se tiene en cuenta el trabajo organizativo: completar el inventario, migrar los servicios heredados que no pueden soportar la renovación automatizada, y construir la capa de monitorización desde cero si aún no existe.

Empieza por el inventario. Encuentra cada certificado en tu infraestructura, incluidos los que no figuran en ninguna lista. Luego automatiza la renovación de todo lo que pueda automatizarse, construye monitorización independiente para todo lo que no pueda, y trata cualquier proceso de renovación manual como deuda técnica con una fecha límite inamovible. El mandato de 47 días no es un problema futuro. Es el mecanismo que hace imposible seguir aplazando el trabajo que ya debería estar hecho.