Durante años, un atajo práctico ha mantenido unida gran parte de la autenticación máquina a máquina: las organizaciones reutilizaban sus certificados TLS públicos para la autenticación TLS mutua. Un certificado emitido para un servidor web solía incluir las claves de autenticación extendida tanto para el servidor como para el cliente, de modo que el mismo certificado que protegía un punto final público también podía autenticar a un cliente en un protocolo de enlace mTLS. Este atajo está a punto de dejar de funcionar, y los sistemas que dependen de él fallarán no con una advertencia, sino en su próxima renovación.
Este artículo explica el problema de la expiración de la garantía de autenticación de clientes (clientAuth EKU), su origen, el momento exacto en que se aplica y las medidas a tomar. La solución para la mayoría de las organizaciones afectadas es dejar de usar certificados públicos para la autenticación de clientes e implementar una infraestructura de clave pública (PKI) privada diseñada específicamente para este fin. Analizaremos el cronograma, la razón técnica de la divergencia entre la confianza pública y la privada, los riesgos de la inacción y una estrategia práctica para implementar mTLS en una PKI privada antes de la fecha límite.
Por qué esto importa ahora
Tres factores convierten esto en algo urgente, no teórico. Las autoridades de certificación públicas que emiten la mayoría de los certificados TLS están eliminando la extensión de uso de autenticación de cliente (clientAuth EKU) hasta 2026, Chrome está completando su migración a jerarquías exclusivas para servidores dedicados, y los fallos se producen silenciosamente al renovar los certificados, en lugar de anunciarse en una fecha concreta. En conjunto, transforman un detalle de configuración discreto en una fecha límite que se cumple certificado a certificado.
Chrome establece los plazos
El programa Chrome Root de Google impulsa este cambio mediante la adopción de jerarquías TLS dedicadas exclusivamente al servidor. Según la política del programa Chrome Root, cualquier nuevo certificado CA intermedio (subordinado) debe incluir únicamente la EKU serverAuth a partir del 15 de junio de 2026, y todos los certificados hoja emitidos recientemente deben incluir únicamente serverAuth a partir del 15 de marzo de 2027, fecha en la que Chrome deja de confiar en los certificados TLS públicos que incluyen la EKU clientAuth. Los certificados emitidos antes de esas fechas siguen siendo válidos hasta su vencimiento, lo que genera una transición gradual: no se produce ningún fallo en la fecha límite, pero cada renovación posterior elimina la funcionalidad en la que se basaba mTLS.
Los CA actúan incluso antes.
La fecha límite práctica es anterior a la fecha de vencimiento de Chrome, ya que varias autoridades de certificación están eliminando la EKU mucho antes. Let's Encrypt elimina la EKU clientAuth de los certificados emitidos a partir del 13 de mayo de 2026, y Sectigo la elimina antes del 15 de mayo de 2026. DigiCert dejó de incluirla por defecto el 1 de octubre de 2025, ahora solo la emite bajo solicitud explícita y la eliminará por completo el 1 de marzo de 2027. Por lo tanto, la fecha límite efectiva la establece la CA que emite su certificado, no la fecha de vencimiento de Chrome: si su mTLS depende de un certificado de Let's Encrypt o Sectigo que se renueva después de mediados de mayo de 2026, puede dejar de funcionar meses antes de que Chrome lo aplique, porque el certificado renovado simplemente no incluirá clientAuth.
Esto forma parte de una estrategia deliberada para establecer jerarquías específicas.
El cambio no es arbitrario. Refleja una tendencia generalizada en la industria hacia jerarquías PKI dedicadas y de propósito único, presentada a través de las actualizaciones de políticas del Programa Raíz de Chrome. El objetivo es eliminar las cadenas de confianza de certificados multipropósito para mejorar la seguridad de los certificados de servidor y simplificar su administración. La era de un solo certificado para múltiples propósitos está llegando a su fin de forma deliberada. Esta dirección se definió en las discusiones del Foro CA/Navegador de octubre de 2024 y se formalizó en sucesivas versiones de las políticas del Programa Raíz de Chrome. Se espera que los demás programas raíz importantes, incluidos los de Apple y Mozilla, se alineen, por lo que se trata de una trayectoria de la industria, no de la preferencia de un solo proveedor.
Cómo funcionan mTLS y la EKU clientAuth
Antes de planificar la migración, conviene comprender qué controlan las claves extendidas, por qué el TLS mutuo es el elemento que falla y por qué la infraestructura de clave pública privada (PKI) está exenta. Las secciones siguientes abordan cada uno de estos puntos, además de explicar por qué la confianza pública no era la herramienta adecuada para la autenticación de clientes internos.
Lo que hace la EKU
El uso extendido de clave es una extensión de certificado que declara para qué se puede usar un certificado para autenticar. Dos valores son fundamentales aquí, y se identifican mediante identificadores de objeto: la autenticación del servidor, id-kp-serverAuth, es OID 1.3.6.1.5.5.7.3.1, y la autenticación del cliente, id-kp-clientAuth, es OID 1.3.6.1.5.5.7.3.2. Durante años, los certificados TLS públicos se emitieron con ambos usos extendidos de clave, lo que permitía que un solo certificado actuara como identidad tanto del servidor como del cliente en TLS mutuo. Los navegadores solo verifican el uso extendido de clave del servidor (serverAuth EKU) para establecer una conexión HTTPS, por lo que eliminar clientAuth de los certificados de servidor públicos no tiene costo para el servicio web habitual, a la vez que cierra una vía real de uso indebido.
Por qué TLS mutuo es lo que falla
En TLS convencional, solo el servidor presenta un certificado; el cliente se autentica por otros medios o no se autentica en absoluto. En TLS mutuo, ambos extremos presentan certificados, y el certificado del cliente debe afirmar la EKU clientAuth para ser aceptado como identidad de cliente. Las organizaciones que reutilizaban sus certificados de servidor públicos de doble EKU para el lado del cliente de mTLS, o para la autenticación de servidor a servidor, dependían de la presencia del valor clientAuth. Una vez que las CA dejan de incluirlo, un certificado renovado solo contiene serverAuth, y el protocolo de enlace mTLS que esperaba una EKU de cliente falla. Este cambio afecta a las organizaciones que utilizan certificados de servidor para fines de autenticación de cliente, como TLS mutuo y autenticación de servidor a servidor. TLS mutuo es ahora la primitiva de autenticación predeterminada en arquitecturas de confianza cero y de malla de servicios, y en sistemas distribuidos como Kafka, Cassandra y pasarelas API donde la rotación de certificados está automatizada, una sola renovación puede provocar fallos de autenticación en todo un clúster.
La excepción crucial: la infraestructura de clave pública privada no se ve afectada.
El hecho técnico más importante para la planificación es que este cambio se aplica únicamente a los certificados de confianza pública. La excepción es explícita: estos cambios no afectan la autenticación de clientes PKI privados, ya que solo afectan a los certificados de confianza pública. Una autoridad de certificación privada, cuya raíz solo es de confianza dentro de su propio entorno y no por navegadores públicos, puede emitir certificados con la EKU clientAuth libremente. El problema de la caducidad es un fenómeno de confianza pública, y la PKI privada es la solución diseñada para evitarlo. Una CA privada puede ejecutarse en plataformas como Microsoft AD CS , HashiCorp Vault, AWS Private CA o un servicio administrado, y los certificados de cliente se pueden inscribir y renovar automáticamente a través de EST, ACME o SCEP , lo que permite que los certificados de cliente de corta duración sean prácticos a gran escala.
Por qué la confianza pública fue la herramienta equivocada para mTLS.
Este cambio también supone una corrección. Los certificados públicos nunca fueron el medio adecuado para la autenticación de clientes internos, y el ecosistema de certificados en general lo ha estado dejando claro. La propia guía de DigiCert sobre la reducción del riesgo de revocación aboga por trasladar los dispositivos conectados y los servicios internos fuera de la confianza pública, señalando que no existe un plazo de revocación de cinco días para los certificados de confianza privada y que las aplicaciones internas y la comunicación de dispositivos de red privada no requieren confianza pública. El uso de certificados públicos para mTLS exponía a los sistemas internos a eventos de revocación de CA públicas y cambios en las políticas del programa raíz que no guardaban relación con el caso de uso interno. La infraestructura de clave pública privada elimina por completo esta dependencia. Además, prepara la autenticación interna para la transición generalizada hacia certificados de corta duración y emisión automatizada, donde la gestión manual de certificados ya no es viable.
Riesgos y dificultades
El problema de la autenticación de cliente genera riesgos tanto para quienes no hacen nada como para quienes migran precipitadamente. La siguiente tabla muestra dónde suele fallar cada ruta.
| Supervisión | Causa | Consecuencia |
|---|---|---|
| Fracaso silencioso en la renovación | El certificado público se renueva sin la EKU clientAuth después de que la CA emisora la elimine. | Los protocolos de enlace mTLS fallan; la autenticación de servicio a servicio se interrumpe. |
| dependencia oculta | No existe un inventario que indique dónde se utilizan los certificados públicos para mTLS. | Se produjeron fallos en sistemas que nadie sabía que dependían de ese atajo. |
| Migración apresurada | Descubrir la dependencia solo en el momento de la renovación. | Transición de emergencia con pocas pruebas y alto riesgo de error. |
| Acoplamiento de la confianza pública | mTLS interno vinculado a la política y revocación de la CA pública. | Interrupciones internas causadas por eventos externos de CA. |
| CA privada no administrada | Implementación de una infraestructura de clave pública privada sin disciplina en su ciclo de vida. | Nueva proliferación de claves y una raíz de confianza interna sin supervisión. |
El peligro reside en que la dependencia es invisible.
La parte más difícil del problema de la autenticación de cliente no es la solución, sino saber dónde se está expuesto. La reutilización de certificados públicos para mTLS suele carecer de documentación, haber sido configurada hace años por un equipo que ya no trabaja en la empresa, e integrada en enlaces entre servicios que funcionan correctamente hasta que una renovación elimina la EKU. Sin un inventario que registre qué certificados contienen autenticación de cliente y dónde se utilizan como identidades de cliente, una organización no puede saber qué sistemas fallarán en su próxima renovación hasta que esto ocurra. La detección es la primera y más urgente tarea.
Los servicios financieros y sectores similares se ven afectados de manera desproporcionada.
Algunos sectores dependen más de este patrón que otros. El cambio afecta particularmente a sectores como los servicios financieros y los servicios tecnológicos, que utilizan certificados de servidor para la autenticación de clientes. Las organizaciones de estos sectores deben abordar el proceso de descubrimiento con urgencia. Para quienes realmente necesitan autenticación de clientes con raíz pública en toda la organización, una infraestructura de clave pública (PKI) X9 dedicada, regida por los estándares ASC X9 y operada fuera del Chrome Root Store, puede emitir certificados con ambas EKU, y se está adoptando en el sector financiero precisamente para este fin.
Mejores prácticas de implementación
Implementar mTLS con PKI privada antes de que se produzca el colapso es un proyecto controlado si comienza con el descubrimiento y termina con la automatización. Los siete pasos que se describen a continuación se ejecutan en secuencia, ya que no se puede definir el alcance de lo que no se ha descubierto, ni se puede migrar de forma segura lo que no se ha probado previamente.
- Descubre todas las dependencias de mTLS en certificados públicos: Inventaria qué certificados contienen la EKU clientAuth y dónde se utilizan como identidades de cliente o para la autenticación de servidor a servidor. Esto te indica el alcance exacto de lo que fallará y cuándo, según la fecha de renovación de cada certificado. CBOM seguro Automatiza este proceso de descubrimiento, catalogando cada certificado, las EKU que contiene y los sistemas que dependen de él.
- Confirme las fechas de renovación comparándolas con los plazos establecidos por la CA: Compare la renovación de cada certificado afectado con la fecha de eliminación de su CA emisora, el 13 de mayo para Let's Encrypt y el 15 de mayo para Sectigo, con DigiCert emitiendo clientAuth solo bajo petición hasta su eliminación el 1 de marzo de 2027, para que sepa qué dependencias tienen menos margen de tiempo.
- Configurar una CA privada para la autenticación de clientes: Establezca una PKI privada cuya raíz solo sea de confianza dentro de su entorno y emita certificados de cliente que contengan la EKU clientAuth desde ella. La PKI privada no se ve afectada explícitamente por el cambio de confianza pública y es la ruta prevista para mTLS interno. PKI como servicio Ofrece precisamente eso: una CA privada controlada que emite certificados clientAuth sin la carga de construir y gestionar la infraestructura.
- Separe claramente la relación de confianza entre el servidor y el cliente: Mantenga certificados públicos de autenticación de servidor (serverAuth) para los servidores accesibles al público y utilice certificados privados de cliente para el lado del cliente de mTLS, adoptando el modelo de jerarquía dedicada en lugar de combatirlo. En la práctica, esto significa un certificado público de autenticación de servidor (serverAuth) en el balanceador de carga y un certificado privado de autenticación de cliente (clientAuth) en cada servicio que se autentique como cliente.
- Proteja la raíz privada y automatice la emisión: Almacene las claves de firma de la CA privada en un HSM y utilice un protocolo de inscripción automatizado como EST o ACME para que los certificados de cliente de corta duración se emitan y renueven sin intervención manual. Una CA privada sin automatización del ciclo de vida simplemente cambia un problema por otro. HSM como servicio Ancla la raíz privada en hardware validado, y CertSecure Manager automatiza la emisión y renovación para que los certificados de cliente de corta duración nunca caduquen.
- Migrar y validar antes de la fecha de renovación: Trasladar cada dependencia de mTLS a certificados de cliente privados y probar el protocolo de enlace de extremo a extremo mucho antes de que el certificado público se renueve sin la EKU, de modo que el cambio esté planificado en lugar de ser provocado por una interrupción del servicio.
- Gestionar la infraestructura de clave pública privada como si fuera una infraestructura de producción: Mantenga un inventario de los certificados de cliente emitidos, garantice la propiedad y la rotación, y supervise la raíz privada para evitar que la nueva infraestructura de clave pública (PKI) se convierta en una fuente de confianza no gestionada. CertSecure Manager ofrece esta gobernanza desde una única plataforma, con un inventario actualizado de los certificados de cliente emitidos, además de información sobre la propiedad, la rotación y la supervisión.
Cómo puede ayudar la consultoría de cifrado
Superar el desafío de la autenticación de clientes se reduce a tres aspectos clave: identificar dónde se utilizan certificados públicos para mTLS, reemplazarlos con certificados de una CA privada controlada y automatizar la emisión para que los nuevos certificados de cliente se renueven automáticamente. Aquí es precisamente donde entra en juego la solución PKI-as-a-Service de Encryption Consulting . Proporciona una autoridad de certificación privada totalmente administrada que emite certificados de autenticación de clientes bajo su control, con el control de perfiles, la política de emisión y la gestión del ciclo de vida que requiere el mTLS interno, y sin la complejidad de crear y operar una CA desde cero.
En torno a la CA privada, este mismo proceso se basa en un conjunto coordinado de servicios de consultoría de cifrado, cada uno de los cuales desempeña un papel distinto:
- PKI-as-a-Service proporciona la autoridad de certificación privada totalmente administrada que emite certificados clientAuth bajo su control, con el control de perfiles, la política de emisión y la administración del ciclo de vida que necesita el mTLS interno, sin la carga de crear y administrar una CA desde cero.
- CBOM seguro Descubre todas las dependencias ocultas de mTLS en la confianza pública, catalogando cada certificado, las EKU que contiene y los sistemas que dependen de él, para que sepas el alcance exacto de lo que fallará y cuándo.
- Administrador de CertSecure Automatiza la emisión y renovación de certificados en autoridades de certificación públicas y privadas, y mantiene un inventario actualizado con información sobre la propiedad, la rotación y la supervisión, de modo que los certificados de cliente de corta duración nunca caducan y la infraestructura de clave pública privada permanece gobernada.
- HSM como servicio Establece como base la nueva raíz de confianza interna en hardware validado, protegiendo las claves de firma de la CA privada sin necesidad de implementar ni mantener nuevos dispositivos.
El principio fundamental es que la autenticación interna debe basarse en una infraestructura que usted controle, gobernada y automatizada, y desvinculada de las políticas de la CA pública, de modo que un cambio como el de clientAuth se convierta en un problema menor en lugar de una interrupción del servicio. Para evaluar su exposición y configurar mTLS con PKI privada antes de su próxima renovación, póngase en contacto con Encryption Consulting para solicitar un análisis de certificados y una evaluación de PKI privada.
Conclusión
El vencimiento de la EKU de clientAuth es un ejemplo clásico de cómo un atajo conveniente puede llegar a su fin. Reutilizar certificados TLS públicos para TLS mutuo funcionó durante años, pero la transición de la industria a jerarquías dedicadas y de propósito único ha puesto fin a esta práctica. Chrome dejará de confiar en los certificados públicos que incluyan la EKU de clientAuth; las jerarquías intermedias pasarán a ser exclusivas para servidores a partir del 15 de junio de 2026, y los certificados hoja a partir del 15 de marzo de 2027. Además, dado que varias CA eliminarán la EKU antes de lo previsto en 2026, mTLS, que depende de este atajo, dejará de funcionar en su próxima renovación, de forma silenciosa y sin previo aviso.
La solución es clara: identifique dónde depende de certificados públicos para la autenticación de clientes, implemente una infraestructura de clave pública (PKI) privada que pueda emitir certificados clientAuth libremente, ya que no se ve afectada por el cambio de confianza pública, separe la confianza del servidor y del cliente, y automatice la emisión para que los nuevos certificados de cliente se renueven automáticamente. Comience a identificar las dependencias ahora, ya que la fecha límite efectiva la establece la CA que renueva sus certificados, no una fecha específica. Implemente mTLS con PKI privada de forma planificada antes de que se produzca el cambio, y este se convertirá en una modernización planificada hacia una infraestructura que usted controla, en lugar de una interrupción inesperada.
