Eliminación de clientAuth EKU: dónde falla mTLS y cómo migrar a PKI privada

Tu red mTLS puede superar todas las comprobaciones de estado, renovar todos los certificados según lo previsto y, aun así, dejar de autenticar clientes de la noche a la mañana. Nada se piratea. Nada caduca antes de tiempo. Un certificado simplemente se renueva, regresa sin problemas con un valor de Uso de clave extendida faltante, y el siguiente protocolo de enlace que depende de él falla. Así es como se implementará la desaparición de clientAuth, y ya está en marcha.

TL; DR La política del programa raíz de Chrome v1.8, sección 1.3.2, está eliminando el uso extendido de clave (EKU) clientAuth de los certificados TLS leaf de confianza pública. Las nuevas CA subordinadas deben ser serverAuth-only desde el 15 de junio de 2026, y cada nuevo certificado leaf público debe ser serverAuth-only antes del 15 de marzo de 2027. Es casi seguro que su autoridad de certificación realizará el cambio antes de la fecha límite de Chrome. DigiCert, Sectigo, Let's Encrypt, Google Trust Services y SSL.com han establecido límites internos más tempranos, algunos tan pronto como septiembre de 2025. El fallo es silencioso por diseño: los certificados existentes siguen funcionando hasta que caducan, por lo que la interrupción aparece en la siguiente renovación rutinaria, no en ninguna fecha de política, y puede surgir horas o días después en infraestructura no relacionada. Volver a emitir o fijar el certificado leaf no lo salvará. Los verificadores calculan la EKU efectiva como la intersección de cada certificado en la cadena, por lo que una vez que su jerarquía de emisión pasa a ser serverAuth-only, el OID clientAuth del nodo hoja deja de ser reconocido, incluso si todavía está impreso en el certificado. La solución definitiva es una PKI privada que usted administra para la identidad del cliente y de la máquina, creada internamente o consumida como PKI-as-a-Service, migrada a través de un plan de cuatro fases sin tiempo de inactividad.

Puntos Clave

• Conozca el mandato: La política del programa raíz de Chrome v1.8 es la fuente. El 15 de junio de 2026 ya se implementaron jerarquías de CA subde propósito único. El 15 de marzo de 2027 es el límite estricto para los certificados hoja. Es probable que su propia CA realice la transición antes de cualquiera de estas fechas.
• Inventario ahora, no al momento de la renovación: Encuentre todos los consumidores de clientAuth en sistemas mTLS, malla de servicios, IoT, VPN, 802.1X, SIP y sistemas heredados de máquina a máquina.
• Evita los callejones sin salida: Las opciones de suscripción voluntaria, las reemisiones de último minuto y las raíces que no son del navegador solo retrasan el problema. Una infraestructura de clave pública privada es la única opción que le brinda EKU y una política de emisión que usted realmente controla.
• Revisa toda la cadena, no solo la hoja: Un cliente intermedio que pierde la autenticación puede invalidar un certificado de hoja antes de que llegue la renovación de ese mismo certificado.
• Busque más allá de su propio inventario de certificados: Los registros de Transparencia de Certificados sacan a la luz certificados olvidados y certificados de TI en la sombra que sus propios registros no registran.
• Migrar deliberadamente: Descubra, diseñe, implemente y luego realice la transición con confianza paralela, y valide toda la cadena en el entorno de pruebas antes de que una renovación en producción le obligue a tomar una decisión.

¿Qué es lo que realmente está cambiando?

Durante años, un certificado TLS de confianza pública podía contener dos valores de uso de clave extendida a la vez: id-kp-serverAuth (OID 1.3.6.1.5.5.7.3.1) e id-kp-clientAuth (OID 1.3.6.1.5.5.7.3.2), tal como se define en la sección 4.2.1.12 de la RFC 5280. Un único certificado podía finalizar HTTPS como servidor y también autenticarse como cliente en flujos mTLS, de servicio a servicio y de identidad de máquina.

Según la Política del Programa Raíz de Chrome v1.8, Sección 1.3.2, esta doble función desaparecerá. Los nuevos certificados TLS de confianza pública solo incluirán la autenticación del servidor (serverAuth). Los certificados de doble propósito existentes seguirán siendo válidos hasta su vencimiento, pero cada renovación emitida después de la fecha de entrada en vigor de la CA volverá a incluir únicamente la autenticación del servidor (serverAuth) de forma predeterminada.

Dos fechas son cruciales a nivel de política: las nuevas CA subordinadas divulgadas al CCADB deben ser serverAuth-only desde el 15 de junio de 2026, y cada certificado de suscriptor (hoja) emitido a partir del 15 de marzo de 2027 debe afirmar serverAuth only. Google planteó esta división por primera vez en la reunión F2F-63 del Foro CA/Navegador en octubre de 2024, y luego la codificó como una política del Programa Raíz de Chrome en lugar de una votación del Foro CA/Navegador. Chrome aún representa aproximadamente dos tercios del mercado global de navegadores, por lo que una CA pública que ignore el programa raíz de Chrome corre el riesgo de perder la confianza de la mayor parte de la web, y todas las CA importantes están tratando la política como obligatoria.

Este artículo parte de la base de que usted ya conoce esta información. Para consultar el historial completo del mandato, el papel del CA/Browser Forum y el lenguaje de la política de Chrome sección por sección, consulte los análisis detallados de Encryption Consulting sobre la Política del Programa Raíz de Chrome v1.8 y el mandato del CA/Browser Forum . A continuación, se presenta la parte que la mayoría de los análisis sobre este cambio omiten: dónde falla exactamente su infraestructura, cómo encontrar todos los certificados en riesgo y cómo trasladar la identidad del cliente a un lugar seguro antes de que una renovación obligue a implementar el problema en producción.

La fecha límite de tu CA, no la de Chrome, es tu fecha límite real.

Las autoridades de certificación públicas se están adelantando a las fechas límite establecidas por Chrome. Los certificados existentes siguen funcionando hasta que caducan, pero la primera renovación posterior a la fecha límite de la CA solo permite la autenticación del servidor, y es entonces cuando la autenticación del cliente deja de funcionar silenciosamente.

Autoridad certificada	clientAuth está desactivado por defecto.	Corte estricto (no se emitió ninguna autorización de cliente)
DigiCert	1 de octubre de 2025	1 de marzo de 2027 (todas las marcas de DigiCert)
sectigo	7 de octubre de 2025	10 de febrero de 2027, sin excepciones.
Vamos a cifrar	11 de febrero de 2026 (perfil ACME predeterminado)	8 de julio de 2026 (perfil de puente tlsClient retirado)
Servicios de confianza de Google	10 de noviembre de 2025 (Solicitudes de servicio al cliente rechazadas)	13 de abril de 2026, sin excepciones.
SSL.com	15 de septiembre de 2025	Actualizado a Chrome el 15 de marzo de 2027.

Consulta directamente la página de avisos de tu propia autoridad competente; varias de estas fechas ya se han adelantado con respecto a lo anunciado originalmente, y las autoridades competentes no dudan en acelerar aún más los plazos.

Por qué la división es en realidad la decisión correcta

Resulta tentador considerar esto como una mera formalidad burocrática por parte del proveedor del navegador. No lo es, y conviene comprender el porqué antes de diseñar una arquitectura en torno a ello, ya que la misma lógica debería guiar el diseño de la infraestructura de clave pública privada a la que se migre.

La validación no es autorización: la emisión de certificados públicos demuestra el control del dominio mediante métodos como ACME HTTP-01 y DNS-01, tal como se define en las secciones 8.3 y 8.4 de la RFC 8555, o la identidad de la organización para los certificados OV y EV, según la sección 3.2.2.4 de los Requisitos Básicos. Nada de esto verifica que un sistema determinado esté autorizado para actuar como cliente frente a su infraestructura. Un certificado público de autenticación de cliente siempre anunciaba una propiedad de confianza que la CA emisora ​​nunca validó realmente.

El uso de dos EKU duplica el alcance de un ataque con una clave robada: un certificado que contiene tanto autenticación de servidor como de cliente implica que una clave privada comprometida permite a un atacante suplantar la identidad de su servidor y moverse lateralmente como un cliente de confianza, utilizando la misma clave para ambos. Separar los certificados, las claves y sus ciclos de vida según su propósito elimina por completo esta segunda vía de ataque. Se trata del principio de mínimo privilegio aplicado a los certificados, una idea que, por fin, se implementa a nivel de EKU.

Dónde falla realmente el protocolo de enlace mTLS

Este es el detalle que la mayoría de quienes explican este cambio omiten, y es el que más importa cuando estás depurando una página a las 2 de la madrugada.

En un intercambio de claves TLS mutuo, el servidor envía una solicitud de certificado (CertificateRequest), el cliente responde con su certificado y luego envía una verificación de certificado (CertificateVerify), una firma que prueba que posee la clave privada correspondiente (este es el flujo de TLS 1.3; TLS 1.2 agrega un paso intermedio de intercambio de claves del cliente sin cifrar, pero el punto de fallo es idéntico). El verificador realiza dos comprobaciones realmente separadas, y confundirlas es donde la mayoría de los análisis posteriores al incidente se equivocan.

En primer lugar, se ejecuta la validación de ruta según lo definido en la Sección 6 de la RFC 5280, construyendo y verificando la cadena hasta una raíz de confianza. Este paso se completa con éxito. La cadena de certificados es completamente válida. La RFC 5280 define la extensión EKU en la Sección 4.2.1.12, pero no requiere que un verificador compruebe el propósito de EKU como parte de la validación de ruta.

Esta comprobación de propósito la añade la implementación específica de TLS, no está contemplada en la RFC. Las principales bibliotecas, como OpenSSL, JSSE de Java, crypto/tls de Go y rustls de Rust, aplican la validación de propósito EKU por defecto: buscan clientAuth en el certificado presentado, no lo encuentran y lo rechazan directamente. Se trata de un fallo de autenticación grave, no de una advertencia, y suele producirse en cuanto el verificador evalúa el EKU del certificado del cliente, a menudo justo en el mensaje Certificate, en lugar de solo después de CertificateVerify. No fluyen datos de la aplicación antes de que se ejecute esta comprobación.

La aplicación de esta norma es deliberada, no fortuita. El propio sistema de seguimiento de errores de Go documenta un caso (golang/go#23884) en el que un certificado de cliente con autenticación de servidor únicamente fue rechazado correctamente bajo RequireAndVerifyClientCert en Go 1.9.4, y posteriormente aceptado erróneamente tras una regresión en Go 1.10. Los responsables del mantenimiento de Go trataron la regresión como un error y lo corrigieron, lo que constituye una confirmación clara de que la aplicación de la norma EKU es el comportamiento predeterminado previsto en todo el ecosistema, y ​​no un caso excepcional que se pueda ignorar.

La trampa del encadenamiento: volver a emitir la hoja no te salvará.

Aquí está el detalle que delata a los equipos que creen haber ganado tiempo. Los verificadores como Chrome y las pilas TLS subyacentes no solo comprueban el EKU del certificado hoja. Validan toda la cadena, y el EKU efectivo de un certificado es la intersección de los propósitos permitidos por cada certificado en la ruta superior.

Consideremos un certificado hoja que aún enumera tanto serverAuth como clientAuth, emitido bajo una CA intermedia que ha migrado a una jerarquía que solo utiliza serverAuth:

{ serverAuth } ∩ { serverAuth, clientAuth } = { serverAuth }

El OID clientAuth del certificado hoja sigue impreso en el certificado. Simplemente se ignora, ya que ningún certificado superior al de la hoja puede contener una EKU que excluya clientAuth para que se mantenga en la cadena. El silencio funciona: un certificado de CA intermedio sin extensión EKU no tiene restricciones. Es una EKU explícita que omite clientAuth la que causa problemas en todo lo que se encuentra debajo.

La consecuencia práctica es que no se puede mantener activa la autenticación de cliente reemitiendo o fijando el certificado hoja existente una vez que la jerarquía de la CA emisora ​​pasa a ser exclusivamente de autenticación de servidor. Un certificado intermedio puede perder la capacidad de autenticación de cliente para todo lo que se encuentre bajo su dominio antes de que llegue la fecha de renovación de cualquier certificado hoja individual. Si solo se realiza un seguimiento de las fechas de vencimiento de los certificados hoja, se está haciendo un seguimiento del tiempo equivocado.

¿Qué cargas de trabajo se rompen silenciosamente?

El radio de acción es mayor de lo que suponen la mayoría de los inventarios de certificados, y la aplicación de la normativa varía según el proveedor, lo que precisamente dificulta su evaluación basándose únicamente en una hoja de cálculo.

carga de trabajo	Por qué depende de clientAuth	Notas de aplicación
mTLS / malla de servicio	Los sidecares se autentican entre sí con certificados de cliente para el tráfico este-oeste.	Generalmente estrictos; donde las interrupciones son más visibles
API para socios y empresas	Las pasarelas presentan certificados de cliente para demostrar la identidad en mTLS entre organizaciones.	Estricto contractual en la mayoría de las integraciones.
IoT e identidad de dispositivos	Cada dispositivo presenta un certificado de cliente para demostrar a qué miembro de la flota pertenece.	Estricto; las flotas de dispositivos son difíciles de parchear rápidamente.
autenticación del cliente VPN	Los clientes se autentican en la puerta de enlace con un certificado (OpenVPN, AnyConnect, Fortinet).	Dependiente del proveedor, generalmente estricto
Wi-Fi / 802.1X (EAP-TLS)	El certificado del solicitante (dispositivo) normalmente incluye clientAuth.	RFC 5216 §5.3 recomienda la verificación, pero también acepta que no haya EKU en absoluto.
SIP / SBC / comunicaciones unificadas	Algunos operadores requieren clientAuth para la confianza del controlador de borde de sesión.	Depende del operador; la documentación de Microsoft Teams Direct Routing actualmente acepta certificados SBC sin autenticación de cliente.
Equilibradores de carga	Verifique los certificados del cliente, pero solo aplique clientAuth si está configurado explícitamente.	F5 BIG-IP aplica el propósito de EKU solo si un administrador activa esa regla.
Middleware heredado de comunicación máquina a máquina	Los sistemas más antiguos requieren un certificado de doble propósito para ambos roles.	A menudo son los más difíciles de parchear; frecuentemente no pertenecen a ningún equipo actual.

La conclusión principal es que la aplicación de las normas depende realmente del proveedor. Verifica tu propia infraestructura en lugar de asumir que todas las cargas de trabajo de esta tabla fallan el mismo día; algunas podrían seguir funcionando con dificultades debido a un tecnicismo hasta que una futura actualización solucione ese problema.

El patrón de fallo silencioso

La característica más peligrosa de este cambio es que nada lo anuncia. La secuencia de fallos se ve así:

1. Llega el día de la política: No ocurre nada. Los certificados duales de EKU existentes siguen siendo válidos hasta que caduquen individualmente.
2. Pasan las semanas: Los despliegues parecen completamente estables. Las renovaciones automáticas de ACME siguen funcionando exactamente como siempre.
3. Se activan los sistemas de renovación rutinaria: El certificado se renueva correctamente, pero devuelve la funcionalidad serverAuth-only. Es un certificado perfectamente válido. Simplemente le falta la funcionalidad necesaria para esta carga de trabajo.
4. El siguiente protocolo de enlace mTLS falla: La comprobación EKU rechaza el certificado la próxima vez que se utilice para la autenticación del cliente, lo que puede ocurrir horas o días después de la renovación, en una infraestructura que parece no tener ninguna relación con quien renovó el certificado.

Dado que la rotación está automatizada de principio a fin, un ciclo de renovación en una autoridad de certificación puede provocar la caída de toda una red de servicios, y resulta realmente difícil de diagnosticar, ya que el certificado supera todas las comprobaciones excepto la que realmente importa. La validación de la cadena es correcta. La fecha de caducidad es correcta. La firma es válida. Es solo para autenticación de servidor, y nadie estaba supervisando ese campo específico.

Cómo encontrar la exposición de clientAuth

No se puede migrar lo que no se ha encontrado. Seis maneras de crear un inventario real, aproximadamente en orden de dificultad:

1. Inventario por EKU: Enumera todos los certificados TLS emitidos públicamente que posees e identifica cualquier certificado que contenga clientAuth. Un flujo de trabajo de lista de materiales criptográficos (CBOM) permite escalar este proceso a un gran número de certificados.
2. Registros de transparencia de certificados de búsqueda: La política de Chrome exige el registro de transacciones (CT) para todos los certificados TLS de confianza pública, por lo que un agregador como crt.sh devolverá el historial completo de emisión de sus dominios, incluidos los certificados olvidados o de TI en la sombra que nadie recuerda haber solicitado.
3. Comprueba la cadena completa, no solo la hoja: Verifique qué afirman realmente los certificados intermedios de su CA emisora. La funcionalidad puede caducar en el certificado intermedio antes de la renovación del certificado leaf.
4. Mapea el grafo de dependencias: Identifique qué flujos de autenticación mutua en su entorno consumen realmente clientAuth, no solo qué certificados contienen la EKU.
5. Confirme la compatibilidad con doble certificación por aplicación: ¿Cada aplicación puede tener certificados de cliente y servidor independientes, o se asume que un solo certificado sirve para ambos? Si no es posible, es un tema que se debe tratar con el proveedor ahora, no en marzo de 2027.
6. Automatice el descubrimiento con una plataforma CLM: Las comprobaciones manuales no son viables para gestionar más allá de un pequeño número de certificados. Una plataforma de gestión del ciclo de vida de los certificados realiza un inventario continuo de las EKU, no solo cuando alguien se acuerda de auditarlas.

Tres comandos cubren la mayoría de las comprobaciones rápidas, y todos son compatibles con Windows, Linux y macOS:

# Leer la extensión EKU de un archivo de certificado en disco openssl x509 -in cert.pem -noout -ext extendedKeyUsage   # Compruebe la EKU en un certificado presentado por un punto final TLS activo. echo | openssl s_client -connect :443 -nombre del servidor 2>/dev/null \ | openssl x509 -noout -ext extendedKeyUsage   # Enumerar las EKU para cada certificado en un almacén de claves Java/PKCS12 keytool -list -v -keystore -tipo de almacén PKCS12

Lo que debes buscar en la salida es la cadena "TLS Web Client Authentication" o el OID sin procesar 1.3.6.1.5.5.7.3.2. Si aparece hoy y el certificado proviene de una CA pública, considéralo como expuesto.

Por qué las soluciones alternativas comunes no llevan a ninguna parte

Tres atajos tentadores y dónde termina cada uno.

Opciones de activación: DigiCert y Sectigo aún ofrecen opciones de registro que mantienen activa la autenticación de cliente, por ahora. Estas opciones desaparecen al cumplirse la fecha límite de cada CA, incluso para las renovaciones de certificados que ya posee. Esto no es una solución definitiva, sino una cuenta regresiva con fecha de finalización fija.

Reemisión anticipada: Reemitir hoy mantiene la autenticación de cliente activa durante un ciclo de vida adicional del certificado. Sin embargo, la duración de los certificados públicos se reducirá a 47 días para marzo de 2029 según la propuesta SC-081v3 del Foro de Navegadores/CA, por lo que su próxima renovación se producirá después de la fecha límite. El plazo límite se acerca cada vez que se utiliza este truco; nunca se aleja.

Raíces que no son navegadores: Las jerarquías como X9 PKI aún admiten certificados EKU duales, pero Chrome y Firefox no confían en ellos automáticamente. Tendrías que distribuir esa confianza a cada dispositivo que dependa de ella, lo que cambia un problema de certificados por un problema de distribución total de la confianza. Rara vez es mejor esa opción.

El patrón común a los tres casos es que la identidad del cliente nunca fue el propósito principal de la confianza en la web pública. Se basaba en un certificado diseñado para otra función. La solución definitiva es un modelo de confianza que se pueda gestionar directamente.

Opinión de experto: Construye la separación que siempre quisiste.

He aquí lo que merece la pena aclarar: esta migración es una buena excusa para construir la arquitectura que probablemente ya deberías tener. Una infraestructura de clave pública (PKI) privada, diseñada específicamente para la identidad de clientes y máquinas, te brinda un control de EKU y perfiles que las autoridades de certificación públicas nunca iban a ofrecer: perfiles serverAuth y clientAuth de propósito único por defecto, un perfil de doble EKU mantenido solo como un puente de migración temporal y deliberado en lugar de un hábito permanente, y una duración de los certificados que se mide en horas o días una vez que la emisión está automatizada, lo cual es una mejora de seguridad, no una carga.

También te desvincula de la inestabilidad pública que no controlas. El plazo de 47 días y cualquier cambio en la política del programa raíz dejan de ser una emergencia, porque las partes que confían en ti son tuyas, los anclajes de confianza residen en tus propios almacenes y las reglas son las que tú escribes. Y como controlas la jerarquía, los perfiles híbridos y de ML-DSA post-cuánticos se convierten en algo que puedes probar ahora, antes del lanzamiento de PQC del ecosistema público, en lugar de un proyecto futuro independiente.

Nada de esto implica volver a emitir certificados de doble propósito libremente. La misma lógica de mínimo privilegio que justificó la separación de serverAuth y clientAuth en TLS público se aplica también dentro de su propia jerarquía.

Lo que realmente requiere una infraestructura de clave pública (PKI) privada de nivel de producción

“Crear una CA privada” es fácil de decir, pero realmente difícil de implementar correctamente. Hacerlo mal implica cambiar un plazo por una interrupción del servicio. Seis requisitos que distinguen una PKI privada de nivel de producción de una autoridad de certificación que se convierte en un incidente en sí misma:

Requisito	Lo que realmente significa
Material clave protegido por HSM	Claves raíz y de CA emisoras generadas y almacenadas en HSM validados según FIPS 140-3, la raíz se mantiene fuera de línea, con ceremonias de clave documentadas.
Nivel de emisión diseñado para alto rendimiento	Diseñado para un volumen real de certificados con alta disponibilidad; compatible con ACME, SCEP y EST para que la emisión automatizada se mantenga al ritmo de ciclos de vida cortos.
Infraestructura de revocación	Puntos de distribución de CRL y respondedores OCSP; el stapling ayuda a validar los certificados del servidor, pero las comprobaciones de certificados del cliente en mTLS suelen ser búsquedas de CRL u OCSP iniciadas por el verificador.
Perfiles de certificados anclados	Cada perfil especifica EKU, algoritmos y períodos de validez explícitos, con roles de cliente y servidor separados por perfil o sub-CA.
Preparación para auditorías y para la gestión de casos clínicos (CP/CPS)	Una política de certificación, una declaración de prácticas de certificación, registros clave de la ceremonia y una estructura de gobernanza que resistan la evaluación de un evaluador externo.
Visibilidad y automatización del ciclo de vida	Descubrimiento continuo más renovación y rotación automatizadas; el seguimiento manual no puede seguir el ritmo de los certificados que se miden en horas o días.

Cumplir con los seis requisitos exige un gran esfuerzo de ingeniería, un compromiso operativo constante y conocimientos criptográficos especializados que la mayoría de los equipos internos no pueden asumir por sí solos. Esa es la razón principal por la que muchas organizaciones optan por una infraestructura de clave pública gestionada (PKIaaS) en lugar de implementarla desde cero.

El plan maestro para la migración sin tiempo de inactividad

Cuatro fases, diseñadas para que nada falle durante el cambio de confianza. La regla fundamental en las cuatro fases es la siguiente: mantener las cadenas de certificados antigua y nueva en paralelo durante el período de transición, no revocar nada hasta que todos los consumidores confíen en la nueva cadena y completar la migración antes de la fecha límite de la autoridad de certificación, no en ella.

Fase	Enfócate	Pasos concretos
01. Descubre	Encontrar exposición	Inventariar certificados hoja por EKU, mapear cadenas hoja e intermedias, identificar cada flujo mTLS, capturar plazos de renovación.
02. Diseño	Definir perfiles	Configure EKU explícitas, separe los perfiles de cliente y servidor, defina los algoritmos y los tamaños de clave, diseñe la estrategia CRL/OCSP.
03. Implementar	Generar confianza	Implemente el nivel raíz y de emisión (o extiéndalo a través de PKIaaS cuando tenga sentido), automatice la inscripción ACME, SCEP y EST, distribuya anclas de confianza
04. Cortar	Cambia de forma segura	Ejecutar cadenas antiguas y nuevas en paralelo, validar rutas completas en el entorno de pruebas, rotar los certificados gradualmente, retirar la confianza heredada una vez confirmada la adopción.

Dos modos de fallo que deben evitarse explícitamente en el diseño: migrar en la fecha de entrada en vigor en lugar de antes, y revocar la cadena antigua antes de que todos los consumidores hayan adoptado la nueva. Ambos convierten una migración planificada en una interrupción del servicio.

Cómo la solución PKIaaS de Encryption Consulting se adapta a esta migración

La fase de implementación descrita anteriormente es donde la mayoría de los equipos avanzan rápidamente o se estancan durante meses adquiriendo hardware, contratando personal para operaciones 24/7 y redactando la documentación de CP/CPS desde cero. PKI-as-a-Service de Encryption Consulting está diseñado para eliminar ese cuello de botella: una PKI de inquilino único, totalmente administrada y de alta disponibilidad, con claves de CA protegidas en HSM FIPS 140-3 Nivel 3, y CertSecure Manager , la plataforma de gestión del ciclo de vida de certificados independiente de la CA de EC, integrada para una visibilidad y automatización de todo el entorno.

Fundamento: Su CA raíz, las CA subordinadas y los servicios OCSP/CRL están completamente alojados, sin necesidad de mantener una infraestructura de CA local. HSM-as-a-Service significa que EC proporciona y mantiene el hardware FIPS 140-3 Nivel 3; las claves de CA permanecen dentro del HSM, nunca se pueden exportar al software, y usted conserva el control y la propiedad de las claves.

Operaciones: CertSecure Manager ofrece visibilidad completa del entorno y automatiza el descubrimiento, la inscripción, la renovación y la revocación de certificados públicos, privados y emitidos por PKIaaS, mediante ACME, SCEP y EST. Gracias a la gestión integral del servicio, EC supervisa el estado de la CA, la renovación de la CRL, el estado del HSM y la caducidad de los certificados las 24 horas del día, detectando los problemas antes de que se conviertan en el tipo de interrupción silenciosa descrita anteriormente en esta publicación.

Gobernanza: EC proporciona documentación y plantillas de gobernanza para CP/CPS, control de acceso basado en roles y ceremonias de claves documentadas y presenciadas, la misma gobernanza que un evaluador solicitará durante una auditoría. Los perfiles de certificado están diseñados específicamente para esta migración, con criptoagilidad integrada para que los perfiles de certificado híbridos y compatibles con PQC estén disponibles a medida que evolucionan los estándares, en lugar de requerir otro proyecto de migración en el futuro.

En consonancia con el plan de cuatro fases: Descubrir y Diseñar suelen ser un ejercicio conjunto con su equipo; Implementar es donde PKIaaS realiza el trabajo más pesado, estableciendo una jerarquía gobernada en semanas en lugar de los meses que suele llevar una creación desde cero; y La Transición cuenta con el respaldo de la automatización de CertSecure Manager para que el despliegue de la cadena paralela no se convierta en un despliegue manual y propenso a errores.

Preguntas frecuentes

¿Qué es la EKU clientAuth y por qué se está eliminando de los certificados TLS públicos?

El uso extendido de clave clientAuth (OID 1.3.6.1.5.5.7.3.2) permite que un certificado TLS se autentique como cliente, además de la función de serverAuth de autenticar un servidor ante los navegadores. La política del programa raíz de Chrome v1.8 lo está eliminando de los certificados hoja públicos porque la emisión pública solo validaba la identidad del dominio o la organización, nunca la autorización del cliente, y porque un certificado de doble propósito duplica las capacidades de una clave robada.

¿Mi fecha límite real es el 15 de marzo de 2027, fecha que establece Chrome, o es otra?

Casi con toda seguridad, la fecha límite será anterior. Las autoridades de certificación públicas, como DigiCert, Sectigo, Let's Encrypt, Google Trust Services y SSL.com, han establecido sus propias fechas límite antes de la fecha de entrada en vigor de Chrome, varias de ellas ya en 2025. Consulta la página de avisos de tu autoridad de certificación específica en lugar de basar tus planes únicamente en la fecha establecida para todo el sector.

¿Puedo mantener la autenticación de cliente funcionando reemitiendo o fijando mi certificado actual?

No. Los verificadores calculan la EKU efectiva como la intersección de todos los certificados de la cadena. Una vez que la jerarquía de su CA emisora ​​pasa a ser exclusivamente serverAuth, un certificado intermedio puede excluir clientAuth para todo lo que esté debajo de él, y volver a emitir o fijar el certificado hoja no cambia eso.

¿Qué es lo primero que falla cuando clientAuth desaparece de mis certificados?

Todo lo que dependa de TLS mutuo para la identidad de la máquina o del cliente: sidecars de malla de servicios, pasarelas API de socios, flotas de dispositivos IoT, clientes VPN y cualquier balanceador de carga o middleware configurado explícitamente para aplicar la EKU clientAuth. El fallo no aparece en la fecha de aplicación; aparece en la siguiente renovación del certificado y en el siguiente handshake mTLS posterior.

¿La migración a una infraestructura de clave pública privada también contribuye a la preparación para la era post-cuántica?

Sí, indirectamente pero de forma útil. Dado que usted controla la jerarquía, puede probar perfiles de certificados híbridos y ML-DSA dentro de su propia PKI privada mucho antes del despliegue posterior a la computación cuántica del ecosistema de certificados públicos, lo que convierte esta migración en una ventaja inicial en lugar de un segundo proyecto independiente más adelante.

¿Listo para ver en qué posición te encuentras?

Esta semana, revise la lista de verificación de detección anterior y compárela con su propio conjunto de certificados. Cuando esté listo para diseñar e implementar la infraestructura de clave pública privada (PKI), vea cómo se relaciona la PKI como servicio con esta migración específica o póngase en contacto con el equipo de PKI de Encryption Consulting para solicitar una evaluación de detección y migración.