El 6 de diciembre de 2018, unos 32 millones de clientes de O2 en Reino Unido se quedaron sin datos móviles durante casi un día entero. A la misma hora, al otro lado del mundo, decenas de millones de usuarios de SoftBank vivían lo mismo en Japón. No hubo ataque. No se quemó ningún router. La causa fue un certificado caducado en el software SGSN-MME de Ericsson, el equipo que gestiona el tráfico en el núcleo de esas redes móviles. Cuando un nodo detecta que su certificado ha vencido, se apaga solo: es una medida de seguridad pensada para que nadie aproveche esa grieta para colarse. El problema es que esa misma medida, multiplicada por miles de nodos, dejó a parte de Europa y de Asia sin cobertura. La factura del incidente se estimó en cifras cercanas a los 100 millones de libras. Todo, por una fecha.
Y si piensas que eso solo le pasa a quien gestiona infraestructura de telecomunicaciones, mira hacia febrero de 2020. Un lunes por la mañana, justo cuando millones de personas arrancaban la semana, Microsoft Teams dejó de funcionar durante unas tres horas. ¿El motivo? A Microsoft se le había olvidado renovar un certificado de autenticación. Una compañía que, por cierto, vende software capaz de avisar precisamente de eso. Unos veinte millones de usuarios tirados por un descuido que cualquiera con un poco de oficio habría evitado con un script y un cron.
Los certificados TLS son la base de la confianza en internet. Sin ellos no hay cifrado fiable, no hay identidad verificable, no hay comunicación segura entre servicios. Pero, a diferencia de otros componentes críticos, los certificados tienen fecha de caducidad y requieren renovación periódica. Y esa renovación, si no se automatiza y se vigila bien, es una fuente constante de incidentes evitables. De los dos titulares de arriba al tuyo solo hay una diferencia de escala.
Este artículo no es un tutorial paso a paso. Es una guía de criterio: qué decisiones tomar, qué vigilar y cómo no acabar siendo el siguiente caso de estudio.
Por qué fallan los certificados
Los certificados TLS caducan. Eso es un hecho técnico, no un defecto de diseño. La caducidad forzada limita el daño que puede hacer una clave privada comprometida y obliga a renovar la cadena de confianza con regularidad. Pero esa misma caducidad significa que alguien tiene que renovar antes de que expire. Y ahí empiezan los problemas.
El error más común no es técnico: es organizativo. Alguien generó un certificado hace dos años, lo instaló en varios servicios, documentó el proceso en un sitio que ya nadie consulta y se olvidó del asunto. Cuando caduca, nadie sabe quién lo gestionaba ni dónde está instalado exactamente. La renovación se convierte en una carrera contrarreloj para localizar todos los servicios afectados. Es, literalmente, lo que le pasó a Ericsson: el código defectuoso llevaba meses corriendo y el aviso fue el apagón.
El otro problema habitual es la renovación manual. Funciona bien con tres certificados y un equipo pequeño. Deja de funcionar con treinta servicios, varios entornos y rotación de personal. La renovación manual no escala y depende de que alguien se acuerde a tiempo. El día que esa persona está de vacaciones, o ya no trabaja en la empresa, el certificado vence solo.
El margen ya no es el que era
Durante años, la respuesta cómoda era pedir certificados de larga duración para tener que renovar lo menos posible. Eso se ha acabado. En abril de 2025, el CA/Browser Forum —el organismo donde se sientan las autoridades de certificación y los fabricantes de navegadores— aprobó una propuesta de Apple para recortar drásticamente la vida útil de los certificados TLS públicos. La votación salió adelante sin un solo voto en contra.
El recorte es por fases, y conviene tenerlo presente porque ya está en marcha:
- Hasta el 15 de marzo de 2026, el máximo eran 398 días.
- Desde el 15 de marzo de 2026, el máximo es de 200 días. Esto ya está vigente.
- Desde marzo de 2027, bajará a 100 días.
- Desde marzo de 2029, el tope será de 47 días.
A eso se suma que el periodo durante el cual se puede reutilizar la validación de dominio se reduce hasta unos diez días al final de la transición. En la práctica, casi cada emisión exigirá volver a validar.
La lectura para quien administra sistemas es directa: lo que hoy renuevas una vez al año, en pocos años habrá que renovarlo cada seis o siete semanas. Renovar a mano deja de ser incómodo para volverse inviable. No es una recomendación de un blog de seguridad; es un requisito que impondrán navegadores y autoridades de certificación. Quien no automatice antes de 2029 no es que vaya a trabajar peor: es que sus servicios dejarán de validar.
Qué vigilar antes de que sea tarde
Vigilar certificados no es opcional. Es tan crítico como vigilar el espacio en disco o la memoria. Un certificado caducado puede tumbar un servicio de cara al público o romper la comunicación entre componentes internos. Las dos cosas son inaceptables en producción.
Lo primero, la fecha de caducidad. Parece obvio, pero muchos equipos solo se enteran de que un certificado ha vencido cuando empiezan a llegar los errores. La monitorización debe avisar con antelación suficiente para actuar. Con certificados de larga duración, treinta días era un margen razonable; con la duración recortándose hacia los 47 días, ese margen hay que ajustarlo y, sobre todo, no depender de que lo mire una persona.
No basta con vigilar el certificado del servidor web principal. Hay que comprobar todos los puntos donde se usa TLS: balanceadores de carga, APIs internas, conexiones entre microservicios, interfaces de administración, sistemas de monitorización. Es habitual que un certificado secundario pase desapercibido hasta que alguien intenta acceder a ese servicio y se encuentra el error. Y los internos son los más traicioneros: cuando uno de esos caduca, no genera un mensaje claro para el usuario final, solo registros crípticos en servicios intermedios que cuesta horas correlacionar.
Conviene vigilar también la cadena completa. Un certificado puede ser válido, pero si falta un intermedio o la cadena está mal montada, los clientes verán errores de validación. Esto se nota especialmente cuando no todos los clientes tienen las mismas versiones de navegadores o de librerías TLS.
Automatizar la rotación sin perder el control
La automatización ha mejorado muchísimo. Let’s Encrypt popularizó la emisión automática con el protocolo ACME, y hoy hay múltiples herramientas que renuevan sin intervención manual. Sus certificados duran noventa días por defecto, y desde 2025 ofrecen incluso opciones de vida ultracorta, de apenas unos días, pensadas justo para flujos totalmente automatizados. Pero automatizar no es sinónimo de olvidarse.
La automatización debe incluir validación. No basta con que un proceso renueve: hay que comprobar que la renovación ha funcionado, que el nuevo certificado se ha desplegado y que los servicios lo están usando de verdad. Una renovación que falla en silencio es peor que la manual, porque genera una falsa sensación de seguridad. Crees que está cubierto, y no lo está.
Hay que decidir también dónde se guardan las claves privadas. Automatizar la emisión implica que algún sistema tiene acceso a ellas, y ese sistema debe estar protegido en consecuencia. No tiene sentido cifrar el tráfico con TLS si las claves acaban en un repositorio público o en un servidor sin medidas mínimas.
En entornos con muchos servicios, centralizar compensa. Herramientas como cert-manager en Kubernetes, o un buen gestor de secretos, permiten emitir, renovar y distribuir certificados de forma coordinada. Eso reduce el riesgo de que uno quede olvidado en algún rincón de la infraestructura, que es precisamente el rincón donde luego salta el incendio.
Errores que se repiten
Confiar ciegamente en que la renovación automática siempre funcionará es el primero. Los procesos automáticos fallan: por cambios en la infraestructura, por problemas de red, por una actualización que rompe compatibilidad. Si no compruebas que la renovación se completó, te enteras el día que el certificado vence.
No tener inventario es el segundo. Cuando un certificado caduca, la primera pregunta es siempre la misma: ¿dónde más está instalado esto? Sin un inventario actualizado, la respuesta es «no lo sabemos», y eso significa buscar a ciegas por todos los servicios. Es la diferencia entre resolver un incidente en diez minutos o en diez horas.
Y el tercero, ignorar lo interno. Muchos equipos vigilan de cerca lo que da la cara al público y se olvidan de los certificados que cifran las comunicaciones entre servicios. Cuando uno de esos cae, el diagnóstico es más lento porque el síntoma no es evidente. El usuario no ve un error de certificado: ve que «algo va raro».
Qué se gana y qué se pierde
Automatizar y monitorizar tiene un coste inicial: configurar las herramientas, integrarlas con lo que ya tienes y formar al equipo. Pero se amortiza rápido. Cada incidente evitado ahorra horas de trabajo urgente, desgaste y, a veces, dinero contante y sonante —pregúntale a O2.
También hay contrapartidas honestas. La automatización introduce dependencias: si usas un proveedor externo para emitir, confías en que estará disponible cuando toque renovar; si usas una herramienta concreta, asumes que seguirá siendo compatible con tu infraestructura. Son dependencias manejables, pero conviene tenerlas presentes y no descubrirlas el peor día. Y la monitorización añade ruido al sistema de alertas, así que hay que calibrar los umbrales: avisar con margen para reaccionar, pero no tan pronto ni tan a menudo que las alertas se acaben ignorando por costumbre.
El criterio que de verdad importa
Un certificado caducado no es nunca un fallo criptográfico. La criptografía funcionó: el sistema hizo exactamente lo que debía al encontrarse una fecha vencida. Lo que falla está siempre antes —un inventario que nadie mantenía, un proceso que dependía de la memoria de una persona, una renovación que se daba por hecha. Ericsson no cayó por no saber de TLS. Microsoft tampoco. Cayeron porque nadie estaba mirando el calendario.
La diferencia entre esos titulares y un equipo que duerme tranquilo no está en las herramientas, que hoy son mejores que nunca. Está en haber decidido, antes de que pase nada, que ningún certificado vencerá sin que alguien lo haya visto venir. Y con los 47 días asomando en el horizonte, esa decisión ha dejado de ser una buena práctica recomendable. Es, sencillamente, la única forma de que el sistema siga en pie.
Para seguir aprendiendo
- Documentación oficial de Let’s Encrypt — Explica el protocolo ACME y cómo funciona la emisión automática, con ejemplos de integración en distintos entornos. https://letsencrypt.org/docs/
- TLS Certificate Lifetimes Will Officially Reduce to 47 Days (DigiCert) — Detalle del calendario aprobado por el CA/Browser Forum y las fechas de cada fase. https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days
- Bulletproof TLS and PKI, 2.ª edición, de Ivan Ristić (Feisty Duck, 2022) — Referencia técnica completa sobre TLS, certificados e infraestructura de clave pública, con enfoque práctico en seguridad. https://store.feistyduck.com/products/bulletproof-ssl-and-tls-2ed
- Proyecto cert-manager — Controlador de Kubernetes para gestión automática de certificados TLS, con documentación detallada sobre patrones de uso en entornos en la nube. https://cert-manager.io/
- Documentación de OpenSSL — Herramienta fundamental para trabajar con certificados, claves y cadenas de confianza desde línea de comandos. https://www.openssl.org/docs/