¿Qué son los certificados de 47 días? Qué cambia, por qué es importante y cómo prepararse.

El Forode Autoridades de Certificación/Navegadores (CA/B) ha aprobado oficialmente una reducción del período máximo de validez de TLS de confianza pública a solo 47 días para 2029. Este cambio representa un cambio fundamental en la forma en que las organizaciones deben abordar la gestión del ciclo de vida de los certificados (CLM). Si bien las ventajas en materia de seguridad son evidentes, las implicaciones operativas son considerables. Las organizaciones que dependen de procesos manuales encontrarán esta nueva realidad insostenible, lo que hace que la automatización y la gobernanza no sean solo prácticas recomendadas, sino necesidades operativas. 

¿Qué son los certificados de 47 días y qué certificados se ven afectados?

La obligación de 47 días se aplica específicamente a TLS de confianza pública, es decir, las credenciales digitales que protegen los sitios web, las aplicaciones de acceso público y determinadas infraestructuras periféricas. Estos certificados autentican los servidores y cifran los datos en tránsito, lo que los convierte en la columna vertebral de las comunicaciones seguras por Internet. 

• TLS de confianza públicason emitidos por autoridades de certificación (CA) que los navegadores y sistemas operativos reconocen de forma predeterminada. Permiten conexiones HTTPS seguras para usuarios externos sin necesidad de configurar manualmente la confianza. La limitación de 47 días se aplica exclusivamente a estos certificados. 

• Los certificados privados o internos, emitidos por la propia infraestructura PKI privada de una organización, no se ven directamente afectados por esta normativa. Las organizaciones pueden seguir emitiendo certificados internos con una vigencia más larga si sus casos de uso lo justifican. Sin embargo, muchas organizaciones preocupadas por la seguridad optan por aplicar las mejores prácticas de los certificados públicos en su PKI privada para mantener una postura de seguridad y unos procesos operativos coherentes. 

La implementación se llevará a cabo de forma gradual, en lugar de reducirse inmediatamente a 47 días: 

• Marzo de 2026: la validez máxima se reduce a 200 días. 

• 2027: Reducción adicional a 100 días. 

• 2029: Último paso hacia una validez máxima de 47 días. 

Estos períodos de validez incluyen ventanas de renovación integradas. El certificado de 47 días, por ejemplo, está diseñado con aproximadamente 30 días de vida útil prevista más un margen de 17 días para las actividades de renovación. Esta estructura significa que las organizaciones tendrán que renovar los certificados aproximadamente cada mes, lo que da como resultado entre 8 y 12 ciclos de renovación al año por certificado, dependiendo del margen de tiempo que mantengan. 

Los certificados afectados por este cambio suelen ser algunos de los activos más importantes de una organización. No se encuentran aislados en un único servidor web. Una implementación típica podría incluir: 

• Servidores web y servidores de aplicaciones 

• Equilibradores de carga que terminan TLS 

• Cargas de trabajo en la nube y aplicaciones en contenedores 

• Infraestructura periférica y redes de distribución de contenidos 

• Pasarelas API y puntos finales de microservicios 

Un certificado puede implementarse en varias ubicaciones simultáneamente: un equilibrador de carga, varios servidores de aplicaciones y sistemas de copia de seguridad. Esta multiplicidad amplifica el reto operativo que suponen las renovaciones frecuentes. 

¿Cómo pasó la industria de certificados de 10 años a 47 días?

El camino hacia los certificados de 47 días abarca más de una década de reducciones graduales: 

• Antes de 2012: los certificados podían tener una validez de 10 años. 

• 2012: Reducción de la validez máxima a 5 años. 

• 2015: Reducción adicional a 3 años. 

• 2018: Reducción a 2 años (825 días) 

• 2020: Norma actual de 398 días (aproximadamente 13 meses) 

• 2026-2029: Reducción gradual a 47 días. 

La transición de 2020 a 398 días ofrece importantes lecciones para el cambio actual. Google propuso inicialmente una reducción de la vigencia de los certificados y sometió la medida a votación en el Foro CA/B. La propuesta fue rechazada. Sin embargo, Apple anunció de forma independiente que su navegador nativo, Safari, no aceptaría certificados con períodos de validez superiores a 398 días, lo que obligó de facto a todo el sector a seguir su ejemplo. Las CA no tuvieron más remedio que cumplir, y otros navegadores hicieron lo mismo. 

El cambio actual a certificados de 47 días sigue un patrón diferente. En esta ocasión, el cambio ha sido impulsado por las CA a través de un proceso de votación formal, en lugar de ser impuesto unilateralmente por un proveedor de navegadores. Apple presentó la votación SC081v3, que proponía un calendario de reducción gradual, y esta fue aprobada en el proceso de votación del CA/B Forum. Dado que las CA no emitirán certificados que superen estos nuevos límites de validez, las organizaciones no tienen otra alternativa: deben adaptarse. 

La reacción del sector ha sido dispar. Mientras que los proveedores de seguridad y las autoridades de certificación apoyan en general el cambio, los administradores de sistemas y los equipos de PKI expresan su profunda preocupación. Los debates en línea revelan la tensión existente entre los ideales de seguridad y la realidad operativa. Un administrador se preguntó si el siguiente paso lógico serían los «certificados de un segundo», lo que pone de manifiesto la frustración ante el ritmo del cambio. Otros señalaron que muchos sistemas heredados y la infraestructura actual no admiten protocolos de renovación automatizada de forma inmediata, lo que crea un importante problema de deuda técnica. 

¿Por qué los navegadores y las autoridades de certificación están impulsando los certificados de 47 días?

El impulso hacia los certificados de 47 días se deriva de tres objetivos interrelacionados que van más allá de las simples mejoras de seguridad. 

Mayor seguridad y menor radio de explosión 

Una menor duración de los certificados reduce directamente las oportunidades que tienen los atacantes para explotar certificados o claves privadas comprometidos. El principio de seguridad refleja las políticas de rotación de contraseñas: cuanto más frecuentemente cambian las credenciales, menos tiempo tienen los adversarios para aprovechar las credenciales robadas o comprometidas. 

Esto cobra especial relevancia en el contexto de los ataques «recoger ahora, descifrar después». Los adversarios con recursos suficientes pueden interceptar y almacenar el tráfico cifrado hoy, apostando por que eventualmente obtendrán las claves de descifrado o que los ordenadores cuánticos harán vulnerables los algoritmos de cifrado actuales. Una rotación más frecuente de las claves dificulta considerablemente el éxito de esta estrategia. Cada nuevo certificado utiliza un nuevo par de claves, lo que limita la cantidad de tráfico histórico que puede descifrar una sola clave comprometida. 

Cuando los certificados se ven comprometidos —por violaciones de la seguridad del servidor, configuraciones erróneas o ataques a la cadena de suministro—, su menor duración limita los daños. Un certificado comprometido con 47 días de validez supone un riesgo mucho menor que uno válido durante un año. 

Forzar el cambio hacia la automatización y las prácticas modernas de PKI 

Apple y Google están utilizando explícitamente la reducción de la vigencia de los certificados como mecanismo para impulsar al sector haciaCLM automatizadaCLM. Los procesos de renovación manual, que pueden ser tolerables con certificados anuales, se vuelven completamente insostenibles cuando los certificados deben renovarse cada pocas semanas. 

Esta función coercitiva es intencionada. La gestión manual de certificados a gran escala introduce errores humanos, crea cuellos de botella operativos y deja a las organizaciones vulnerables a interrupciones del servicio por certificados caducados. Al hacer que los procesos manuales sean operativamente imposibles, el sector obliga de hecho a las organizaciones a adoptar prácticas de automatización modernas. 

Las ventajas de la transición van más allá de la simple prevención de interrupciones. La gestión automatizada de certificados permite: 

• Aplicación coherente de las políticas en todos los certificados 

• Reducción de los gastos generales operativos y del agotamiento del equipo. 

• Mejor visibilidad del inventario y el uso de certificados. 

• Respuesta más rápida a incidentes de seguridad que requieren la sustitución de certificados. 

• Fundación para gestionar futuras transiciones criptográficas 

Preparación para la poscuántica y la criptoagilidad 

La fecha límite de 2029 no es casual. El NIST ha establecido un calendario para la transición a la criptografía poscuántica (PQC), y ha marcado 2030 como el año en que los algoritmos actuales, como RSA y ECC, comenzarán a quedar obsoletos en favor de alternativas resistentes a la cuántica. 

Las organizaciones que hayan automatizadoCLM 2029 estarán en una posición mucho mejor para gestionar la transición poscuántica. El intercambio de algoritmos criptográficos entre miles o millones de certificados requiere la misma infraestructura de automatización que se necesita para las renovaciones frecuentes. La obligación de renovar los certificados cada 47 días da a las organizaciones un plazo de cinco años para desarrollar las capacidades de automatización que necesitarán para la transición cuántica. 

La criptoagilidad, es decir, la capacidad de cambiar rápidamente los algoritmos criptográficos y los tipos de claves en toda una infraestructura, se convierte en una ventaja competitiva y una necesidad de seguridad. Las organizaciones que esperen hasta 2030 para abordar la automatización se enfrentarán a una caótica carrera para sustituir los algoritmos y, al mismo tiempo, gestionar certificados de corta duración. 

¿Qué cambios supondrán los certificados de 47 días para el día a día de los equipos de PKI y administración de sistemas?

El impacto operativo de los certificados de 47 días va mucho más allá de la simple renovación más frecuente de los certificados. El cambio afecta de manera fundamental a los flujos de trabajo, la dinámica de los equipos, los procesos de validación y la gestión de la infraestructura. 

La frecuencia de renovación se dispara 

El cambio más evidente es el aumento drástico de la frecuencia de renovación. Las organizaciones que actualmente renuevan los certificados anualmente pasarán a renovarlos cada pocas semanas. Un certificado que antes requería atención una vez al año ahoraexigirá entre 8 y 12 ciclos de renovación al año. 

Las investigaciones de Gartnerindican que la renovación integral de certificados, desde la generación del par de claves hasta la verificación final de la implementación, suele requerir entre tres y seis horas de trabajo humano cuando se realiza manualmente. Esto incluye: 

• Generación del par de claves en el sistema de destino 

• Creación y envío de la solicitud de firma de certificado (CSR) 

• Obtener la aprobación de las partes interesadas pertinentes. 

• A la espera de la validación y emisión de CA 

• Descarga e instalación del nuevo certificado 

• Verificación de la instalación y el funcionamiento correctos 

• Posible reinicio de los servicios para activar el nuevo certificado. 

Multiplique esas 3-6 horas por 8-12 ciclos de renovación por certificado y, a continuación, multiplique por el número total de certificados de confianza pública en su entorno. Para las organizaciones con cientos o miles de certificados públicos, el cálculo se vuelve insostenible sin automatización. 

Carga operativa y riesgo de agotamiento 

La gestión de certificados rara vez recae exclusivamente en el equipo de PKI. El proceso integral suele implicar: 

• Equipos de PKI o de seguridad que gestionan las relaciones y políticas de CA. 

• Propietarios de aplicaciones que comprenden las dependencias del servicio 

• Equipos de infraestructura que gestionan servidores y equilibradores de carga. 

• Equipos de red que gestionan DNS 

• Equipos de gestión del cambio que coordinan las ventanas de mantenimiento. 

Cada ciclo de renovación requiere la coordinación entre estos grupos. La naturaleza multifásica de la renovación de certificados (generación de claves, creación de CSR, validación de CA, emisión, implementación, verificación y posibles reinicios del servicio) crea múltiples puntos en los que pueden producirse retrasos o errores. 

El coste humano va más allá del tiempo dedicado a las renovaciones. Los constantes cambios de contexto, las solicitudes urgentes de renovación y el estrés de evitar interrupciones contribuyen al agotamiento del equipo. Cuando la renovación de certificados se convierte en una tarea semanal o quincenal, en lugar de un evento anual, puede acaparar la capacidad del equipo e impedir que se trabaje en iniciativas estratégicas. 

La ventana de validación se reduce 

Los requisitos de validación de dominio (DV) también se están endureciendo junto con la vigencia de los certificados. Actualmente, la validación de la propiedad del dominio suele tener una vigencia de un año. Con el nuevo marco, la validez de la DV se reduce a aproximadamente 10 días. 

Esto significa que las organizaciones deben gestionar los registros DNS o los archivos de validación HTTP con mucha más frecuencia. Para las organizaciones con grandes carteras de dominios, esto supone una campaña de validación continua en lugar de un evento anual. El proceso de validación debe automatizarse o se convertirá en otra tarea manual insostenible. 

Las implementaciones heredadas y multisalto quedan expuestas 

Muchas implementaciones de certificados son más complejas de lo que parecen. Es posible que sea necesario instalar un único certificado en: 

• Un equilibrador de carga que termina TLS 

• Varios servidores de aplicaciones detrás del equilibrador de carga 

• Sistemas de respaldo o conmutación por error 

• Entornos de desarrollo y puesta en escena que reflejan la producción. 

Las renovaciones parciales, en las que se actualiza un certificado en 9 de cada 10 servidores, crean riesgos ocultos de interrupción del servicio. El décimo servidor sigue utilizando el certificado antiguo hasta que caduca y, entonces, falla. Con las renovaciones anuales, estas implementaciones parciales pueden pasar desapercibidas durante meses. Con las renovaciones mensuales, la probabilidad de que se produzcan implementaciones parciales y las consiguientes interrupciones del servicio aumenta drásticamente. 

El mandato de 47 días pondrá al descubierto estos patrones de implementación complejos y de múltiples saltos, y obligará a las organizaciones a documentarlos y automatizarlos adecuadamente. 

¿Cuáles son los mayores riesgos si no te adaptas? 

Las organizaciones que no se preparan para los certificados de 47 días se enfrentan a varios tipos de riesgos, que van desde interrupciones operativas hasta vulnerabilidades estratégicas. 

Interrupciones por certificados caducados o renovados parcialmente 

Las interrupciones por caducidad de certificados siguen un patrón predecible: un sistema crítico deja de funcionar, los usuarios no pueden conectarse, se pierden ingresos y los equipos se apresuran a identificar la causa. Finalmente, alguien descubre que se trata de un certificado caducado. Para entonces, todos los que han participado en la respuesta al incidente han perdido horas de trabajo y la organización ha sufrido daños financieros y de reputación. 

El «juego de culpar a los certificados por las interrupciones» se ha convertido en una broma habitual en los círculos de TI: cuando un sistema falla, todo el mundo se esconde mientras se intenta determinar quién es el responsable. Inevitablemente, se culpa al equipo de PKI, incluso cuando la causa principal fue la falta de procesos, una documentación deficiente o una propiedad poco clara. 

Con certificados de 47 días, la frecuencia de posibles interrupciones aumenta proporcionalmente si los procesos siguen siendo manuales. Los certificados más importantes, los que garantizan los servicios de atención al cliente y las aplicaciones empresariales críticas, son los que más probabilidades tienen de provocar interrupciones visibles y costosas cuando caducan. 

TI en la sombra y compras de certificados públicos no autorizadas 

Cuando los procesos oficiales de adquisición de certificados son lentos o engorrosos, las unidades de negocio suelen eludirlos por completo. Los propietarios de aplicaciones que «no pueden esperar al equipo de PKI» acuden directamente a una CA pública y compran certificados utilizando tarjetas de crédito corporativas. 

Estos certificados paralelos existen fuera de los sistemas oficiales de inventario y gestión. Están sujetos a los mismos límites de validez de 47 días que los certificados gestionados oficialmente, pero no tienen automatización ni visibilidad. Cuando caducan, nadie recibe alertas y no existe ningún proceso de renovación. 

Es probable que el mandato de 47 días aumente inicialmente las compras de certificados de TI paralelos, ya que los equipos buscan soluciones rápidas para los frecuentes requisitos de renovación. Las organizaciones deben agilizar y facilitar la adquisición oficial de certificados, o perderán la visibilidad de una parte importante de su inventario de certificados. 

Certificados comodín como puntos únicos de fallo 

Los certificados comodín, que protegen todos los subdominios de un dominio (*.example.com), son prácticos desde el punto de vista operativo, pero crean un riesgo concentrado. Un solo certificado comodín puede implementarse en cientos de servidores y servicios. 

Cuando un certificado comodín caduca, todos los sistemas que lo utilizan fallan simultáneamente. Un proveedor de juegos documentó su experiencia con la caducidad de un certificado comodín que dejó fuera de servicio toda su infraestructura backend, lo que afectó a miles de usuarios. El incidente se convirtió en un caso de estudio público sobre lo que no se debe hacer con los certificados comodín. 

El mandato de 47 días amplifica el riesgo de los certificados comodín. Cuanto más frecuentemente se debe renovar un certificado, más oportunidades existen de que se produzcan fallos en la renovación. Un comodín implementado en 100 ubicaciones debe renovarse y desplegarse con éxito en las 100 ubicaciones cada mes. Si se falla en una sola, se tendrá una implementación parcial a la espera de causar una interrupción del servicio. 

La lucha poscuántica en 2030 

Las organizaciones que no hayan implementado la automatización del ciclo de vida de los certificados para 2029 se enfrentarán a una crisis en 2030, cuando comience la transición a la criptografía poscuántica. Sustituir miles de certificados por nuevos algoritmos y gestionar al mismo tiempo manualmente ciclos de vida de 47 días es simplemente inviable. 

Las organizaciones que inviertan ahora en automatización tratarán la transición poscuántica como un cambio de configuración: actualizarán los parámetros del algoritmo y dejarán que la automatización se encargue de la implementación. Las organizaciones que no cuenten con automatización se enfrentarán a un proyecto de varios años para sustituir manualmente todos los certificados, al tiempo que intentarán implementar la automatización que deberían haber creado años atrás. 

¿Desde dónde parten la mayoría de las organizaciones hoy en día? 

Comprender el estado actual de la gestión de certificados en la mayoría de las organizaciones ayuda a contextualizar el reto que se avecina. A pesar de los avances en la tecnología PKI, muchas organizaciones siguen utilizando enfoques obsoletos. 

Herramientas fragmentadas y lagunas de visibilidad 

Los entornos típicos de gestión de certificados consisten en: 

• Hojas de cálculo que registran el inventario de certificados (a menudo desactualizadas) 

• Bases de datos ad hoc mantenidas por equipos individuales. 

• Herramientas de escaneo de red que detectan certificados en la red. 

• Múltiples portales de CA para diferentes proveedores de certificados 

• Scripts personalizados para casos de uso específicos 

Ninguna de estas herramientas proporciona una visibilidad completa en tiempo real. Los certificados más importantes, los que protegen los servicios críticos, suelen ser los que faltan en el inventario oficial. Como dijo un profesional: «Los certificados más importantes son los que no aparecen en tu hoja de cálculo». 

Sin propiedad ni responsabilidad claras 

En muchas organizaciones, la responsabilidad sobre los certificados se distribuye entre varios equipos sin que exista una propiedad clara. El equipo de PKI puede gestionar las relaciones con las CA, pero los equipos de aplicaciones solicitan e instalan los certificados, los equipos de infraestructura gestionan los servidores y los equipos de seguridad establecen las políticas. 

Esta difusión de la responsabilidad crea una tragedia de los comunes: si todo el mundo posee certificados, nadie los posee. Cuando algo sale mal, la respuesta habitual es señalar con el dedo en lugar de resolver el problema de forma sistemática. 

Procesos manuales e inconsistentes 

Incluso las organizaciones con procesos de certificación definidos suelen depender en gran medida de pasos manuales: 

• Los propietarios de aplicaciones generan manualmente CSR con información inconsistente. 

• Los flujos de trabajo de aprobación implican cadenas de correos electrónicos y actualizaciones de hojas de cálculo. 

• La instalación del certificado requiere sesiones SSH manuales o conexiones RDP. 

• La verificación depende de que los administradores comprueben manualmente los servicios. 

• Las renovaciones se registran en calendarios y sistemas de recordatorios. 

Los errores humanos en la creación de CSR (certificados de solicitud de certificado): errores tipográficos en los nombres de dominio, tamaños de clave incorrectos, nombres alternativos de sujeto faltantes, provocan retrasos y repetición del trabajo. Los procesos manuales también son lentos, lo que crea fricciones entre los equipos de seguridad que intentan aplicar las políticas y los equipos de aplicaciones que intentan implementar los servicios rápidamente. 

Dependencia excesiva de certificados públicos cuando bastaría con una PKI privada 

Muchas organizaciones utilizan por defecto certificados de confianza pública para servicios internos que nunca se enfrentan a la Internet pública. Esto ocurre por varias razones: 

• La infraestructura PKI privada no estaba disponible o era difícil de usar. 

• Los equipos de aplicaciones necesitaban certificados rápidamente y acudieron a las CA públicas. 

• Falta de comprensión sobre cuándo es realmente necesaria la confianza pública. 

• Decisiones históricas que nunca se revisaron 

El uso de certificados públicos para servicios internos genera costes innecesarios, gastos operativos y, ahora, renovaciones más frecuentes de lo necesario. El mandato de 47 días ofrece la oportunidad de reevaluar qué servicios requieren realmente la confianza pública y trasladar las cargas de trabajo adecuadas a una PKI privada con una vida útil más larga. 

¿Cómo es el ciclo de vida de un certificado moderno con una validez de 47 días? 

Prepararse para los certificados de 47 días requiere replantearse la gestión de certificados como un sistema integrado en lugar de como un conjunto de tareas manuales. El estado objetivo abarca varias capacidades clave. 

Inventario completo y visibilidad en tiempo real 

Una gestión eficaz de los certificados comienza por saber qué certificados existen, dónde se implementan y cuándo caducan. Para ello se requieren múltiples mecanismos de detección: 

• Las integraciones de CAque extraen datos sobre la emisión de certificados directamente de autoridades de certificación públicas y privadas proporcionan la fuente fidedigna sobre qué certificados se han emitido. 

• Las soluciones de detección de redesescanean TLS en toda la infraestructura e identifican los certificados en uso activo. De este modo, se detectan los certificados que podrían haberse emitido fuera de los canales oficiales o implementado sin la documentación adecuada. 

• La detección directa de almacenes de claves y dispositivosexamina directamente los almacenes de certificados, los equilibradores de carga, los servicios en la nube y las aplicaciones. Este enfoque encuentra certificados que pueden no estar sirviendo activamente TLS , pero que siguen estando presentes en el entorno. 

La combinación de estos ángulos de descubrimiento proporciona una visibilidad completa. Ningún método por sí solo lo abarca todo, pero juntos crean una imagen completa. 

Gobernanza, propiedad y política definidas 

Una propiedad y una responsabilidad claras evitan las acusaciones que suelen seguir a los incidentes relacionados con los certificados. Una gobernanza eficaz incluye: 

Propietarios definidospara cada certificado o categoría de certificados que son responsables de las renovaciones, actualizaciones y respuesta ante incidentes. 

• Flujos de trabajo basados en rolesque dirigen las solicitudes, aprobaciones y renovaciones de certificados a los equipos adecuados en función del propósito y el nivel de riesgo del certificado. 

• Perfiles estandarizadosque definen tamaños de claves, algoritmos, vidas útiles, convenciones de nomenclatura y políticas de comodines aceptables. La estandarización reduce los errores y garantiza la coherencia. 

• Aplicación de políticasque impiden la emisión de certificados que no cumplen con los estándares de la organización, detectando problemas antes de que se implementen los certificados. 

Automatización durante todo el ciclo de vida, no solo durante la inscripción 

La verdadera automatización va más allá de simplemente solicitar y recibir certificados. Abarca: 

• ACME y protocolos similarespara la inscripción automatizada cuando sean adecuados. ACME funciona bien para servidores web y entornos Kubernetes, pero no resuelve todos los casos de uso. 

• Cert-manager paraentornos Kubernetes, con las integraciones adecuadas para las autoridades de certificación.  

• Integración de infraestructura como códigocon herramientas como Terraform, lo que permite que el aprovisionamiento de certificados forme parte de la implementación automatizada de la infraestructura. 

• Gestión del ciclo de vida de los certificados (CLM) y coordinaciónpara implementaciones complejas de múltiples saltos y sistemas heredados que no admiten protocolos modernos. Las soluciones de coordinación pueden implementar certificados en diversos destinos, incluidos equilibradores de carga, servidores de aplicaciones, almacenes de certificados y sistemas de archivos remotos. 

• Alerta y confirmaciónde que los certificados no solo se emiten, sino que realmente se implementan y están activos. La emisión sin implementación crea una falsa sensación de seguridad. 

Separación de responsabilidades para reinicios y control de cambios 

AlgunasCLM ofrecen la posibilidad de reiniciar automáticamente los servicios tras la implementación de certificados. Aunque esto parece conveniente, conlleva riesgos. Reiniciar automáticamente los servicios de producción sin un control adecuado de los cambios puede provocar interrupciones imprevistas. 

Un enfoque más adecuado separa la implementación de certificados del reinicio de los servicios: 

• Las soluciones de automatización gestionan la renovación y la implementación de certificados. 

• El sistema notifica al departamento de gestión de cambios que hay un nuevo certificado disponible. 

• La gestión del cambio coordina los reinicios del servicio durante las ventanas de mantenimiento aprobadas. 

• Una supervisión y alerta adecuadas detectan cualquier problema con el proceso de reinicio. 

Esta separación garantiza que las renovaciones de certificados se realicen en los plazos necesarios, mientras que los reinicios del servicio siguen los procedimientos de control de cambios adecuados. 

¿CómoKeyfactor en el cambio a certificados de 47 días? 

Aunque el cambio a certificados de 47 días está impulsado por las CA públicas y los navegadores, son las organizaciones, y no las CA, las que soportan la carga operativa de las renovaciones frecuentes. El papel Keyfactores ayudarles a gestionar este cambio de forma eficaz. 

Keyfactor la visibilidad de todos los certificados 

Keyfactor Command proporciona un descubrimiento completo de los certificados emitidos por CA, los puntos finales de red y los almacenes de certificados. Este enfoque multángulo ayuda a las organizaciones a identificar certificados desconocidos o no gestionados que suponen un riesgo de interrupción del servicio. La plataforma es compatible con entornos PKI públicos y privados, lo que proporciona a los equipos una única fuente de información veraz para todo su inventario de certificados, independientemente del origen de estos o de cómo se implementen. 

La gestión independiente de CA simplifica las operaciones 

Las organizaciones suelen depender de múltiples CA (autoridades de certificación): diferentes proveedores para diferentes casos de uso, relaciones heredadas o requisitos geográficos. Gestionar cada CA por separado se vuelve inmanejable con certificados de corta duración. Keyfactor los equipos estandarizar los procesos y las políticas en todas las CA en una sola plataforma. Esto elimina las inconsistencias y las ineficiencias de tener que manejar múltiples portales, cada uno con diferentes interfaces y flujos de trabajo. 

Automatización del flujo de trabajo completo de renovación 

Los ciclos de vida cortos requieren más que la inscripción en ACME; las organizaciones deben garantizar la implementación, la verificación y la supervisión continua. Keyfactor las tareas del ciclo de vida de extremo a extremo, reduciendo el proceso de renovación manual de 3 a 6 horas a un flujo de trabajo escalable. Las capacidades de coordinación de la plataforma garantizan que los certificados lleguen realmente a todos los puntos finales en una implementación multisistema, y no solo al primer servidor de la cadena. 

Descubriendo la criptografía en toda la empresa 

Más allá de los certificados, las organizaciones necesitan visibilidad sobre los algoritmos criptográficos, las claves y las dependencias. Las soluciones de detección criptográfica Keyfactorayudan a los equipos a comprender dónde se utiliza la criptografía y si está obsoleta o es vulnerable. Se trata de una preparación fundamental para futuras transiciones, como la criptografía poscuántica. Los equipos pueden identificar qué sistemas utilizan qué algoritmos, evaluar el alcance de los cambios necesarios y planificar estrategias de migración antes de la fecha límite de 2030. 

Sentar las bases para la criptoagilidad 

Las organizaciones que automaticen ahora la gestión de certificados estarán mejor preparadas para los próximos cambios en el sector.Keyfactor la infraestructura y la automatización necesarias para sustituir certificados o algoritmos a gran escala. Cuando los algoritmos poscuánticos sean obligatorios, las organizaciones conCLM maduroCLM tratar la transición como un cambio de configuración en lugar de como un proyecto de crisis de varios años. 

¿Cómo deben empezar a prepararse las organizaciones ahora? 

Prepararse para los certificados de 47 días no requiere implementar todo de una vez, pero sí requiere empezar ahora. Las organizaciones disponen de varios años para desarrollar capacidades antes de la fecha límite de 2029. 

• Comience por la visibilidad y el inventario.Antes de poder automatizar la gestión de certificados, debe saber qué certificados existen. Implemente la detección en CA públicas y privadas, puntos finales de red y almacenes de certificados. Documente los certificados de TI ocultos y las implementaciones comodín. Comprender su estado actual es la base para todo lo demás. 

• Clasifique los certificados según el riesgo, el entorno y la viabilidad de la automatización.No todos los certificados son iguales. Los servicios web orientados al cliente requieren un tratamiento diferente al de los sistemas de desarrollo internos. Identifique qué certificados son más críticos para las operaciones comerciales y cuáles son más fáciles de automatizar. Esta clasificación sirve de guía para establecer prioridades. 

• Estandarice las políticas y solucione los problemas evidentes.Antes de automatizar las malas prácticas, corríjalas. Elimine los certificados comodín innecesarios, traslade los servicios internos a una PKI privada cuando sea apropiado, estandarice los tamaños de clave y los algoritmos, y establezca convenciones de nomenclatura claras. Limpie su entorno de certificados antes de automatizarlo. 

• Automatización piloto en un dominio contenido.Elija un subconjunto bien definido de su inventario de certificados para la automatización inicial, tal vez servidores web front-end o una pila de aplicaciones específica. Implemente la automatización de extremo a extremo para ese dominio, aprenda de la experiencia y documente lo que funciona. A continuación, amplíe gradualmente a otros dominios. 

• Utilice el cambio de 47 días como catalizador para modernizar tanto la PKI pública como la privada.Aunque la normativa solo afecta a los certificados públicos, las capacidades de automatización y gobernanza que desarrolle beneficiarán a toda su infraestructura PKI. Las organizaciones que traten esto como un esfuerzo de modernización integral, en lugar de como una simple casilla de cumplimiento normativo, obtendrán beneficios más amplios. 

La transición a los certificados de 47 días es inevitable. Las organizaciones que empiecen a prepararse ahora lo vivirán como una evolución controlada. Las que esperen se enfrentarán a una crisis.