Resumen
- Una retirada, una fecha de desconfianza o una versión del navegador cambia la política deseada; no demuestra que cada sistema, aplicación, contenedor o equipo integrado la aplique.
- La operación debe tratarse como una migración de los sistemas que validan la cadena, con pruebas de rechazo para cada fuente de confianza y cohorte de clientes.
En un escenario de validación controlado e hipotético, una cohorte actual de Chrome rechaza una cadena TLS, mientras un equipo Windows administrado por la empresa y un servicio dentro de una imagen de contenedor antigua la aceptan. El certificado es idéntico en los tres ensayos hipotéticos.
No es una rareza de sintaxis. Es el mapa de tres decisiones de confianza diferentes.
En 2024, Chrome anunció una desconfianza dirigida contra determinadas raíces de Entrust. La regla dependía de la fecha del primer Signed Certificate Timestamp: los certificados posteriores al límite publicado dejarían de ser fiables por defecto a partir de Chrome 131, mientras que los anteriores recibirían otro trato. No fue la simple eliminación de un archivo interpretada al mismo tiempo por todos los clientes, sino una regla de aceptación con fecha efectiva, versión del navegador y espacio para raíces locales expresamente confiables.
La arquitectura de Chrome deja ver el problema de la flota. En Windows, macOS, ChromeOS, Linux y Android, Chrome ha avanzado hacia su propio almacén de raíces y mecanismo integrado de validación. En iOS rigen las reglas de la plataforma Apple. Una política empresarial también ha permitido temporalmente elegir entre el almacén de Chrome y el mecanismo de validación de la plataforma, y Chrome puede incorporar raíces en las que el sistema operativo confía expresamente. El nombre del navegador no identifica toda la fuente de confianza.
Microsoft muestra una segunda divergencia. Su documentación distingue Removal, EKU Removal, Disallow, Disable y NotBefore. Retirar una raíz de la lista de confianza hace que sus cadenas no sean fiables por defecto, pero en ciertos almacenes todavía puede instalarse manualmente. Disallow es más fuerte: añade el certificado a la lista prohibida y una instalación manual no recupera sin más la confianza. Disable y NotBefore tienen reglas temporales y de uso distintas.
Esos estados se distribuyen mediante actualizaciones. Los clientes Windows conectados pueden recibir automáticamente las listas de confianza y prohibición. Una red aislada puede redirigirlas a un servidor interno. Microsoft documenta cómo comprobar por separado AuthRoot y Disallowed y su última sincronización. Una política publicada en un servidor no prueba que el cliente la haya consumido.
Apple publica un almacén raíz compartido y archiva versiones anteriores. La versión instalada es, por tanto, una prueba operativa. También advierte que un dispositivo antiguo no queda descrito por la lista actual de una página. Mozilla diferencia del mismo modo entre desactivar permisos de confianza y retirar el certificado, puede programar cualquiera de las dos medidas y permite que distribuidores derivados mantengan selecciones diferentes.
Definir la acción antes de medirla
«Retirar la raíz» es demasiado impreciso para dirigir un incidente. La intención puede ser rechazar todas las cadenas, solo los certificados emitidos después de una fecha, un uso concreto o una raíz dentro de un programa de certificados raíz, conservando a la vez una excepción privada. Cada acción requiere un resultado de prueba diferente.
El denominador no son los dispositivos inscritos, sino las cohortes de sistemas de validación: navegador y versión, almacén del sistema, entorno de ejecución, almacén de certificados del runtime, imagen base, firmware, cliente integrado y excepción administrada. Para cada cohorte hay que conservar la huella de la raíz, la cadena observada y si se espera aceptación o rechazo. Un cliente obsoleto que aún conecta después de una medida de seguridad está fallando, aunque el monitor de disponibilidad lo marque en verde.
Los documentos públicos prueban políticas y mecanismos de distribución. No revelan el inventario, las excepciones, el ciclo de firmware ni los resultados de un operador. La conclusión operativa es una inferencia: el cambio de confianza debe contrastarse con los sistemas que validan el proceso real. No atribuye una interrupción a ningún cliente, operador de raíz o plataforma.
Fuentes
- https://security.googleblog.com/2024/06/sustaining-digital-certificate-security.html
- https://www.chromium.org/Home/chromium-security/root-ca-policy/
- https://support.google.com/chrome/a/answer/2657289
- https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/
- https://learn.microsoft.com/en-us/security/trusted-root/deprecation
- https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/configure-trusted-roots-disallowed-certificates
- https://support.apple.com/en-us/103272
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

