Chrome dejará de aceptar clientAuth en certificados SSL/TLS: ¿Qué implica para los desarrolladores?

Chrome dejará de aceptar certificados SSL con autenticación de cliente desde junio de 2026

Google ha realizado cambios en su política de seguridad (Chrome Root Store v1.6). A partir del 15 de junio de 2026, no se aceptarán certificados SSL/TLS públicos que también se utilicen para autenticar a los clientes (clientAuth), lo cual podría afectar la compatibilidad con Chrome.

¿Qué cambia?

Cuando Chrome deje de aceptar certificados SSL/TLS públicos que incluyan la extensión de uso de clave para autenticación de cliente (clientAuth), se producirán cambios técnicos y operativos importantes en la manera en que se emiten, implementan y validan los certificados en sitios web y sistemas que dependen de esta funcionalidad.

La transición inicia el 15 de junio de 2025 y se aplicará por completo un año después.

Cambios clave

1. Restricción de uso de EKU en certificados públicos

• Chrome (a través de su política Chrome Root Store v1.6) solo confiará en certificados públicos con la EKU serverAuth.
• Ya no se permitirá que un certificado público combine los usos de serverAuth y clientAuth.

2. Fin del soporte para jerarquías mixtas (PKI híbrida)

• Certificados emitidos desde una jerarquía que permita simultáneamente la autenticación de servidor y cliente dejarán de ser confiables en Chrome.
• Esto afecta a las infraestructuras de clave pública (PKI) que no separen claramente los propósitos de cada certificado.

¿A quien afecta este cambio?

1. Empresas que implementan autenticación mutua (mTLS) en entornos públicos

• Organizaciones que requieren que los clientes (usuarios, aplicaciones o dispositivos) presenten certificados para autenticarse ante servicios públicos, como APIs o plataformas SaaS.
• Chrome ya no aceptará certificados que combinen serverAuth y clientAuth, lo que romperá esquemas mTLS que no estén adecuadamente segmentados.

2. Autoridades Certificadoras (CAs) y operadores de PKI

• Las CAs públicas que actualmente emiten certificados con ambos EKU (serverAuth + clientAuth) deberán revisar y modificar sus políticas de emisión.
• Las jerarquías de certificación (PKI) mixtas que no separen roles de autenticación tendrán que ser rediseñadas para cumplir con los nuevos lineamientos de Chrome Root Store.

3. Administradores de sistemas y equipos de seguridad IT

• Deberán auditar los certificados desplegados en servidores, servicios, balanceadores y dispositivos que usen certificados públicos.
• Necesitarán migrar a certificados exclusivamente serverAuth y reconfigurar las soluciones que dependan de mTLS, como firewalls, proxies, gateways o servicios cloud.

4. Desarrolladores y arquitectos de soluciones

• Aquellos que diseñen sistemas que involucren la autenticación cliente mediante certificados deberán adaptar su arquitectura para cumplir con la nueva separación de roles entre certificados públicos (para servidores) y privados (para clientes).
• Esto puede implicar usar certificados privados/autofirmados para los clientes en lugar de certificados públicos.

¿A quién no afecta directamente?

• Sitios web comunes que solo usan HTTPS para cifrado y no emplean autenticación de cliente.
• Certificados emitidos por PKI privadas no visibles públicamente (por ejemplo, dentro de redes internas).
• Clientes o usuarios finales que solo navegan por sitios seguros y no participan en mTLS o aplicaciones corporativas avanzadas.

¿Qué hacer?

Es fundamental tomar acciones preventivas desde ahora para asegurar la continuidad de tus servicios y evitar errores de conexión en los navegadores.

1. Audita tus certificados actuales

• Identifica si estás utilizando certificados públicos que incluyen el uso extendido de clave (Extended key usage, EKU) para clientAuth.
• Verifica especialmente certificados usados en:Autenticación mutua (mTLS)
• APIs públicas seguras
• Aplicaciones web corporativas con login por certificado

2. Reemite los certificados afectados

• Solicita a tu Autoridad Certificadora (CA) la emisión de certificados exclusivamente con el EKU serverAuth si se usarán en servidores públicos.
• Evita certificados “multiuso” que mezclen funciones de cliente y servidor.

3. Rediseña tu infraestructura PKI si usas mTLS

Por qué:

• Las PKI que permiten emitir certificados combinados (clienAuth + serverAuth) ya no serán compatibles con Chrome.

Solución:

• Separa la infraestructura:Una jerarquía PKI para certificados públicos de servidor
• Otra jerarquía o CA privada para certificados de cliente, usada internamente o en entornos controlados.

4. Actualiza tus procesos de autenticación cliente

Si utilizas mTLS en interfaces públicas o accesibles desde navegadores, considera las siguientes alternativas:

Recomendaciones

Planifica tu migración

Cronograma sugerido:

Capacita a tu equipo técnico

• Asegúrate de que los equipos de seguridad, infraestructura, y desarrollo comprendan el cambio.
• Comparte esta política con tus proveedores de servicios o socios tecnológicos que trabajen con certificados.