Lecciones de la revocación masiva de certificados de DigiCert

Respuesta rápida: En julio de 2024, DigiCert revocó más de 83 000 certificados TLS de aproximadamente 6,800 clientes con solo 24 horas de aviso tras detectar una vulnerabilidad en la validación de dominios con una vigencia de cinco años. La lección: la gestión del ciclo de vida de los certificados no puede depender del seguimiento manual, y el margen de error se reduce cada vez más a medida que el Foro CA/Browser disminuye gradualmente la validez máxima de los certificados a 47 días para 2029.

La mayoría de las empresas tratan un incidente con una autoridad de certificación como un problema ajeno hasta que son ellas quienes se ven obligadas a reemplazar certificados en sus sistemas de producción sin previo aviso. La revocación masiva de DigiCert puso a unas 6,800 organizaciones precisamente en esa situación. Algunas tenían unas pocas horas de trabajo por delante. Otras tenían miles de certificados repartidos en sistemas que nadie había mapeado por completo, y sin forma de saber cuáles fallarían primero.

El fallo específico que encontró DigiCert es menos importante que lo que expuso: inventarios de certificados que solo existen en hojas de cálculo, procesos de renovación que dependen de que un ingeniero recuerde la fecha de vencimiento y la falta de herramientas que puedan responder en menos de un día a la pregunta "¿qué certificados tenemos realmente y dónde están?". Estas deficiencias no desaparecen una vez que la noticia deja de ser relevante, y se vuelven más costosas cada vez que la industria acorta la vigencia de los certificados.

Resumen Ejecutivo

La revocación masiva de certificados de DigiCert en julio de 2024 obligó a aproximadamente 6,800 clientes a reemplazar más de 83,000 certificados en un plazo de 24 horas, y cualquier autoridad de certificación puede desencadenar la misma situación bajo las reglas del CA/Browser Forum. La presión no hace más que aumentar: la propuesta SC-081v3 del CA/Browser Forum reduce gradualmente la validez máxima de los certificados TLS públicos a 200 días en marzo de 2026, 100 días en marzo de 2027 y 47 días para marzo de 2029, y la propia encuesta Trust Pulse de DigiCert de julio de 2025 reveló que el 45% de las organizaciones habían sufrido interrupciones del servicio relacionadas con certificados durante el último año, y el 37.5% de estas se debieron a un certificado caducado. Cerrar esa brecha comienza con el descubrimiento y la automatización de certificados , ya que una organización que no puede inventariar lo que posee no puede sobrevivir a un plazo de revocación de 24 horas, y la misma disciplina sustenta la agilidad criptográfica y la preparación para PQC a través de un CBOM en tiempo real que convierte la visibilidad de los certificados en una capacidad continua en lugar de una instantánea única.

Ir a: Conclusiones clave | Plazo de validez de 47 días | Impacto por equipo | Hoja de ruta de preparación | Cómo puede ayudar la consultoría en cifrado | Preguntas frecuentes

Puntos Clave

• En julio de 2024, DigiCert revocó más de 83,000 certificados de aproximadamente 6,800 clientes tras descubrirse un fallo en la validación de dominios que databa de 2019, con un plazo de revocación inferior a 24 horas debido al cumplimiento de la normativa.
• El calendario aprobado por el Foro CA/Browser reduce la validez máxima de los certificados TLS públicos de 398 días en la actualidad a 200 días para el 15 de marzo de 2026, a 100 días para el 15 de marzo de 2027 y a 47 días para el 15 de marzo de 2029.
• La encuesta Trust Pulse de DigiCert de julio de 2025 reveló que el 45 % de las organizaciones experimentaron interrupciones del servicio relacionadas con certificados durante el último año, y el 37.5 % atribuyeron una interrupción específicamente a un certificado caducado.
• El seguimiento manual de certificados, las hojas de cálculo, los recordatorios del calendario y el conocimiento tácito no pueden seguir el ritmo de un ciclo de renovación de 47 días en un entorno PKI híbrido o multinube.
• El descubrimiento automatizado, la visibilidad centralizada y la renovación basada en políticas ya no son proyectos de optimización; son el requisito básico para evitar el próximo evento de revocación masiva, sea cual sea la autoridad de certificación.

¿Qué sucedió con la revocación masiva de DigiCert?

El 29 de julio de 2024, DigiCert anunció la revocación de un lote de certificados TLS tras detectar que algunos se habían emitido con una validación de control de dominio incorrecta . Según las normas del CA/Browser Forum, una autoridad de certificación que detecte este tipo de defecto de validación dispone de 24 horas para revocar los certificados afectados, sin excepciones. Inicialmente, DigiCert fijó el 30 de julio como fecha límite y posteriormente la extendió hasta el 3 de agosto de 2024 a las 19:30 UTC, debido al elevado volumen de certificados afectados.

El fallo de validación de dominio

La causa raíz se remonta a un cambio en el sistema en 2019. Uno de los métodos de validación de control de dominio de DigiCert solicita al cliente que publique un registro DNS CNAME con un valor aleatorio, precedido por un guion bajo para evitar conflictos con nombres de dominio reales. Una actualización de 2019 de dicho sistema dejó de añadir el prefijo de guion bajo en ciertos casos, y la deficiencia pasó desapercibida durante varias rondas de pruebas de regresión, ya que estas pruebas verificaban el comportamiento del flujo de trabajo, no la estructura del valor generado. DigiCert solo descubrió la omisión en julio de 2024 mientras investigaba un informe no relacionado, momento en el que ya había afectado a validaciones de los últimos cinco años.

La carrera de 24 horas

Dado que la vulnerabilidad afectaba a la validación y no a la intención de emisión, DigiCert no tenía margen de maniobra en cuanto a los plazos. Todos los certificados afectados debían reemplazarse en un solo día hábil, independientemente de la criticidad del sistema subyacente. Algunas organizaciones con certificados en infraestructuras de acceso público o dispositivos integrados solicitaron prórrogas, las cuales fueron denegadas, ya que los requisitos básicos del CA/Browser Forum no contemplan excepciones por dificultades operativas. Unos pocos clientes emprendieron acciones legales para intentar retrasar la revocación de certificados específicos. Análisis independientes realizados por investigadores de seguridad revelaron que decenas de miles de certificados afectados seguían activos en servidores de acceso público semanas después de la fecha límite, lo que demuestra la gran disparidad en la velocidad de remediación entre los clientes afectados.

La verdadera lección: los fallos en la obtención de certificados son un riesgo sistémico, no un hecho aislado.

Resulta tentador catalogar esto como un simple "DigiCert tuvo un mal mes" y seguir adelante. Sin embargo, esa interpretación no capta la esencia del problema. Cualquier autoridad de certificación puede detectar un defecto de validación que obligue a la revocación masiva casi sin previo aviso, ya que la regla de las 24 horas es un requisito básico del CA/Browser Forum, no una política de DigiCert. Las organizaciones que se recuperaron rápidamente en 2024 no fueron las que tenían menos certificados, sino las que ya sabían, sin prisas, exactamente qué certificados poseían, dónde se encontraba cada uno y quién era su propietario. Ese es el verdadero factor diferenciador, y no tiene nada que ver con la CA que utilice la organización.

Cronograma de validez del certificado de 47 días que debe seguir

El incidente de DigiCert ocurrió bajo el actual período máximo de validez de los certificados, de 398 días. Este margen de seguridad está desapareciendo. El 11 de abril de 2025, el Foro CA/Browser aprobó una propuesta, originalmente presentada por Apple y respaldada por Sectigo, que reduce gradualmente la validez máxima de los certificados TLS públicos a 47 días para 2029. Cada fase también acorta el período de reutilización de la validación del control de dominio, por lo que el plazo operativo para revalidar la propiedad del dominio se estrecha a la par que la vida útil del certificado.

Fecha de vigencia	Validez máxima	¿Quiénes se ven afectados?	Acción Necesaria	Fuente
Marzo 15, 2026	200 días	Todas las organizaciones que emiten o renuevan certificados TLS públicos	Adopte una cadencia de renovación de aproximadamente cada seis meses; confirme que sus herramientas CA y ACME admiten el período de reutilización más corto.	Boleta de CA/Browser Forum, a través de Sectigo
Marzo 15, 2027	100 días	Equipos que aún dependen de la emisión manual o de ciclos de renovación trimestrales.	Implementar la renovación automatizada mucho antes de esta fecha; los procesos manuales no podrán seguir el ritmo de una cadencia aproximadamente trimestral a escala empresarial.	Boleta de CA/Browser Forum, a través de Sectigo
Marzo 15, 2029	47 días	Toda la infraestructura TLS de cara al público, incluidas las infraestructuras PKI híbridas y multinube.	La emisión, renovación e implementación de certificados deben estar completamente automatizadas de principio a fin; la renovación manual mensual a gran escala no es operativamente viable.	Boleta de CA/Browser Forum, a través de Sectigo

Fuente de la política: El cronograma de 47 días proviene de una votación del CA/Browser Forum aprobada el 11 de abril de 2025, respaldada públicamente y documentada por el anuncio oficial de Sectigo . Considere el CA/Browser Forum y los avisos de cumplimiento de su propia autoridad de certificación como la fuente de información fidedigna para este cronograma, ya que los requisitos del programa raíz del navegador pueden ajustar los detalles de aplicación a medida que se acerca cada fase.

¿Quién es el responsable?: Impacto y acciones del equipo

Un evento de revocación masiva o un ciclo de renovación de 47 días no recae en un solo equipo. Afecta de manera diferente a las funciones de PKI, seguridad, plataforma y cumplimiento, y cada una requiere una acción específica, no un comunicado compartido.

Equipo	¿Qué cambia para ellos?	Acción inmediata
Equipo PKI	Las plantillas de certificados, los flujos de trabajo de emisión y las relaciones con las CA deben tolerar un período de validez mucho más corto sin necesidad de una reaprobación manual en cada ciclo.	Audite cada flujo de trabajo de emisión para detectar pasos de aprobación manual que no se adapten a una cadencia de 47 días.
Seguridad	Una vida útil más corta de los certificados reduce el tiempo durante el cual una clave robada o emitida incorrectamente sigue siendo útil, que es el objetivo, pero también significa que una detección más rápida ahora soporta la carga de la respuesta a incidentes.	Confirme que se haya implementado la monitorización del registro de transparencia de certificados para que los certificados no autorizados o en modo de sombra salgan a la luz en cuestión de horas, no de semanas.
Equipo de Plataforma e Infraestructura	Cada servicio, balanceador de carga, puerta de enlace API y punto final interno que consume un certificado necesita una ruta de renovación e implementación automatizada, no un manual de procedimientos.	Inventaría qué sistemas todavía requieren la intervención humana para instalar un certificado renovado y prioriza aquellos para su automatización.
Equipo de cumplimiento	La evidencia de auditoría para la gobernanza de certificados debe reflejar un inventario actualizado continuamente, no una hoja de cálculo puntual elaborada antes de una revisión.	Confirme que su inventario de certificados puede generar evidencia lista para auditoría bajo demanda, no solo después de un esfuerzo de recopilación manual.

La gestión manual de certificados es ahora un riesgo empresarial, no solo una tarea de TI.

La propia investigación de DigiCert lo confirma. En su encuesta Trust Pulse de julio de 2025, DigiCert descubrió que el 45 % de las organizaciones reportaron haber experimentado interrupciones del servicio debido a incidentes relacionados con certificados durante el año anterior, y el 37.5 % atribuyó una interrupción específicamente a un certificado caducado, uno de los modos de fallo más prevenibles en la infraestructura empresarial. Más de la mitad de los encuestados también afirmó no tener confianza en su capacidad para realizar un seguimiento de las fechas de caducidad de los certificados en todo su entorno. Esta no es una deficiencia operativa aislada, sino la situación generalizada.

• Los certificados caducados o emitidos incorrectamente provocan interrupciones del servicio que los clientes perciben como un problema suyo, no de su autoridad certificadora.
• El seguimiento manual no permite reducir de forma fiable un ritmo de renovación anual o de 398 días a uno de 47 días sin aumentar la plantilla indefinidamente.
• Un inventario basado en una hoja de cálculo no puede responder con la suficiente rapidez a la pregunta "¿qué certificados tenemos ahora mismo?" como para responder a un evento de revocación masiva dentro de un plazo de cumplimiento de 24 horas.
• Los marcos de cumplimiento normativo, como DORA y PCI DSS, exigen cada vez más un inventario de certificados actualizado de forma continua, y no uno elaborado manualmente antes de cada auditoría.

Donde la automatización cambia las reglas del juego

Precisamente esta es la brecha que CertSecure Manager está diseñado para cerrar. El descubrimiento automatizado encuentra certificados en todo su entorno en lugar de depender de que alguien recuerde que existen. Un panel centralizado proporciona a los equipos de PKI, seguridad y plataforma la misma vista en tiempo real de los certificados emitidos, los que están por vencer y los que ya están vencidos. La renovación y revocación basadas en políticas a través de ACME, SCEP y EST significa que un ciclo de 47 días, o una notificación de revocación masiva repentina de cualquier CA, se convierte en un evento automatizado rutinario en lugar de una respuesta de emergencia que requiere la intervención de todo el personal.

Gestión del ciclo de vida de los certificados en entornos PKI híbridos y multinube

Los entornos PKI híbridos y multinube aumentan aún más la complejidad, ya que los certificados suelen emitirse y gestionarse mediante herramientas diferentes en cada entorno: un proceso para los certificados emitidos por AWS, otro para los emitidos por la CA de Microsoft en las instalaciones, y otro más para los certificados integrados en las integraciones SaaS. Un evento de revocación masiva o un periodo de renovación reducido deja al descubierto todas las fisuras entre estas herramientas. Estandarizar una única capa de gestión de certificados que detecte y gestione los certificados en la nube, en las instalaciones y en la infraestructura híbrida mediante una API común elimina la necesidad de coordinar cuatro procesos manuales distintos durante un incidente. Además, garantiza que se aplique de forma consistente un ciclo de renovación de 47 días en todas partes, en lugar de solo en el entorno que su equipo supervisa con mayor atención.

Elaboración de una hoja de ruta para la obtención del certificado.

Ni una revocación masiva ni el plazo de 47 días se solucionan de un solo golpe. La preparación debe considerarse un programa por fases con una lista de verificación inicial clara y una secuencia realista.

Lista de verificación de preparación

• Inventario completo y actualizado de todos los certificados públicos y privados, incluidos los emitidos fuera de su relación principal con la autoridad de certificación.
• Se asigna un propietario nominal a cada certificado, no solo a cada sistema.
• Se ha implementado la renovación automática, al menos para los certificados con mayor tráfico y más importantes para el negocio.
• El registro de transparencia de certificados está activo para sus dominios principales.
• Un manual de procedimientos probado para un escenario de revocación masiva de emergencia, independiente de su proceso de renovación habitual.
• Informes listos para auditoría que se pueden generar bajo demanda, en lugar de elaborarlos manualmente antes de cada ciclo de revisión.

Una secuencia de despliegue realista

1. Primero, realiza un análisis exhaustivo de toda tu infraestructura. No puedes automatizar lo que aún no has encontrado.
2. Automatice la renovación de sus certificados de mayor riesgo y mayor tráfico antes de abordar la larga lista de certificados de baja prioridad.
3. Ampliar la renovación y el despliegue automatizados a entornos multinube e híbridos para que ningún entorno se convierta en el eslabón débil.
4. Elabore y pruebe un plan de revocación de emergencia antes de necesitarlo, no durante un plazo límite de 24 horas.
5. Trasladar la generación de evidencia de auditoría a la misma plataforma para que la presentación de informes de cumplimiento deje de ser un proyecto manual e independiente.

Métricas que demuestran que el programa funciona

La preparación no es un estado del proyecto que se defina una sola vez. Realice un seguimiento continuo de estos aspectos después de la implementación:

• Porcentaje de certificados renovados automáticamente frente a los renovados manualmente.
• Número de interrupciones o incidentes cercanos relacionados con certificados por trimestre.
• Tiempo promedio desde el descubrimiento del certificado hasta la asignación de un propietario con nombre.
• Tiempo necesario para elaborar un inventario completo y actualizado de certificados bajo demanda.
• Tiempo medio para revocar y reemplazar un certificado en caso de emergencia.

Conectando esto con la agilidad criptográfica y la preparación para PQC

La disciplina en el ciclo de vida de los certificados es fundamental para lo que viene después. La agilidad criptográfica , la capacidad de intercambiar algoritmos y certificados criptográficos sin reconstruir el sistema, depende de saber qué se tiene y poder cambiarlo rápidamente. Esa es precisamente la capacidad que exige un ciclo de renovación de 47 días. El mismo trabajo automatizado de descubrimiento e inventario también contribuye directamente a la planificación de la preparación post-cuántica : una lista de materiales criptográficos proporciona la visibilidad a nivel de algoritmo necesaria para secuenciar una migración PQC , y convertir ese inventario en una capacidad operativa continua en lugar de una instantánea puntual es lo que mantiene tanto el programa de certificados como el cronograma de preparación cuántica realistas en lugar de aspiracionales.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting colabora con equipos de PKI, seguridad y cumplimiento normativo para subsanar las deficiencias que surgen durante una revocación masiva. CertSecure Manager automatiza la detección, emisión, renovación y revocación de certificados en entornos de nube, locales e híbridos desde un único panel de control, de modo que un plazo de cumplimiento de 24 horas o un ciclo de renovación acelerado de 47 días se convierten en un flujo de trabajo rutinario en lugar de una emergencia. Nuestro equipo de asesoría en PKI puede auditar su infraestructura de certificados actual, identificar deficiencias en la propiedad y la automatización, y ayudarle a elaborar la hoja de ruta de preparación descrita anteriormente. Y cuando la preparación de certificados se relaciona con la planificación post-cuántica, nuestra práctica de asesoría en PQC, que incluye una metodología de migración estructurada, ayuda a secuenciar ese trabajo utilizando los mismos datos de inventario en lugar de empezar desde cero.

Conclusión

La revocación masiva de certificados de DigiCert en 2024 se resolvió hace años, pero las condiciones que la hicieron problemática persisten, e incluso se han vuelto más estrictas. Un certificado de 398 días ofrecía a los equipos un amplio margen de error manual. Un certificado de 47 días no. Las organizaciones que gestionan el ciclo de vida de los certificados como una infraestructura continua y automatizada, en lugar de una tarea secundaria que solo se revisa durante una crisis, serán las que afrontarán la próxima revocación masiva, de cualquier CA, sin mayores problemas. Quienes aún dependan de hojas de cálculo y recordatorios de calendario revivirán julio de 2024 con mucha más precaución.

Preguntas frecuentes

¿Cuál es la principal conclusión que se puede extraer de las lecciones aprendidas de la revocación masiva de certificados de DigiCert?

La lección principal es que cualquier autoridad de certificación puede verse obligada a revocar certificados masivamente con tan solo 24 horas de aviso, según las normas del Foro CA/Browser. Las organizaciones que ya contaban con un inventario de certificados completo y actualizado se recuperaron rápidamente. Aquellas que dependían del seguimiento manual se vieron desbordadas, y algunas aún tenían certificados expuestos activos en servidores públicos semanas después de la fecha límite.

¿Por qué es importante esto para la gestión del ciclo de vida de los certificados empresariales?

La gestión del ciclo de vida de los certificados determina si un evento de revocación es una respuesta automatizada rutinaria o una emergencia que requiere la intervención de todo el personal. A medida que el Foro CA/Browser reduce gradualmente la validez máxima de los certificados a 47 días para 2029, el margen operativo para los procesos manuales se reduce cada vez más, lo que convierte la gestión automatizada del ciclo de vida en un requisito básico en lugar de una mejora opcional.

¿Qué equipos son responsables de poner en práctica estas directrices?

Los equipos de PKI, seguridad, plataforma e infraestructura, y cumplimiento normativo tienen cada uno una parte de este proceso. Los equipos de PKI necesitan flujos de trabajo de emisión que toleren periodos de validez más cortos, los equipos de seguridad necesitan una supervisión más rápida de la transparencia de los certificados, los equipos de plataforma necesitan renovación e implementación automatizadas, y los equipos de cumplimiento normativo necesitan un inventario listo para auditorías disponible bajo demanda.

¿Qué riesgos aumentan si este tema se aborda manualmente?

La gestión manual de certificados aumenta el riesgo de interrupciones por certificados caducados, un problema que, según la propia encuesta de DigiCert de julio de 2025, el 37.5 % de las organizaciones ya habían experimentado, junto con una respuesta más lenta durante un período de revocación de emergencia, pruebas de auditoría más débiles y una mayor probabilidad de que los certificados no oficiales pasen desapercibidos hasta que provoquen un incidente.

¿Cómo reduce la automatización el riesgo de interrupción de los certificados?

El descubrimiento automatizado encuentra certificados en todo el entorno sin depender de que alguien recuerde su existencia, mientras que la renovación basada en políticas mediante protocolos como ACME, SCEP y EST reemplaza los certificados antes de que caduquen sin intervención manual. Esta combinación permite que un ciclo reducido de 47 días, o una notificación de revocación masiva repentina, se asuman como operaciones rutinarias en lugar de una crisis.

¿Qué métricas deberían monitorizar los equipos tras la implementación?

Realizar un seguimiento del porcentaje de certificados renovados automáticamente frente a los renovados manualmente, el número de interrupciones o incidentes relacionados con certificados por trimestre, el tiempo promedio para asignar un propietario a un certificado recién descubierto, el tiempo para generar un inventario completo bajo demanda y el tiempo promedio para revocar y reemplazar un certificado durante una emergencia.

¿Cómo se relaciona esto con el plazo de 47 días para la obtención del certificado TLS?

El incidente de DigiCert es un anticipo de la presión operativa a la que se enfrentará permanentemente toda organización una vez que la validez máxima de 47 días del CA/Browser Forum entre en vigor el 15 de marzo de 2029. Las mismas capacidades automatizadas de detección, inventario y renovación que limitan los daños durante un evento de revocación masiva son precisamente lo que requiere un ciclo de renovación de 47 días como práctica habitual.

¿Cómo debería gestionarse esto en entornos PKI híbridos o multinube?

Los entornos PKI híbridos y multinube requieren una única capa de gestión de certificados que pueda descubrir y administrar certificados en todos los entornos mediante un conjunto común de políticas y API. Sin esta consolidación, una revocación masiva o un período de renovación reducido deja al descubierto las deficiencias entre las herramientas desconectadas, y la aplicación de un ciclo de 47 días resulta inconsistente entre los distintos entornos.