Resumen de gestión
Esta publicación de blog aborda los próximos cambios con respecto a la eliminación del Uso de clave extendida (EKU) de autenticación de cliente de los certificados SSL/TLS de confianza pública , un cambio impulsado por preocupaciones de seguridad y la necesidad de roles más claros en las operaciones criptográficas.
A partir de septiembre de 2025, las principales autoridades de certificación (CA) comenzarán a eliminar gradualmente el EKU de autenticación de cliente de la emisión de certificados públicos, y el plazo final para esta extensión será a mediados de 2026.
El objetivo principal de estos cambios, según el foro CA/B, es reducir los riesgos de seguridad asociados a los certificados de doble propósito e implementar directrices más estrictas para su uso. Las organizaciones que dependen de TLS mutuo o de la autenticación de cliente deberán adoptar certificados de cliente dedicados para garantizar el cumplimiento normativo y mantener la seguridad de sus operaciones. Esta entrada de blog describe las implicaciones de estos cambios, los beneficios de seguridad que ofrecen y las medidas prácticas que las organizaciones deben tomar para prepararse para esta transición.
Introducción
La seguridad y el cumplimiento normativo son consideraciones primordiales para las organizaciones que utilizan certificados criptográficos para la autenticación y la comunicación. La eliminación del Uso Extendido de Clave (EKU) de Autenticación de Cliente de los certificados SSL redefinirá su uso, especialmente en escenarios de TLS mutuo ( mTLS ). Esta entrada de blog ofrece una descripción general completa del EKU de Autenticación de Cliente, sus implicaciones y el cronograma para su implementación gradual . Al comprender estos próximos cambios, las organizaciones pueden tomar las medidas necesarias para garantizar su cumplimiento normativo y seguridad, a la vez que mejoran la claridad de sus prácticas de gestión de certificados.
¿Qué es el uso extendido de clave de autenticación de cliente (EKU)?
La autenticación de cliente EKU (Extended Key Usage) es una extensión de certificado que designa un certificado digital para autenticar un cliente (como un usuario o dispositivo) en un servidor, comúnmente utilizado en escenarios de TLS mutuo ( mTLS ).
Es una función añadida a los certificados digitales que especifica el uso de una clave pública. Crea una lista clara de usos aprobados, garantizando que la clave solo se utilice para ciertas tareas criptográficas. Los usos permitidos se identifican mediante números únicos llamados Identificadores de Objeto (OID), que categorizan cada propósito específico, como la firma de código, la autenticación de servidor, la autenticación de cliente o el correo electrónico seguro.
Al verificar un certificado, se consulta el EKU para encontrar el OID. Al incluir la extensión EKU, una autoridad de certificación (CA) limita el uso del certificado, vinculando cada propósito a un OID específico. A continuación, se muestran algunos ejemplos:
- Autenticación de servidor web TLS : El certificado se puede usar para verificar un servidor, como un sitio web HTTPS. El OID para la autenticación del servidor es 1.3.6.1.5.5.7.3.1 .
- Autenticación de cliente web TLS : Un cliente puede usar el certificado para verificarse ante un servidor, como en TLS mutuo. El OID para la autenticación de cliente es 1.3.6.1.5.5.7.3.2 .
Normalmente, los navegadores y servidores solo requieren el EKU serverAuth para configurar una conexión HTTPS segura. Sin embargo, muchos certificados de servidor TLS han incluido históricamente tanto el EKU serverAuth como el clientAuth .
Uso de EKU en PKI
- Los EKU restringen las funciones permitidas de un certificado, como la autenticación del servidor, la autenticación del cliente, la firma de código o la protección del correo electrónico.
- Cuando se requiere autenticación del cliente (por ejemplo, mTLS ), la presencia del EKU clientAuth indica a un sistema que se puede confiar en el certificado para ese propósito.
- Históricamente, algunos certificados TLS de servidor incluían EKUs serverAuth y clientAuth , pero esta práctica se está dejando de utilizar para reducir los riesgos de seguridad y aclarar los roles criptográficos.
Cambios en la industria
- A partir de 2025-2026, las principales CA y los programas raíz del navegador (como Google Chrome) requerirán la separación de los EKU de autenticación del servidor y del cliente, lo que significa que los certificados TLS públicos solo deben tener serverAuth EKU, y no clientAuth , para evitar el uso indebido y mejorar la seguridad.
- Las organizaciones que necesitan autenticación de clientes ahora necesitarán certificados de cliente dedicados con el EKU clientAuth .
Impacto de la eliminación del EKU de autenticación de cliente en los certificados SSL
Eliminar el EKU de autenticación de cliente de los certificados SSL significa que los futuros certificados de servidor público se utilizarán estrictamente para la autenticación del servidor y no para fines del lado del cliente como TLS mutuo ( mTLS ).
Impactos en el uso del certificado SSL
- Los certificados de servidor emitidos después de mediados de 2025 solo incluirán el EKU serverAuth , lo que evitará cualquier uso ambiguo o inseguro como credenciales de autenticación del cliente.
- Los certificados existentes (emitidos antes de las fechas límite) siguen siendo válidos hasta su vencimiento; no se revocarán retroactivamente.
- Los servidores web HTTPS estándar no se ven afectados, ya que los navegadores (como Chrome y Firefox) solo verifican la autenticación del servidor e ignoran el EKU de clientAuth para el acceso al sitio web.
- Para los entornos que dependen de mTLS o de la autenticación de cliente/dispositivo con certificados SSL públicos, en el futuro se requerirá un certificado de autenticación de cliente independiente .
Beneficios de seguridad y cumplimiento
- Reduce los riesgos de mal uso y uso dual no intencional, mejorando la separación entre Internet público y las infraestructuras PKI internas.
- Alinea a todas las autoridades de certificación (CA) y navegadores bajo pautas más estrictas que admiten certificados seguros y de propósito único.
Pasos para las organizaciones
- Revise los inventarios de certificados para determinar qué sistemas dependen de certificados de servidor/ de uso dual para la autenticación del cliente.
- Actualice los sistemas para utilizar certificados de cliente dedicados (con clientAuth EKU) para TLS mutuo, autenticación de dispositivos o conexiones de servidor a servidor.
- Modificar los procesos/la documentación de solicitud de certificados para que las renovaciones futuras cumplan con las nuevas políticas y eviten interrupciones del servicio.
Tabla de efectos
| Caso de uso |
Cambio después de la eliminación de EKU |
Acción requerida |
| Sitios web HTTPS |
Sin impacto; el SSL estándar continúa |
Ninguno |
| TLS mutuo ( mTLS ) |
Los certificados de servidor no pueden autenticar a los clientes |
Cambiar a certificados de cliente dedicados |
| Sistemas heredados/empresariales |
Certificados de doble uso rechazados; posible incompatibilidad |
Actualice los sistemas, utilice certificados de cliente dedicados |
La eliminación del EKU de autenticación del cliente es una medida impulsada por la seguridad para garantizar que los certificados SSL se utilicen para los fines previstos, con un impacto mínimo para la mayoría de los usuarios, excepto aquellos que dependen de mTLS o entornos de autenticación mixta.
¿Cuándo dejarán las CA de emitir certificados con EKU de autenticación de cliente?
Las autoridades de certificación (CA) comenzarán a eliminar gradualmente los certificados SSL/TLS con EKU de autenticación de cliente a partir de septiembre de 2025, con fechas límite finales a mediados de 2026, según la CA.
Principales aspectos destacados de la cronología de CA
- 15 de septiembre de 2025: la mayoría de las CA principales, incluidas Sectigo y Trustico , dejarán de incluir el EKU de autenticación de cliente de forma predeterminada. en nuevos certificados SSL.
- 1 de octubre de 2025: DigiCert dejará de emitir certificados TLS públicos con ClientAuth EKU de forma predeterminada. Se podrán atender solicitudes especiales hasta el 1 de mayo de 2026, fecha a partir de la cual ningún certificado público podrá incluir ClientAuth EKU.
- 13 al 15 de mayo de 2026: Fechas límite finales para toda la industria; todas las CA principales (incluidas Let’s Encrypt, Sectigo , DigiCert y Trustico ) eliminarán de forma permanente el EKU de autenticación de cliente de la nueva emisión de certificados SSL/TLS públicos, incluidas las renovaciones y reemisiones.
- 15 de junio de 2026: el programa raíz de Google Chrome solo confiará en certificados SSL públicos con serverAuth EKU y rechazará cualquiera con ClientAuth EKU a partir de esta fecha.
Tabla de resumen
| Nombre de CA |
Fecha de finalización predeterminada |
Fecha límite estricta |
| Sectigo |
15 de septiembre de 2025 |
15 de mayo de 2026 |
| Certificado digital |
1 de octubre de 2025 |
1 de mayo de 2026 |
| Vamos a encriptar |
principios de 2026 |
13 de mayo de 2026 |
| Trustico |
15 de septiembre de 2025 |
15 de mayo de 2026 |
Después de estos plazos, ningún certificado SSL/TLS público nuevo o renovado de las principales CA contendrá el EKU de autenticación de cliente, lo que marca la transición de toda la industria.
¿Qué beneficios de seguridad se obtienen al eliminar ClientAuth EKU?
Según el foro CA/B, eliminar el EKU de ClientAuth de los certificados SSL de confianza pública aporta varios beneficios de seguridad clave al reforzar la especificidad del propósito del certificado y reducir los riesgos de mal uso o configuración incorrecta.
Separación de funciones de confianza
- Los certificados de servidor público se utilizarán estrictamente para la autenticación del servidor, no para la autenticación del cliente o dispositivo.
- Esto minimiza la posibilidad de que los certificados se reutilicen más allá de su función prevista, cumpliendo el principio del mínimo privilegio.
Riesgo reducido de configuración incorrecta
- Algunos sistemas anteriormente aceptaban cualquier certificado con un EKU ClientAuth para la autenticación del cliente, lo que generaba un posible acceso no autorizado si se confiaba por error en un certificado de servidor público.
- Restringir los EKU a sus usos previstos hace que la arquitectura de PKI sea más clara y más sólida para el mantenimiento y las auditorías.
Mejora de la higiene y el cumplimiento de la PKI
- La implementación de jerarquías de certificados separadas para los roles de servidor y cliente alinea a las autoridades de certificación (CA) con los requisitos del navegador y los estándares PKI modernos.
- Reduce la complejidad y la superficie de ataque de los certificados multipropósito, lo que facilita la gestión y la protección de las implementaciones de PKI públicas y privadas.
Prevención del abuso de certificados multipropósito
- Los certificados de uso mixto (con EKUs serverAuth y clientAuth ) pueden ser objeto de abuso si se utilizan en esquemas de autenticación no previstos, lo que podría facilitar el movimiento lateral o la escalada de privilegios.
- Al requerir certificados separados para cada propósito, las organizaciones pueden monitorear, auditar y controlar mejor los escenarios de acceso sensibles.
Tabla de resumen
| Beneficio de seguridad |
Descripción |
| Separación de roles (menor privilegio) |
Evita que los certificados se utilicen fuera del ámbito |
| Reduce el riesgo de configuración incorrecta |
Elimina la superposición accidental de EKU de cliente/servidor |
| Mejora la arquitectura PKI |
Permite una clara separación de PKI y la aplicación de políticas |
| Reduce la superficie de ataque |
No permite el acceso no deseado a través de certificados multipropósito |
En resumen, eliminar ClientAuth EKU de los certificados SSL del servidor fortalece la seguridad al aclarar el uso del certificado, garantizar el cumplimiento y reducir el riesgo de que los certificados públicos se utilicen indebidamente para escenarios de autenticación de clientes sensibles.
¿Cómo preparar sus sistemas para el cronograma de desuso de EKU?
Para preparar los sistemas para el cronograma de desuso del EKU de autenticación de cliente , las organizaciones deben tomar medidas proactivas para garantizar la continuidad de las operaciones seguras y el cumplimiento para las fechas límite de 2025-2026.
Pasos de preparación
- Inventario de certificados actuales y su uso
- Audite todos los certificados SSL/TLS existentes para identificar cuáles tienen EKU de autenticación de cliente incluido .
- Determinar qué aplicaciones dependen de estos certificados para la autenticación del cliente (por ejemplo, TLS mutuo, autenticación del dispositivo).
- Determine si estas aplicaciones que requieren certificados públicos de confianza para ServerAuth y ClientAuth admiten la configuración de certificados (y claves) independientes para ClientAuth y ServerAuth, y de qué manera. De no ser así, contacte al proveedor de la aplicación cuando esta función esté disponible.
- Plan para la segmentación de certificados
- Separe las funciones de autenticación del cliente y del servidor mediante el uso de certificados dedicados para cada propósito.
- Obtenga certificados de cliente con ClientAuth EKU estrictamente para la autenticación del cliente y certificados de servidor con ServerAuth EKU únicamente.
- Actualizar sistemas y aplicaciones
- Modificar el software del cliente y del servidor para admitir certificados distintos para TLS mutuo y otros métodos de autenticación de clientes.
- Asegúrese de que las aplicaciones validen correctamente los valores EKU para evitar aceptar certificados incorrectos.
- Ajustar los procesos de gestión de certificados
- Actualizar las políticas internas y la documentación para reflejar las nuevas restricciones en el uso de EKU.
- Coordinar con las CA para la emisión de certificados sin ClientAuth EKU en certificados de servidor después de las fechas límite.
- Probar y validar
- Realice pruebas con los cambios de certificado planificados en entornos de prueba o desarrollo antes del lanzamiento a producción.
- Verifique que todos los flujos de autenticación, incluido TLS mutuo, funcionen correctamente con las nuevas configuraciones de certificado.
- Comunicar los cambios
- Informar a las partes interesadas, incluidos TI, equipos de seguridad y propietarios de aplicaciones sobre el impacto de la desuso de EKU.
- Proporcionar capacitación u orientación sobre el manejo de nuevos certificados y prácticas de PKI.
Tabla de resumen
| Acción |
Descripción |
| Inventario de certificados |
Identificar certificados con ClientAuth EKU |
| Utilice certificados dedicados |
Roles de cliente y servidor separados con EKU relevantes |
| Actualizaciones del sistema/aplicación |
Apoyar y hacer cumplir el uso de certificados específicos de EKU |
| Ajuste de políticas/procesos |
Reflejar la desestimación de EKU en las políticas de emisión/renovación |
| Pruebas y validación |
Confirmar la funcionalidad con nuevas configuraciones de certificados |
| Comunicación con las partes interesadas |
Educar a los equipos sobre los cambios y el cumplimiento de EKU |
Al seguir esta hoja de ruta, las organizaciones pueden minimizar las interrupciones operativas y mantener una sólida postura de seguridad de PKI durante la transición de desuso del EKU de autenticación de cliente.
Información específica para clientes de KeyTalk
La solución de gestión de certificados y claves de KeyTalk permite la renovación automática de certificados (y claves privadas) y proporciona los medios para retransmitir, instalar y configurar automáticamente estos certificados en su punto final de destino para una aplicación de destino.
Se recomienda a los clientes de KeyTalk que necesiten certificados ClientAuth de confianza pública que:
- Cree una nueva plantilla de certificado dedicada para solicitar certificados ClientAuth de confianza pública. La forma más sencilla es copiar su plantilla de certificado multipropósito y cambiar el producto a certificado ClientAuth para la CA pública correspondiente. No olvide conectar su nueva plantilla de certificado a la autoridad de registro de la base de datos interna.
- Defina manualmente los FQDN para las aplicaciones que necesitan certificados ClientAuth como KeyTalk SEAT, o cree estos automáticamente cuando se soliciten nuevos certificados autenticados.
- Pruebe si la inscripción es exitosa y si su KeyTalk CKMS obtuvo el tipo correcto de certificado.
- Habilite ACME cuando corresponda para su nueva plantilla de certificado ClientAuth y anote la URL única del servidor ACME de KeyTalk
- Configure, cuando corresponda, sus agentes ACME existentes que se ejecutan en los puntos finales que alojan las aplicaciones que necesitan el certificado ClientAuth adicional, para solicitar un certificado adicional proveniente de la URL ACME recientemente habilitada.
- Configure, cuando corresponda, sus agentes empresariales KeyTalk existentes que se ejecutan en los puntos finales que alojan las aplicaciones que necesitan el certificado ClientAuth adicional, para solicitar un certificado adicional proveniente de la plantilla de certificado recientemente habilitada y, cuando sea necesario, actualice los scripts de PowerShell o Bash conectados para aplicar correctamente el certificado ClientAuth obtenido a la aplicación de destino
- Pruebe si los certificados ClientAuth automatizados se obtienen correctamente y se aplican correctamente a sus aplicaciones de destino.
¿Tiene preguntas sobre este artículo o sobre cómo KeyTalk CKMS le ayuda a simplificar la gestión y automatización de certificados digitales? Nuestro equipo de soporte está disponible las 24 horas, los 7 días de la semana para ayudarle y guiarle en la implementación de una arquitectura PKI totalmente automatizada a través de correo electrónico o nuestra página de contacto.
El equipo de KeyTalk
