¿Por qué GoDaddy elimina ClientAuth EKU y realiza la transición a la jerarquía raíz R1 para la emisión de TLS DV?
A partir del 15 de junio de 2026, los certificados SSL/TLS de confianza pública emitidos para uso de servidor ya no podrán incluir el uso de clave extendida de “Autenticación de cliente” (EKU: clientAuth). Estos son los puntos clave para comprender:
- El cambio es parte de la actualización de la política del programa raíz de Chrome: los nuevos certificados deben incluir solo el EKU de “Autenticación del servidor”.
- Chrome no confiará en los nuevos certificados públicos emitidos después de esa fecha que incluyan clientAuth.
- Los certificados emitidos con clientAuth antes del 15 de junio de 2026 no se ven afectados por este cambio y seguirán siendo válidos hasta que caduquen o sean revocados.
- Los certificados de CA privada (para uso interno) no se ven afectados por este cambio & mdash; solo se aplica a los certificados de confianza pública.
En resumen: si tu organización usa certificados TLS públicos para la autenticación del cliente (a través de clientAuth EKU), deberás actuar antes del 15 de junio de 2026 . Para el uso estándar de TLS del sitio web (solo autenticación del servidor), este cambio no requiere acción. Sin embargo, es un recordatorio oportuno para revisar tu certificado de uso, separar las funciones de manera apropiada y asegurarte de estar alineado con el modelo de confianza en evolución.
Cómo GoDaddy implementará este cambio
Nuestros intermediarios actuales de firma/emisión G2 no tienen ninguna EKU en la lista, lo que hace que esa jerarquía no cumpla con el requisito del Programa raíz de Chrome. Como resultado, la emisión de los intermedios G2 afectados debe terminar antes de esa fecha.
En lugar de crear nuevos intermedios de emisión en la cadena G2 & mdash; que está previsto que expire/finalice con Google en abril de 2027 & mdash; estamos trasladando la emisión de DV a nuestra nueva jerarquía R1 para cumplir con las restricciones de la política en el futuro.
Estamos cambiando la cadena de emisión de DV pública para que los nuevos certificados hoja de DV se emitan desde la jerarquía CA raíz TLS de GoDaddy - R1, utilizando la CA DV - R1v1 de CA intermedia TLS de GoDaddy emisora certs.godaddy.com. Esto significa que la cadena de emisores presentada por los servidores (hoja + intermedio) puede diferir de lo que algunos sistemas han visto históricamente, y cualquier herramienta interna que asuma un nombre intermedio heredado específico o un orden de cadena debe actualizarse para aceptar la nueva cadena R1.
Además, los certificados hoja emitidos desde esta jerarquía no contendrán ClientAuth EKU. Cualquier flujo de trabajo que dependiera de que los certificados hoja DV se pudieran usar para la autenticación del cliente TLS debe migrar a un perfil de certificado/ruta PKI apropiados. Durante el lanzamiento, los certificados permanecen operativos en los navegadores porque los clientes validan usando la ruta de confianza requerida R1 → G2 con firma cruzada publicada en nuestro repositorio (certs.godaddy.com).
Cómo los certificados permanecen operativos durante la transición de R1 (signo cruzado R1 → G2)
A medida que migramos la emisión pública de TLS de DV a la jerarquía R1, la raíz R1 todavía está en proceso de ser ampliamente confiable/distribuida en los almacenes de confianza del navegador y del sistema operativo. Para garantizar que los certificados R1 recién emitidos funcionen inmediatamente en los navegadores, confiamos en una ruta de confianza con firma cruzada de regreso a la raíz G2 ya confiable.
En términos prácticos, el certificado hoja se emite bajo la CA emisora de R1 DV, pero los clientes lo validan creando una cadena a GoDaddy Class 2 Root - G2 usando el certificado cruzado R1 → G2 publicado. Los artefactos relevantes en el repositorio son el anclaje de confianza G2 (gdroot-g2), el certificado cruzado (gd_tls_root-r1-cross-g2), el intermedio de emisión R1 DV (gd_tls_issuing_dv-r1v1) y la raíz de la jerarquía nativa (gd_tls_root-r1 ) certs.godaddy.com. Este enfoque de signo cruzado permite a los navegadores validar la cadena hoy (anclaje en G2), mientras que la confianza de R1 se propaga con el tiempo.
¿Por qué se está haciendo este cambio?
Hay varias razones para dejar de usar certificados que admiten tanto serverAuth como clientAuth (también conocidos como certificados de propósito mixto):
- Separar la autenticación del servidor de la autenticación del cliente ayuda a simplificar el modelo de certificado de confianza.
- Higiene de seguridad mejorada: Los certificados con demasiados propósitos aumentan el riesgo (es decir, el uso indebido de clientAuth de formas no deseadas).
- El uso de jerarquías de PKI dedicadas para funciones distintas ayuda a mantener límites de confianza más claros, alineándose con las mejores prácticas de PKI (Infraestructura de clave pública) más amplias.
¿Cuáles son los beneficios de este cambio?
- Riesgo reducido de los certificados multipropósito: Al restringir los certificados públicos solo a serverAuth, la superficie de ataque se reduce y los límites de confianza son más claros.
- Mejor cumplimiento & Gobernanza: Las organizaciones tendrán una separación más clara entre la autenticación del servidor y la autenticación del cliente, lo que puede respaldar una mejor auditoría y administración del ciclo de vida de los certificados.
- Claridad operativa mejorada: Cuando la funcionalidad de clientAuth se separa en los certificados o la infraestructura apropiados, es más fácil administrar roles, revocaciones, renovaciones y garantizar que se use el certificado correcto para el propósito correcto.
- Preparación para el futuro: Este cambio se alinea con los modelos de confianza de PKI / navegador en evolución y ayuda a posicionar a las organizaciones para modelos de seguridad y automatización más nuevos.
¿Quién no se ve afectado?
La mayoría de los sitios web que usan certificados solo para la autenticación del servidor (es decir, TLS/HTTPS típico) no se ven afectados. Si solo usas el certificado para proteger tu sitio web para los usuarios, este cambio no requiere acción.
¿A quiénes afecta?
Este cambio afecta a las organizaciones que usan certificados de servidor de confianza pública para la autenticación del cliente (también conocido como TLS / mTLS mutuo) o autenticación de servidor a servidor que dependen del EKU de clientAuth. Por ejemplo, algunos servicios financieros, servicios SaaS o API de múltiples inquilinos pueden verse afectados por este cambio.
Lo que debes hacer
- Si estás alojado fuera de GoDaddy : Asegúrate de que el paquete completo proporcionado por los puntos finales de descarga o la interfaz del cliente se esté instalando cuando actualices tu próximo certificado.
- Si estás usando certificados en cualquier caso de uso que dependa de ClientAuth (mTLS) : Asegúrate de migrar esos flujos de trabajo para usar un certificado autofirmado o una solución de CA privada.
Los equipos también deben confirmar que ninguna característica o documentación interna asume que los certificados hoja DV incluyen ClientAuth EKU, ya que los certificados hoja emitidos por R1 no lo incluirán.
¿Significa esto que todos los certificados emitidos después del 15 de junio de 2026 son inválidos?
No. Los certificados emitidos antes del 15 de junio de 2026 que incluyen clientAuth siguen siendo válidos (hasta el vencimiento) según el modelo de confianza existente. El cambio solo afecta a los nuevos certificados públicos emitidos a partir de esa fecha.
Si solo uso mi certificado para un sitio web típico HTTPS (autenticación de servidor), ¿debo hacer algo?
Si tu hosting está fuera de GoDaddy, aún debes asegurarte de que el paquete se use correctamente.
¿Qué es exactamente la “autenticación del cliente” en este contexto?
La autenticación del cliente se refiere al uso de un certificado por parte de un cliente (usuario, dispositivo u otro servidor) para autenticarse en el servidor. Se usa comúnmente en mTLS (TLS mutuo) o en la autenticación API de servidor a servidor donde el servidor necesita verificar el certificado presentado por el cliente que se conecta.
¿Puedo seguir usando certificados de clientAuth?
Sí & mdash; pero para la confianza pública deberás usar un certificado emitido específicamente para la autenticación del cliente (es decir, EKU de clientAuth dedicado) o usar una CA privada para tus sistemas internos. Los certificados de servidor público con clientAuth EKU ya no serán confiables en Chrome si se emitieron después del 15 de junio de 2026.
¿Otros navegadores aplicarán este cambio o solo Chrome?
La política se origina en el Programa raíz de Chrome, pero los cambios en el ecosistema PKI pública a menudo influyen en otros navegadores y tiendas de confianza. Es aconsejable suponer una aplicabilidad más amplia o al menos que el cumplimiento futuro importará en todas las plataformas.
¿Esto se aplica a los certificados de CA internos/privados?
No, el cambio afecta solo a los certificados SSL/TLS de confianza pública (aquellos en los que confían los almacenes raíz públicos). La infraestructura de CA privada utilizada para la autenticación del cliente interno no se ve afectada directamente.
¿Cuándo debemos estar preparados para este cambio?
El plazo previsto es el 27 de mayo de 2026. Para esa fecha, los equipos responsables deberían haber completado la validación de preparación (configuración de emisión, corrección de paquete/descarga, guía de instalación de la cadena de implementación, monitoreo y verificaciones de dependencia de EKU) para que la implementación pueda continuar sin interrupción del servicio.