Cambio de política de EKU de Google Chrome

Aplicación de la EKU en Chrome en 2026 qué debe cambiar BFSI 

A partir del 15 de junio de 2026, los certificados TLS de confianza pública deben incluir la extensión EKU y afirmar solo id-kp-serverAuth. Chrome no lo es “ignorando EKU”; está aplicando jerarquías TLS de propósito único y certificados  solo con serverAuth. Si utiliza certificados de CA públicos para mTLS, autenticación de API o flujos de servidor a servidor, planifique una transición a PKI privada o PKI financiera específica del sector.

Lo que realmente está cambiando

• Jerarquías TLS de propósito único. Se espera que las CA públicas utilicen jerarquías dedicadas a la autenticación del servidor TLS (sin propósitos mixtos).
• Perfil del certificado Leaf del 15 de junio de 2026. Todos los certificados de suscriptor de TLS de confianza pública emitidos a partir del 15 de junio de 2026 deben incluir EKU y afirmar solo id-kp-serverAuth.
• Eliminación progresiva de clientAuth en TLS público. Los certificados TLS públicos serán solo serverAuth en el futuro.

Corrección de clave: Chrome no elimina ni ignora serverAuth. La política espera certificados exclusivos de serverAuth después del 15 de junio de 2026.

Lo que no está cambiando

• La PKI privada/empresarial está fuera de alcance. Los requisitos de Chrome se aplican a las PKI representadas por raíces en Chrome Root Store. Las jerarquías “empresariales”, “privadas” o “solo confiables localmente” no están sujetas a este requisito.
• Chrome nunca dependió de clientAuth EKU para validar sitios web. Ese punto a veces se malinterpreta como “EKU es ignorado” No lo es, Chrome todavía espera serverAuth para certificados  TLS públicos.

Por qué BFSI debería prestar atención

Las cargas de trabajo de BFSI a menudo reutilizan certificados CA públicos más allá de los navegadores:

• TLS mutuo (mTLS) para integraciones seguras de banco a banco o PSP
• Autenticación de API en ecosistemas de banca abierta
• Mensajería de servidor a servidor (limpieza/liquidación, informes, puertas de enlace)

Si está utilizando certificados TLS públicos que incluyen o dependen de clientAuth, esos patrones se romperán a medida que las CA públicas converjan en  TLS exclusivas de serverAuth. Cambie estos casos de uso a un fideicomiso privado (PKI empresarial) o una PKI financiera especialmente diseñada. Mantenga TLS público solo para HTTPS orientado al navegador.

Perspectivas regionales (guía rápida)

• Estados Unidos: Se espera una adopción más fuerte de arquitecturas sectoriales alineadas con PKI y NIST para la confianza interorganizacional.
• Europa: Alinear TLS y pilas de identidad con eIDAS/PSD2; mantener la confianza pública y privada claramente separadas. Utilice PKI privada para la autenticación del cliente/máquina.
• Medio Oriente y África: la rápida digitalización hace que este sea un buen momento para adoptar PKI y CLM privados desde el primer día, minimizando las interrupciones a medida que las CA públicas eliminan clientAuth de TLS.
• APAC: Con mandatos estilo RBI/MAS para una autenticación sólida, priorice la PKI privada y la automatización para escalar la banca digital de forma segura.

El camino a seguir: PKI privada y PKI sectorial

1. Mueva la autenticación del cliente/máquina fuera del TLS público. Utilice PKI privada para mTLS, identidad del dispositivo y autenticación de API que no sea del navegador. Mantenga certificados públicos exclusivos de serverAuth exclusivamente para HTTPS orientado al navegador.
2. Considere una PKI sectorial para finanzas Los programas de PKI de la industria para la confianza interorganizacional brindan políticas de nivel financiero e interoperabilidad fuera de los almacenes de confianza de los navegadores.
3. Automatice con CLM y aumente la criptoagilidad. Utilice CLM para separar certificados públicos de privados, automatizar renovaciones y prepararse para transiciones de PQC sin interrupciones.

Lista de verificación de acciones para BFSI (antes del 15 de junio de 2026)

• Inventarie todos los certificados utilizados para mTLS/API/servidor a servidor; identifique cualquier dependencia de certificados de confianza pública para la autenticación del cliente/máquina.
• Refactorización: reemplácelos con certificados de PKI privados y mantenga el TLS público solo para HTTPS orientado al navegador.
• Confianza en el segmento: imponer una separación estricta entre los certificados TLS públicos (solo ServerAuth) y los certificados de cliente/máquina privados.
• Automatice la emisión/renovación a través de CLM; monitoree los perfiles de EKU para evitar desviaciones.
• Plan para la preparación del PQC junto con esta migración.

Cómo puede ayudar eMudhra y AXERA

• Implementaciones privadas de PKI (iniciales o administradas): diseños listos para el regulador para mTLS, identidad de dispositivos y comunicaciones interbancarias.
• Interoperabilidad de nivel financiero: alineación de PKI sectorial para la confianza interorganizacional entre bancos, PSP e infraestructuras de mercado.
• CertiNext (CLM): automatización, criptoagilidad y renovaciones sin tiempo de inactividad en las capas de aplicaciones e infraestructura.
• Experiencia global en BFSI: implementaciones en América del Norte, Europa, MEA y APAC.

Ejemplos del mundo real (representativos)

• Institución financiera global: automatizó miles de renovaciones con CLM para eliminar el riesgo de interrupciones en las operaciones bancarias.
• Banco Central de Medio Oriente: Infraestructura de pagos nacionales asegurada con automatización de certificados.
• Telecomunicaciones con integraciones BFSI: se evitaron interrupciones en el flujo de API migrando a PKI privada para mTLS.

Por qué las instituciones del BFSI confían en eMudhra

• TSP y CA globales reconocidos y confiables en 100+ países
• Experiencia comprobada en PKI de grado BFSI y mandatos de cumplimiento
• CLM impulsado por automatización para eliminar errores humanos y tiempos de inactividad
• La criptoagilidad se adaptará sin problemas a los estándares de la era PQC
• Servicios de PKI gestionados escalables para reducir la sobrecarga operativa

Cuando los certificados sustentan el tejido de confianza de BFSI, eMudhra garantiza que permanezcan invisibles, confiables y siempre compatibles.

Conclusión

Se acerca el cambio de política EKU de Chrome. Ahora es el momento de evaluar su estrategia TLS, realizar la transición de casos de uso no relacionados con el navegador a PKI privada y adoptar la criptoagilidad para que su tejido de confianza permanezca invisible, confiable y siempre compatible.

Con AXERA Evita interrupciones inesperadas debido a certificados TLS vencidos.