Mandato del Foro CA/Navegador: El fin de los certificados Dual-EKU

La propuesta SC-081v3 del Foro CA/Browser fue aprobada por unanimidad en abril de 2025 con el apoyo de los cuatro miembros principales del Foro ( Google, Apple, Microsoft y Mozilla) y 25 autoridades de certificación con derecho a voto. Esta propuesta introdujo una serie de cambios sustanciales en los Requisitos Básicos de TLS (TBR), siendo la separación del Uso Extendido de Claves del Cliente (EKU) uno de los más significativos desde el punto de vista estructural.

La política del programa raíz de Chrome v1.8 , que funciona como mecanismo de aplicación para el almacén raíz de Google Chrome , va más allá. Exige no solo que los certificados hoja no incluyan clientAuth, sino también que se reorganicen jerarquías PKI completas, incluyendo las CA intermedias que se encadenan a las raíces en el almacén raíz de Chrome, las cuales ya no deben contener valores EKU duales. La separación debe producirse a nivel de CA, no solo a nivel de certificado.

Antes de profundizar en el mandato, conviene sentar las bases técnicas. El Uso Extendido de Clave (EKU, por sus siglas en inglés) es un campo dentro de un certificado digital X.509 que define los fines específicos para los que se puede usar la clave pública de un certificado. Los sistemas que validan certificados comprueban los valores de EKU para determinar si un certificado presentado está autorizado para la operación que se intenta realizar.

Hay dos valores de EKU que se encuentran en el centro de este mandato:

• Autenticación del servidor (OID 1.3.6.1.5.5.7.3.1): Indica que el certificado es válido para autenticar un servidor ante un cliente. Esto es lo que utiliza tu sitio web HTTPS. Los navegadores comprueban esta EKU al establecer una conexión TLS.
• Autenticación de cliente (OID 1.3.6.1.5.5.7.3.2): Indica que el certificado es válido para autenticar un cliente ante un servidor. Esto se utiliza en mTLS, autenticación de dispositivos y en situaciones donde el cliente debe demostrar su identidad, en lugar de solo el servidor.

Las autoridades de certificación públicas emitieron certificados TLS que contenían valores EKU duales . El certificado tiene el siguiente aspecto:

Un único certificado podía contener tanto la autenticación del servidor como la del cliente . Esta práctica de doble EKU era conveniente, ya que un solo certificado podía cumplir una doble función, pero era arquitectónicamente deficiente, y el Foro CA/Browser la ha eliminado formalmente de la infraestructura de clave pública (PKI).

Respuesta rápida: ¿Qué es el requisito del certificado Dual-EKU?

La exigencia de certificados de doble EKU del CA/Browser Forum SC-081v3 (abril de 2025) y la política del programa raíz de Chrome v1.8 eliminan clientAuth de los certificados TLS de confianza pública. A partir del 15 de junio de 2026 , ninguna nueva CA intermedia podrá tener valores de doble EKU. A partir del 15 de marzo de 2027 , cada nuevo certificado TLS de confianza pública emitido deberá contener únicamente serverAuth . La autenticación del cliente deberá trasladarse a una jerarquía PKI privada dedicada.

Puntos Clave

• La propuesta SC-081v3 del Foro CA/Navegador fue aprobada por unanimidad en abril de 2025 con el apoyo de Google, Apple, Microsoft, Mozilla y 25 autoridades de certificación (CA) con derecho a voto. La Política del Programa Raíz de Chrome v1.8 impone la separación a nivel de jerarquía de CA, no solo a nivel de certificado hoja. A partir del 15 de junio de 2026, ninguna nueva CA intermedia divulgada a la CCADB podrá contener tanto serverAuth como clientAuth. A partir del 15 de marzo de 2027, cada nuevo certificado hoja TLS de confianza pública deberá contener únicamente la EKU serverAuth.
• La encuesta DigiCert Trust Pulse (2 de julio de 2025) reveló que el 45 % de las organizaciones experimentaron interrupciones del servicio relacionadas con certificados durante el año anterior, y el 37.5 % atribuyeron una interrupción a un certificado caducado. El requisito de doble EKU introduce un nuevo modo de fallo más difícil de diagnosticar: un certificado renovado sin clientAuth es válido, no ha caducado y es de confianza, pero falla silenciosamente en todos los casos de uso de autenticación de cliente con errores genéricos (fallo en el protocolo de enlace TLS, acceso denegado, fallo en la verificación del par) que no identifican la falta de EKU como la causa.
• El documento CA/Browser Forum SC-081v3 también reduce gradualmente la validez máxima de TLS de 200 días (marzo de 2026) a 100 días (marzo de 2027) y finalmente a 47 días (marzo de 2029). Con una validez de 47 días, un certificado se renueva aproximadamente ocho veces al año. Cada renovación de un certificado de doble EKU que no se haya migrado a una infraestructura de clave pública privada representa una posible interrupción silenciosa de la autenticación. El mandato y la reducción de la validez coinciden en el calendario, lo que agrava el riesgo para las organizaciones que retrasan la detección y la migración.
• Ocho categorías de casos de uso se ven afectadas: TLS mutuo (mTLS), autenticación de red RADIUS e IEEE 802.1X, VPN basada en certificados (OpenVPN, Cisco Secure Client, Fortinet), comunicación de servidor a servidor de Microsoft Exchange, Escritorio remoto y puerta de enlace RDP, identidad de dispositivos e IoT, autenticación de API y de servidor a servidor, y cargas de trabajo de CI/CD y DevOps. Las dependencias más peligrosas son las no documentadas: sistemas que dependen de clientAuth porque los certificados públicos históricamente lo incluían por defecto, sin que dicha dependencia se registrara formalmente.
• Las normas NIST FIPS 203, 204 y 205 (finalizadas el 13 de agosto de 2024) exigen la sustitución de los algoritmos RSA y de curva elíptica en todas las jerarquías PKI en el cronograma de desuso de NIST IR 8547. Las jerarquías de CA privadas creadas para cumplir con el mandato de doble EKU también deben incluir la planificación de la migración post-cuántica para los algoritmos de clave de CA privada. Realice un seguimiento de los requisitos de migración de algoritmos de clave de CA privada a través de la Centro de Excelencia PQC.

¿A quién debería importarle el mandato de doble EKU?

La obligatoriedad de la doble EKU no implica un cambio en la plantilla de certificados. Se trata de una modificación de la arquitectura PKI que requiere la coordinación de los equipos de PKI, arquitectos de seguridad, ingenieros de plataforma, equipos de cumplimiento y CISO. Cada equipo es responsable de una parte específica de la transición, y las deficiencias en cualquier área generan fallos de autenticación silenciosos, que constituyen el principal riesgo operativo de esta obligatoriedad.

Rol	POR QUÉ ES IMPORTANTE	Acción
Equipos de PKI y certificados	Controle el diseño de la jerarquía de CA privada y la separación de plantillas de certificados: la política del programa raíz de Chrome v1.8 requiere la separación a nivel de CA, no solo a nivel de certificado hoja, lo que significa que los equipos de PKI deben diseñar y operar una jerarquía privada con CA emisoras dedicadas para la autenticación de clientes (solo EKU clientAuth, no serverAuth) separada de la jerarquía TLS pública (solo serverAuth); las plataformas de CA empresariales estándar requieren una configuración explícita de la plantilla para aplicar la separación de EKU y evitar la emisión de EKU duales; la fecha límite del 15 de marzo de 2027 es improrrogable para los certificados recién emitidos, sin posibilidad de prórroga para las organizaciones que no hayan completado la migración.	Audite el inventario completo de certificados para cualquier certificado de confianza pública que contenga valores EKU tanto de serverAuth como de clientAuth utilizando Administrador de CertSecure; diseñar la jerarquía de CA privadas con CA emisoras dedicadas para la autenticación del cliente, la identidad del usuario, la identidad del dispositivo y la identidad de la carga de trabajo; configurar las plantillas de certificados para imponer la separación de EKU (plantillas públicas solo para serverAuth, plantillas privadas solo para clientAuth) sin que sea posible la emisión de EKU duales; usar CBOM seguro para el descubrimiento completo del patrimonio criptográfico, incluidos todos los certificados emitidos por CA en entornos de nube, locales y multinube; evaluar PKIaaS para la jerarquía de CA privada si la capacidad de operaciones PKI internas es limitada
Arquitectos de seguridad	Gestionar la arquitectura PKI: el mandato requiere no solo una nueva plantilla de certificado, sino también una nueva jerarquía de CA privadas con su propia CA raíz, CA emisoras, protección de claves respaldada por HSM, estrategia de distribución del almacén de confianza, infraestructura CRL/OCSP y selección del protocolo de inscripción; los arquitectos de seguridad también deben diseñar el límite entre los certificados TLS públicos (solo para autenticación de servidor, de confianza para el navegador) y los certificados de cliente privados (solo para autenticación de cliente, de confianza privada) para garantizar que ningún sistema pueda usar un certificado público para la autenticación del cliente o viceversa; la migración post-cuántica de los algoritmos de clave de CA privadas (ECDSA a ML-DSA según NIST FIPS 204, finalizado el 13 de agosto de 2024) también debe planificarse en el momento del diseño de la arquitectura.	Diseñar la arquitectura de jerarquía de CA privada: CA raíz fuera de línea, CA emisoras separadas para cada caso de uso de autenticación de cliente (mTLS, dispositivo, usuario, carga de trabajo, API), protección de clave respaldada por HSM que cumpla con los requisitos FIPS 140-3 Nivel 3, infraestructura CRL y OCSP, y plan de distribución de almacén de confianza; especificar protocolos de inscripción para cada caso de uso (WSTEP para máquinas unidas a Windows AD, ACME para cargas de trabajo nativas de la nube, SCEP para móviles/IoT, EST para inscripción de propósito general); planificar la ruta de migración post-cuántica para algoritmos de clave de CA privada a través de la Centro de Excelencia PQC; definir el límite de la política que impide que cualquier sistema utilice un certificado TLS público para la autenticación de clientes después del 15 de marzo de 2027.
Equipos de plataforma y DevOps	Gestionar la migración a nivel de aplicación: todos los sistemas que actualmente presentan un certificado TLS público para la autenticación de clientes deben reconfigurarse para presentar un certificado de cliente privado. Esto incluye los puntos finales mTLS en arquitecturas de microservicios, servidores RADIUS e infraestructura de autenticación 802.1X, puertas de enlace VPN (OpenVPN, Cisco Secure Client, Fortinet), plataformas IoT y sistemas de gestión de dispositivos, configuraciones de malla de servicios de Kubernetes, puertas de enlace API con autenticación de cliente basada en certificados y canalizaciones de CI/CD que se autentican en registros, repositorios de artefactos y clústeres de Kubernetes. Los equipos de plataforma también deben integrar la inscripción de certificados privados (WSTEP, ACME, SCEP, EST) en los flujos de trabajo de aprovisionamiento de infraestructura para que los nuevos sistemas reciban certificados de cliente privados automáticamente.	Mapea todas las configuraciones de mTLS, implementaciones de RADIUS, puertas de enlace VPN, políticas de malla de servicios de Kubernetes, configuraciones de autenticación de puerta de enlace API y uso de certificados de canalización CI/CD para identificar qué casos de uso presentan certificados públicos para la autenticación del cliente; reconfigura cada sistema para presentar un certificado privado clientAuth-only de la nueva jerarquía PKI privada; integra la inscripción de certificados privados en las canalizaciones de aprovisionamiento de infraestructura (cert-manager para Kubernetes, ACME para nativos de la nube, WSTEP para Windows unidos a AD); agrega monitoreo de la tasa de éxito de autenticación para casos de uso de mTLS, RADIUS y VPN para detectar fallas de eliminación de clientAuth antes de que se conviertan en interrupciones que afecten al cliente.
Equipos de cumplimiento	Debe presentar evidencia de auditoría de que la organización ha completado la migración antes de la fecha límite del 15 de marzo de 2027: las industrias reguladas que implementan mTLS (requisito 4 de PCI DSS 4.0), autenticación de red basada en certificados (HIPAA, DORA) o identidad de dispositivo (CMMC) se enfrentan a riesgos de cumplimiento si los certificados de autenticación de cliente se renuevan sin clientAuth y los fallos de autenticación se atribuyen a una postura de emisión de certificados que no cumple con la normativa; la encuesta DigiCert Trust Pulse (2 de julio de 2025) reveló que el 45 por ciento de las empresas experimentaron tiempo de inactividad relacionado con certificados, y los hallazgos de auditoría relacionados con fallos en la gobernanza de certificados son una consecuencia directa de dependencias duales de EKU no descubiertas.	Incluir el estado de migración de EKU dual en el paquete trimestral de evidencia de cumplimiento: porcentaje de certificados de confianza pública que aún utilizan clientAuth, porcentaje de casos de uso de autenticación de cliente migrados a certificados privados e incidentes de interrupción de autenticación atribuibles a la eliminación de clientAuth; vincular la fecha límite del 15 de junio de 2026 para la CA intermedia y la fecha límite del 15 de marzo de 2027 para el certificado hoja con los hitos de cumplimiento internos; confirmar que la jerarquía PKI privada produce informes de gobernanza de certificados listos para auditoría bajo demanda (CA emisora, EKU, vencimiento, propietario, método de inscripción) sin ensamblaje manual; verificar la cobertura de automatización de inscripción de CA privada para que la validez de 47 días a partir de marzo de 2029 no introduzca obligaciones de renovación manual de certificados.
CISO	El mandato de doble EKU representa un riesgo operativo a nivel de la junta directiva: los fallos de autenticación causados ​​por la eliminación de clientAuth no se anunciarán como errores de certificado, sino como fallos en el protocolo de enlace TLS, mensajes de acceso denegado, pérdida de conectividad VPN, eventos de dispositivos IoT fuera de línea y fallos en la canalización CI/CD sin causa aparente; la encuesta DigiCert Trust Pulse (2 de julio de 2025) reveló que el 37.5 % de las interrupciones relacionadas con certificados se debían a certificados caducados, pero el modo de fallo de doble EKU es más difícil de diagnosticar que la caducidad porque el certificado es válido; el plazo de validez comprimido (47 días para marzo de 2029) implica que los eventos de renovación se producen ocho veces al año, lo que multiplica la exposición a dependencias no descubiertas.	Financie un programa de descubrimiento e inventario de certificados utilizando Administrador de CertSecure como prioridad inmediata, completado antes del 15 de junio de 2026; financiar la creación de la jerarquía PKI privada o la participación en PKIaaS antes de que el plazo intermedio de la CA obligue a tomar medidas de emergencia; exigir que el estado de migración de doble EKU, la cobertura de automatización de inscripción de PKI privada y las métricas de interrupción de autenticación atribuibles a fallas en el propósito del certificado se informen como KPI a nivel de junta; evaluar PKI como servicio Para que la jerarquía de CA privada evite construir y operar infraestructura HSM bajo presión de plazos; exigir que la planificación de la migración posterior a la computación cuántica del algoritmo de clave de CA privada se incluya en la revisión anual del programa PKI.

Lista de verificación para la transición a doble EKU: Problema, impacto en el negocio, acción recomendada y responsable.

Utilice esta lista de verificación antes de la fecha límite del 15 de junio de 2026 para la CA intermedia y la fecha límite del 15 de marzo de 2027 para el certificado hoja, con el fin de identificar las deficiencias en la transición, comprender el impacto comercial de cada deficiencia y asignar la responsabilidad de la remediación.

Problema	Impacto en el negocio	Acción sugerida	Propietario
No hay inventario de certificados que contengan valores EKU tanto de serverAuth como de clientAuth.	Las organizaciones no pueden identificar qué certificados perderán silenciosamente la autenticación de cliente al renovarse; el descubrimiento después de la fecha límite implica una solución bajo presión de interrupción en lugar de una migración planificada; la encuesta DigiCert Trust Pulse (julio de 2025) reveló que el 45 por ciento de las empresas experimentaron tiempo de inactividad relacionado con certificados, y las dependencias duales de EKU no descubiertas son la principal causa de ese tiempo de inactividad para este mandato.	Despliegue Administrador de CertSecure Para el descubrimiento completo de certificados en todas las fuentes de CA, incluidas las CA públicas, AWS Private CA, Azure Key Vault, HashiCorp Vault PKI y AD CS local; filtrar el inventario para certificados que contengan tanto OID 1.3.6.1.5.5.7.3.1 como OID 1.3.6.1.5.5.7.3.2; asignar cada certificado de doble EKU al sistema que lo presenta y al sistema que depende de él para la autenticación del cliente; generar un cronograma de migración clasificado por riesgo basado en las fechas de vencimiento.	Equipo PKI + CISO
No existe jerarquía PKI privada para certificados de autenticación de clientes.	Sin una CA privada, no existe una fuente compatible para certificados que solo admitan autenticación de cliente; las organizaciones se enfrentan a una fecha límite estricta (15 de marzo de 2027) sin posibilidad de prórroga: las CA públicas no pueden emitir certificados de autenticación de cliente después de esa fecha, y no hay período de gracia para las organizaciones que no hayan creado una CA privada.	Diseñar e implementar una jerarquía de CA privada con CA emisoras dedicadas para casos de uso de autenticación de clientes; proteger las claves privadas de CA con HSM FIPS 140-3 Nivel 3; configurar plantillas de certificados con EKU clientAuth solamente y sin serverAuth; alternativamente, contratar a Encryption Consulting. PKIaaS Para una CA privada totalmente gestionada, construida, operada y mantenida conforme a las normativas bajo plazos ajustados.	Equipo de PKI + Arquitecto de seguridad
La CA raíz privada no se distribuye a todos los sistemas de partes que confían en ella.	Los certificados de cliente emitidos por la PKI privada son rechazados por los sistemas que no han instalado la CA raíz privada; se producen fallos de autenticación incluso aunque el certificado esté configurado correctamente con clientAuth, porque el sistema receptor no confía en la cadena de CA emisora.	Distribuya la CA raíz privada a todos los sistemas Windows unidos al dominio mediante Directiva de grupo (almacén de Entidades de certificación raíz de confianza); distribúyala a los sistemas Linux mediante update-ca-certificates a través de Ansible, Chef o Puppet; distribúyala a los sistemas móviles e IoT mediante MDM; pruebe el éxito de la autenticación desde sistemas representativos antes de migrar las cargas de trabajo de producción; documente el plan de distribución de confianza y confirme la cobertura antes de cada fase de migración.	Equipo de plataforma + Equipo de PKI
Casos de uso de autenticación de clientes en la renovación manual de certificados	Con una validez máxima de TLS de 47 días a partir de marzo de 2029, la renovación manual de los certificados de cliente genera ocho eventos de renovación por año por certificado; los procesos manuales con esa frecuencia son operativamente insostenibles e introducen ocho oportunidades de interrupción por certificado por año si se omite o retrasa alguna renovación.	Inscriba todos los certificados de cliente privado en la renovación automática utilizando el protocolo de inscripción adecuado: WSTEP para máquinas Windows unidas a AD (sin intervención manual mediante GPO), ACME para cargas de trabajo nativas de la nube y en contenedores, SCEP para dispositivos móviles e IoT, EST para inscripción de propósito general; integre la inscripción en las canalizaciones de aprovisionamiento de infraestructura para que los nuevos sistemas reciban certificados de cliente privado automáticamente sin intervención manual del equipo de PKI.	Equipo de plataforma + Equipo de PKI
No se realiza un seguimiento de la tasa de éxito de autenticación para mTLS, RADIUS y VPN.	Los fallos de eliminación de ClientAuth se presentan como errores genéricos (fallo en el protocolo de enlace TLS, acceso denegado, fallo en la verificación del par, tiempo de espera de autenticación) que son fáciles de diagnosticar erróneamente como problemas de red, de conjunto de cifrado o de configuración de la aplicación; sin una monitorización específica de la tasa de éxito de la autenticación, la causa raíz solo se identifica después de un tiempo de inactividad prolongado.	Agregue monitoreo de la tasa de éxito de autenticación para todos los puntos finales mTLS, eventos de autenticación RADIUS, intentos de conexión VPN y comprobaciones de dispositivos IoT; configure alertas sobre cambios en la tasa de fallos de autenticación que se correlacionen con eventos de renovación de certificados; incluya validación de EKU en las comprobaciones de estado del certificado para que un certificado renovado que no tenga clientAuth se marque antes de que cause un fallo de autenticación en producción.	Equipo de plataforma + Arquitecto de seguridad
Los algoritmos de clave CA privada no están incluidos en el plan de migración post-cuántica.	Las normas NIST FIPS 203/204/205 (finalizadas el 13 de agosto de 2024) exigen la sustitución de RSA y ECC en todas las jerarquías PKI según el cronograma de descontinuación de NIST IR 8547; una jerarquía de CA privada construida bajo el plazo de doble EKU sin planificación de algoritmos post-cuánticos debe reconstruirse o volver a generar claves antes de la fecha límite de descontinuación, lo que agrava la carga de migración.	Clasifique los algoritmos de clave privada de CA (RSA, ECDSA P-256/P-384) según los hitos de obsolescencia de NIST IR 8547 en el momento del diseño de la arquitectura; planifique la migración a ML-DSA (FIPS 204) para las claves de firma de CA; utilice CBOM seguro para descubrir todos los activos criptográficos en la jerarquía PKI privada; realizar un seguimiento de los requisitos de migración a través de la Centro de Excelencia PQC; evaluar Preparación para PQC Servicios para una evaluación migratoria estructurada.	Arquitecto de seguridad + Equipo de PKI

El mandato: lo que requieren SC-081 y el programa Chrome Root.

Las autoridades de certificación públicas ya no podrán emitir certificados de servidor TLS que incluyan el uso extendido de clave clientAuth. Los certificados de CA intermedios que admiten tanto serverAuth como clientAuth y que se encadenan a una raíz de confianza pública deberán dejar de emitirse.

Cualquier organización que necesite certificados de autenticación de clientes debe obtenerlos de una jerarquía PKI dedicada y diseñada específicamente para ello, que, por definición, no puede ser una jerarquía de CA pública de confianza en los almacenes raíz de los navegadores.

La fecha más crítica para las organizaciones es el 15 de junio de 2026 , certificados CA subordinados/intermedios: cualquier nuevo intermedio divulgado a CCADB en o después de esa fecha debe afirmar únicamente serverAuth, y no se pueden agregar nuevos intermedios duales de EKU a las jerarquías de confianza de Chrome.

A partir del 15 de marzo de 2027 , cada certificado hoja emitido recientemente que se encadene a una raíz de confianza de Chrome también deberá ser serverAuth-only; a partir de ese momento, Chrome rechazará los certificados hoja TLS públicos que aún contengan la EKU clientAuth, y los protocolos de enlace afectados fallarán. Los certificados emitidos antes de la fecha límite aplicable seguirán siendo válidos hasta su vencimiento, pero al renovarlos se volverán a emitir sin clientAuth.

Para calificar como jerarquía PKI de autenticación de servidor TLS dedicada según esta política:

1. Todos los correspondientes no vencido y no revocado Los certificados CA subordinados que operan bajo una raíz existente incluida en el Chrome Root Store DEBEN:
   • si se divulga a la CCADB antes del 15 de junio de 2026: incluir el uso de clave extendido extensión y (a) solo afirmar un propósito de extendedKeyUsage de id-kp-serverAuth o (b) solo afirmar los propósitos de extendedKeyUsage de id-kp-serverAuth y id-kp-clientAuth.
   • si se divulga a la CCADB el o después del 15 de junio de 2026: incluir la extensión extendedKeyUsage y afirmar únicamente un propósito extendedKeyUsage de id-kp-serverAuth.
   • NO contener una clave pública que corresponda a ningún otro certificado no caducado o no revocado que afirme valores de extendedKeyUsage diferentes.
2. Todos los certificados de suscriptor correspondientes emitidos a partir del 15 de marzo de 2027, DEBE incluir la extensión extendedKeyUsage y solo afirmar un propósito extendedKeyUsage de id-kp-serverAuth.

A partir del 15 de marzo de 2027 , cada nuevo certificado TLS de confianza pública deberá tener un único propósito: la autenticación del servidor. Deberá contener únicamente el EKU serverAuth, eliminando por completo el OID clientAuth. El certificado de CA pública deberá tener el siguiente aspecto:

La siguiente tabla especifica los campos obligatorios y permitidos para los certificados de servidor TLS de suscriptor (hoja) emitidos por CA de confianza pública según el mandato del Foro CA/Navegador, 7.1.2.7 Perfil de certificado de suscriptor (servidor):

Campo / Extensión	Presencia	Valores y requisitos permitidos
versión	DEBE	v3 (valor entero 2)
número de serie	DEBE	Entero positivo, con al menos 64 bits de salida de un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG).
sujetoAltName	DEBE	Esta extensión DEBE contener al menos una entrada. Cada entrada DEBE ser una dNSName or Dirección IP como se describe en Sección 7.1.4.2.
restricciones básicas	DEBE	Para un certificado de suscriptor (hoja), el cUn campo DEBE estar configurado en FALSO. Restricción de longitud de ruta NO DEBE estar presente.
uso de clave	DEBE	Es un atributo crítico. Los valores aceptables de uso de clave varían según si el certificado subjectPublicKeyInfo identifica una clave pública RSA o una ECC clave pública. Las CA DEBEN asegurarse de que el uso de la clave sea apropiado para la clave pública del certificado. Los usos de clave permitidos son: Firma digital + cifrado de clave para RSA, y firma digital únicamente para ECDSA.
uso de clave extendido	DEBE	El siguiente valor DEBE estar presente: • id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) El siguiente valor NO DEBE estar presente: • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2) – Prohibido para certificados de hojas recién emitidos a partir del 15 de marzo de 2027 en Política del programa raíz de Chrome v1.8, Sección 1.3.2
Políticas de certificación	DEBE	Si está presente, la extensión Políticas de certificados DEBE contener al menos una Información sobre políticas.
AutoridadInformaciónAcceso	DEBE	No es un campo crítico. • Identificador de clave- DEBE estar presente. DEBE ser idéntico al campo subjectKeyIdentifier de la CA emisora. • AutoridadEmisor de certificados- NO DEBE estar presente • Número de serie del certificado de autoridad NO DEBE estar presente
identificador de clave de sujeto	DEBE	La CA DEBE generar un identificador de clave de sujeto que es único dentro del alcance de todos los certificados que ha emitido para cada clave pública única
Puntos de distribución cRL	DEBE	Esta extensión DEBE estar presente y NO DEBE estar marcada como crítica. La extensión Puntos de distribución de CRL DEBE estar presente en: • Certificados CA subordinados; y • Certificados de suscriptor que 1) no califican como “Certificados de suscriptor de corta duración” y 2) no incluyen una extensión de acceso a información de autoridad con un método de acceso id-ad-ocsp.

Nota sobre extendedKeyUsage: La sección 7.1.2.7.10 de los Requisitos básicos de TLS del Foro CA/Navegador aún indica que id-kp-clientAuth puede estar permitido, pero no es obligatorio a nivel de los BR (Requisitos básicos de TLS). La prohibición estricta proviene de la sección 1.3.2 de la Política del Programa Raíz de Chrome , que exige que todos los certificados de suscriptor emitidos a partir del 15 de marzo de 2027 incluyan únicamente id-kp-serverAuth. Las CA deben cumplir con esta política para permanecer en el Almacén Raíz de Chrome, lo que hace que la restricción sea prácticamente universal.

La propuesta electoral SC-081 también introduce una reducción gradual del período máximo de validez de los certificados TLS de confianza pública. La validez se reduce a 200 días a partir de marzo de 2026, a 100 días a partir de marzo de 2027 y a 47 días a partir de marzo de 2029. La menor duración de los certificados hace que la inscripción automatizada mediante ACME, WSTEP, SCEP y EST sea un requisito indispensable, en lugar de una simple conveniencia. Cualquier organización que dependa de la renovación manual de certificados se enfrentará a una carga operativa insostenible a medida que se reduzcan los períodos de validez. Esto refuerza la necesidad de una infraestructura de clave pública (PKI) privada gestionada con una gestión del ciclo de vida totalmente automatizada desde el primer día.

Cronología pública de CA

La fecha más crítica para las organizaciones es el 15 de junio de 2026 , cuando Chrome rechazará activamente los certificados TLS públicos que contengan la EKU clientAuth. Cualquier nueva CA subordinada (CA intermedia) que se divulgue a la Base de Datos de CA Comunes (CCADB) a partir de esta fecha deberá contener únicamente id-kp-serverAuth . No se podrán agregar nuevas CA intermedias con EKU mixtas a las jerarquías de confianza de Chrome a partir de esta fecha. Cualquier sistema que presente un certificado de este tipo en un protocolo de enlace TLS validado por Chrome fallará. Los certificados existentes emitidos antes de esta fecha seguirán siendo válidos hasta su vencimiento, pero una vez renovados, se emitirán sin clientAuth.

Las autoridades de certificación no esperaron a la fecha límite estricta de marzo de 2027. La mayoría de las principales autoridades de certificación comenzaron a eliminar clientAuth mucho antes, impulsadas por la fecha límite intermedia de junio de 2026 establecida por Chrome para las autoridades de certificación, y a continuación se muestra el cronograma completo a junio de 2026:

Fecha	CA / Programa	Milestone	Estado
Septiembre 15, 2025	SSL.com	Deja de emitir clientAuth por defecto	PASADO
1 de octubre de 2025	DigiCert	Deja de emitir clientAuth por defecto	PASADO
14 de octubre de 2025	sectigo	Deja de emitir clientAuth por defecto	PASADO
11 de febrero de 2026	Vamos a cifrar	El perfil ACME predeterminado elimina clientAuth.	PASADO
15 de junio de 2026	Google Chrome	Rechaza los certificados TLS públicos con clientAuth EKU	CRÍTICA
8 de julio de 2026	Vamos a cifrar	El perfil de tlsclient ha sido descontinuado permanentemente.	PRÓXIMOS
10 de febrero de 2027	sectigo	Plazo límite improrrogable, sin excepciones.	PRÓXIMOS
1 de marzo de 2027	DigiCert	Eliminación total, sin excepciones.	PRÓXIMOS
15 de marzo de 2027	Programa raíz de Chrome	Fecha límite final del sector	FECHA LIMITE

¿Por qué se está eliminando la EKU de autenticación de cliente?

Resulta tentador considerar este mandato simplemente como una carga de cumplimiento. En realidad, subsana una brecha de seguridad real y poco reconocida. Comprender la siguiente justificación de seguridad ayuda a las organizaciones a entender por qué se está implementando este cambio:

• La infraestructura de clave pública (PKI) web pública se creó para autenticar servidores ante los navegadores: Los procesos de validación de dominio (DV) y validación de organización (OV) que utilizan las autoridades de certificación públicas están diseñados para verificar la propiedad del dominio y la identidad de la organización con el fin de autenticar el servidor. No están diseñados para establecer que un sistema determinado esté autorizado a actuar como cliente en un contexto de autenticación específico. Incluir la extensión de conocimiento clientAuth en un certificado emitido públicamente implica un estándar de validación que nunca se llevó a cabo.
• La vulneración de la clave privada ha tenido consecuencias graves: Cuando un certificado de servidor TLS incluye tanto la autenticación del servidor (serverAuth) como la del cliente (clientAuth), una clave privada comprometida causa un daño doble. Un atacante que extrae la clave privada de un servidor no solo puede suplantar la identidad de ese servidor ante los clientes, sino también presentar ese certificado como una credencial de cliente válida a cualquier sistema que confíe en la CA emisora ​​y verifique la EKU de clientAuth. Una sola vulneración se convierte en capacidad de movimiento lateral. Eliminar clientAuth de los certificados de servidor elimina por completo este segundo vector de ataque.
• La separación permite una gestión adecuada del ciclo de vida: Los certificados de servidor y los de cliente tienen requisitos de ciclo de vida fundamentalmente diferentes. Los certificados de servidor están vinculados a nombres de dominio, se renuevan en infraestructura pública y los gestionan los equipos de operaciones web. Los certificados de cliente están vinculados a identidades de sistema y requieren capacidades de revocación que se aplican a nivel de aplicación. Combinarlos en un solo certificado dificulta su correcta gestión. La separación restablece la propiedad y la responsabilidad claras.

Impacto de la eliminación de la EKU de autenticación de cliente

La eliminación de la EKU clientAuth afecta a las organizaciones que actualmente utilizan un certificado de servidor TLS de confianza pública para la autenticación de clientes.

Las organizaciones que utilizan certificados públicos exclusivamente para la autenticación estándar de servidores HTTPS generalmente no se ven afectadas. Sus sitios web, portales y aplicaciones de cara al público pueden seguir utilizando certificados que contengan únicamente la EKU serverAuth.

El problema surge cuando el mismo certificado público se utiliza para autenticar a un usuario, dispositivo, servidor, aplicación o carga de trabajo en otro sistema. Si dicho certificado se renueva o se vuelve a emitir sin la EKU clientAuth, es posible que el sistema receptor ya no lo acepte como una credencial de cliente válida.

Es importante destacar que el certificado aún puede ser válido, no estar caducado y ser de confianza. El fallo se produce porque el certificado ya no está autorizado para la autenticación del cliente.

Para ayudarle a identificar qué podría fallar y por qué, la siguiente tabla destaca las posibles áreas de impacto en toda su organización.

Caso de uso	Impacto potencial
TLS mutuo (mTLS)	Durante una conexión mTLS, el sistema receptor puede verificar que el certificado del cliente incluya la EKU clientAuth. Si falta esta EKU, el certificado podría ser rechazado y el protocolo de enlace TLS fallaría. Esto puede afectar a microservicios, pasarelas API, mallas de servicios, integraciones entre empresas y autenticación personalizada entre aplicaciones. El error podría manifestarse como un fallo genérico en el protocolo de enlace TLS o en la validación del certificado, en lugar de un problema de caducidad.
RADIUS, IEEE 802.1X y EAP-TLS	En la autenticación de red basada en certificados, los usuarios o dispositivos presentan un certificado de cliente para demostrar su identidad. Si el servidor de autenticación requiere la EKU clientAuth y el certificado renovado no la incluye, la solicitud de autenticación fallará. Como consecuencia, los dispositivos afectados podrían no poder conectarse a redes Wi-Fi corporativas, redes cableadas o servicios VPN.
OpenVPN, Cisco Secure Client y Fortinet VPN	Muchas implementaciones de VPN basadas en certificados requieren que el certificado del usuario o dispositivo que se conecta contenga la EKU clientAuth. Si se renueva un certificado público utilizado previamente para la autenticación VPN sin dicha EKU, la puerta de enlace VPN podría rechazarlo. En ese caso, los usuarios podrían no poder establecer una conexión de acceso remoto segura.
Microsoft Exchange y comunicación de servidor a servidor	Las configuraciones de comunicación entre el conector SMTP, EWS y socios utilizan certificados para la autenticación mutua o entre servidores. Si se espera que el certificado del servidor de conexión admita la autenticación del cliente, eliminar la EKU clientAuth puede interrumpir la autenticación o el flujo de correo. El impacto real depende de la versión de Exchange, la configuración del conector y los requisitos de validación del certificado.
Entornos de escritorio remoto y puerta de enlace RDP	La puerta de enlace de escritorio remoto suele utilizar un certificado de servidor para autenticarse ante los clientes conectados. Sin embargo, los entornos que también utilizan autenticación de cliente basada en certificados, autenticación con tarjeta inteligente o controles de autenticación mutua personalizados pueden depender de certificados de cliente dedicados. Reutilizar un certificado de servidor público para este fin puede provocar fallos de autenticación tras su renovación.
IoT e identidad de dispositivos	Los dispositivos IoT, industriales y embebidos pueden usar certificados para autenticarse en servicios en la nube, plataformas de gestión o pasarelas de dispositivos. Si se renueva un certificado de dispositivo sin la EKU clientAuth requerida, la plataforma puede rechazar la identidad del dispositivo. Esto puede impedir el registro del dispositivo, el envío de telemetría, la gestión remota, las actualizaciones de software o la ejecución de comandos.
Autenticación API y de servidor a servidor	Las aplicaciones y los servidores suelen actuar como clientes TLS al llamar a API internas o externas. Si presentan un certificado TLS público como identidad de cliente, la API receptora podría rechazarlo una vez eliminada la autenticación del cliente (clientAuth). Esto puede interrumpir las integraciones, aunque el mismo certificado siga funcionando con normalidad para las conexiones HTTPS entrantes.
Cargas de trabajo de CI/CD y DevOps	Los servidores de compilación, los agentes de despliegue, los contenedores y las plataformas de automatización pueden usar certificados para autenticarse en registros, clústeres de Kubernetes, repositorios de artefactos o API internas. Cuando un certificado renovado deja de ser compatible con la autenticación de clientes, las canalizaciones automatizadas pueden fallar sin una causa evidente relacionada con el certificado.

¿Por qué estos fallos pueden ser difíciles de diagnosticar?

La eliminación de clientAuth no necesariamente produce un mensaje claro que indique que falta la EKU. Dependiendo de la aplicación, el sistema operativo o la biblioteca TLS, el fallo puede notificarse de la siguiente manera:

• Fallo en el protocolo de enlace TLS
• No se permite la finalidad del certificado.
• Certificado no compatible
• Certificado defectuoso
• acceso denegado
• Se rechazó la identidad del cliente.
• Fallo en la verificación de pares
• Tiempo de espera de autenticación agotado

Esto hace que sea fácil diagnosticar erróneamente el problema como un problema de cadena de confianza, caducidad, red, conjunto de cifrado o configuración de la aplicación.

El riesgo más significativo no se limita a los certificados que ya se sabe que admiten TLS mutuo . Incluye sistemas no documentados que han estado utilizando la EKU clientAuth porque, históricamente, los certificados TLS públicos la incluían por defecto.

Las organizaciones deben identificar estas dependencias antes de renovar o reemitir los certificados afectados. Esperar hasta la renovación puede convertir un reemplazo rutinario de certificados en una interrupción inesperada que afecte la conectividad de las aplicaciones, el acceso a la red, el acceso remoto o la autenticación de dispositivos.

La solución: Transición a una CA privada

Las autoridades de certificación de confianza pública están siendo restringidas para emitir certificados TLS para la autenticación de clientes (es decir, certificados que incluyen la EKU clientAuth). Como resultado, las organizaciones ya no pueden confiar en los certificados TLS públicos para casos de uso de autenticación de clientes internos, como TLS mutuo, autenticación de dispositivos, identidad de carga de trabajo, autenticación de API y comunicación de servidor a servidor.

Una infraestructura de clave pública (PKI) privada resuelve este problema, ya que opera fuera del ecosistema de PKI públicas de confianza para navegadores. Su autoridad de certificación raíz solo es de confianza para los usuarios, dispositivos, aplicaciones y sistemas seleccionados por la organización. Por lo tanto, la organización puede emitir certificados de cliente dedicados que incluyan la extensión de uso de certificados (EKU) clientAuth sin afectar ni depender de la confianza pública de los navegadores.

La infraestructura de clave pública privada (PKI) también permite una separación adecuada entre los dos propósitos de los certificados:

• Certificados de servidor públicos o privados que contengan únicamente el EKU serverAuth
• Certificados de cliente privado dedicados que contienen solo el EKU clientAuth (OID 1.3.6.1.5.5.7.3.2), sin ningún OID serverAuth presente, como se muestra en la captura de pantalla a continuación:

Esta separación garantiza que un certificado de servidor se utilice únicamente para autenticar un servidor, mientras que un certificado de cliente se utilice únicamente para autenticar un usuario, dispositivo, aplicación o estación de trabajo. Reduce el impacto de una posible filtración de claves privadas y proporciona un control más claro sobre la emisión, la propiedad, la renovación y la revocación de certificados.

Con una infraestructura de clave pública (PKI) privada, las organizaciones también pueden definir políticas de certificados para satisfacer sus requisitos de seguridad específicos, incluyendo procedimientos de validación de identidad, periodos de validez de los certificados, convenciones de nomenclatura, algoritmos aprobados, requisitos de protección de claves y métodos de inscripción. Los certificados se pueden emitir y renovar automáticamente mediante protocolos como ACME, SCEP, EST, CMP, WSTEP o la inscripción automática de Microsoft.

Este cambio permite a las organizaciones diseñar flujos de trabajo de autenticación adaptados a sus necesidades específicas, sin las limitaciones de las autoridades de certificación públicas. La siguiente sección describe cómo debería ser la jerarquía de la infraestructura de clave pública (PKI).

Cómo debe cambiar la jerarquía de PKI

Eliminar la EKU clientAuth de los certificados TLS de confianza pública no es simplemente un cambio en la plantilla del certificado. Requiere que las organizaciones separen la autenticación del servidor público de la autenticación del cliente interno a nivel de la arquitectura PKI.

Según el nuevo modelo, los certificados de confianza pública solo deben usarse para autenticar servidores ante clientes externos, como navegadores que se conectan a sitios web y aplicaciones de acceso público. Estos certificados contienen únicamente la EKU serverAuth y continúan su cadena hasta una CA raíz de confianza pública.

La autenticación de clientes debe trasladarse a una jerarquía PKI privada independiente. Esta jerarquía privada emite certificados específicos para usuarios, dispositivos, aplicaciones, cargas de trabajo y servidores que necesitan autenticarse como clientes.

Por lo tanto, la arquitectura objetivo debe incluir:

• Una jerarquía PKI TLS pública para certificados de servidor orientados a Internet que contiene únicamente serverAuth
• Una CA raíz privada sin conexión a un dominio, protegida con un módulo de seguridad de hardware compatible con FIPS 140-3 Nivel 3.
• Una o más autoridades de certificación emisoras privadas dedicadas a la autenticación de clientes. Protección mediante HSM para las claves privadas de las autoridades de certificación emisoras.
• Los perfiles de certificado de cliente están limitados al EKU clientAuth únicamente (no hay OID serverAuth presente), con el uso de clave configurado como digitalSignature, por lo que el certificado no se puede utilizar para la autenticación del servidor bajo ninguna circunstancia.

  

• Perfiles de certificado separados para dispositivos, usuarios, cargas de trabajo, API y otras identidades.
• Servicios CRL u OCSP para la revocación de certificados, con puntos finales CDP configurados como públicos o privados según el caso de uso y los requisitos de accesibilidad de la organización.
• Inscripción, renovación y revocación automatizadas de certificados.
• Distribución de la CA raíz privada a los sistemas que deben confiar en los certificados del cliente.

Según esta arquitectura, un servidor que desempeña ambas funciones puede necesitar dos certificados separados:

1. Un certificado de servidor que contiene serverAuth para aceptar conexiones TLS entrantes.
2. Un certificado de cliente que contiene clientAuth para autenticarse al conectarse a otro sistema.

Esta separación garantiza que cada certificado y clave privada tenga un propósito claramente definido. Además, permite a las organizaciones aplicar diferentes políticas de validación de identidad, ciclo de vida, revocación y protección de claves a las identidades de servidor y cliente.

El diseño, la implementación y el funcionamiento continuo de esta jerarquía privada requieren conocimientos especializados en PKI, infraestructura HSM segura, automatización del ciclo de vida de los certificados, servicios de revocación, monitorización, recuperación ante desastres y gestión continua de políticas. La siguiente sección de este blog explica en detalle cómo PKIaaS de Encryption Consulting ofrece una CA privada totalmente gestionada, creada, operada y mantenida conforme a la normativa en su nombre.

PKIaaS de Encryption Consulting

La creación y el funcionamiento de una jerarquía PKI privada no son técnicamente complejos en concepto, pero sí lo son en su ejecución, ya que incluyen la adquisición de HSM, ceremonias de CA raíz fuera de línea, accesibilidad a CDP/AIA, automatización del ciclo de vida de los certificados, documentación de políticas y operaciones de inscripción.

El servicio PKIaaS (Infraestructura de Clave Pública como Servicio ) de Encryption Consulting cumple con plazos ajustados y ofrece una infraestructura de clave pública privada completa como servicio gestionado . Encryption Consulting la desarrolla, la gestiona y garantiza su cumplimiento normativo, mientras que usted conserva la propiedad total.

Sin dependencia de un proveedor: Sus claves privadas, jerarquía de CA y certificados le pertenecen por completo. Si decide migrar la infraestructura de clave pública (PKI) a su entorno local, Encryption Consulting realizará una ceremonia formal y documentada de transferencia de claves. El material de clave privada de la CA se transferirá de forma segura a su HSM mediante procedimientos de exportación autenticados y con doble control.

Sus certificados actuales seguirán siendo válidos, sin necesidad de reemisión. Todo el proceso de transferencia estará completamente documentado y será auditable, lo que garantiza la continuidad operativa y la titularidad total.

Usted es el propietario de la infraestructura de clave pública (PKI). Nosotros la creamos, administramos y operamos en su nombre. Así es como funciona nuestra colaboración.

Fase 1: Descubrimiento e inventario de certificados

Antes de diseñar la nueva infraestructura de clave pública (PKI), Encryption Consulting desarrolla una visión completa del entorno de certificados actual del cliente. Esto es fundamental, ya que muchos sistemas dependen de clientAuth sin que dicha dependencia se haya detectado formalmente.

Admitimos varios métodos de detección de certificados , incluidos el escaneo de red, el escaneo sin agente y la detección basada en la integración.

El descubrimiento basado en la integración proporciona una visión autorizada y en tiempo real de los datos de los certificados al conectarse directamente con las Autoridades de Certificación y plataformas en la nube como AWS, Microsoft Azure y Google Cloud. También puede examinar las configuraciones de las aplicaciones, incluidos los ajustes de mTLS, e integrarse con clústeres de Kubernetes, plataformas de gestión de secretos como HashiCorp Vault y CyberArk Conjur, y canalizaciones de CI/CD, como GitHub Actions, Jenkins y GitLab.

Entre las capacidades de detección adicionales se incluyen la monitorización pasiva mediante proxies, cortafuegos y puntos de acceso a la red; el escaneo de directorios a través de LDAP y Active Directory; y la detección mediante herramientas de gestión de configuración como Ansible, Chef y Puppet.

El resultado es un inventario completo de certificados que incluye los sujetos, los nombres alternativos del sujeto (SAN), las unidades de extensión de certificados (EKU), los emisores y las fechas de vencimiento. Cada certificado que contiene la autenticación de cliente (clientAuth) se asocia tanto al sistema que lo presenta como al sistema que lo utiliza para la autenticación.

Los resultados se organizan en un cronograma de migración clasificado por riesgo. El cliente obtiene una visión clara de qué sistemas pueden fallar, cuándo están en riesgo y el impacto potencial en el negocio si se renueva un certificado sin la autenticación del cliente.

Fase 2: Diseño de la arquitectura PKI

No se construye nada hasta que la arquitectura se revisa y se aprueba. Cada CA, cada plantilla de certificado y cada punto final de revocación se especifican por escrito antes de generar cualquier clave.

La arquitectura suele incluir una CA raíz sin conexión a un dominio y CA emisoras independientes para la autenticación de clientes, TLS interno y la autenticación de identidad del dispositivo. Esta separación garantiza que los certificados de cliente contengan únicamente la autenticación del cliente (clientAuth).

Se definen perfiles de certificado para cada caso de uso, incluyendo algoritmos, periodos de validez, formatos de sujeto y SAN, uso de clave, EKU, OID de política y puntos finales de revocación. Las ubicaciones de CRL y OCSP se configuran como públicas o privadas según dónde se vayan a utilizar los certificados.

Esto crea una jerarquía clara y orientada a un propósito, sin certificados EKU duales y sin ambigüedad sobre lo que cada certificado está autorizado a hacer.

Fase 3: Ceremonia de CA raíz y desarrollo de la infraestructura.

La clave privada de la CA raíz se genera y protege mediante un módulo de seguridad de hardware (HSM) compatible con FIPS 140-3 Nivel 3. La CA raíz permanece alojada de forma segura en el centro de datos y se mantiene sin conexión entre las operaciones autorizadas de firma de certificados. Para la recuperación ante desastres, se conserva una copia de seguridad cifrada y con control de acceso del material de clave en un entorno HSM geográficamente separado.

Posteriormente, Encryption Consulting desarrolla la infraestructura PKI de soporte, que incluye autoridades de certificación emisoras reforzadas, respondedores OCSP, servicios de publicación de CRL y capacidades de gestión de certificados.

Fase 4: Distribución en tiendas de confianza

Los certificados emitidos por una infraestructura de clave pública privada (PKI) solo son confiables cuando la autoridad de certificación raíz privada está instalada en todos los sistemas que los validan. Esta fase distribuye el nuevo certificado de la autoridad de certificación raíz privada a todos los sistemas de partes confiables dentro del alcance.

Los sistemas Windows unidos a un dominio reciben la CA raíz mediante directivas de grupo, que se agrega al almacén de autoridades de certificación raíz de confianza. Los sistemas Linux se actualizan mediante update-ca-certificates, implementado a través de Ansible, Chef o Puppet, según la cadena de herramientas de administración de configuración existente.

Tras la distribución, se prueban los sistemas representativos utilizando los certificados de cliente recién emitidos. Esta fase finaliza únicamente cuando el cliente confirma que las cadenas de certificados son de confianza y que la autenticación se realiza correctamente.

Fase 5: Implementación de la puerta de enlace PKIaaS

Esta fase implementa la puerta de enlace PKIaaS, un conjunto de componentes de registro y administración instalados en la infraestructura del cliente. La puerta de enlace conecta los sistemas internos del cliente con la jerarquía de CA alojada por Encryption Consulting. Todas las solicitudes de certificados pasan a través de ella. Las claves privadas de la CA permanecen en los HSM de Encryption Consulting en todo momento, ya que la puerta de enlace solo gestiona el tráfico del protocolo de registro, sin realizar nunca operaciones de firma.

La puerta de enlace expone un punto final del Protocolo de Inscripción de Confianza WS (WSTEP), lo que permite la inscripción de certificados totalmente automatizada para máquinas Windows sin necesidad de interacción por parte del usuario o del administrador. El servicio de Directiva de Inscripción de Certificados (CEP) está configurado para determinar qué plantillas de certificado son aptas para él en función de su identidad en Active Directory y su pertenencia a directivas de grupo.

El servicio web de inscripción de certificados valida la solicitud según la política de inscripción, la enruta a través de la puerta de enlace PKIaaS a la CA emisora ​​y devuelve el certificado firmado directamente al equipo, que lo instala automáticamente en el almacén de certificados correspondiente. Desde la configuración de la GPO en adelante, todo el ciclo de vida (descubrimiento de políticas, solicitud, firma, instalación y renovación) no requiere intervención manual.

Un panel de control basado en la web donde los usuarios autorizados pueden solicitar certificados, enviar solicitudes de firma de certificado (CSR), buscar en el inventario de certificados, renovar certificados, revocar certificados comprometidos o no utilizados y revisar el estado de los certificados.

El panel de control incluye un sistema de control de acceso basado en roles. Los administradores de certificados pueden solicitar o revocar certificados, los auditores pueden revisar informes y registros de actividad, y los administradores pueden gestionar los perfiles aprobados y las políticas de inscripción.

Cada inscripción, renovación, revocación, aprobación, cambio de configuración e inicio de sesión administrativo queda registrado en un registro de actividad auditable.

Fase 6: Migración de certificados: Sistema por sistema

Una vez que los servicios de confianza e inscripción estén operativos, Encryption Consulting comenzará a reemplazar los certificados públicos de doble EKU con certificados privados de cliente dedicados.

La migración comienza con los entornos de desarrollo y preproducción. A continuación, se migran los servicios internos y las API, seguidos de la infraestructura de red, incluyendo VPN, RADIUS y 802.1X. Los sistemas críticos para el negocio, como Exchange, las aplicaciones principales y los sistemas internos de la organización, se migran solo después de que se confirmen las pruebas y los procedimientos de reversión.

Cada solicitud de certificado se envía mediante el método de inscripción correspondiente, como WSTEP, ACME, SCEP, EST o el panel de administración. El nuevo certificado se emite únicamente con la EKU clientAuth. La aplicación se configura para presentar el nuevo certificado y una prueba de autenticación de extremo a extremo confirma que la conexión se realiza correctamente.

Tras una validación satisfactoria, el antiguo certificado dual EKU se elimina o revoca según corresponda, y el nuevo certificado se inscribe en el proceso de renovación automática.

Fase 7: Operaciones en curso y cumplimiento normativo

En esta fase, PKIaaS proporciona un valor continuo más allá de la configuración inicial.

La plataforma CLM de Encryption Consulting gestiona de forma continua la emisión, renovación y revocación de certificados, la publicación de CRL, la disponibilidad de OCSP, la monitorización de HSM, el mantenimiento de la infraestructura, la validación de copias de seguridad y las operaciones de PKIaaS Gateway.

Los servicios de inscripción, como WSTEP, ACME, SCEP y EST, se mantienen de forma continua para que los certificados puedan emitirse y renovarse sin intervención manual.

Encryption Consulting también supervisa los requisitos de seguridad de las organizaciones pertinentes, las novedades del CA/Browser Forum, los estándares criptográficos, los cambios en los algoritmos y las actualizaciones de las políticas de certificados, como la compatibilidad con la criptografía postcuántica . Cuando un cambio afecta al entorno del cliente, la configuración de la infraestructura de clave pública (PKI) y los perfiles de certificados se actualizan antes de la fecha límite correspondiente.

Conclusión

La eliminación de la EKU clientAuth de los certificados TLS de confianza pública supone un cambio fundamental en la forma en que las organizaciones deben gestionar la autenticación basada en certificados. Los certificados públicos seguirán protegiendo sitios web y servicios externos, pero la autenticación de clientes para usuarios, dispositivos, aplicaciones y cargas de trabajo deberá migrar a una infraestructura de clave pública (PKI) privada diseñada específicamente para este fin. Las organizaciones que no identifiquen las dependencias ocultas de doble EKU corren el riesgo de sufrir interrupciones inesperadas al renovar los certificados sin clientAuth; fallos que no se manifestarán como errores de certificado, sino como tiempos de espera de autenticación, fallos en el protocolo de enlace TLS y mensajes de acceso denegado sin causa aparente.

El servicio PKIaaS de Encryption Consulting ofrece una solución integral para esta transición. Evaluamos el entorno existente, identificamos los sistemas afectados, diseñamos e implementamos la infraestructura de clave pública (PKI) privada, protegemos las claves de CA dentro de los módulos de seguridad de hardware (HSM), desplegamos servicios de registro, migramos certificados y gestionamos el entorno de forma continua. El registro automatizado mediante WSTEP, ACME, SCEP y EST garantiza que los certificados se emitan, renueven y revoquen sin generar una carga operativa adicional.

Para comenzar con una evaluación gratuita de preparación de PKI, contáctenos en [email protected] o visite encryptionconsulting.com/pkiaas.

Preguntas frecuentes

¿Cuál es la principal conclusión del mandato del Foro CA/Browser: El fin de los certificados Dual-EKU?

La propuesta SC-081v3 del Foro CA/Navegador (abril de 2025) y la Política del Programa Raíz de Chrome v1.8 eliminan clientAuth de los certificados TLS de confianza pública según un calendario estricto. A partir del 15 de junio de 2026, ninguna nueva CA intermedia en una jerarquía de confianza de Chrome podrá tener valores EKU duales. A partir del 15 de marzo de 2027, cada nuevo certificado TLS de confianza pública emitido deberá contener únicamente serverAuth. Las organizaciones que utilicen certificados públicos para mTLS, RADIUS, VPN, identidad de dispositivos IoT o autenticación de servidor a servidor deberán migrar esos casos de uso a una jerarquía PKI privada dedicada antes de estas fechas límite o se enfrentarán a fallos de autenticación silenciosos cuando se renueven los certificados afectados.

¿Por qué es importante el mandato de doble EKU para los equipos de PKI empresariales?

Los equipos de PKI empresariales se enfrentan a dos presiones convergentes derivadas de la misma votación. La encuesta DigiCert Trust Pulse (2 de julio de 2025) reveló que el 45 % de las organizaciones experimentaron interrupciones del servicio relacionadas con certificados el año anterior; el mandato de doble EKU introduce precisamente el modo de fallo silencioso que produce dichas interrupciones: un certificado renovado sin autenticación de cliente sigue funcionando para HTTPS, pero falla en todos los casos de uso de autenticación de cliente con errores genéricos. Simultáneamente, SC-081v3 reduce la validez máxima de TLS a 47 días para marzo de 2029, lo que significa que los eventos de renovación que exponen las dependencias de doble EKU ocurren hasta ocho veces al año en lugar de una sola vez.

¿Qué riesgos aumentan si la transición a la doble EKU se gestiona de forma manual o reactiva?

Aumentan cuatro categorías de riesgo: interrupciones silenciosas de autenticación (mensajes de error genéricos que son fáciles de diagnosticar erróneamente); dependencias no descubiertas (sistemas que dependen de clientAuth sin documentación formal); tiempo de remediación comprimido (con una validez de 47 días, el período entre la renovación y el fallo es de seis semanas en lugar de doce meses); y brechas de migración post-cuántica (los algoritmos de clave CA privada también deben migrar a ML-DSA según NIST FIPS 204, finalizado el 13 de agosto de 2024; es más difícil incluir una PKI privada no planificada en la hoja de ruta de migración).

¿Qué equipos deberían liderar la transición a la doble EKU?

Los equipos de PKI y certificados son responsables del diseño de la jerarquía de CA privadas y la separación de plantillas de certificados. Los arquitectos de seguridad son responsables del modelo de gobernanza: distribución de confianza de CA raíz privada, selección del protocolo de inscripción y planificación de la migración post-cuántica para algoritmos de claves de CA privadas. Los equipos de plataforma y DevOps son responsables de la migración a nivel de aplicación: reconfiguración de mTLS, RADIUS, VPN, IoT y sistemas CI/CD. Los equipos de cumplimiento son responsables de la evidencia de auditoría que confirma que la migración se completó antes de la fecha límite del 15 de marzo de 2027.

¿Cómo se relaciona el mandato de doble EKU con la gestión del ciclo de vida de los certificados?

El mandato es un evento del ciclo de vida del certificado: cada certificado TLS público que actualmente contiene clientAuth perderá esa EKU en su próxima renovación. El descubrimiento y el inventario de certificados son requisitos previos para una gestión segura del ciclo de vida: las organizaciones que desconocen qué certificados contienen clientAuth no pueden gestionar de forma segura el ciclo de vida de renovación sin riesgo de provocar interrupciones en la autenticación. CertSecure Manager proporciona la capa CLM: descubrimiento automatizado de dependencias de clientAuth, aplicación de políticas en la emisión (perfiles separados por EKU), renovación automatizada mediante WSTEP/ACME/SCEP/EST, gestión de revocaciones e informes listos para auditoría.

¿Cómo deberían las organizaciones medir el éxito en la transición al sistema dual EKU?

Métricas clave: cero certificados de confianza pública que contengan tanto autenticación de servidor como de cliente; el 100 % de los casos de uso de autenticación de cliente migrados a certificados privados solo de autenticación de cliente; cero interrupciones de autenticación atribuibles a la eliminación de la autenticación de cliente en la renovación; cobertura de la automatización de la inscripción de PKI privada (porcentaje de certificados de cliente en renovación automatizada); y clasificación de preparación post-cuántica (algoritmos de clave de CA privada clasificados según los hitos de obsolescencia de NIST IR 8547 con cronograma de migración definido). Informe estos datos trimestralmente según el calendario de plazos del Foro CA/Navegador.

¿Qué se debe auditar o supervisar periódicamente?

Supervisar continuamente: inventario de certificados de confianza pública que incluyan tanto serverAuth como clientAuth, con alertas de renovación que señalen los certificados dual-EKU antes de su renovación; tasas de éxito de autenticación mTLS, RADIUS, VPN e IoT para la detección temprana de fallos en la eliminación de clientAuth. Auditar trimestralmente: porcentaje de casos de uso de autenticación de cliente migrados a certificados privados; cobertura de automatización de inscripción de CA privadas; clasificación del algoritmo de clave de CA privada según NIST FIPS 203/204/205 (finalizada el 13 de agosto de 2024); integridad de la evidencia de cumplimiento para la fecha límite del 15 de marzo de 2027.

¿Cómo afecta el mandato de doble EKU a los entornos PKI en la nube, híbridos o con múltiples CA?

Los entornos en la nube e híbridos suelen tener la mayor densidad de dependencias de doble EKU no descubiertas: microservicios que usan mTLS con certificados públicos, cargas de trabajo nativas de la nube que usan autenticación basada en certificados para API en la nube, clústeres de Kubernetes que usan certificados para la identidad de la malla de servicios y canalizaciones de CI/CD que se autentican en registros. Los entornos de múltiples CA necesitan una capa CLM centralizada que descubra las dependencias de clientAuth en todas las fuentes de CA, no solo en el inventario de CA públicas, incluidas AWS Private CA, HashiCorp Vault PKI y Microsoft AD CS.

¿Qué errores comunes deben evitar los equipos?

Los errores más frecuentes son: no descubrir las dependencias de clientAuth antes de renovar los certificados; tratar el mandato como un simple cambio de plantilla de certificado sin separar la jerarquía PKI a nivel de CA (la política del programa raíz de Chrome requiere la separación a nivel de CA); no distribuir la CA raíz privada a todos los sistemas de partes que confían en ella antes de migrar; crear una PKI privada bajo la presión de los plazos sin planificar la migración posterior a la computación cuántica de los algoritmos de clave de CA privada; y no inscribir los certificados de cliente migrados en procesos de renovación automatizados que puedan mantener una validez de 47 días a partir de marzo de 2029.

¿Qué se debe renovar trimestralmente?

Trimestralmente: auditar el inventario de certificados para certificados de confianza pública que aún conservan clientAuth; verificar que la CA raíz privada se haya distribuido a todos los sistemas nuevos agregados desde la última auditoría; confirmar la cobertura de automatización de inscripción de CA privada para todos los casos de uso de autenticación de cliente; clasificar los algoritmos de clave de CA privada según los hitos de desuso post-cuántico del NIST (ML-DSA según FIPS 204, finalizado el 13 de agosto de 2024); verificar que no se hayan divulgado nuevas CA intermedias de doble EKU a CCADB en jerarquías de confianza de Chrome (prohibido a partir del 15 de junio de 2026). Para la planificación de la migración de algoritmos de clave de CA privada post-cuántica, consulte el Centro de Excelencia de PQC.