Gestión del ciclo de vida de los certificados (CLM): la guía completa para sobrevivir a los certificados cortos
Por CaptainDNS
Publicado el 9 de julio de 2026
- La aritmética lo cambia todo: un parque de 1000 certificados renovados cada 47 días genera más de 7700 renovaciones al año, es decir de 8 a 9 veces el volumen de un ciclo anual
- Las herramientas van con retraso: según el informe PKI de Keyfactor (2024), solo el 32 % de las organizaciones dispone de una herramienta de gestión del ciclo de vida de los certificados, mientras que el 86 % sufrió una caída ligada a un certificado en el último año
- Seis fases, un bucle: inventario, emisión, implementación, renovación, revocación y supervisión, orquestados por ACME (RFC 8555) y ARI (RFC 9773), forman un ciclo cero-touch
- Para entender por qué la duración baja a 47 días, consulta el calendario completo de la reducción SC-081v3; este artículo trata cómo sobrevivir operativamente
El 21 de julio de 2024, el Banco de Inglaterra cortó su sistema de pagos interbancarios CHAPS durante 91 minutos. Ni ciberataque ni fallo de hardware. Un certificado TLS caducado en un componente de la red. Durante una hora y media, miles de millones de libras en transacciones de alto valor quedaron en espera por culpa de un archivo de unos pocos kilobytes que había superado su fecha. La lección es brutal: en una infraestructura moderna, un certificado olvidado es una bomba de relojería.
El incidente no tiene nada de aislado, y el contexto lo agrava. El CA/Browser Forum aprobó la reducción de la duración de vida máxima de los certificados TLS a 47 días para marzo de 2029, con fases intermedias en 2026 y 2027. El debate está cerrado: los certificados cortos llegan, lo quieran o no los equipos de operaciones. La verdadera pregunta ya no es si hay que prepararse, sino cómo seguir el ritmo. Renovar un certificado una vez al año es una tarea de calendario. Renovarlo cada 47 días en todo un parque es ingeniería de producción.
Esta guía es el manual de supervivencia. Divide la vida de un certificado en seis fases, muestra cómo ACME y su extensión ARI transforman este ciclo en un bucle cero-touch, desarrolla un plan de acción y luego se amplía hacia la cripto-agilidad y la migración post-cuántica. Se dirige a los administradores de sistemas, los ingenieros de plataforma y los CISO que deben construir una cadena de renovación que aguante. El porqué del calendario regulatorio lo trata en detalle el artículo sobre la reducción a 47 días. Aquí hablamos de mecánica.
Verifica y supervisa la caducidad de tus certificados
El verdadero problema ya no es la duración, es el volumen
La reacción instintiva ante los certificados de 47 días se centra en la duración: «mi certificado ya solo dura un mes y medio». Análisis equivocado. Un certificado corto no es más frágil que uno largo; cifra exactamente de la misma manera. El verdadero problema es aritmético. Está en la frecuencia de las operaciones: lo que atasca es la multiplicación de las renovaciones a escala de un parque.
La explosión aritmética del volumen
Haz el cálculo sobre un parque de tamaño medio. Con certificados anuales (398 días), 1000 certificados implican alrededor de 1000 renovaciones al año, es decir menos de tres al día. Es manejable, incluso a mano, con una hoja de cálculo y disciplina.
Pasa a 47 días. Cada certificado debe renovarse aproximadamente cada 30 días (con el margen de seguridad integrado en la cifra 47), es decir unas 8 veces al año. Los 1000 certificados generan entonces más de 7700 renovaciones anuales, es decir más de 21 operaciones al día, fines de semana y festivos incluidos. El factor multiplicador es de 8 a 9. Ningún equipo humano sigue este ritmo a mano sin errores.
Un detalle agrava la mecánica: la reutilización de las pruebas de control de dominio (reutilización DCV) baja a 10 días en la fase final, frente a los 47 días de validez del certificado. Dos contadores, dos ritmos. La validez de 47 días dice con qué frecuencia debe reemitirse el certificado; la ventana DCV de 10 días dice con qué frecuencia debe volver a probarse tu control del dominio. No confundas ambos: la validez vale 47 días, la reutilización de la prueba solo 10. Como resultado, cada renovación arrastra tras de sí una nueva validación de dominio, ya que la prueba anterior ya ha caducado. El calendario de estas fases se trata en la guía dedicada; quédate con que la carga de validación también se multiplica.
El coste real de una caducidad
¿Por qué tanta atención a un archivo que caduca? Porque una caducidad no detectada corta el servicio, y el corte sale caro. Los incidentes públicos lo recuerdan con bastante frecuencia.
La caída de CHAPS del Banco de Inglaterra del 21 de julio de 2024 (91 minutos de interrupción de un sistema de liquidación interbancaria) sigue siendo el ejemplo típico del certificado vencido en un componente crítico. Y otra vez en diciembre de 2025: el dominio bazel.build, utilizado por decenas de miles de pipelines de compilación en el mundo, se volvió inaccesible por la caducidad de su certificado, rompiendo cadenas de integración continua incluso en terceros que no tenían nada que ver. Y según el informe PKI de Keyfactor, el 86 % de las organizaciones sufrió al menos una caída ligada a un certificado en los últimos doce meses. No estamos en la cola de la distribución. Es la norma.
El coste de estas caídas se cuantifica con regularidad, pero desconfía de los atajos. Circulan varios órdenes de magnitud, procedentes de metodologías distintas, y fusionarlos en una sola cifra sería deshonesto. Circulan tres referencias distintas:
- Algunas estimaciones sectoriales sitúan el coste de una caída importante ligada a un certificado entre 500 000 y 5 millones de dólares según la criticidad del servicio afectado.
- El informe PKI de Keyfactor adelanta un coste medio de 2,86 millones de dólares por caída ligada a un certificado, para las organizaciones encuestadas.
- Otros análisis de indisponibilidad de aplicaciones retienen un orden de magnitud de 72 000 dólares por hora de interrupción para un servicio en producción.
Estas cifras no miden lo mismo (coste por incidente, coste medio declarado, coste por hora) y proceden de fuentes separadas. Coinciden en un punto: una caducidad nunca es gratis, y el precio de una buena herramienta es irrisorio a su lado.
¿Por qué solo el 32 % de las organizaciones tiene herramientas?
Si la cuestión está tan clara, ¿por qué solo el 32 % de las organizaciones dispone de una herramienta de gestión del ciclo de vida de los certificados, según Keyfactor? Se acumulan tres razones.
La inercia del modelo anual, en primer lugar. Mientras un certificado duraba un año, un recordatorio de calendario y una hoja de cálculo daban la ilusión de control. La deuda de automatización permanecía invisible, porque el olvido rara vez se pagaba. Luego, la responsabilidad fragmentada: los certificados son emitidos por equipos diferentes (red, aplicaciones, seguridad, proveedores), y nadie mantiene el inventario completo. Y la subestimación, por último. Muchos equipos creen dominar su parque cuando ignoran certificados emitidos al margen, en un subdominio de prueba o por un servicio en la nube.
El paso a los 47 días disuelve esta ilusión. Lo que era una renovación al año se vuelve inmanejable a ocho. Las herramientas ya no son un lujo. Son una condición de supervivencia.
Las 6 fases del ciclo de vida
La gestión del ciclo de vida de los certificados (CLM, por Certificate Lifecycle Management) divide la vida de un certificado en seis fases que giran en bucle. Conocerlas es identificar dónde debe intervenir la automatización y dónde un fallo se convierte en caída. Estas fases no son lineales: forman un círculo, ya que el fin de un certificado desencadena el inicio del siguiente.
Fase 1: inventario y descubrimiento
No se gestiona lo que no se ve. La primera fase establece la lista exhaustiva de los certificados en servicio, y es más difícil de lo que parece. La amenaza principal tiene un nombre: los certificados fantasma.
Un certificado fantasma (o shadow certificate) se emite fuera del proceso oficial, a menudo por un equipo que despliega un servicio en la nube, un desarrollador que prueba una funcionalidad, un proveedor que instala un equipo. No aparece en ninguna hoja de cálculo central. Caduca sin avisar. Y es él, precisamente, el que causa las caídas más sorprendentes, porque nadie lo supervisaba.
El descubrimiento se apoya en varias fuentes, ninguna completa por sí sola. Los registros de transparencia de certificados (Certificate Transparency) recogen públicamente todo certificado emitido por una CA pública para tus dominios: dicen qué se ha emitido, pero no dónde está implementado ni si sigue en servicio. El escaneo de red activo de tus rangos de direcciones IP y de tus puertos cubre ese hueco al observar lo que realmente se presenta en la red, certificados internos incluidos, ausentes de los registros públicos. Queda el punto ciego de la nube: la consulta de las API de los proveedores (balanceadores de carga gestionados, CDN, terminaciones TLS gestionadas) hace aflorar certificados que ni CT ni el escaneo ven fácilmente, porque viven en servicios opacos. Cruzar estas tres fuentes es la única manera de acercarse a la exhaustividad.
El inventario que resulta debe registrar, para cada certificado, tres metadatos no negociables. Su propietario, primero: el equipo o la persona responsable, sin quien una alerta no tiene a quién dirigirse. Su fecha de caducidad, que desencadena toda la mecánica de renovación. Y su algoritmo de clave, el dato que hará posible una migración criptográfica selectiva llegado el momento. Sin estos tres campos, las fases siguientes avanzan a ciegas: imposible alertar a la persona adecuada, priorizar las renovaciones urgentes o planificar un cambio de algoritmo. Un inventario sin propietario no es un inventario. Es una lista de sospechosos.
Fase 2: emisión
La emisión es el momento en que la CA genera el certificado. Parte de una CSR (Certificate Signing Request), una solicitud firmada que contiene la clave pública y la identidad del dominio. La clave privada, en cambio, nunca abandona el servidor. Invariante de seguridad, no negociable.
Una etapa demasiado a menudo descuidada condiciona esta fase: el registro CAA. Un registro DNS de tipo CAA declara qué autoridades de certificación tienen derecho a emitir para tu dominio. Si tu cliente de automatización apunta a una CA que el CAA no autoriza, la emisión falla en silencio. Configurar el CAA correctamente es, por tanto, un requisito previo para toda automatización que aguante; la guía completa de los registros CAA detalla la maniobra. Y en la era de las renovaciones frecuentes, un error de CAA no rompe una renovación aislada: rompe todas las renovaciones futuras.
Fase 3: implementación
Emitir un certificado no sirve de nada si no llega al servidor que lo espera. La fase de implementación copia el nuevo certificado y su clave en el lugar adecuado, y luego recarga el servicio (servidor web, balanceador de carga, terminación TLS) para que lo tenga en cuenta.
Ahí es donde interviene una pieza maestra: los deploy hooks. Un deploy hook es un script ejecutado automáticamente tras la obtención de un nuevo certificado. El punto crítico no es la recarga, es la validación antes de la recarga. Un buen hook verifica que el nuevo certificado es válido, que su cadena está completa y que la clave privada corresponde bien a la clave pública, antes de tocar el servicio en producción. Recargar con un certificado corrupto o una cadena incompleta transforma una operación rutinaria en una caída. La regla se resume en cinco palabras: validar y luego recargar, nunca al revés.
Este detalle separa una automatización que aguanta de una automatización que adormece con una falsa sensación de seguridad. Una renovación puede tener éxito del lado de la CA (el certificado se emite correctamente) y fallar del lado de la implementación (el archivo no se copia, la recarga falla, falta la cadena intermedia). Sin validación posterior a la implementación, estos fallos permanecen invisibles hasta que un visitante se topa con un error de certificado. Un hook bien diseñado va más allá de la simple verificación: abre una conexión TLS real hacia el servicio tras la recarga, confirma que el certificado servido es efectivamente el nuevo y, en caso de anomalía, conserva la configuración antigua válida en lugar de pasar a una configuración rota. Es la implementación atómica aplicada a los certificados: solo se pasa a producción si la nueva versión se ha demostrado funcional, y en caso contrario se prefiere un certificado todavía válido a un corte.
Fase 4: renovación
La renovación reemite el certificado antes de su caducidad. Es la fase más sensible: su fallo lleva directamente a la caída. Contrariamente a una idea extendida, una renovación no es una prórroga. Es una reemisión completa, con una nueva validación de dominio si la ventana DCV ha caducado.
Toda la estrategia reside en la ventana de renovación, es decir el momento en que se desencadena la operación antes de la caducidad. Demasiado pronto, se desperdicia duración de vida. Demasiado tarde, ya no hay margen en caso de problema. Los 47 días se han calibrado precisamente para dejar un margen cómodo si se renueva unos treinta días antes del vencimiento: quedan entonces unos quince días para detectar y corregir un fallo antes del corte. Pero ese margen solo vale si la renovación se intenta lo bastante pronto y si se detecta el fallo mientras corre. De ahí el papel decisivo de la supervisión.
Error clásico: tratar el fallo de renovación como un evento raro, gestionado caso por caso. A una renovación al año, pasaba. A ocho renovaciones al año y por certificado, en todo un parque, los fallos se vuelven estadísticamente ciertos. Un proveedor DNS momentáneamente indisponible, un registro CAA modificado por error, una cuota de API alcanzada, una rotación de credenciales olvidada: cada uno de estos incidentes banales bloquea una renovación. La pregunta, por tanto, no es si una renovación fallará, sino cuántas fallarán cada mes, y si tu cadena las recupera por sí sola (reintento programado) y las señala a tiempo. Un pipeline maduro trata el fallo como un caso nominal, no como una excepción.
Fase 5: revocación
La revocación invalida un certificado antes de su caducidad natural, por ejemplo tras el robo de una clave privada. Históricamente, se apoya en dos mecanismos: las listas de revocación (CRL) y el protocolo OCSP. Salvo que ambos están en gran medida rotos en la práctica (CRL demasiado voluminosas, OCSP en soft-fail que los navegadores ignoran), un punto desarrollado en la guía sobre la reducción de duración.
La buena noticia es que los certificados cortos vuelven la revocación menos crítica. Un certificado comprometido de 47 días caduca por sí solo en unas semanas, lo que acota la ventana de explotación sin depender de un mecanismo de revocación deficiente. La revocación sigue siendo útil para los compromisos graves, pero ya no es la única línea de defensa. La duración corta hace ya una parte del trabajo.
Fase 6: supervisión
La supervisión es la red de seguridad que recupera los fallos de las otras cinco fases antes de que deriven en caída. Alerta cuando se acerca la caducidad, típicamente a 60, 30, 15 y 7 días del vencimiento, con un escalado que crece a medida que la fecha se aproxima.
Un principio cuenta aquí más que los demás: la supervisión debe ser independiente del cliente de automatización. Si el sistema que renueva tus certificados es también el que te alerta de su caducidad, su fallo te priva de la renovación y de la alerta, en el peor momento. El punto de vista debe ser, por tanto, externo, observando el certificado realmente servido en la red en lugar del estado interno de la renovación. Es la diferencia entre «mi cliente cree haber renovado» y «el mundo ve un certificado válido».
Esta independencia no tiene nada de refinamiento teórico: apunta a la clase de fallos más solapada. El certificado se ha emitido correctamente, el cliente de automatización muestra «éxito», los registros internos están en verde, pero el archivo no ha aterrizado en el servidor adecuado, o un viejo nodo de un clúster sigue sirviendo el certificado antiguo, o una terminación TLS intermedia no se ha recargado. Todo eso permanece invisible desde el interior del sistema de renovación. Solo una sonda externa, que abre una conexión TLS real desde Internet y lee la fecha de caducidad del certificado efectivamente presentado, lo ve. La supervisión de último recurso no cree lo que la renovación declara: verifica lo que el servicio sirve. La misma lógica que separa una prueba unitaria de una prueba de extremo a extremo, aplicada a los certificados.
La automatización ACME: del manual al cero-touch
Las seis fases solo aguantan a alta frecuencia si están automatizadas. El protocolo que lo hace posible se llama ACME. Su extensión ARI lo vuelve fluido y previsible. Juntos, transforman un ciclo manual en un bucle cero-touch, donde la renovación se hace sin que ninguna mano humana intervenga.
El protocolo ACME (RFC 8555)
ACME (Automatic Certificate Management Environment), estandarizado en la RFC 8555, describe el diálogo automatizado entre un cliente (tu servidor) y una autoridad de certificación. Tres tiempos: el cliente prueba que controla el dominio, la CA verifica la prueba y luego emite el certificado.
Una sutileza merece que nos detengamos en ella: ACME no tiene noción de «renovación». Ningún endpoint «renew». Una renovación, en ACME, es solo una nueva emisión, idéntica a la primera. La ausencia es deliberada: garantiza que cada certificado surge de una validación fresca, sin estado persistente que pudiera divergir. Este diseño explica también por qué la reducción de la ventana DCV pesa tanto. Como cada renovación es una emisión nueva, desencadena una nueva validación en cuanto la prueba anterior ha caducado. Sin atajos.
La prueba de control del dominio pasa por dos challenges principales. Con DNS-01, el cliente publica un registro TXT bajo _acme-challenge.captaindns.com que contiene un valor derivado de un token proporcionado por la CA; esta consulta luego el DNS para verificar su presencia. Es el único challenge compatible con los certificados wildcard (*.captaindns.com), y funciona incluso cuando el servidor de destino no está expuesto en Internet, lo que lo vuelve ideal para los entornos automatizados y las infraestructuras internas. Con HTTP-01, el cliente coloca un archivo en una URL concreta (/.well-known/acme-challenge/) que la CA recupera por HTTP; más simple de poner en un servidor web ya expuesto, pero no gestiona los wildcards y supone el puerto 80 accesible desde el exterior. La elección depende de tu topología, pero DNS-01 se impone en cuanto hay wildcards, entornos sin servidor web expuesto, o ganas de desacoplar la emisión de la disponibilidad del servicio. En todos los casos, la automatización del challenge supone que tu proveedor DNS expone una API. Sin ella, DNS-01 vuelve a ser manual, y por tanto inutilizable a alta frecuencia.
La extensión ARI (RFC 9773)
ACME automatiza la emisión, pero deja una pregunta abierta: ¿cuándo renovar? La respuesta ingenua («a 30 días de la caducidad») no escala. Si todos los clientes de una CA renuevan en el mismo umbral, la CA sufre picos de carga, y una revocación de urgencia por su parte no puede señalarse a los clientes.
ARI (ACME Renewal Information), estandarizada en la RFC 9773, resuelve esto. La CA expone ahora, para cada certificado, una ventana de renovación sugerida que el cliente consulta con regularidad mediante un endpoint dedicado. En lugar de codificar en duro «renovar a 30 días de la caducidad», el cliente pregunta a la CA «¿cuándo debo renovar este certificado concreto?» y sigue la respuesta. Tres beneficios.
El suavizado, en primer lugar. La CA reparte las ventanas sugeridas en el tiempo para evitar las oleadas de renovación simultáneas. Sin ARI, millones de certificados emitidos el mismo día tenderían a renovarse el mismo día, concentrando la carga; con ARI, la CA los distribuye a lo largo de varios días, en beneficio de su propia infraestructura y de la estabilidad del ecosistema. La reactividad, después. Si la CA debe revocar un lote de certificados en masa (por ejemplo tras un incidente de conformidad que la obliga a reemitirlo todo), adelanta la ventana sugerida, y los clientes que respetan ARI renuevan antes de la revocación, sin corte. Un canal de urgencia de la CA hacia sus clientes, allí donde una revocación masiva provocaba antes caídas en cascada. El tercer beneficio reside en el rendimiento: las renovaciones guiadas por ARI escapan generalmente a los rate limits de la CA, lo que se vuelve indispensable a alta frecuencia. Un cliente que renueva ocho veces al año y por certificado, sobre miles de certificados, saturaría rápido las cuotas estándar. ARI hace así que la renovación pase de ser una decisión unilateral del cliente a una negociación continua con la CA. Resultado práctico: exigir el soporte de ARI es uno de los criterios más determinantes a la hora de elegir un cliente o una plataforma.
Elegir tu cliente: ¿scripts o plataforma?
El protocolo está estandarizado, así que la elección recae en el cliente que lo implementa. Para un servidor único, certbot renew (el cliente de referencia de la EFF) lanzado por una tarea programada basta: consulta el vencimiento, renueva cuando es necesario y desencadena los deploy hooks configurados. acme.sh, un script de shell sin dependencias, ofrece una flexibilidad comparable y admite decenas de API DNS para el challenge DNS-01.
La verdadera frontera separa el enfoque por scripts del enfoque por plataforma. Los scripts (certbot, acme.sh, un servidor con ACME nativo como algunos reverse proxies) convienen a un puñado de servidores bien controlados: coste de entrada nulo, pero el inventario, la supervisión transversal y la gobernanza permanecen sobre tus hombros. Una plataforma CLM centraliza estas funciones sobre cientos o miles de certificados heterogéneos: descubrimiento automático, panel de caducidad, políticas de emisión, control de los CAA. El detonante del cambio no es solo el número de certificados, es la heterogeneidad del parque y la necesidad de gobernanza centralizada.
El caso Let's Encrypt: el explorador de las duraciones cortas
Let's Encrypt desempeña desde hace diez años el papel de laboratorio a escala real de los certificados cortos. La autoridad anunció el 2 de diciembre de 2025 el paso de su duración por defecto de 90 días a 45 días, anticipando el calendario regulatorio para dar al ecosistema tiempo de validar sus pipelines. Ya ofrece certificados short-lived de 6 días para los entornos totalmente automatizados (CDN, plataformas cloud): la prueba de que una duración de vida de < 7 días aguanta a escala industrial. Y desde el 15 de enero de 2026, emite incluso certificados para direcciones IP, en disponibilidad general. El mensaje no varía: lo que parece extremo hoy se convierte en la norma mañana, y las infraestructuras ya automatizadas vivirán la transición como un no-evento.
🎯 Plan de acción: tu checklist CLM
La teoría está puesta. Aquí tienes la secuencia para construir una cadena de renovación que aguante. Cada etapa prepara la siguiente; no las inviertas.
- Descubrir: lanza un descubrimiento multifuente (registros Certificate Transparency, escaneo de red, API cloud) para desenmascarar los certificados fantasma. Parte del principio de que tu inventario mental es incompleto mientras no se demuestre lo contrario.
- Inventariar: registra para cada certificado su propietario, su fecha de caducidad y su algoritmo de clave. Estos tres metadatos sostienen todo lo demás.
- Desplegar un cliente ACME con ARI: elige certbot, acme.sh o una plataforma CLM según la heterogeneidad del parque, y verifica que el soporte ARI está activo para aprovechar el suavizado y la exención de rate limit.
- Validar el DNS: configura el registro CAA para autorizar tu CA, y da al cliente los accesos API DNS necesarios para el challenge DNS-01, con permisos mínimos limitados a los registros
_acme-challenge. - Cablear los deploy hooks: automatiza la implementación posterior a la emisión con una validación sistemática (cadena completa, correspondencia de clave) antes de recargar el servicio.
- Supervisar de forma escalonada e independiente: coloca alertas a 60, 30, 15 y 7 días, desde un punto de vista externo distinto de tu cliente de automatización.
- Probar en
--dry-run: verifica que la renovación funciona sin mano humana antes de contar con ella en producción. Un pipeline no probado es un pipeline que fallará en el peor momento. - Documentar la revocación de urgencia: escribe el procedimiento de revocación inmediata en caso de robo de clave, aunque las duraciones cortas reduzcan su criticidad. Un procedimiento redactado en frío vale más que una improvisación en caliente.
Manual contra automatizado: el impacto del volumen
A parque constante de 1000 certificados, el paso de 398 a 47 días multiplica la carga operativa. La automatización deja de ser un lujo para convertirse en una condición de resistencia.
Renovaciones anuales a 398 días
Alrededor de 3 operaciones al día, sostenible a mano con disciplina.
Renovaciones anuales a 47 días
Más de 21 operaciones diarias, fines de semana incluidos, fuera del alcance humano.
Factor multiplicador de carga
El volumen de operaciones se multiplica por 8 a 9 a parque constante.
Organizaciones con herramientas CLM
Según el informe PKI de Keyfactor, dos tercios de las organizaciones siguen sin herramienta dedicada.
Cripto-agilidad y migración post-cuántica
El CLM no se reduce a la caducidad. Al construir una cadena de renovación fiable, se gana una capacidad cuyo valor supera con creces la prevención de caídas: la cripto-agilidad. Es el beneficio oculto de la restricción de los 47 días.
Un modelo de tres pilares
La cripto-agilidad es la capacidad de una organización para cambiar de algoritmo criptográfico rápido y sin roturas. Se apoya en tres pilares, que recubren exactamente las funciones del CLM. El descubrimiento: saber dónde están todos tus certificados y qué algoritmos utilizan (la fase de inventario). La gobernanza: tener políticas de emisión y un control centralizado de quién emite qué (el papel de una plataforma CLM). La automatización: poder reemitir todo el parque sin mano humana (el bucle ACME). Una organización que sostiene estos tres pilares puede pivotar su criptografía. La que no los sostiene es prisionera de sus algoritmos.
¿Por qué los 47 días conllevan la cripto-agilidad?
La duración corta es un entrenamiento forzado. Un equipo que renueva sus certificados ocho veces al año, de forma automatizada y fiable, ha ejercitado su rotación hasta convertirla en un reflejo de producción. Ese músculo es exactamente lo que hace falta para cambiar de algoritmo. A la inversa, un equipo que renueva una vez al año, a mano, con dolor, será incapaz de migrar su parque de urgencia llegado el momento. La restricción regulatoria de los 47 días produce, por tanto, un efecto imprevisto: vuelve ágiles a las organizaciones a su pesar. La tarea pesada se convierte en un activo.
El post-cuántico en el punto de mira
Este músculo de rotación pronto servirá. El NIST publicó en 2024 los estándares finales de criptografía post-cuántica, en particular ML-KEM (intercambio de claves) y ML-DSA (firmas digitales), diseñados para resistir a los futuros ordenadores cuánticos. Los sistemas empiezan a integrarlos: Windows Server 2025 introdujo un soporte de los algoritmos post-cuánticos en noviembre de 2025. El paso a estos algoritmos impondrá reemitir la totalidad de los certificados existentes, quizás en un plazo ajustado.
Ahora bien, no se migra un parque que no se ve y que se renueva a mano. El CLM es el requisito previo de la migración post-cuántica: sin inventario completo, sin gobernanza y sin automatización, una migración criptográfica a escala es imposible. No vamos a desarrollar aquí la transición post-cuántica, un tema vasto en sí mismo. Solo dejar el vínculo planteado: construir hoy una cadena CLM fiable es dotarse de la única herramienta que volverá manejable esa transición mañana.
FAQ
¿Qué es la gestión del ciclo de vida de los certificados (CLM)?
El CLM (Certificate Lifecycle Management) designa el conjunto de procesos que enmarcan la vida de un certificado TLS, desde su descubrimiento hasta su revocación. Cubre seis fases: inventario, emisión, implementación, renovación, revocación y supervisión. Su objetivo es evitar las caídas ligadas a la caducidad y garantizar que cada certificado en servicio es válido, está actualizado y es conocido.
¿Cuáles son las seis fases del ciclo de vida de un certificado?
Las seis fases son: el inventario y el descubrimiento (listar todos los certificados, incluidos los fantasma), la emisión (generación mediante una CSR), la implementación (copia a los servidores y recarga), la renovación (reemisión antes de la caducidad), la revocación (invalidación en caso de compromiso) y la supervisión (alertas de caducidad). Forman un bucle continuo más que una secuencia lineal.
¿Cómo automatizar la renovación de los certificados?
La automatización se apoya en el protocolo ACME (RFC 8555), implementado por clientes como certbot o acme.sh. El cliente prueba el control del dominio mediante un challenge DNS-01 o HTTP-01, la CA verifica y luego emite el certificado. La extensión ARI (RFC 9773) añade una ventana de renovación sugerida por la CA. Los deploy hooks despliegan a continuación el certificado sin intervención humana.
¿Cómo supervisar la caducidad de un certificado?
Una supervisión eficaz escalona las alertas a 60, 30, 15 y 7 días del vencimiento, con un escalado creciente. El punto que lo cambia todo: debe ser independiente del cliente de automatización y observar el certificado realmente servido en la red, no el estado interno de la renovación. Un fallo de la renovación se detecta así incluso cuando el propio sistema de renovación está caído.
¿Qué es un certificado fantasma o shadow IT?
Un certificado fantasma es un certificado emitido fuera del proceso oficial, a menudo por un equipo cloud, un desarrollador o un proveedor, sin figurar en el inventario central. Estos certificados caducan sin avisar y causan caídas sorprendentes, porque nadie los supervisa. Su descubrimiento pasa por los registros Certificate Transparency, el escaneo de red y las API de los proveedores cloud.
¿Cuál es la diferencia entre ACME y ARI?
ACME (RFC 8555) es el protocolo que automatiza la emisión de los certificados: prueba de control del dominio, verificación, emisión. ARI (ACME Renewal Information, RFC 9773) es una extensión que responde a la pregunta del momento de la renovación: la CA expone una ventana sugerida, lo que suaviza la carga, permite revocaciones de urgencia anticipadas y exime generalmente las renovaciones de los límites de rendimiento.
¿Cuál es la duración de vida de un certificado TLS en 2026?
En 2026, la duración máxima de un certificado TLS público pasa a 200 días (primera fase), antes de 100 días en 2027 y luego 47 días en 2029, según el ballot SC-081v3 del CA/Browser Forum. El calendario completo y las razones de esta reducción se detallan en nuestra guía sobre la reducción a 47 días.
¿Hace falta una plataforma CLM o bastan los scripts?
Los scripts (certbot, acme.sh) bastan para un puñado de servidores bien controlados: coste nulo, pero inventario y gobernanza a tu cargo. Una plataforma CLM se vuelve necesaria en cuanto el parque es heterogéneo, disperso entre varios equipos, y requiere una gobernanza centralizada (descubrimiento automático, políticas de emisión, panel de control). El criterio de cambio es la heterogeneidad y la necesidad de control, no solo el número de certificados.
¿Qué es la cripto-agilidad y por qué es importante?
La cripto-agilidad es la capacidad de cambiar de algoritmo criptográfico rápidamente y sin roturas. Se apoya en tres pilares que recubren el CLM: descubrimiento, gobernanza y automatización. Una organización que renueva sus certificados de forma fiable ha ejercitado su proceso de rotación, lo que la prepara para las migraciones futuras, en particular hacia la criptografía post-cuántica estandarizada por el NIST.
¿Cuánto cuesta una caída ligada a un certificado?
Circulan varias estimaciones, procedentes de metodologías distintas que no hay que fusionar: una horquilla de 500 000 a 5 millones de dólares por caída importante según la criticidad del servicio, un coste medio de 2,86 millones de dólares por caída declarada en el informe PKI de Keyfactor, y un orden de magnitud de 72 000 dólares por hora de indisponibilidad de aplicaciones. Convergen en un punto: una caducidad nunca es gratis.
Descarga las tablas comparativas
Los asistentes pueden reutilizar las cifras accediendo a los archivos JSON o CSV.
📖 Glosario
- CLM (Certificate Lifecycle Management): conjunto de procesos que cubren las seis fases de la vida de un certificado TLS, desde el descubrimiento hasta la revocación, cuyo objetivo es evitar las caídas de caducidad y mantener un parque controlado.
- ACME (Automatic Certificate Management Environment): protocolo estandarizado (RFC 8555) que automatiza el diálogo entre un cliente y una autoridad de certificación para la emisión y la renovación de certificados. No posee noción de renovación: cada renovación es una nueva emisión.
- ARI (ACME Renewal Information): extensión de ACME (RFC 9773) por la cual la CA comunica al cliente una ventana de renovación sugerida, que permite el suavizado de carga, las revocaciones de urgencia anticipadas y la exención de los límites de rendimiento.
- DCV (Domain Control Validation): proceso por el cual una CA verifica que el solicitante controla el dominio. La reutilización de una prueba DCV está limitada a 10 días en la fase final de SC-081v3, imponiendo una revalidación casi continua.
- CSR (Certificate Signing Request): solicitud firmada que contiene la clave pública y la identidad del dominio, enviada a la CA para obtener un certificado. La clave privada asociada nunca abandona el servidor.
- Revocación, CRL y OCSP: mecanismos destinados a invalidar un certificado antes de su caducidad. Las CRL (listas de revocación) son demasiado voluminosas y OCSP sufre del soft-fail que los navegadores ignoran, lo que vuelve la revocación poco fiable; los certificados cortos reducen su criticidad.
- Cripto-agilidad: capacidad de una organización para migrar rápidamente hacia nuevos algoritmos criptográficos, apoyada en los tres pilares descubrimiento, gobernanza y automatización, todos cubiertos por el CLM.
- Certificado short-lived: certificado de duración de vida muy corta (6 días en Let's Encrypt), destinado a los entornos totalmente automatizados y que demuestra la viabilidad industrial de las duraciones ultra-cortas.
Un inventario actualizado y una cadena de renovación automatizada solo valen si la capa DNS que las sostiene está sana. Como la validación de dominio depende ahora de la cadena de confianza DNS, verifica que tu DNSSEC es válido y coherente con nuestra herramienta de diagnóstico DNSSEC: una cadena rota bloquea en silencio cada renovación.
📚 Guías de certificados y DNS relacionadas
- SC-081v3: certificados TLS de 47 días, por qué y cómo prepararte: el calendario regulatorio y el porqué de la reducción de duración.
- DANE y TLSA: la guía completa: autenticar tus certificados mediante el DNS y gestionar la rotación TLSA al ritmo de las renovaciones.
- Registros CAA: la guía completa: bloquear las autoridades autorizadas a emitir para tu dominio, requisito previo de una automatización fiable.
Fuentes
- RFC 8555: Automatic Certificate Management Environment (ACME)
- RFC 9773: Automated Certificate Management Environment (ACME) Renewal Information (ARI) Extension
- Let's Encrypt: Decreasing Certificate Lifetimes to 45 Days
- Ballot SC-081v3: Reduce Validity and Data Reuse Periods (CA/Browser Forum)
- Keyfactor: State of Machine Identity Management (PKI Report 2024)
