En el panorama en constante evolución de la seguridad en Internet, pocos cambios tienen el potencial de remodelar prácticas fundamentales como la actualización de la política del programa raíz de Google Chrome. A lo largo de una serie de plazos que comienzan en 2026, Chrome está cambiando cómo Certificados SSL/TLS se puede utilizar. Las jerarquías de certificados públicos ahora deben dedicarse exclusivamente a la autenticación de servidor TLS, lo que significa que la compatibilidad con la autenticación de cliente TLS está desapareciendo en el mundo de los certificados públicos. Si su organización depende de certificados públicos autoridades de certificación En lo que respecta a las autoridades de certificación (CA) para autenticar usuarios, dispositivos o aplicaciones, este cambio exige atención inmediata.
Analicemos qué significa esto, por qué está sucediendo y cómo puedes prepararte.
El corazón del cambio: Política del programa raíz de Chrome v1.8
En el centro de esta transición se encuentra la Política del Programa Raíz de Chrome v1.8 (última actualización: 5 de febrero de 2026), que continúa impulsando el programa hacia la autenticación de servidor TLS dedicada. PKI jerarquías. Según esta política, las jerarquías de certificados incluidas en el almacén de confianza de Chrome deben servir únicamente para la autenticación de servidor TLS, y las raíces de uso múltiple se están eliminando gradualmente.
En la práctica, esto significa que las autoridades de certificación públicas se están alejando de certificados que incluyen los usos de clave extendida (EKU) id-kp-serverAuth e id-kp-clientAuth. Estos EKU definen para qué se puede usar un certificado: autenticación de servidor o de cliente, pero no ambas. El cambio se producirá en dos fechas importantes que conviene anotar en el calendario.
A partir del 15 de junio de 2026, cualquier nuevo certificado de CA intermedio (subordinado) divulgado a la CCADB bajo una raíz en el Chrome Root Store deberá contener únicamente la EKU serverAuth. Posteriormente, a partir del 15 de marzo de 2027, la misma regla se aplicará a los certificados que usted implemente: cada certificado hoja recién emitido que se encadene a una raíz de confianza de Chrome también deberá contener únicamente serverAuth. Después de esa fecha, clientAuth desaparecerá de los certificados públicos.
Los certificados emitidos antes de la fecha límite aplicable seguirán siendo válidos hasta su vencimiento (a menos que sean revocados), pero los certificados públicos nuevos y renovados ya no incluirán clientAuth. La mayoría de los principales CAEmpresas como DigiCert, Sectigo y Let's Encrypt comenzaron a eliminar la EKU clientAuth por defecto mucho antes de estas fechas límite.
¿Por qué este Matters
La autenticación de cliente TLS es un mecanismo crítico que se utiliza para verificar la identidad de los clientes, ya sean usuarios, dispositivos o aplicaciones, cuando se conectan a un servidor. Es distinto de la autenticación del servidor, que es lo que la mayoría de la gente asocia con HTTPS.
La autenticación de cliente se utiliza comúnmente en:
- Acceso VPN: Verificación de los dispositivos de los empleados que se conectan de forma remota.
- Activación de la conexión Wi-Fi: Autenticación de dispositivos sin contraseñas estáticas.
- TLS mutuo (mTLS): Garantizar la seguridad de la comunicación API en microservicios.
- Inicio de sesión único (SSO): Integración de certificados en dispositivos de punto final.
- Entornos DevOps: Identificación de cargas de trabajo y contenedores.
Muchas organizaciones han estado utilizando autoridades de certificación públicas para estos fines, a menudo sin saberlo, porque resulta práctico y económico. Pero con la nueva política de Chrome, este enfoque ya no será viable.
¿Por qué está pasando esto?
Esta medida forma parte de una tendencia más amplia del sector hacia una mayor dedicación. PKI jerarquías. Los certificados multipropósito, aquellos que se utilizan tanto para la autenticación del servidor como del cliente, introducen complejidad y posibles riesgos de seguridad. Al separar estos casos de uso, navegadores como Chrome buscan:
- Mejorar la gestión de certificados.
- Reforzar la confianza en la infraestructura de clave pública (PKI).
- Reduce el riesgo de mal uso o mala configuración.
Las autoridades de certificación públicas nunca se diseñaron para flujos de trabajo de autenticación interna. Están sujetas a auditorías externas, normativas de cumplimiento y políticas de navegador. Esto las hace inadecuadas para la flexibilidad y el control que requieren los escenarios de autenticación de clientes.
La solución: la transición a las CA privadas
Si su organización utiliza certificados públicos para la autenticación de clientes, el camino a seguir es claro: migrar a una autoridad de certificación (CA) privada.
Los beneficios de las CA privadas incluyen:
- Perfiles de certificados personalizables.
- Control total sobre la emisión y revocación.
- No depende de los almacenes de confianza del navegador.
- Soporte para protocolos como CUMBRE, EST y SCEP.
Este cambio permite a las organizaciones diseñar flujos de trabajo de autenticación adaptados a sus necesidades, sin verse limitadas por las CA públicas.
Qué debes hacer a continuación
Aquí tienes una guía práctica para prepararte para las fechas límite de Chrome en 2026 y 2027:
- Audite el uso de su certificado: Identifique dónde se utiliza la autenticación de cliente TLS. ¿Utiliza flujos de trabajo ACME públicos como Let's Encrypt? ¿Qué dispositivos y servicios se ven afectados?
- Evalúe su riesgo: Determina qué certificados se verán afectados y cuándo. Planifica su reemplazo antes de que caduquen o dejen de ser confiables.
- Implementar una CA privada: Elija una solución que se adapte a su entorno: en la nube, local o híbrida. Asegúrese de que admita la automatización y la integración con sus herramientas existentes.
- Implemente CLM y migre sus certificados de CA públicos a una CA privada: Con su CA privada establecida, implemente una CLM Plataforma para gestionar el ciclo de vida de los certificados, aplicar políticas y mantener la visibilidad en todo el entorno. Antes de migrar, defina las plantillas de certificado y las EKU adecuadas en la CA privada para que los certificados reemitidos incluyan los usos correctos (para la autenticación de clientes, la EKU clientAuth sin serverAuth). Una vez configurado esto, utilice la función de cambio de CA de CLM para transferir masivamente los certificados de autenticación de clientes de la CA pública existentes a la CA privada, en lugar de buscarlos y reemitirlos manualmente uno por uno.
- Eduque a sus equipos: Asegúrese de que la TI, DevOpsy los equipos de seguridad comprenden las implicaciones y están alineados con la estrategia de migración.
¿Cómo puede ayudar la consultoría de cifrado?
Consultoría de cifrado Administrador de CertSecure Es una solución de gestión del ciclo de vida de certificados independiente del proveedor que centraliza el descubrimiento, la automatización, el registro, la aplicación de políticas y las integraciones. Previene interrupciones gracias a las renovaciones automatizadas, mejora el cumplimiento normativo, optimiza las operaciones de TI y unifica la gestión de las CA públicas y privadas a través de una plataforma única, automatizada y escalable.
En lo que respecta específicamente al cambio en Chrome, su función de detección e inventario le permite encontrar exactamente cuáles de sus certificados tienen la EKU clientAuth actualmente, y su migración de CA pública con un solo clic le ayuda a trasladar esas cargas de trabajo a una CA privada de forma masiva, sin el esfuerzo manual de rastrear y volver a emitir certificados uno por uno.
Además, si necesita un lugar para emitir certificados de autenticación de clientes una vez que salgan del almacén de confianza pública, Encryption Consulting PKI como servicio Te ofrece una CA privada totalmente administrada. Gestiona tu implementación de PKI de principio a fin, con emisión de certificados, administración automatizada del ciclo de vida, aplicación de políticas y cumplimiento con los estándares de seguridad de la industria, para que puedas establecer una jerarquía privada dedicada para VPN, Wi-Fi, mTLS y SSO sin tener que construir ni operar la infraestructura tú mismo.
Conclusión
La actualización del programa raíz de Chrome no es solo un ajuste técnico; marca un cambio fundamental en la forma en que se gestionan la identidad digital y la confianza en internet. Si bien puede alterar los flujos de trabajo de autenticación existentes, también ofrece a las organizaciones una oportunidad oportuna para modernizar su arquitectura PKI y construir una base más segura, escalable y resiliente.
Si su organización aún utiliza certificados públicos para la autenticación de clientes, es hora de actuar. Los plazos son fijos, la aplicación de la normativa es estricta y la decisión de Chrome de utilizar una infraestructura de clave pública (PKI) dedicada exclusivamente a la autenticación de servidores convierte a las autoridades de certificación privadas en la única opción viable.
Al mismo tiempo, el creciente volumen de certificados, la reducción de su vigencia y la creciente complejidad de los entornos distribuidos hacen que la gestión del ciclo de vida de los certificados (CLM) sea esencial, no opcional. Una solución CLM robusta previene interrupciones, automatiza las renovaciones, garantiza el cumplimiento normativo y proporciona a las organizaciones visibilidad y control totales sobre sus activos criptográficos.
En un ecosistema donde los requisitos de confianza del navegador siguen endureciéndose, PKI A medida que los entornos se diversifican y las identidades digitales se multiplican en arquitecturas de nube, DevOps, IoT y de confianza cero, la gestión eficaz del ciclo de vida de los certificados se convierte en un elemento fundamental para una estrategia de autenticación segura, eficiente y preparada para el futuro.
