Índice
¿Estás al tanto de que uno de los cambios más relevantes en los certificados SSL afecta directamente a la forma en que se autentican los usuarios y dispositivos en la red? Y lo que es más importante, ¿tienes claro qué significa exactamente el clientAuth EKU y, sobre todo, cómo su eliminación impactará en la seguridad y la operativa digital de tu empresa? Porque estos cambios además de redefinir los estándares técnicos, también van a transformar las estrategias de gestión de certificados y la arquitectura de las infraestructuras PKI que muchas organizaciones utilizan actualmente. Estéis preparados o no en tu empresa, que sepas que esto va a pasar.
Es por eso que, ante este escenario, es primordial entender con precisión qué es el clientAuth EKU, por qué se elimina y cuáles son las consecuencias para los distintos actores involucrados, desde empresas con ambientes mTLS hasta administradores de sistemas, equipos de seguridad y desarrolladores de software.
¿Qué es el clientAuth EKU?
El clientAuth EKU (Extended Key Usage o Uso Extendido de Clave para autenticación de cliente) es una extensión específica dentro de algunos certificados SSL que habilita a estos para autenticar tanto servidores, como a clientes en entornos de red. ¿Qué significa esto? Que permite validar la identidad de usuarios, máquinas o dispositivos frente a un servidor, siendo necesario en escenarios avanzados como la autenticación mutua TLS (mTLS) o la autenticación servidor a servidor.
Origen y evolución histórica del clientAuth EKU
Históricamente, esta extensión nació con los primeros estándares de certificados digitales X.509, aprobados en 1988 por organizaciones internacionales como la ISO y el CCITT. Estos estándares definieron un formato para que un certificado digital asociara una clave pública a una identidad de manera segura, y especificaron el uso de extensiones como el Extended Key Usage (EKU) para delimitar las funciones permitidas de cada certificado.
Dentro de esta estructura, el clientAuth EKU se creó para indicar que un certificado puede usarse para autenticar a clientes, mientras que el serverAuth EKU sirve para autenticar servidores. En etapas iniciales, algunas autoridades de certificación y proveedores añadían ambos EKU (cliente y servidor) en certificados SSL públicos y privados por defecto, facilitando que un único certificado asegurara conexiones HTTPS y, al mismo tiempo, autenticara clientes en procesos mutuos de verificación.
Función técnica y características del clientAuth EKU
El clientAuth EKU está identificado por un OID (Object Identifier) único 1.3.6.1.5.5.7.3.2, diferenciándose del serverAuth (OID 1.3.6.1.5.5.7.3.1). Esta extensión actúa como un indicador en navegadores, sistemas y servidores, señalando que un certificado puede autenticar clientes, otorgándole un rol activo adicional al tradicional de servidor.
Sin embargo, con la evolución de la industria y el aumento de complejidad en escenarios de autenticación, se cuestionó la viabilidad de mantener esta doble funcionalidad en un mismo certificado. Se detectaron riesgos de seguridad y dificultades operativas, especialmente en la gestión de infraestructuras PKI y la prevención de configuraciones erróneas.
Por ello, actualmente se está eliminando gradualmente la extensión clientAuth EKU de certificados SSL públicos, siguiendo directrices de programas raíz como el Chrome Root Program y de autoridades certificadoras líderes como SSL.com, Sectigo, DigiCert y, también, nosotros mismo. Este cambio busca acotar y especializar los usos de los certificados SSL para aumentar la seguridad de las conexiones y mejorar la eficiencia en la gestión y automatización.
¿Por qué se elimina el clientAuth EKU?
Tal como dice la expresión, lo que no te mata te hace más fuerte, y en este caso, la eliminación del clientAuth EKU busca fortalecer la seguridad digital y adaptarse a nuevas normativas y estándares internacionales. Las grandes Autoridades de Certificación (CAs) como puede ser la anteriormente mencionada Sectigo, por citar alguna de ellas, junto con programas raíz como Chrome Root Program, están adoptando esta medida que entrará en vigor completamente en junio de 2026, y que desde ya, os confirmamos que afectará al 100% de los nuevos certificados SSL/TLS públicos emitidos.
Mejora de la seguridad
Hay que tener en cuenta que limitar los certificados SSL a solo la autenticación de servidor (serverAuth) reduce la superficie de ataque, lo que nos otorga un control más granular (detallado y específico, vamos) y seguro sobre el acceso a sistemas y datos. Sectigo reporta que un 15% de los incidentes relacionados con autenticación detectados en empresas son atribuibles a la inclusión del clientAuth EKU en certificados públicos, con un potencial de reducción del 25% en vulnerabilidades tras la eliminación.
Además, el 80% de las grandes organizaciones ha implementado o planea implementar la separación clara de funciones en sus infraestructuras PKI para cumplir con exigencias regulatorias como GDPR y PCI DSS. Ya lo hemos comentado pero nunca está de más volver a recordar que Google Chrome, con más del 65% del mercado global, comenzará a bloquear certificados con clientAuth EKU a partir de junio de 2026, para impulsar así, la necesidad de adaptación inmediata.
Reducción del riesgo de ataques
Para quien no esté familiarizado con el tema, el hecho de que un certificado SSL tenga simultáneamente las extensiones clientAuth y serverAuth facilita, favorece, potencia o cómo quieras llamarlo, los problemas de seguridad, especialmente en entornos empresariales que utilizan autenticación mutua TLS (mTLS) o autenticación entre servidores. En estos escenarios, tanto cliente como servidor deben validarse mutuamente usando certificados digitales específicos.
Este diseño flexible tiene la consecuencia no deseada de que un mismo certificado, diseñado para autenticar servidores, pueda ser empleado incorrectamente para autenticar clientes, algo que genera confusión y configuraciones erróneas. Esto impulsa los ataques Man-in-the-Middle (MitM), y, con los datos por delante, podemos decir que ya se ha reportado que hasta el 27% de estos ataques en entornos corporativos estuvieron vinculados a certificados multiuso con clientAuth EKU.
Antes del cambio (hasta el 15 de septiembre de 2025):
- Se detectó un aumento del 18% en errores humanos relacionados con la gestión inapropiada de certificados con clientAuth EKU.
- Más del 70% de las infraestructuras PKI no lograban segmentar roles ni auditar accesos adecuadamente, aumentando así el riesgo de brechas y sacando a la luz un cumplimiento normativo insuficiente.
Fases del cambio (a partir del 15 de septiembre):
- Sectigo comenzará a emitir nuevos certificados sin incluir por defecto el clientAuth EKU.
- DigiCert seguirá una línea similar desde el 1 de octubre de 2025.
- La eliminación completa será efectiva para mayo de 2026.
- Y, como ya hemos comentado anteriormente, a partir del 15 de junio de 2026, Google Chrome no aceptará certificados públicos que contengan el clientAuth EKU.
¿Qué esperar después del cambio? (desde mediados de 2026):
- Se prevé una reducción del 25% en vulnerabilidades relacionadas con errores de autenticación.
- Se mejorará significativamente la trazabilidad y el cumplimiento normativo.
- Se fortalecerá la separación de funciones y el principio de mínimos privilegios, pilares claves de la ciberseguridad moderna.
Impulsar la automatización
La eliminación del clientAuth EKU facilita la automatización en la gestión de certificados, lo que representa un cambio positivo para la eficiencia y seguridad operativa. Al reducir la complejidad técnica de los certificados, es posible integrar soluciones automatizadas que minimizan errores humanos y agilizan el ciclo de vida completo del certificado.
Entre las funciones clave de estas plataformas se incluyen:
- Descubrimiento centralizado de todos los certificados desplegados en infraestructuras heterogéneas, internas y externas.
- Emisión y renovación automática con protocolos estándar como ACME, para evitar expiraciones inesperadas.
- Integración con aplicaciones, servidores, dispositivos de red y entornos DevOps para un despliegue y administración sin fisuras.
- Auditorías continuas y alertas proactivas para mantener la seguridad y cumplimiento normativo.
Hoy en día existen múltiples plataformas líderes en automatización de PKI y certificados SSL, que ofrecen soluciones adaptadas a distintos tamaños y niveles técnicos de organizaciones. Algunas de las más destacadas son:
- DigiCert Trust Lifecycle Manager (TLM): Plataforma avanzada que automatiza el ciclo de vida completo con flujos integrados, descubrimiento sin agentes y soporte para múltiples CA.
- GlobalSign Atlas: Orientada a entornos multinube y DevOps, con APIs y soporte ACME para integración flexible y control multi-CA.
- Sectigo Certificate Manager (SCM): Solución funcional y económica, ideal para empresas que requieren automatización básica con soporte ACME y multi-CA.
- Certificado de Sello Electrónico de Camerfirma: Otra de nuestras soluciones digitales cualificadas que permite a empresas y entidades realizar firmas electrónicas automáticas sin incorporar datos personales de representantes. Especialmente indicado para procesos desasistidos y automatizados como generación de facturas, recibos, nóminas o registros de mercancías. Asociado a una clave custodiada por una máquina que garantiza integridad, autenticidad y no repudio. Además, es compatible con protocolos seguros SSL y Web Services. Lo tenéis disponible en formatos software y hardware con duración desde 1 hasta 4 años. Esta herramienta que ponemos a tu alcance, representa un avance estratégico para cumplir con el cambio normativo que elimina el clientAuth EKU, lo que impulsa la especialización, seguridad y automatización necesaria en la gestión digital actual.
| Aspecto | Antes | Después eliminación clientAuth EKU |
| Coste promedio de renovación | 100% base | Reducción promedio del 20% |
| Tiempo promedio despliegue | 10 días | Reducción hasta 7 días (30% menos) |
| Porcentaje de errores humanos | 12% | Disminución a aproximadamente 7% |
| Compatibilidad con sistemas PKI | Limitada | Alta, optimización con automatización |
| Complejidad auditoría | Alta | Simplificada, con roles claros y separados |
Y ojo, porque estas eficiencias operacionales conllevan un ahorro estimado del 15% anual en costes de gestión para grandes organizaciones, además de minimizar los riesgos por errores humanos y mejorar la resiliencia de la infraestructura digital.
¿A quién afecta este cambio en los certificados SSL?
Este cambio implica modificaciones importantes para distintos profesionales y organizaciones que utilizan certificados SSL en sus arquitecturas, particularmente aquellos en entornos con autenticación mutua o sistemas que combinan funciones cliente-servidor.
Empresas y organizaciones que utilizan la autenticación mutua (mTLS)
Las organizaciones que aplican mTLS para proteger accesos a APIs, plataformas SaaS o servicios en la nube se verán en la necesidad de segmentar sus certificados en distintas jerarquías para servidor y cliente. La eliminación del clientAuth EKU en certificados públicos obliga a migrar a soluciones PKI privadas o separadas para mantener la autenticación cliente.
Administradores de sistemas
Los administradores deberán afrontar cambios en la gestión de certificados públicos para garantizar interoperabilidad y cumplimiento con nuevos estándares.
Desafíos antes del cambio:
- Control de certificados multiuso con clientAuth EKU.
- Complejidad en la renovación y configuración de certificados.
- Dificultades para segmentar roles en la infraestructura.
Desafíos tras el cambio:
- Identificación y reemplazo de certificados con clientAuth EKU.
- Adaptación a infraestructuras PKI segmentadas.
- Actualización de scripts y automatizaciones.
Equipos de seguridad IT
La nueva normativa impulsa un aumento en la seguridad al especializar los certificados pero implica la necesidad de auditorías más frecuentes y controles específicos para auditoría y trazabilidad.
Desarrolladores y arquitectos de software
Deben revisar y adaptar sus modelos de autenticación para garantizar compatibilidad con certificados serverAuth exclusivos y migrar esquemas mTLS hacia infraestructuras PKI privadas.
| Recomendación | Herramientas compatibles |
| Renovación y gestión automatizada | Certbot, ACME, Let’s Escrypt Automation |
| Gestión PKI privada | OpenXPKI, EJBCA, Microsoft AD CS |
| Desarrollo mTLS segmentado | Bibliotecas TLS compatibles con certificados diferenciados |
| Auditoría y monitoreo | CertStream, ELK Stack, herramientas SIEM |
¿Cómo preparar el cambio de certificados SSL?
Para evitar interrupciones y garantizar la continuidad, la planificación y ejecución de un plan ordenado es indispensable para alinear los sistemas al cambio de eliminación del clientAuth EKU en certificados SSL. En Camerfirma, como expertos en certificación digital, te recomendamos enfocar este proceso en tres pasos esenciales para una transición segura y eficiente.
Audita tus certificados SSL para identificar los afectados
Un inventario completo y actualizado es el primer paso que debes dar para detectar certificados con clientAuth EKU antes de las fechas límite. Ten en cuenta que la auditoría debe contemplar ámbitos tecnológicos y organizativos, para asegurarnos una gestión adecuada de la renovación y actualización. Para que te sea más cómodo y fácil, estas son algunas prácticas recomendadas:
- Realizar un escaneo exhaustivo en toda la infraestructura TI para identificar certificados que contengan el clientAuth EKU.
- Clasificar certificados por tipos, emisores, periodo de validez y sistemas que los utilizan.
- Verificar compatibilidad de aplicaciones y servicios con la eliminación del clientAuth EKU.
- Controlar certificados instalados en dispositivos, balanceadores, proxies, y servidores.
- Detectar scripts y procesos automatizados que incluyan solicitudes con clientAuth EKU.
- Establecer reportes periódicos para seguimiento y planificación de renovaciones anticipadas.
Recuerda que en Camerfirma te ofrecemos soluciones avanzadas para la centralización y gestión automatizada de certificados, para así hacerte la vida más fácil y facilitarte la realización de estas auditorías y mejorar así, la trazabilidad para que ningún certificado quede fuera del control.
Reemplaza los certificados SSL que no cumplen con la normativa
El cambio requiere emitir nuevos certificados que incluya exclusivamente serverAuth EKU y actualizar todos los sistemas relacionados, para mantener la seguridad y compatibilidad operativa. De nuevo, en Camerfirma podemos ayudarte, poniendo a tu disposición una asesoría técnica y servicios de emisión adaptados a esta nueva normativa.
Pasos técnicos recomendados:
- Inventariar certificados con clientAuth EKU.
- Identificar sistemas o servicios que dependen de autenticación mutua o serverAuth simultáneo.
- Planificar y calendarizar la renovación anticipada de certificados problemáticos.
- Revisar y actualizar configuraciones, scripts y sistemas automatizados vinculados.
- Validar la correcta instalación de los nuevos certificados con auditorías específicas.
- Capacitar al equipo técnico para el mantenimiento y gestión futuros.
Automatización eficiente de los certificados SSL
Con la eliminación del clientAuth EKU, la automatización de procesos se vuelve más sencilla y segura. Sobre todo, si tenemos en cuenta que el protocolo ACME (Automatic Certificate Management Environment), ampliamente adoptado, facilita la gestión continua minimizando errores y reduciendo tiempos.
Parámetros comparativos:
| Parámetro | Antes | Después |
| Tiempo promedio renovación | 10 días | 7 días (reducción 30%) |
| Porcentaje de errores | 12% errores humanos | 7% errores (reducción 42%) |
| Integración automatizada | Parcial y manual | Completa con ACME y APIs |
A tener en cuenta que estas mejoras operativas reducen costes y elevan la fiabilidad, lo que, a su vez, contribuye a un entorno más resiliente frente a amenazas y fallos. Vamos, un valor esencial para las organizaciones del siglo XXI.
Considera disponer de una PKI privada
Para organizaciones con necesidades específicas de autenticación mutua o autenticación servidor a servidor, implementar una PKI privada proporciona ventajas estratégicas fundamentales que complementan los certificados públicos.
Veamos algunas de ellas:
- Control absoluto sobre las políticas de emisión, revocación y administración.
- Posibilidad de incluir EKU individuales como clientAuth para usos internos.
- Adecuación flexible a requisitos regulatorios y corporativos específicos.
- Integración sencilla con entornos on-premise y nube privada.
- Mayor autonomía, independencia y reducción de dependencia de CAs públicas.
- Facilita cumplir normativas y auditorías internas y externas más exigentes.
Para finalizar nos gustaría decir que hay que ver este cambio, como lo que es, una oportunidad para modernizar y hacer más segura la gestión de certificados digitales. ¿Y qué mejor que hacerlo con Camerfirma como socio?
