Mozilla de Firefox sigue los pasos de Google y desconfía de los certificados TLS de Entrust

Respuesta rápida: Mozilla dejó de confiar en los certificados raíz TLS de Entrust emitidos después del 30 de noviembre de 2024, un mes después de la fecha límite del 11 de noviembre de 2024 establecida por Google Chrome, debido a años de incumplimientos de normativa sin resolver. Posteriormente, Entrust vendió todo su negocio de certificados públicos a Sectigo, completando la operación el 18 de septiembre de 2025. Las organizaciones que aún utilizan certificados de Entrust deberían migrar ahora y automatizar la gestión del ciclo de vida.

Durante décadas, Entrust fue una de las autoridades de certificación más consolidadas de internet, y aproximadamente el 10 % de las empresas Fortune 500 confiaban en ella para proteger sus principales sitios web. Esto cambió en 2024. Google Chrome y Mozilla Firefox eliminaron a Entrust de sus almacenes de certificados raíz tras años de fallos de cumplimiento sin resolver, y las consecuencias no terminaron ahí: Entrust vendió todo su negocio de certificados públicos a Sectigo en 2025. Para cualquier organización que aún utilice certificados emitidos por Entrust o que desee comprender cómo una autoridad de certificación pierde la confianza de los navegadores, aquí tiene la información completa y actualizada.

Resumen Ejecutivo

Entrust perdió la confianza de los navegadores por etapas: Google Chrome dejó de emitir nuevos certificados de Entrust el 11 de noviembre de 2024, Apple hizo lo mismo el 15 de noviembre de 2024 y Mozilla Firefox el 30 de noviembre de 2024, citando todos años de fallos de cumplimiento sin resolver en lugar de un solo incidente. Entrust vendió entonces todo su negocio de certificados públicos a Sectigo, completando la transición el 18 de septiembre de 2025. La misma presión subyacente, una industria que se aleja de tolerar la gobernanza de certificados lenta y manual, es lo que también impulsa la votación SC-081v3 del CA/Browser Forum , que 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 certificados TLS de 47 días para marzo de 2029. La encuesta Trust Pulse de DigiCert de julio de 2025 encontró que el 45% de las empresas tuvieron tiempo de inactividad relacionado con certificados en el año anterior, y el 37.5% se atribuyó a un certificado caducado (Fuente: Encuesta Trust Pulse de DigiCert, julio de 2025 ). Las organizaciones que no pudieron responder rápidamente "¿cuáles de nuestros certificados provienen de Entrust?" a finales de 2024 son las mismas organizaciones que tendrán problemas con los ciclos de renovación de 47 días en 2029; Ambos problemas tienen su origen en la misma deficiencia en la detección y automatización de certificados.

Ir a: Conclusiones clave | Cronograma | Impacto por rol | Lista de verificación de preparación | Hoja de ruta de migración | Cómo puede ayudar EC | Preguntas frecuentes

Puntos Clave

• Mozilla Firefox dejó de confiar en los certificados TLS de Entrust emitidos después del 30 de noviembre de 2024, un mes después de la fecha límite del 11 de noviembre de 2024 establecida por Google Chrome y del 15 de noviembre de 2024 establecida por Apple Safari.
• Ambos navegadores citaron años de fallos de cumplimiento sin resolver, y no un solo incidente, como motivo de la desconfianza.
• Entrust procedió a vender la totalidad de su negocio de certificados públicos a Sectigo, operación que se anunció el 29 de enero de 2025 y que se completó el 18 de septiembre de 2025.
• Akamai recomendó a sus clientes que reemplazaran los certificados de origen de Entrust y eliminó las raíces de Entrust y AffirmTrust de su repositorio de certificados de confianza antes del 1 de marzo de 2025.
• La propuesta SC-081v3 del Foro CA/B, aprobada en abril de 2025, reduce la validez máxima de los certificados TLS públicos 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, lo que hace que las transiciones manuales de CA sean cada vez más difíciles de gestionar.
• La encuesta Trust Pulse de DigiCert de julio de 2025 reveló que el 45 % de las empresas experimentaron interrupciones del servicio relacionadas con certificados durante el último año, y que el 37.5 % de esas interrupciones se debieron a certificados caducados.

La decisión inicial de Google de desconfiar de Entrust

En junio de 2024, el programa Chrome Root de Google fue el primero en anunciar que dejaría de confiar en Entrust como autoridad de certificación (CA) , citando un patrón de comportamientos preocupantes observados durante varios años. Numerosos incidentes de incumplimiento habían mermado la confianza de Google en la capacidad de Entrust para cumplir con los requisitos del programa Chrome Root. El bloqueo de Chrome se aplica a los certificados de Entrust con una marca de tiempo de certificado firmado (SCT) posterior al 11 de noviembre de 2024 a las 11:59:59 UTC, y entró en vigor con Chrome 131.

La decisión de Mozilla de desconfiar de Entrust

Ben Wilson, responsable de la tienda de aplicaciones de Mozilla, explicó la decisión en una publicación pública en el foro de políticas de seguridad para desarrolladores de Mozilla, señalando que la respuesta de Entrust no inspiró confianza a pesar de los esfuerzos declarados de la compañía por solucionar los problemas. Wilson recalcó que el informe actualizado de Entrust no difería significativamente de los compromisos que la compañía adquirió en 2020, compromisos que posteriormente incumplió.

La decisión de Mozilla se basó en tres factores:

• Incumplimientos reiterados: Entre marzo y mayo de 2024, Mozilla registró 22 incidentes distintos relacionados con Entrust, muchos de ellos vinculados a retrasos e incumplimiento de plazos.
• Respuesta inadecuada: La respuesta de Entrust a las preocupaciones de Mozilla no demostró un cambio significativo en sus operaciones.
• Contexto histórico: Los compromisos previos de Entrust de 2020 no se cumplieron, lo que influyó en la confianza de Mozilla en la respuesta de 2024.

Cronología de la desconfianza y la confianza: fechas de entrada en vigor, impacto y fuentes

La tabla que aparece a continuación detalla todos los hitos confirmados en la desconfianza hacia Entrust, desde los cortes iniciales en los navegadores hasta la salida de Entrust del negocio de los certificados públicos y el cambio generalizado en el sector hacia periodos de validez de certificados más cortos.

Fecha de vigencia	Requisito	¿Quiénes se ven afectados?	Acción Necesaria	Fuente
11 de noviembre.	Google Chrome deja de confiar en los nuevos certificados TLS de Entrust (SCT con fecha posterior a esta fecha límite).	Más de 131 usuarios de Chrome en Windows, macOS, ChromeOS, Android y Linux.	Reemplace cualquier certificado Entrust emitido después de esta fecha.	Blog de seguridad en línea de Google
15 de noviembre.	Apple desconfía de los nuevos certificados de las raíces Entrust afectadas.	Usuarios de Safari y otras plataformas de Apple	Confirme que ningún certificado nuevo emitido por Entrust dependa de la confianza de Apple después de esta fecha.	Guía sobre desconfianza en los certificados DigiCert Entrust
30 de noviembre.	Mozilla Firefox deja de confiar en los nuevos certificados TLS de Entrust.	Usuarios de Firefox en todas las plataformas, además de software que no es un navegador y que depende del almacén de confianza de Mozilla.	Reemplace cualquier certificado Entrust emitido después de esta fecha.	Anuncio de la política de seguridad para desarrolladores de Mozilla
Marzo 1, 2025	Akamai elimina las raíces de Entrust y AffirmTrust de su almacén de confianza de origen.	Clientes de Akamai que utilizan certificados Entrust en el origen	Reemplace los certificados de origen antes de esta fecha.	Guía de atención al cliente de Akamai
Marzo 11, 2025	Entrust deja de emitir nuevos certificados TLS públicos desde sus propias autoridades de certificación raíz.	Todos los clientes con certificado TLS de Entrust	Comience a migrar la emisión de certificados a Sectigo.	Centro de información sobre certificados TLS de Entrust
18 de septiembre de 2025	Entrust completa la transición de su negocio de certificados públicos a Sectigo.	Todos los clientes restantes de certificados públicos de Entrust	Migración completa a Sectigo para cualquier renovación.	Centro de información sobre certificados TLS de Entrust
Marzo 15, 2026	El foro CA/B reduce la validez máxima de los certificados TLS públicos a 200 días.	Todas las organizaciones que utilizan certificados TLS de acceso público	Adopte un ciclo de renovación de 6 meses y evalúe la automatización.	Boleta del Foro CA/B SC-081v3 (vía Sectigo)
Marzo 15, 2027	La validez máxima de un certificado TLS público se reduce a 100 días.	Todas las organizaciones que utilizan certificados TLS de acceso público	Adoptar un ciclo de renovación trimestral.	Boleta del Foro CA/B SC-081v3 (vía Sectigo)
Marzo 15, 2029	La validez máxima de un certificado TLS público se reduce a 47 días.	Todas las organizaciones que utilizan certificados TLS de acceso público	Automatice completamente la emisión y renovación de certificados.	Boleta del Foro CA/B SC-081v3 (vía Sectigo)

Nota de implementación: esta tabla muestra la URL de esta publicación en su versión preliminar. Si la URL publicada difiere de la que se muestra aquí, actualice esta fila antes de publicarla en producción.

Respuesta de Akamai para clientes empresariales

Tras la decisión de Google, Akamai emitió directrices específicas para los clientes que utilizaban certificados de Entrust . Akamai continuó ofreciendo soporte para los certificados de borde de Entrust en su CDN segura hasta su vencimiento, pero recomendó reemplazarlos de forma proactiva para evitar interrupciones en los clientes de Chrome. Para las conexiones de origen, Akamai eliminó los certificados raíz de Entrust y AffirmTrust de su almacén de confianza antes del 1 de marzo de 2025. Los clientes que no hubieran reemplazado los certificados afectados para esa fecha corrían el riesgo de sufrir interrupciones en el tráfico seguro hacia su infraestructura de origen.

¿Por qué los navegadores desconfían de las autoridades de certificación?

El papel de las autoridades competentes y el cumplimiento normativo

Las autoridades de certificación (CA) generan confianza en internet mediante la emisión de certificados que permiten conexiones cifradas entre navegadores y sitios web. Para mantener esa confianza, las CA deben cumplir con estrictos estándares de la industria definidos por los Requisitos Básicos del Foro CA/Navegador (CA/B) . Estos estándares abarcan:

• Procesos de validación: Validación adecuada de las solicitudes de certificados para confirmar la autenticidad de la entidad solicitante.
• Seguridad operacional: Medidas de seguridad robustas que protegen la infraestructura de la CA e impiden la emisión de certificados no autorizados.
• Cumplimiento de los protocolos: Cumplimiento de los protocolos establecidos para la emisión, gestión y revocación de certificados.

Auditorías y rendición de cuentas

Las autoridades de certificación (CA) rinden cuentas mediante auditorías periódicas realizadas por terceros independientes. Estas auditorías verifican el cumplimiento de los requisitos básicos del Foro CA/B. El incumplimiento de estos estándares puede llevar a los navegadores a desconfiar por completo de los certificados de una CA.

El proceso de toma de decisiones de desconfianza de CA

Cuando un navegador como Google Chrome o Mozilla Firefox decide no confiar en una CA, el proceso generalmente sigue cuatro etapas:

• Recopilación de pruebas: Investigación de los procesos de emisión de la CA, la seguridad operativa y el cumplimiento de los estándares de la industria, a partir de registros de transparencia, foros y divulgaciones públicas.
• Evaluación conforme a las normas: Evaluar la evidencia frente a los Requisitos Base del Foro CA/B para determinar el cumplimiento.
• Divulgación pública y respuesta: Compartir los hallazgos con la CA y el público, dando a la CA la oportunidad de responder y esbozar las medidas correctivas.
• Decisión final: En función de la respuesta de la CA y la gravedad de los problemas, el navegador puede proceder con desconfianza si la respuesta se considera insuficiente.

El impacto de la desconfianza en las empresas

Cuando una CA pierde credibilidad, todos los certificados que ha emitido dejan de ser reconocidos como válidos por el navegador afectado. Las consecuencias prácticas son significativas:

• Advertencias de seguridad: Los sitios web que utilizan certificados de autoridades de certificación no confiables muestran advertencias en el navegador, lo que puede minar la confianza del usuario y exponer vulnerabilidades reales.
• Riesgos de cumplimiento: Las organizaciones que no reemplacen los certificados que no sean de confianza pueden enfrentarse a infracciones normativas y a observaciones en las auditorías.
• Interrupciones operativas: La sustitución de certificados a gran escala puede interrumpir el servicio, aumentar los costes operativos y consumir una cantidad considerable de tiempo del personal.

El mecanismo detallado de la desconfianza en las CA

1. Informe de incidentes: El proceso comienza con la detección y el reporte de incidentes de cumplimiento, que a menudo salen a la luz gracias a investigadores de seguridad, otras autoridades de certificación o sistemas de monitoreo automatizados.
2. Repaso inicial: El Foro CA / B o bien el equipo de la tienda de aplicaciones del navegador realiza una revisión inicial. Los incidentes graves dan lugar a una investigación más exhaustiva.
3. Investigación: La investigación examina las prácticas de emisión de la CA, los informes de auditoría y la postura de seguridad general.
4. Revelación pública: Las conclusiones se hacen públicas y se le da a la CA la oportunidad de responder y esbozar las medidas correctivas.
5. Evaluación de la respuesta: El equipo de la tienda raíz del navegador evalúa si la respuesta y las medidas correctivas de la CA son adecuadas.
6. Decisión de desconfianza: Si la respuesta no es suficiente, el navegador procede con desconfianza y actualiza su almacén raíz para eliminar la confianza en la CA. certificados raíz.
7. Impacto en los certificados: Todos los certificados emitidos por la CA no confiable dejan de ser válidos en ese navegador, y las organizaciones afectadas deben reemplazarlos por certificados de una CA confiable.

Precedente histórico: La desconfianza hacia Symantec

La desconfianza hacia Entrust recuerda al caso de Symantec en 2018. Google detectó múltiples casos de emisión irregular de certificados por parte de Symantec, lo que llevó a la eliminación gradual de la confianza en los certificados de Symantec en los principales navegadores. Este proceso culminó con la venta del negocio de CA de Symantec a DigiCert, un resultado similar al que Entrust siguió seis años después con su venta a Sectigo.

El panorama general: la reducción de la vigencia de los certificados aumenta las apuestas.

La desconfianza hacia Entrust no es un hecho aislado. Es un ejemplo de una tendencia más amplia hacia la reducción de la duración de los certificados y una menor tolerancia a la gestión manual de los mismos. Una encuesta de DigiCert Trust Pulse, publicada el 2 de julio de 2025, reveló que el 45 % de las empresas experimentaron interrupciones en el servicio relacionadas con certificados durante el último año, y el 37.5 % de esas interrupciones se debieron específicamente a certificados caducados. El seguimiento manual de certificados ya está resultando ineficaz para las organizaciones con el actual período máximo de validez de 398 días.

Este desafío está a punto de intensificarse. El 11 de abril de 2025, el Foro CA/B aprobó la propuesta SC-081v3 , una medida respaldada por Sectigo que reduce gradualmente la validez máxima de los certificados TLS públicos de 398 días a 200 días el 15 de marzo de 2026, a 100 días el 15 de marzo de 2027 y, finalmente, a 47 días el 15 de marzo de 2029. Cada ciclo de renovación, que antes se realizaba una vez al año, deberá realizarse aproximadamente cada seis semanas para 2029. Un evento de desconfianza de la CA bajo este cronograma dejaría a las empresas prácticamente sin margen de reacción manual, razón por la cual la automatización de certificados ha pasado de ser una conveniencia a un requisito.

Impacto empresarial por función y fecha límite

La respuesta ante un incidente de desconfianza en la CA y la preparación para una menor vigencia de los certificados involucran a más de un equipo. Esta matriz describe los cambios que se producen en cada grupo y las medidas a tomar al respecto.

Equipo	Lo que esto significa para usted	Acción inmediata	Fecha límite para realizar el seguimiento
Equipo de PKI/Certificados	Posee directamente cualquier certificado emitido por Entrust que quede y la menguante vigencia.	Inventaría todos los certificados Entrust que aún estén en producción y confirme la CA de reemplazo.	Inmediato, luego 15 de marzo de 2026 para una validez de 200 días.
Seguridad	Es responsable de la evaluación de riesgos para los cambios de confianza de CA y del plan de respuesta a incidentes para futuros eventos de desconfianza.	Agregar escenarios de desconfianza en la CA y vencimiento de certificados al plan de respuesta a incidentes	Hasta proximo aviso
Equipo de plataforma/infraestructura	Gestiona los servidores, balanceadores de carga y CDN donde se implementan los certificados.	Confirme que los protocolos de automatización como ACME, SCEP o EST estén habilitados en cada punto de contacto del certificado.	Antes del 15 de marzo de 2026
Equipo de cumplimiento	Debe demostrar la gobernanza de certificados para marcos como PCI DSS, HIPAA y DORA.	Documente la migración de la CA y conserve la evidencia del reemplazo del certificado.	Alineado con el ciclo de auditoría de cada marco

Lista de verificación de preparación para el ciclo de vida del certificado

• Inventaria todos los certificados que aún emita Entrust o cualquier otra autoridad de certificación que no sea de confianza.
• Confirme qué sistemas internos se vinculan directamente a los certificados raíz de Entrust en lugar de validar la cadena completa.
• Pruebe los protocolos de inscripción automatizada, incluidos ACME, SCEP y EST, con su CA de reemplazo.
• Configure alertas de vencimiento con 30, 14 y 7 días de antelación a la fecha de caducidad de cualquier certificado.
• Documente la migración como evidencia de cumplimiento para las auditorías de PCI DSS, HIPAA o DORA.
• Revise las dependencias de proveedores y SaaS que aún puedan hacer referencia internamente a raíces de Entrust.

Hoja de ruta de migración: ¿Qué hacer a continuación?

1. ejecutar un completo descubrimiento de certificados Escanee las autoridades de certificación públicas y privadas para encontrar cualquier certificado emitido por Entrust que aún esté disponible.
2. Priorice la sustitución de los dominios de cara al cliente y que son críticos para los ingresos.
3. Seleccione una CA de reemplazo (Sectigo ahora emite directamente el volumen de certificados públicos que antes emitía Entrust) y confirme su compatibilidad con el protocolo de automatización.
4. Automatice la reemisión y renovación a través de ACME, SCEP o EST en lugar de realizar solicitudes manuales.
5. Extienda la misma automatización a los certificados que se acerquen a los 200 días, luego a los 100 días y luego Validez de 47 días hitos.
6. Vuelva a probar los planes de recuperación ante desastres y respuesta a incidentes frente a un evento simulado de desconfianza en CA.

Consideraciones sobre infraestructura de clave pública (PKI) híbrida y multinube

Las organizaciones que gestionan certificados en AWS, Azure, Google Cloud y PKI locales se enfrentan a una versión más compleja de este problema. Cada entorno suele tener su propio almacén de certificados, herramientas de renovación y relaciones con las CA. Un evento de desconfianza en una CA o la reducción de su período de validez los afecta a todos simultáneamente, aunque rara vez al mismo tiempo. Centralizar el descubrimiento y la automatización en todas las CA, tanto en la nube como locales, en lugar de gestionar cada entorno por separado, es lo que evita que un evento como la desconfianza en Entrust se convierta en una situación crítica que dure varias semanas en un entorno híbrido. Desarrollar este tipo de agilidad criptográfica ahora también sienta las bases para la migración poscuántica, que sigue la misma lógica de reducción de la vida útil de los certificados.

Cómo puede ayudar la consultoría de cifrado

La consultoría en cifrado ayuda a las empresas a anticiparse a los cambios en las autoridades de certificación, como la desconfianza en Entrust, antes de que se conviertan en emergencias. CertSecure Manager ofrece a los equipos de seguridad e infraestructura de clave pública (PKI) un panel de control único para descubrir todos los certificados en autoridades de certificación públicas, privadas y entornos en la nube, automatizar las renovaciones mediante ACME, SCEP y EST, y aplicar políticas para que ningún certificado dependa de una única relación con una autoridad de certificación.

Para los equipos que necesitan visibilidad completa de su huella criptográfica antes de una migración, CBOM Secure crea una Lista de Materiales Criptográficos ( CBOM ) actualizada continuamente para cada certificado, algoritmo y clave en todo el entorno, alineada con los marcos de cumplimiento que la requieren. Y dado que los eventos de desconfianza de las CA y la reducción de la vida útil de los certificados son síntomas de la misma tendencia hacia la agilidad criptográfica, nuestro Centro de Excelencia PQC y el servicio de asesoramiento sobre preparación para PQC ayudan a los equipos a crear una hoja de ruta que abarque tanto el riesgo actual de las autoridades de certificación como la transición poscuántica del futuro.

Conclusión

La desconfianza de Mozilla y Google hacia Entrust, y su posterior salida del negocio de los certificados públicos, pone de manifiesto la rapidez con la que los incumplimientos estrictos pueden acabar con la reputación de una CA. Las organizaciones que dependen de certificados digitales deben mantenerse alerta y ser capaces de adaptarse rápidamente a los cambios en el panorama de las CA. Esto implica abandonar el seguimiento manual y adoptar una gestión automatizada y con verificación continua del ciclo de vida de los certificados, especialmente ahora que el calendario de validez del Foro CA/B impulsa a todas las organizaciones a utilizar certificados de 47 días para 2029.

Comprender cómo y por qué surge la desconfianza hacia las autoridades de certificación, y desarrollar la agilidad criptográfica necesaria para responder a ella sin interrupciones, es lo que diferencia a las organizaciones que tratan un evento de desconfianza como una tarea de mantenimiento rutinaria de aquellas que lo tratan como una emergencia.

Preguntas frecuentes

¿Cuál es la principal conclusión del artículo de Firefox titulado "Mozilla sigue los pasos de Google al desconfiar de los certificados TLS de Entrust"?

La lección principal es que la confianza en una autoridad de certificación puede desvanecerse rápidamente una vez que esta acumula suficientes incumplimientos. Tanto Mozilla como Google eliminaron Entrust de sus almacenes raíz a finales de 2024, y Entrust finalmente vendió todo su negocio de certificados públicos a Sectigo en 2025. Las empresas que dependían de una sola autoridad de certificación tuvieron que migrar bajo presión de tiempo, que es precisamente el escenario que la gestión automatizada del ciclo de vida de los certificados está diseñada para evitar.

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

Un evento de desconfianza de una CA convierte cada certificado emitido por dicha autoridad en un contador en marcha, independientemente de su fecha de vencimiento original. Las empresas que gestionan certificados manualmente suelen descubrir los certificados dependientes de Entrust tarde, durante la respuesta a incidentes en lugar de durante la planificación. La gestión automatizada del ciclo de vida mantiene un inventario actualizado y puede activar la reemisión masiva en el momento en que cambia el estado de confianza de una CA, evitando así el caos que genera el seguimiento manual.

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

Los equipos de PKI y certificados son responsables de la migración técnica de los certificados afectados. Los equipos de seguridad se encargan de la evaluación de riesgos y la planificación de la respuesta a incidentes relacionados con los cambios de confianza de la CA. Los equipos de plataforma e infraestructura operan los servidores, balanceadores de carga y CDN donde se implementan los certificados y deben confirmar la compatibilidad con la automatización. Los equipos de cumplimiento documentan la migración como evidencia para marcos normativos como PCI DSS, HIPAA y DORA.

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

La gestión manual de certificados aumenta la probabilidad de pasar por alto un certificado dependiente de Entrust hasta que se active una advertencia de seguridad en el navegador o se produzca una interrupción del servicio. La encuesta Trust Pulse de DigiCert de julio de 2025 reveló que el 45 % de las empresas experimentaron interrupciones del servicio relacionadas con certificados durante el último año, y que el 37.5 % de esos incidentes fueron causados ​​por certificados caducados. El seguimiento manual también tiene dificultades para mantenerse al día a medida que la validez máxima de los certificados se reduce a 47 días.

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

Los protocolos de automatización como ACME, SCEP y EST permiten que una plataforma de gestión del ciclo de vida de los certificados detecte una fecha de vencimiento próxima o un cambio en la confianza de la CA y vuelva a emitir el certificado sin necesidad de una solicitud manual. Esto elimina la demora humana que suele causar la mayoría de las interrupciones relacionadas con los certificados y mantiene la frecuencia de renovación constante, incluso cuando los períodos de validez se reducen de 398 días en la actualidad a 47 días en marzo de 2029.

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

Se debe realizar un seguimiento del porcentaje de certificados con renovación automática frente a los de renovación manual, la cantidad de certificados próximos a caducar en un plazo de 30 días, el tiempo medio de reemisión tras un cambio de confianza en la CA y la cantidad de certificados que aún están vinculados a una sola CA. Los equipos de cumplimiento también deben realizar un seguimiento de la preparación para auditorías, como la rapidez con la que se puede generar un inventario completo de certificados cuando se solicite.

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

La desconfianza en Entrust y la decisión del Foro CA/B de establecer una validez de 47 días para los certificados son síntomas de un mismo cambio: la infraestructura de clave pública web (PKI) está endureciendo los requisitos de confianza y reduciendo el tiempo durante el cual una relación con una CA que no cumpla con los estándares puede causar daños. Las organizaciones que se preparan para los certificados de 47 días y las que se recuperan de un incidente de desconfianza en una CA necesitan la misma capacidad: la automatización completa de la detección, emisión y renovación de certificados.

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

Los entornos multinube e híbridos deben centralizar la detección y automatización de certificados, en lugar de gestionar cada proveedor de nube o CA local por separado. Un evento de desconfianza de la CA o un cambio en el período de validez afecta a todos los entornos a la vez, pero cada plataforma en la nube tiene sus propias herramientas y plazos de renovación. Una plataforma unificada de gestión del ciclo de vida de los certificados que abarque AWS, Azure, Google Cloud y la infraestructura de clave pública (PKI) local evita que cualquier entorno individual quede desatendido.