Especificaciones de protocolos abiertos de ADCS: Guía técnica completa

Servicios de certificados de Active Directory (ADCS) es uno de los sistemas más ampliamente desplegados. Infraestructura de Clave Pública Soluciones de infraestructura de clave pública (PKI) en el ámbito empresarial. Si bien la mayoría de las organizaciones interactúan con ADCS a través de la interfaz de usuario de Windows o PowerShell, la verdadera complejidad técnica reside en la capa de protocolo subyacente a las especificaciones abiertas publicadas por Microsoft. Comprender estos protocolos es fundamental para arquitectos, ingenieros de seguridad, desarrolladores de herramientas integradas con PKI y profesionales de la seguridad que evalúan vulnerabilidades en la infraestructura de certificados.

Esta guía proporciona un análisis exhaustivo y práctico de cada una de las principales especificaciones del Protocolo Abierto ADCS, cómo se relacionan entre sí y qué significa cada una para la seguridad de su infraestructura de clave pública (PKI).

¿Qué son las especificaciones abiertas de Microsoft?

En el año 2008, Microsoft lanzó el Especificaciones abiertas El programa, una biblioteca de documentación de acceso público que contiene especificaciones técnicas detalladas para protocolos y extensiones de Windows, tenía como objetivo permitir a desarrolladores externos crear clientes y servidores totalmente interoperables con los productos de Microsoft.

La biblioteca de especificaciones abiertas contiene cientos de documentos sobre protocolos de Windows, extensiones de Microsoft Office y mucho más. En el caso específico de ADCS, estos documentos representan la referencia técnica más autorizada y actualizada disponible, y en muchos casos reemplazan el contenido antiguo de TechNet que quedó obsoleto durante la transición de Microsoft a un portal de documentación unificado entre 2015 y 2016.

El panorama de los protocolos abiertos de ADCS

El MS-CERSOD El documento (Descripción general de los protocolos de servicios de certificados) sirve como índice maestro para todas las especificaciones de protocolo relacionadas con ADCS. Organiza la funcionalidad de ADCS en dos grupos distintos:

• Protocolos de inscripción de certificados: Cómo los clientes solicitan, reciben y renuevan sus certificados
• Protocolos de administración de CA: Cómo los administradores gestionan y operan la CA

Protocolos de inscripción de certificados

1. MS-WCCE - Protocolo de inscripción de certificados de cliente de Windows

MS-WCCE es el protocolo de inscripción ADCS fundamental y el que está más profundamente integrado en entornos Windows unidos a un dominio. Define un conjunto de interfaces DCOM (Distributed Component Object Model) que permiten que un cliente se comunique directamente con un autoridad de certificación para:

• Solicitar nuevos certificados X.509
• Renovar certificados existentes
• Recuperar propiedades y capacidades de CA
• Obtenga información sobre el estado de revocación.

Arquitectura central

MS-WCCE se basa en dos interfaces DCOM sucesivas: ICertRequestD e ICertRequestD2. Estas interfaces exponen un modelo sencillo de solicitud-respuesta. El cliente envía una solicitud de certificado (en formato PKCS #10, CMC o PKCS #7) y la CA responde con un certificado firmado o una resolución detallada que explica por qué se denegó la solicitud o se puso en estado pendiente.

Logística de transporte

MS-WCCE utiliza RPC/DCOM sobre TCP. Esto significa que requiere conectividad de red con la CA a través de puertos dinámicos RPC y está intrínsecamente vinculado a la pertenencia a un dominio de Active Directory. El servidor de directivas en un escenario de inscripción de MS-WCCE siempre es un controlador de dominio.

Relevancia para la seguridad

Debido a que MS-WCCE utiliza DCOM y Active Directory, constituye una superficie de ataque para varias técnicas conocidas de escalada de privilegios de Certificados de Seguridad Empresarial (ESC). Las configuraciones incorrectas en las plantillas de certificados (ACL de plantilla, configuración de EKU, permisos del agente de inscripción) pueden permitir que un atacante abuse del flujo de MS-WCCE para obtener certificados para cuentas con altos privilegios.

2. Protocolo remoto MS-ICPR-ICertPassage

MS-ICPR Está estrechamente relacionado con MS-WCCE y también utiliza DCOM/RPC. Expone la interfaz ICertPassage, una interfaz más sencilla y de bajo nivel que se utiliza para el envío directo de solicitudes de certificados a una CA, sin la inteligencia de inscripción más avanzada integrada en MS-WCCE.

MS-ICPR se utiliza principalmente en escenarios de solicitud programática de certificados y aparece como un punto final DCOM distinto en la CA. También es relevante en escenarios de ataques de retransmisión de certificados (como ESC8 y técnicas relacionadas) porque proporciona un canal autenticado para solicitar certificados.

3. Protocolo de política de inscripción de certificados MS-XCEP-X.509

MS-XCEP es el protocolo que impulsa el Servicio web de política de inscripción de certificados Función (CEP) en ADCS. Permite a los clientes recuperar información de la política de inscripción de certificados a través de HTTP/HTTPS mediante mensajería basada en SOAP, sin necesidad de conectividad DCOM directa con la CA.

¿Cómo funciona nuestro equipo?

El cliente envía una solicitud GetPolicies al punto final CEP. El servidor responde con una GetPoliciesResponse que contiene: una colección de objetos de política de inscripción de certificados que describen las plantillas de certificados disponibles, una lista de emisores de certificados (servidores CES) con los que el cliente debe ponerse en contacto para cada plantilla y el método de autenticación que se debe usar para cada emisor (Kerberos, nombre de usuario/contraseña o certificado).

Opciones de autenticación

• Kerberos (para dispositivos unidos a un dominio)
• Nombre de usuario/Contraseña (para dispositivos que no pertenecen a un dominio y se autentican con credenciales de dominio)
• Recuperar propiedades y capacidades de CA

4. MS-WSTEP - Protocolo de inscripción de confianza de servicios web

Donde MS-XCEP gestiona las políticas descubrimientoMS-WSTEP gestiona la emisión real del certificado. Impulsa el Servicio web de inscripción de certificados (CES) función en ADCS. Juntos, MS-XCEP y MS-WSTEP forman la pila de inscripción basada en servicios web que complementa, y en muchos escenarios reemplaza, la pila RPC/DCOM utilizada por MS-WCCE.

Características del protocolo

• Basado en WS-Trust (un estándar de seguridad WS-*), ampliado con capacidades específicas de Microsoft.
• Se comunica a través de HTTPS utilizando mensajes SOAP.
• Admite solicitudes de certificados en formato PKCS #10 y CMC.
• Permite el registro de certificados cifrados de extremo a extremo sin exposición de puertos RPC.

Escenarios de implementación comunes

Escenario	Protocolo utilizado	Logística de transporte	Servicio de rol
Cliente Windows unido a un dominio (local)	MS-WCCE o MS-XCEP + MS-WSTEP	RPC/DCOM o HTTPS	CA / CES
Dispositivo sin dominio con credenciales de dominio	MS-XCEP + MS-WSTEP	HTTPS/SOAP	CEP + CES
Renovación de certificados por internet	MS-XCEP + MS-WSTEP (autenticación basada en certificados)	HTTPS/SOAP	CEP + CES
Inscripción de dispositivos de red (NDES)	SCEP sobre HTTP/HTTPS	HTTP / HTTPS	ECM
Inscripción basada en navegador	CAWE (Inscripción web de California)	HTTPS	Inscripción web en California

Nota de seguridad

La pila de servicios web (MS-XCEP + MS-WSTEP) se implementa habitualmente con acceso a internet o a la DMZ. Es fundamental reforzar la autenticación, configurar TLS y segmentar la red correctamente. Los ataques de retransmisión tipo ESC8 también pueden dirigirse a los puntos finales CES basados ​​en HTTP si no están configurados para requerir HTTPS y Protección Extendida para la Autenticación (EPA).

5. MS-CAESO – Protocolo de inscripción automática de certificados (Archivado)

MS-CAESO El protocolo original que regía la inscripción automática de certificados en entornos Windows —la inscripción y renovación automáticas de certificados para usuarios y equipos de dominio según la Directiva de grupo— ha sido archivado, ya que su funcionalidad principal se ha integrado en las especificaciones MS-WCCE y MS-XCEP/MS-WSTEP.

Comprender MS-CAESO sigue siendo valioso para las organizaciones que utilizan entornos Windows antiguos o que auditan configuraciones PKI heredadas.

Plantilla de certificado y especificaciones de la política

6. MS-CRTD – Descripción de las plantillas de certificados

Las plantillas de certificados son la base de las implementaciones de ADCS empresariales. Definen qué certificados se pueden emitir, a quién, bajo qué condiciones y con qué extensiones de uso de claves. MS-CRTD Especifica la estructura exacta, los atributos y la codificación de los objetos de plantilla de certificado tal como se almacenan en Active Directory.

Qué abarca MS-CRTD

• Esquema de objetos de plantilla de certificado en Active Directory (clase de objeto, nombres de atributos, OID).
• La codificación de las políticas de uso extendido de claves (EKU) dentro de las plantillas.
• Políticas de emisión, configuración del nombre del sujeto, permisos de inscripción y descriptores de seguridad.
• Diferencias en el esquema de la plantilla entre la versión 1, la versión 2 y la versión 3.
• La relación entre los atributos de la plantilla y los campos del certificado resultante

Por qué esto es importante para la seguridad

Comprender MS-CRTD es fundamental para auditar las configuraciones erróneas de las plantillas de certificados, la causa principal de la mayoría de los ataques de escalada de privilegios relacionados con ADCS (ESC1 a ESC15). La vulnerabilidad ESC15 recientemente revelada (CVE-2024-49019) implicaba específicamente la explotación del comportamiento de la plantilla de esquema de la versión 1, lo que subraya por qué un conocimiento profundo de MS-CRTD es un requisito previo de seguridad.

Protocolos de administración de CA

7. MS-CSRA - Protocolo de administración remota de servicios de certificados

MS-CSRA Define las interfaces DCOM que se utilizan para administrar de forma remota una Entidad de Certificación. Es el protocolo que sustenta el complemento MMC de la Entidad de Certificación, la herramienta certutil.exe y la administración programática de CA a través de las API de Windows.

Operaciones administrativas cubiertas

• Iniciar y detener el servicio CA
• Visualización, aprobación, denegación y revocación de solicitudes de certificados pendientes.
• Gestionando la lista de revocación de certificados (CRL) y puntos de distribución de CRL (CDP)
• Configuración de las propiedades de CA (algoritmos de clave, programaciones de CRL, configuración de auditoría)
• Copia de seguridad y restauración de la base de datos de CA
• Consulta de la base de datos de la CA para obtener certificados emitidos, pendientes, fallidos y revocados.

MS-CSRA expone varias interfaces COM, incluidas ICertAdmin, ICertAdmin2, ICertView, ICertView2 e IEnumCERTVIEWROW. La administración remota de CA mediante MS-CSRA requiere pertenecer a los roles de Administrador de CA o Administrador de certificados. Las asignaciones de roles de CA mal configuradas representan un riesgo significativo de escalada de privilegios.

8. Protocolo de administración de respondedores en línea MS-OCSPA

El Protocolo de estado de certificado en línea El respondedor OCSP es un componente clave de la infraestructura PKI moderna. En lugar de requerir que los clientes descarguen y analicen archivos CRL extensos, OCSP permite la verificación de revocación de certificados en tiempo real mediante un sencillo mecanismo de solicitud-respuesta.

MS-OCSPA define las interfaces DCOM utilizadas para administrar el respondedor OCSP de Microsoft (el servicio de rol de respondedor en línea en ADCS), incluyendo la configuración de proveedores de revocación OCSP, la gestión de certificados de firma OCSP y su renovación automática, la supervisión del estado de la caché y el estado del respondedor OCSP, y la configuración de intervalos de actualización para los datos de revocación.

Mejores prácticas operativas

• Los respondedores OCSP deben configurarse con certificados de firma dedicados y de corta duración (no con el certificado de la CA en sí).
• Grapado OCSP Debe habilitarse en los servidores web para reducir el tráfico OCSP y mejorar el rendimiento.
• Múltiples respondedores OCSP detrás de un balanceador de carga mejoran la disponibilidad y eliminan los puntos únicos de fallo.

Inscripción en ADCS más allá de las especificaciones abiertas: NDES/SCEP y protocolos modernos

Si bien las especificaciones abiertas de Microsoft cubren los protocolos de inscripción nativos de Windows, ADCS también admite la inscripción a través de Protocolo simple de inscripción de certificados (SCEP) a través de la función de Servicio de inscripción de dispositivos de red (NDES).

NDES y SCEP

El protocolo SCEP permite que los dispositivos de red (enrutadores, conmutadores, puertas de enlace VPN, dispositivos IoT) que no pueden participar en un dominio de Windows soliciten certificados a una CA de ADCS. NDES actúa como autoridad de registro entre el dispositivo y la CA, validando las solicitudes de inscripción mediante un mecanismo de contraseña de desafío. SCEP está definido por un estándar IETF (RFC 8894) y cuenta con un amplio soporte por parte de los proveedores de dispositivos de red y las plataformas MDM.

Lo que ADCS no admite de forma nativa

ACME (RFC 8555): ADCS no implementa de forma nativa el protocolo ACME. ACME es el estándar utilizado por Let's Encrypt y cada vez más necesario para entornos DevOps modernos y nativos de la nube. Existen soluciones de terceros que permiten la conexión de ADCS con clientes compatibles con ACME.

EST (RFC 7030): ADCS no lo admite de forma nativa; EST es una alternativa más moderna a SCEP para dispositivos con recursos limitados y se implementa cada vez más junto con programas PKI de IoT.

API REST/JSON: ADCS no expone ninguna API REST nativa. La interacción se realiza a través de DCOM, SOAP o las interfaces COM CryptoAPI/CertEnroll.

Implicaciones de seguridad de los protocolos abiertos de ADCS

El conocimiento de la capa de protocolo ADCS se ha convertido en un requisito de seguridad fundamental, no solo en una preocupación para los desarrolladores. Las vulnerabilidades ESC se han generalizado en el ámbito de la seguridad informática, y se han documentado y utilizado como armas las vulnerabilidades ESC1, ESC2, ESC3, ESC6, ESC8 y ESC15. La siguiente tabla relaciona cada vulnerabilidad con su capa de protocolo.

Vulnerabilidad	Capa de protocolo	Causa principal	Notas
ESC1	MS-WCCE + MS-CRTD	La plantilla permite al solicitante proporcionar un nombre de asunto arbitrario.	De gran impacto; ampliamente explotado.
ESC2	MS-WCCE + MS-CRTD	La plantilla tiene cualquier EKU de propósito o ninguna restricción de EKU.	Amplio potencial de abuso de certificados
ESC3	MS-WCCE + MS-CRTD	Abuso del agente de inscripción a través del agente de solicitud de certificados EKU	Cadena de ataque en dos etapas
ESC6	MS-WCCE	El indicador EDITF_ATTRIBUTESUBJECTALTNAME2 está habilitado en CA	Indicador a nivel de CA, no a nivel de plantilla.
ESC8	MS-WSTEP / HTTP CES	Retransmisión NTLM a un punto final CES basado en HTTP	Ataque de retransmisión; requiere HTTP (no HTTPS)
ESC15	Plantillas MS-CRTD (V1)	Inyección arbitraria de políticas de aplicación en plantillas de esquema V1	CVE-2024-49019; se requiere parche.

Guía práctica: Uso de especificaciones abiertas en su programa PKI

Para arquitectos de PKI

• Utilice MS-CERSOD como referencia autorizada para el diseño de arquitecturas de inscripción, especialmente en nube híbrida o escenarios orientados a Internet
• Utilice MS-XCEP + MS-WSTEP para diseñar flujos de inscripción para dispositivos que no pertenecen al dominio, cargas de trabajo en la nube y usuarios remotos.
• Consulte MS-CRTD al diseñar nuevas plantillas de certificados para asegurarse de que la configuración de atributos coincida con su política de seguridad prevista.

Para ingenieros de seguridad

• Compare su configuración de ADCS con MS-CRTD para identificar configuraciones incorrectas de atributos de plantilla que correspondan a las condiciones de ESC.
• Revise las asignaciones de roles de CA en relación con MS-CSRA para garantizar que la superficie de administración de CA esté mínimamente expuesta.
• Asegúrese de que todos los puntos finales de CES (MS-WSTEP) requieran HTTPS y Protección extendida para la autenticación (EPA) para prevenir ataques de retransmisión.

Para desarrolladores

• Implemente clientes de inscripción personalizados utilizando las interfaces DCOM definidas en MS-WCCE y MS-ICPR para entornos de dominio.
• Utilice las interfaces SOAP MS-XCEP + MS-WSTEP para aplicaciones de inscripción multiplataforma o basadas en la web.
• Consulte MS-CSRA para crear herramientas de supervisión, auditoría o gestión del ciclo de vida de CA.

Para equipos de cumplimiento y auditoría

• Las especificaciones abiertas proporcionan evidencia a nivel de protocolo para las certificaciones de cumplimiento (FIP(Criterios Comunes, FedRAMP) sobre cómo se emiten y gestionan los certificados.
• Utilice las funcionalidades de MS-CSRA para crear un inventario automatizado de certificados y un sistema de monitorización del ciclo de vida, algo fundamental para estar preparado para las auditorías.

Cómo puede ayudar la consultoría de cifrado

Encryption Consulting se especializa en Estrategia PKI, arquitectura ADCS y gestión del ciclo de vida del certificado Para organizaciones empresariales y gubernamentales. Ya sea que esté implementando ADCS por primera vez, modernizando una infraestructura de clave pública (PKI) heredada, evaluando su infraestructura de certificados en busca de vulnerabilidades ESC o integrando ADCS con herramientas DevOps modernas, nuestro equipo aporta una profunda experiencia a nivel de protocolo a cada proyecto.

• Evaluaciones de estado de PKI: Auditorías a nivel de protocolo de su entorno ADCS conforme a las especificaciones abiertas de Microsoft y los estándares de endurecimiento de seguridad.
• Diseño de la arquitectura de ADCS: Diseño de la pila de inscripción (MS-WCCE, MS-XCEP/MS-WSTEP, NDES/SCEP), planificación de la jerarquía de CA y gobernanza de plantillas de certificados.
• Gestión del ciclo de vida de los certificados: descubrimiento, supervisión y renovación automatizados de certificados en toda su empresa.
• Refuerzo de la seguridad: Corrección de configuraciones incorrectas de ESC, refuerzo del rol de CA y optimización de la infraestructura CRL/OCSP.

Conclusión

Las especificaciones abiertas de Microsoft para ADCS son mucho más que material de referencia para desarrolladores. Constituyen la base técnica definitiva para comprender cómo se solicitan, emiten, administran y revocan los certificados en toda la empresa. Como ha quedado claro en el panorama de vulnerabilidades de ESC, las lagunas en el conocimiento del protocolo se traducen directamente en debilidades de seguridad explotables.

Ya sea que esté diseñando una nueva arquitectura de inscripción, reforzando una implementación de CA existente, creando herramientas integradas con PKI o realizando una evaluación de seguridad, dominar MS-WCCE, MS-XCEP, MS-WSTEP, MS-CRTD, MS-CSRA y sus estándares similares ya no es opcional. Un entorno ADCS bien gobernado no se limita a una configuración correcta. Requiere un profundo conocimiento de los protocolos que rigen cada interacción entre clientes, CA y los certificados que emiten. Invertir en este conocimiento hoy es la forma más confiable de anticiparse a las amenazas futuras a la infraestructura de certificados.