Mandato del Foro CA/Navegador: El fin de los certificados Dual-EKU

La propuesta SC-081v3 del Foro CA/Browser fue aprobada por unanimidad en abril de 2025 con el apoyo de los cuatro miembros principales del Foro ( Google, Apple, Microsoft y Mozilla) y 25 autoridades de certificación con derecho a voto. Esta propuesta introdujo una serie de cambios sustanciales en los Requisitos Básicos de TLS (TBR), siendo la separación del Uso Extendido de Claves del Cliente (EKU) uno de los más significativos desde el punto de vista estructural.

La política del programa raíz de Chrome v1.8 , que funciona como mecanismo de aplicación para el almacén raíz de Google Chrome , va más allá. Exige no solo que los certificados hoja no tengan autenticación de cliente, sino también que se reorganicen jerarquías PKI completas, incluidas las CA intermedias que se encadenan a las raíces en el almacén raíz de Chrome, y que ya no contengan valores EKU duales. La separación debe producirse a nivel de CA, no solo a nivel de certificado.

Antes de profundizar en el mandato, conviene sentar las bases técnicas. El Uso Extendido de Clave (EKU, por sus siglas en inglés) es un campo dentro de un certificado digital X.509 que define los fines específicos para los que se puede usar la clave pública de un certificado. Los sistemas que validan certificados comprueban los valores de EKU para determinar si un certificado presentado está autorizado para la operación que se intenta realizar.

Hay dos valores de EKU que se encuentran en el centro de este mandato:

• Autenticación del servidor (OID 1.3.6.1.5.5.7.3.1): Indica que el certificado es válido para autenticar un servidor ante un cliente. Esto es lo que utiliza tu sitio web HTTPS. Los navegadores comprueban esta EKU al establecer una conexión TLS.
• Autenticación de cliente (OID 1.3.6.1.5.5.7.3.2): Indica que el certificado es válido para autenticar un cliente ante un servidor. Esto se utiliza en mTLS, autenticación de dispositivos y en situaciones donde el cliente debe demostrar su identidad, en lugar de solo el servidor.

Las autoridades de certificación públicas emitieron certificados TLS que contenían valores EKU duales . El certificado tiene el siguiente aspecto:

Un único certificado podía contener tanto la autenticación del servidor como la del cliente . Esta práctica de doble EKU era conveniente, ya que un solo certificado podía cumplir una doble función, pero era arquitectónicamente deficiente, y el Foro CA/Browser la ha eliminado formalmente de la infraestructura de clave pública (PKI).

El mandato: ¿qué requieren SC-081 y el programa Chrome Root?

Las autoridades de certificación públicas ya no podrán emitir certificados de servidor TLS que incluyan el uso extendido de clave clientAuth. Los certificados de CA intermedios que admiten tanto serverAuth como clientAuth y que se encadenan a una raíz de confianza pública deberán dejar de emitirse.

Cualquier organización que necesite certificados de autenticación de clientes debe obtenerlos de una jerarquía PKI dedicada y diseñada específicamente para ello, que, por definición, no puede ser una jerarquía de CA pública de confianza en los almacenes raíz de los navegadores.

La fecha más crítica para las organizaciones es el 15 de junio de 2026 , certificados CA subordinados/intermedios: cualquier nuevo intermedio divulgado a CCADB en o después de esa fecha debe afirmar únicamente serverAuth, y no se pueden agregar nuevos intermedios duales de EKU a las jerarquías de confianza de Chrome.

A partir del 15 de marzo de 2027 , cada certificado hoja emitido recientemente que se encadene a una raíz de confianza de Chrome también deberá ser serverAuth-only; a partir de ese momento, Chrome rechazará los certificados hoja TLS públicos que aún contengan la EKU clientAuth, y los handshakes afectados fallarán. Los certificados emitidos antes de la fecha límite aplicable seguirán siendo válidos hasta su vencimiento, pero al renovarlos se volverán a emitir sin clientAuth.

Para calificar como jerarquía PKI de autenticación de servidor TLS dedicada según esta política:

1. Todos los correspondientes no vencido y no revocado Los certificados CA subordinados que operan bajo una raíz existente incluida en el Chrome Root Store DEBEN:
   • si se divulga a la CCADB antes del 15 de junio de 2026: incluir el uso de clave extendido extensión y (a) solo afirmar un propósito de extendedKeyUsage de id-kp-serverAuth o (b) solo afirmar los propósitos de extendedKeyUsage de id-kp-serverAuth y id-kp-clientAuth.
   • si se divulga a la CCADB el o después del 15 de junio de 2026: incluir la extensión extendedKeyUsage y afirmar únicamente un propósito extendedKeyUsage de id-kp-serverAuth.
   • NO contener una clave pública que corresponda a ningún otro certificado no caducado o no revocado que afirme valores de extendedKeyUsage diferentes.
2. Todos los certificados de suscriptor correspondientes emitidos a partir del 15 de marzo de 2027, DEBE incluir la extensión extendedKeyUsage y solo afirmar un propósito extendedKeyUsage de id-kp-serverAuth.

A partir del 15 de marzo de 2027 , cada nuevo certificado TLS de confianza pública deberá tener un único propósito: la autenticación del servidor. Deberá contener únicamente el EKU serverAuth, eliminando por completo el OID clientAuth. El certificado de CA pública deberá tener el siguiente aspecto:

La siguiente tabla especifica los campos obligatorios y permitidos para los certificados de servidor TLS de suscriptor (hoja) emitidos por CA de confianza pública según el mandato del Foro CA/Navegador, 7.1.2.7 Perfil de certificado de suscriptor (servidor):

Campo / Extensión	Presencia	Valores y requisitos permitidos
versión	DEBE	v3 (valor entero 2)
número de serie	DEBE	Entero positivo, con al menos 64 bits de salida de un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG).
sujetoAltName	DEBE	Esta extensión DEBE contener al menos una entrada. Cada entrada DEBE ser una dNSName or Dirección IP como se describe en Sección 7.1.4.2.
restricciones básicas	DEBE	Para un certificado de suscriptor (hoja), el cUn campo DEBE estar configurado en FALSO. Restricción de longitud de ruta NO DEBE estar presente.
uso de clave	DEBE	Es un atributo crítico. Los valores aceptables de uso de clave varían según si el certificado subjectPublicKeyInfo identifica una clave pública RSA o una ECC clave pública. Las CA DEBEN asegurarse de que el uso de la clave sea apropiado para la clave pública del certificado. Los usos de clave permitidos son: Firma digital + cifrado de clave para RSA, y firma digital únicamente para ECDSA.
uso de clave extendido	DEBE	El siguiente valor DEBE estar presente: • id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) El siguiente valor NO DEBE estar presente: • id-kp-clientAuth (OID: 1.3.6.1.5.5.7.3.2) – Prohibido para certificados de hojas recién emitidos a partir del 15 de marzo de 2027 en Política del programa raíz de Chrome v1.8, Sección 1.3.2
Políticas de certificación	DEBE	Si está presente, la extensión Políticas de certificados DEBE contener al menos una Información sobre políticas.
AutoridadInformaciónAcceso	DEBE	No es un campo crítico. • Identificador de clave- DEBE estar presente. DEBE ser idéntico al campo subjectKeyIdentifier de la CA emisora. • AutoridadEmisor de certificados- NO DEBE estar presente • Número de serie del certificado de autoridad NO DEBE estar presente
identificador de clave de sujeto	DEBE	La CA DEBE generar un identificador de clave de sujeto que es único dentro del alcance de todos los certificados que ha emitido para cada clave pública única
Puntos de distribución cRL	DEBE	Esta extensión DEBE estar presente y NO DEBE estar marcada como crítica. La extensión Puntos de distribución de CRL DEBE estar presente en: • Certificados CA subordinados; y • Certificados de suscriptor que 1) no califican como “Certificados de suscriptor de corta duración” y 2) no incluyen una extensión de acceso a información de autoridad con un método de acceso id-ad-ocsp.

Nota sobre extendedKeyUsage: La sección 7.1.2.7.10 de los Requisitos básicos de TLS del Foro CA/Navegador aún indica que id-kp-clientAuth puede estar permitido, pero no es obligatorio a nivel de los BR (Requisitos básicos de TLS). La prohibición estricta proviene de la sección 1.3.2 de la Política del Programa Raíz de Chrome , que exige que todos los certificados de suscriptor emitidos a partir del 15 de marzo de 2027 incluyan únicamente id-kp-serverAuth. Las CA deben cumplir con esta política para permanecer en el Almacén Raíz de Chrome, lo que hace que la restricción sea prácticamente universal.

La propuesta electoral SC-081 también introduce una reducción gradual del período máximo de validez de los certificados TLS de confianza pública. La validez se reduce a 200 días a partir de marzo de 2026, a 100 días a partir de marzo de 2027 y a 47 días a partir de marzo de 2029. La menor duración de los certificados hace que la inscripción automatizada mediante ACME, WSTEP, SCEP y EST sea un requisito indispensable, en lugar de una simple conveniencia. Cualquier organización que dependa de la renovación manual de certificados se enfrentará a una carga operativa insostenible a medida que se reduzcan los períodos de validez. Esto refuerza la necesidad de una infraestructura de clave pública (PKI) privada gestionada con una gestión del ciclo de vida totalmente automatizada desde el primer día.

Cronología pública de CA

La fecha más crítica para las organizaciones es el 15 de junio de 2026 , cuando Chrome rechazará activamente los certificados TLS públicos que contengan la EKU clientAuth. Cualquier nueva CA subordinada (CA intermedia) que se divulgue a la Base de Datos de CA Comunes (CCADB) a partir de esta fecha deberá contener únicamente id-kp-serverAuth . No se podrán agregar nuevas CA intermedias con EKU mixtas a las jerarquías de confianza de Chrome a partir de esta fecha. Cualquier sistema que presente un certificado de este tipo en un protocolo de enlace TLS validado por Chrome fallará. Los certificados existentes emitidos antes de esta fecha seguirán siendo válidos hasta su vencimiento, pero una vez renovados, se emitirán sin clientAuth.

Las autoridades de certificación no esperaron hasta la fecha límite estricta de marzo de 2027. La mayoría de las principales autoridades de certificación comenzaron a eliminar clientAuth mucho antes, impulsadas por la fecha límite intermedia de junio de 2026 establecida por Chrome para las autoridades de certificación. A continuación, se muestra el cronograma completo a junio de 2026.

Fecha	CA / Programa	Milestone	Estado
Septiembre 15, 2025	SSL.com	Deja de emitir clientAuth por defecto	PASADO
1 de octubre de 2025	DigiCert	Deja de emitir clientAuth por defecto	PASADO
14 de octubre de 2025	sectigo	Deja de emitir clientAuth por defecto	PASADO
11 de febrero de 2026	Vamos a cifrar	El perfil ACME predeterminado elimina clientAuth.	PASADO
15 de junio de 2026	Google Chrome	Rechaza los certificados TLS públicos con clientAuth EKU	CRÍTICA
8 de julio de 2026	Vamos a cifrar	El perfil de tlsclient ha sido descontinuado permanentemente.	PRÓXIMOS
10 de febrero de 2027	sectigo	Plazo límite improrrogable, sin excepciones.	PRÓXIMOS
1 de marzo de 2027	DigiCert	Eliminación total, sin excepciones.	PRÓXIMOS
15 de marzo de 2027	Programa raíz de Chrome	Fecha límite final del sector	FECHA LIMITE

¿Por qué se está eliminando la EKU de autenticación de cliente?

Resulta tentador considerar este mandato simplemente como una carga de cumplimiento. En realidad, subsana una brecha de seguridad real y poco reconocida. Comprender la siguiente justificación de seguridad ayuda a las organizaciones a entender por qué se está implementando este cambio:

• La infraestructura de clave pública (PKI) web pública se creó para autenticar servidores ante los navegadores: Los procesos de validación de dominio (DV) y validación de organización (OV) que utilizan las autoridades de certificación públicas están diseñados para verificar la propiedad del dominio y la identidad de la organización con el fin de autenticar el servidor. No están diseñados para establecer que un sistema determinado esté autorizado a actuar como cliente en un contexto de autenticación específico. Incluir la extensión de conocimiento clientAuth en un certificado emitido públicamente implica un estándar de validación que nunca se llevó a cabo.
• La vulneración de la clave privada ha tenido consecuencias graves: Cuando un certificado de servidor TLS incluye tanto la autenticación del servidor (serverAuth) como la del cliente (clientAuth), una clave privada comprometida causa un daño doble. Un atacante que extrae la clave privada de un servidor no solo puede suplantar la identidad de ese servidor ante los clientes, sino también presentar ese certificado como una credencial de cliente válida a cualquier sistema que confíe en la CA emisora ​​y verifique la EKU de clientAuth. Una sola vulneración se convierte en capacidad de movimiento lateral. Eliminar clientAuth de los certificados de servidor elimina por completo este segundo vector de ataque.
• La separación permite una gestión adecuada del ciclo de vida: Los certificados de servidor y los de cliente tienen requisitos de ciclo de vida fundamentalmente diferentes. Los certificados de servidor están vinculados a nombres de dominio, se renuevan en infraestructura pública y los gestionan los equipos de operaciones web. Los certificados de cliente están vinculados a identidades de sistema y requieren capacidades de revocación que se aplican a nivel de aplicación. Combinarlos en un solo certificado dificulta su correcta gestión. La separación restablece la propiedad y la responsabilidad claras.

Impacto de la eliminación de la EKU de autenticación de cliente

La eliminación de la EKU clientAuth afecta a las organizaciones que actualmente utilizan un certificado de servidor TLS de confianza pública para la autenticación de clientes.

Las organizaciones que utilizan certificados públicos exclusivamente para la autenticación estándar de servidores HTTPS generalmente no se ven afectadas. Sus sitios web, portales y aplicaciones de cara al público pueden seguir utilizando certificados que contengan únicamente la EKU serverAuth.

El problema surge cuando el mismo certificado público se utiliza para autenticar a un usuario, dispositivo, servidor, aplicación o carga de trabajo en otro sistema. Si dicho certificado se renueva o se vuelve a emitir sin la EKU clientAuth, es posible que el sistema receptor ya no lo acepte como una credencial de cliente válida.

Es importante destacar que el certificado aún puede ser válido, no estar caducado y ser de confianza. El fallo se produce porque el certificado ya no está autorizado para la autenticación del cliente.

Para ayudarle a identificar qué podría fallar y por qué, la siguiente tabla destaca las posibles áreas de impacto en toda su organización.

Caso de uso	Impacto potencial
TLS mutuo (mTLS)	Durante una conexión mTLS, el sistema receptor puede verificar que el certificado del cliente incluya la EKU clientAuth. Si falta esta EKU, el certificado podría ser rechazado y el protocolo de enlace TLS fallaría. Esto puede afectar a microservicios, pasarelas API, mallas de servicios, integraciones entre empresas y autenticación personalizada entre aplicaciones. El error podría manifestarse como un fallo genérico en el protocolo de enlace TLS o en la validación del certificado, en lugar de un problema de caducidad.
RADIUS, IEEE 802.1X y EAP-TLS	En la autenticación de red basada en certificados, los usuarios o dispositivos presentan un certificado de cliente para demostrar su identidad. Si el servidor de autenticación requiere la EKU clientAuth y el certificado renovado no la incluye, la solicitud de autenticación fallará. Como consecuencia, los dispositivos afectados podrían no poder conectarse a redes Wi-Fi corporativas, redes cableadas o servicios VPN.
OpenVPN, Cisco Secure Client y Fortinet VPN	Muchas implementaciones de VPN basadas en certificados requieren que el certificado del usuario o dispositivo que se conecta contenga la EKU clientAuth. Si se renueva un certificado público utilizado previamente para la autenticación VPN sin dicha EKU, la puerta de enlace VPN podría rechazarlo. En ese caso, los usuarios podrían no poder establecer una conexión de acceso remoto segura.
Microsoft Exchange y comunicación de servidor a servidor	Las configuraciones de comunicación entre el conector SMTP, EWS y socios utilizan certificados para la autenticación mutua o entre servidores. Si se espera que el certificado del servidor de conexión admita la autenticación del cliente, eliminar la EKU clientAuth puede interrumpir la autenticación o el flujo de correo. El impacto real depende de la versión de Exchange, la configuración del conector y los requisitos de validación del certificado.
Entornos de escritorio remoto y puerta de enlace RDP	La puerta de enlace de escritorio remoto suele utilizar un certificado de servidor para autenticarse ante los clientes conectados. Sin embargo, los entornos que también utilizan autenticación de cliente basada en certificados, autenticación con tarjeta inteligente o controles de autenticación mutua personalizados pueden depender de certificados de cliente dedicados. Reutilizar un certificado de servidor público para este fin puede provocar fallos de autenticación tras su renovación.
IoT e identidad de dispositivos	Los dispositivos IoT, industriales y embebidos pueden usar certificados para autenticarse en servicios en la nube, plataformas de gestión o pasarelas de dispositivos. Si se renueva un certificado de dispositivo sin la EKU clientAuth requerida, la plataforma puede rechazar la identidad del dispositivo. Esto puede impedir el registro del dispositivo, el envío de telemetría, la gestión remota, las actualizaciones de software o la ejecución de comandos.
Autenticación API y de servidor a servidor	Las aplicaciones y los servidores suelen actuar como clientes TLS al llamar a API internas o externas. Si presentan un certificado TLS público como identidad de cliente, la API receptora podría rechazarlo una vez eliminada la autenticación del cliente (clientAuth). Esto puede interrumpir las integraciones, aunque el mismo certificado siga funcionando con normalidad para las conexiones HTTPS entrantes.
Cargas de trabajo de CI/CD y DevOps	Los servidores de compilación, los agentes de despliegue, los contenedores y las plataformas de automatización pueden usar certificados para autenticarse en registros, clústeres de Kubernetes, repositorios de artefactos o API internas. Cuando un certificado renovado deja de ser compatible con la autenticación de clientes, las canalizaciones automatizadas pueden fallar sin una causa evidente relacionada con el certificado.

¿Por qué estos fallos pueden ser difíciles de diagnosticar?

La eliminación de clientAuth no necesariamente produce un mensaje claro que indique que falta la EKU. Dependiendo de la aplicación, el sistema operativo o la biblioteca TLS, el fallo puede notificarse de la siguiente manera:

• Fallo en el protocolo de enlace TLS
• No se permite la finalidad del certificado.
• Certificado no compatible
• Certificado defectuoso
• acceso denegado
• Se rechazó la identidad del cliente.
• Fallo en la verificación de pares
• Tiempo de espera de autenticación agotado

Esto hace que sea fácil diagnosticar erróneamente el problema como un problema de cadena de confianza, caducidad, red, conjunto de cifrado o configuración de la aplicación.

El riesgo más significativo no se limita a los certificados que ya se sabe que admiten TLS mutuo . Incluye sistemas no documentados que han estado utilizando la EKU clientAuth porque, históricamente, los certificados TLS públicos la incluían por defecto.

Las organizaciones deben identificar estas dependencias antes de renovar o reemitir los certificados afectados. Esperar hasta la renovación puede convertir un reemplazo rutinario de certificados en una interrupción inesperada que afecte la conectividad de las aplicaciones, el acceso a la red, el acceso remoto o la autenticación de dispositivos.

La solución: Transición a una CA privada

Las autoridades de certificación de confianza pública están siendo restringidas para emitir certificados TLS para la autenticación de clientes (es decir, certificados que incluyen la EKU clientAuth). Como resultado, las organizaciones ya no pueden confiar en los certificados TLS públicos para casos de uso de autenticación de clientes internos, como TLS mutuo, autenticación de dispositivos, identidad de carga de trabajo, autenticación de API y comunicación de servidor a servidor. Como resultado, las organizaciones ya no pueden confiar en los certificados TLS públicos para casos de uso de autenticación de clientes internos, como TLS mutuo, autenticación de dispositivos, identidad de carga de trabajo, autenticación de API y comunicación de servidor a servidor.

Una infraestructura de clave pública (PKI) privada resuelve este problema, ya que opera fuera del ecosistema de PKI públicas de confianza para navegadores. Su autoridad de certificación raíz solo es de confianza para los usuarios, dispositivos, aplicaciones y sistemas seleccionados por la organización. Por lo tanto, la organización puede emitir certificados de cliente dedicados que incluyan la extensión de uso de certificados (EKU) clientAuth sin afectar ni depender de la confianza pública de los navegadores.

La infraestructura de clave pública privada (PKI) también permite una separación adecuada entre los dos propósitos de los certificados:

• Certificados de servidor públicos o privados que contengan únicamente el EKU serverAuth
• Certificados de cliente privado dedicados que contienen solo el EKU clientAuth (OID 1.3.6.1.5.5.7.3.2), sin ningún OID serverAuth presente, como se muestra en la captura de pantalla a continuación:

Esta separación garantiza que un certificado de servidor se utilice únicamente para autenticar un servidor, mientras que un certificado de cliente se utilice únicamente para autenticar un usuario, dispositivo, aplicación o estación de trabajo. Reduce el impacto de una posible filtración de claves privadas y proporciona un control más claro sobre la emisión, la propiedad, la renovación y la revocación de certificados.

Con una infraestructura de clave pública (PKI) privada, las organizaciones también pueden definir políticas de certificados para satisfacer sus requisitos de seguridad específicos, incluyendo procedimientos de validación de identidad, periodos de validez de los certificados, convenciones de nomenclatura, algoritmos aprobados, requisitos de protección de claves y métodos de inscripción. Los certificados se pueden emitir y renovar automáticamente mediante protocolos como ACME, SCEP, EST, CMP, WSTEP o la inscripción automática de Microsoft.

Este cambio permite a las organizaciones diseñar flujos de trabajo de autenticación adaptados a sus necesidades específicas, sin las limitaciones de las autoridades de certificación públicas. La siguiente sección describe cómo debería ser la jerarquía de la infraestructura de clave pública (PKI).

¿Cómo debe cambiar la jerarquía de la infraestructura de clave pública (PKI)?

Eliminar la EKU clientAuth de los certificados TLS de confianza pública no es simplemente un cambio en la plantilla del certificado. Requiere que las organizaciones separen la autenticación del servidor público de la autenticación del cliente interno a nivel de la arquitectura PKI.

Según el nuevo modelo, los certificados de confianza pública solo deben usarse para autenticar servidores ante clientes externos, como navegadores que se conectan a sitios web y aplicaciones de acceso público. Estos certificados contienen únicamente la EKU serverAuth y continúan su cadena hasta una CA raíz de confianza pública.

La autenticación de clientes debe trasladarse a una jerarquía PKI privada independiente. Esta jerarquía privada emite certificados específicos para usuarios, dispositivos, aplicaciones, cargas de trabajo y servidores que necesitan autenticarse como clientes.

Por lo tanto, la arquitectura objetivo debe incluir:

• Una jerarquía PKI TLS pública para certificados de servidor orientados a Internet que contiene únicamente serverAuth
• Una CA raíz privada sin conexión a un dominio, protegida con un módulo de seguridad de hardware compatible con FIPS 140-3 Nivel 3.
• Una o más autoridades de certificación emisoras privadas dedicadas a la autenticación de clientes. Protección mediante HSM para las claves privadas de las autoridades de certificación emisoras.
• Los perfiles de certificado de cliente están limitados al EKU clientAuth únicamente (no hay OID serverAuth presente), con el uso de clave configurado como digitalSignature, por lo que el certificado no se puede utilizar para la autenticación del servidor bajo ninguna circunstancia.

  

• Perfiles de certificado separados para dispositivos, usuarios, cargas de trabajo, API y otras identidades.
• Servicios CRL u OCSP para la revocación de certificados, con puntos finales CDP configurados como públicos o privados según el caso de uso y los requisitos de accesibilidad de la organización.
• Inscripción, renovación y revocación automatizadas de certificados.
• Distribución de la CA raíz privada a los sistemas que deben confiar en los certificados del cliente.

Según esta arquitectura, un servidor que desempeña ambas funciones puede necesitar dos certificados separados:

1. Un certificado de servidor que contiene serverAuth para aceptar conexiones TLS entrantes.
2. Un certificado de cliente que contiene clientAuth para autenticarse al conectarse a otro sistema.

Esta separación garantiza que cada certificado y clave privada tenga un propósito claramente definido. Además, permite a las organizaciones aplicar diferentes políticas de validación de identidad, ciclo de vida, revocación y protección de claves a las identidades de servidor y cliente.

El diseño, la implementación y el funcionamiento continuo de esta jerarquía privada requieren conocimientos especializados en PKI, infraestructura HSM segura, automatización del ciclo de vida de los certificados, servicios de revocación, monitorización, recuperación ante desastres y gestión continua de políticas. La siguiente sección de este blog explica en detalle cómo PKIaaS de Encryption Consulting ofrece una CA privada totalmente gestionada, creada, operada y mantenida conforme a la normativa en su nombre.

PKIaaS de Encryption Consulting

La creación y el funcionamiento de una jerarquía PKI privada no son técnicamente complejos en concepto, pero sí lo son en su ejecución, ya que incluyen la adquisición de HSM, ceremonias de CA raíz fuera de línea, accesibilidad a CDP/AIA, automatización del ciclo de vida de los certificados, documentación de políticas y operaciones de inscripción.

El servicio PKIaaS (Infraestructura de Clave Pública como Servicio ) de Encryption Consulting cumple con plazos ajustados y ofrece una infraestructura de clave pública privada completa como servicio gestionado . Encryption Consulting la desarrolla, la gestiona y garantiza su cumplimiento normativo, mientras que usted conserva la propiedad total.

Sin dependencia de un proveedor: Sus claves privadas, jerarquía de CA y certificados le pertenecen por completo. Si decide migrar la infraestructura de clave pública (PKI) a su entorno local, Encryption Consulting realizará una ceremonia formal y documentada de transferencia de claves. El material de clave privada de la CA se transferirá de forma segura a su HSM mediante procedimientos de exportación autenticados y con doble control.

Sus certificados actuales seguirán siendo válidos, sin necesidad de reemisión. Todo el proceso de transferencia estará completamente documentado y será auditable, lo que garantiza la continuidad operativa y la titularidad total.

Usted es el propietario de la infraestructura de clave pública (PKI). Nosotros la creamos, administramos y operamos en su nombre. Así es como funciona nuestra colaboración.

Fase 1: Descubrimiento e inventario de certificados

Antes de diseñar la nueva infraestructura de clave pública (PKI), Encryption Consulting desarrolla una visión completa del entorno de certificados actual del cliente. Esto es fundamental, ya que muchos sistemas dependen de clientAuth sin que dicha dependencia se haya detectado formalmente.

Admitimos varios métodos de detección de certificados , incluidos el escaneo de red, el escaneo sin agente y la detección basada en la integración.

El descubrimiento basado en la integración proporciona una visión autorizada y en tiempo real de los datos de los certificados al conectarse directamente con las Autoridades de Certificación y plataformas en la nube como AWS, Microsoft Azure y Google Cloud. También puede examinar las configuraciones de las aplicaciones, incluidos los ajustes de mTLS, e integrarse con clústeres de Kubernetes, plataformas de gestión de secretos como HashiCorp Vault y CyberArk Conjur, y canalizaciones de CI/CD, como GitHub Actions, Jenkins y GitLab.

Entre las capacidades de detección adicionales se incluyen la monitorización pasiva mediante proxies, cortafuegos y puntos de acceso a la red; el escaneo de directorios a través de LDAP y Active Directory; y la detección mediante herramientas de gestión de configuración como Ansible, Chef y Puppet.

El resultado es un inventario completo de certificados que incluye los sujetos, los nombres alternativos del sujeto (SAN), las unidades de extensión de certificados (EKU), los emisores y las fechas de vencimiento. Cada certificado que contiene la autenticación de cliente (clientAuth) se asocia tanto al sistema que lo presenta como al sistema que lo utiliza para la autenticación.

Los resultados se organizan en un cronograma de migración clasificado por riesgo. El cliente obtiene una visión clara de qué sistemas pueden fallar, cuándo están en riesgo y el impacto potencial en el negocio si se renueva un certificado sin la autenticación del cliente.

Fase 2: Diseño de la arquitectura PKI

No se construye nada hasta que la arquitectura se revisa y se aprueba. Cada CA, cada plantilla de certificado y cada punto final de revocación se especifican por escrito antes de generar cualquier clave.

La arquitectura suele incluir una CA raíz sin conexión a un dominio y CA emisoras independientes para la autenticación de clientes, TLS interno y la autenticación de identidad del dispositivo. Esta separación garantiza que los certificados de cliente contengan únicamente la autenticación del cliente (clientAuth).

Se definen perfiles de certificado para cada caso de uso, incluyendo algoritmos, periodos de validez, formatos de sujeto y SAN, uso de clave, EKU, OID de política y puntos finales de revocación. Las ubicaciones de CRL y OCSP se configuran como públicas o privadas según dónde se vayan a utilizar los certificados.

Esto crea una jerarquía clara y orientada a un propósito, sin certificados EKU duales y sin ambigüedad sobre lo que cada certificado está autorizado a hacer.

Fase 3: Ceremonia de CA raíz y desarrollo de la infraestructura.

La clave privada de la CA raíz se genera y protege mediante un módulo de seguridad de hardware (HSM) compatible con FIPS 140-3 Nivel 3. La CA raíz permanece alojada de forma segura en el centro de datos y se mantiene sin conexión entre las operaciones autorizadas de firma de certificados. Para la recuperación ante desastres, se conserva una copia de seguridad cifrada y con control de acceso del material de clave en un entorno HSM geográficamente separado.

Posteriormente, Encryption Consulting desarrolla la infraestructura PKI de soporte, que incluye autoridades de certificación emisoras reforzadas, respondedores OCSP, servicios de publicación de CRL y capacidades de gestión de certificados.

Fase 4: Distribución en tiendas de confianza

Los certificados emitidos por una infraestructura de clave pública privada (PKI) solo son confiables cuando la autoridad de certificación raíz privada está instalada en todos los sistemas que los validan. Esta fase distribuye el nuevo certificado de la autoridad de certificación raíz privada a todos los sistemas de partes confiables dentro del alcance.

Los sistemas Windows unidos a un dominio reciben la CA raíz mediante directivas de grupo, que se agrega al almacén de autoridades de certificación raíz de confianza. Los sistemas Linux se actualizan mediante update-ca-certificates, implementado a través de Ansible, Chef o Puppet, según la cadena de herramientas de administración de configuración existente.

Tras la distribución, se prueban los sistemas representativos utilizando los certificados de cliente recién emitidos. Esta fase finaliza únicamente cuando el cliente confirma que las cadenas de certificados son de confianza y que la autenticación se realiza correctamente.

Fase 5: Implementación de la puerta de enlace PKIaaS

Esta fase implementa la puerta de enlace PKIaaS, un conjunto de componentes de registro y administración instalados en la infraestructura del cliente. La puerta de enlace conecta los sistemas internos del cliente con la jerarquía de CA alojada por Encryption Consulting. Todas las solicitudes de certificados pasan a través de ella. Las claves privadas de la CA permanecen en los HSM de Encryption Consulting en todo momento, ya que la puerta de enlace solo gestiona el tráfico del protocolo de registro, sin realizar nunca operaciones de firma.

La puerta de enlace expone un punto final del Protocolo de Inscripción de Confianza WS (WSTEP), lo que permite la inscripción de certificados totalmente automatizada para máquinas Windows sin necesidad de interacción por parte del usuario o del administrador. El servicio de Directiva de Inscripción de Certificados (CEP) está configurado para determinar qué plantillas de certificado son aptas para él en función de su identidad en Active Directory y su pertenencia a directivas de grupo.

El servicio web de inscripción de certificados valida la solicitud según la política de inscripción, la enruta a través de la puerta de enlace PKIaaS a la CA emisora ​​y devuelve el certificado firmado directamente al equipo, que lo instala automáticamente en el almacén de certificados correspondiente. Desde la configuración de la GPO en adelante, todo el ciclo de vida (descubrimiento de políticas, solicitud, firma, instalación y renovación) no requiere intervención manual.

Un panel de control basado en la web donde los usuarios autorizados pueden solicitar certificados, enviar solicitudes de firma de certificado (CSR), buscar en el inventario de certificados, renovar certificados, revocar certificados comprometidos o no utilizados y revisar el estado de los certificados.

El panel de control incluye un sistema de control de acceso basado en roles. Los administradores de certificados pueden solicitar o revocar certificados, los auditores pueden revisar informes y registros de actividad, y los administradores pueden gestionar los perfiles aprobados y las políticas de inscripción.

Cada inscripción, renovación, revocación, aprobación, cambio de configuración e inicio de sesión administrativo queda registrado en un registro de actividad auditable.

Fase 6: Migración de certificados - Sistema por sistema

Una vez que los servicios de confianza e inscripción estén operativos, Encryption Consulting comenzará a reemplazar los certificados públicos de doble EKU con certificados privados de cliente dedicados.

La migración comienza con los entornos de desarrollo y preproducción. A continuación, se migran los servicios internos y las API, seguidos de la infraestructura de red, incluyendo VPN, RADIUS y 802.1X. Los sistemas críticos para el negocio, como Exchange, las aplicaciones principales y los sistemas internos de la organización, se migran solo después de que se confirmen las pruebas y los procedimientos de reversión.

Cada solicitud de certificado se envía mediante el método de inscripción correspondiente, como WSTEP, ACME, SCEP, EST o el panel de administración. El nuevo certificado se emite únicamente con la EKU clientAuth. La aplicación se configura para presentar el nuevo certificado y una prueba de autenticación de extremo a extremo confirma que la conexión se realiza correctamente.

Tras una validación satisfactoria, el antiguo certificado dual EKU se elimina o revoca según corresponda, y el nuevo certificado se inscribe en el proceso de renovación automática.

Fase 7: Operaciones en curso y cumplimiento normativo

En esta fase, PKIaaS proporciona un valor continuo más allá de la configuración inicial.

La plataforma CLM de Encryption Consulting gestiona de forma continua la emisión, renovación y revocación de certificados, la publicación de CRL, la disponibilidad de OCSP, la monitorización de HSM, el mantenimiento de la infraestructura, la validación de copias de seguridad y las operaciones de PKIaaS Gateway.

Los servicios de inscripción, como WSTEP, ACME, SCEP y EST, se mantienen de forma continua para que los certificados puedan emitirse y renovarse sin intervención manual.

Encryption Consulting también supervisa los requisitos de seguridad de las organizaciones pertinentes, las novedades del CA/Browser Forum, los estándares criptográficos, los cambios en los algoritmos y las actualizaciones de las políticas de certificados, como la compatibilidad con la criptografía postcuántica . Cuando un cambio afecta al entorno del cliente, la configuración de la infraestructura de clave pública (PKI) y los perfiles de certificados se actualizan antes de la fecha límite correspondiente.

Conclusión

La eliminación de la EKU clientAuth de los certificados TLS de confianza pública supone un cambio fundamental en la forma en que las organizaciones deben gestionar la autenticación basada en certificados. Los certificados públicos seguirán protegiendo sitios web y servicios externos, pero la autenticación de clientes para usuarios, dispositivos, aplicaciones y cargas de trabajo deberá migrar a una infraestructura de clave pública (PKI) privada diseñada específicamente para este fin. Las organizaciones que no identifiquen las dependencias ocultas de doble EKU corren el riesgo de sufrir interrupciones inesperadas al renovar los certificados sin clientAuth; fallos que no se manifestarán como errores de certificado, sino como tiempos de espera de autenticación, fallos en el protocolo de enlace TLS y mensajes de acceso denegado sin causa aparente.

El servicio PKIaaS de Encryption Consulting ofrece una solución integral para esta transición. Evaluamos el entorno existente, identificamos los sistemas afectados, diseñamos e implementamos la infraestructura de clave pública (PKI) privada, protegemos las claves de CA dentro de los módulos de seguridad de hardware (HSM), desplegamos servicios de registro, migramos certificados y gestionamos el entorno de forma continua. El registro automatizado mediante WSTEP, ACME, SCEP y EST garantiza que los certificados se emitan, renueven y revoquen sin generar una carga operativa adicional.

Para comenzar con una evaluación gratuita de preparación de PKI, contáctenos en [email protected] o visite encryptionconsulting.com/pkiaas.