Cómo crear una jerarquía de CA ML-DSA en Microsoft AD CS

Respuesta rápida: La creación de una jerarquía de autoridad de certificación ML-DSA en AD CS en Windows Server 2025 sigue el mismo patrón de dos niveles (raíz y subordinada) que cualquier PKI clásica, con tres diferencias reales: el parámetro KeyLength se especifica en bits derivados del tamaño real de la clave del algoritmo (20 736 bits para ML-DSA-87), CryptoProviderName debe hacer referencia explícita al proveedor ML-DSA CNG, y no hay una ruta de actualización in situ, por lo que debe ser una nueva jerarquía establecida en paralelo a la producción, no una modificación de una CA existente. Necesita dos servidores con Windows Server 2025 con la actualización de seguridad de mayo de 2026 (KB5087539) o posterior, uno para la CA raíz y otro para la CA subordinada, además de un cliente Windows 11 unido al dominio con la actualización de octubre de 2025 o posterior para las pruebas de inscripción. Esta guía describe la configuración real: requisitos previos, configuración de la raíz y la subordinada, plantillas de certificados, validación y qué supervisar después de la implementación.

Nuestra guía de soporte de ML-DSA para Microsoft PKI explica el significado estratégico de esta capacidad. Esta guía es el complemento práctico: incluye los comandos y pasos de configuración necesarios para establecer una jerarquía de CA ML-DSA funcional en un entorno de laboratorio o piloto.

Puntos Clave

• Una jerarquía de CA ML-DSA requiere Windows Server 2025 con la actualización de seguridad de mayo de 2026 (KB5087539) o posterior tanto en el servidor raíz como en los servidores CA subordinados.
• El comando Install-AdcsCertificationAuthority de PowerShell requiere KeyLength en bits, calculado a partir del tamaño real de la clave del conjunto de parámetros ML-DSA, y un CryptoProviderName que hace referencia al proveedor CNG de ML-DSA.
• Las plantillas de certificados necesitan dos cambios específicos para ser compatibles con ML-DSA: un proveedor de almacenamiento de claves CNG no heredado y que el propósito esté configurado como Firma, ya que ML-DSA solo admite la firma, nunca el cifrado.
• AD CS admite los tres conjuntos de parámetros ML-DSA en modo puro, en la configuración de la jerarquía de CA, la emisión de certificados hoja y la firma de respuestas OCSP.
• No existe una ruta de actualización directa desde una CA existente; esta implementación debe configurar nuevas CA raíz y subordinadas en paralelo, validándolas antes de cualquier migración a producción.

Requisitos previos

• Se requiere un controlador de dominio que ejecute la última versión disponible de Windows Server; se recomienda Windows Server 2025.
• Dos servidores con Windows Server 2025 y la actualización de seguridad 2026-05 (KB5087539) o posterior: uno para la CA raíz y otro para la CA subordinada.
• Para las pruebas de inscripción: un cliente unido al dominio que ejecute Windows 11, versión 24H2 o 25H2, con la actualización no relacionada con la seguridad 2025-10 (KB5067036) o posterior.
• Se requiere ser miembro del grupo Administradores de dominio o equivalente para gestionar las plantillas de certificados y la instalación de roles de AD CS.

Configuración de la CA raíz

La CA raíz se puede configurar a través de la consola de la Autoridad de Certificación o mediante PowerShell. El método de PowerShell es más fiable para implementaciones de laboratorio y piloto reproducibles. El siguiente ejemplo utiliza ML-DSA-87, el conjunto de parámetros más alto:

# KeyLength is specified in bits. For ML-DSA-87: 2592 bytes x 8 = 20736 bits

# For Standalone Root CA (recommended for production)
Install-AdcsCertificationAuthority `
  -CAType StandaloneRootCA `
  -CACommonName "<your-root-ca-name>" `
  -KeyLength 20736 `
  -HashAlgorithm NoHash `
  -CryptoProviderName "ML-DSA:87#Microsoft Software Key Storage Provider"

# For Enterprise Root CA (lab and test environments)
Install-AdcsCertificationAuthority `
  -CAType EnterpriseRootCA `
  -CACommonName "<your-root-ca-name>" `
  -KeyLength 20736 `
  -HashAlgorithm NoHash `
  -CryptoProviderName "ML-DSA:87#Microsoft Software Key Storage Provider"

Sustituya el marcador de posición por el nombre común de su CA raíz. Se recomienda el patrón CA raíz independiente para implementaciones de raíz sin conexión en entornos de producción; la CA raíz empresarial es apropiada para entornos de laboratorio y prueba donde la raíz está unida a un dominio. Tenga en cuenta el valor HashAlgorithm: NoHash, ya que la construcción de firma de ML-DSA no utiliza un parámetro de algoritmo hash independiente como lo hace la configuración de CA RSA o ECDSA clásica. Después de la instalación, confirme que el certificado de CA raíz utiliza realmente el algoritmo ML-DSA seleccionado abriendo la consola de la Autoridad de Certificación (certsrv.msc) e inspeccionando las propiedades del certificado de CA.

Configuración de CA subordinada

La CA subordinada sigue el mismo patrón, emitida desde la raíz ML-DSA establecida anteriormente, completando una jerarquía PKI de dos niveles donde ambos niveles utilizan ML-DSA como algoritmo de firma. La protección post-cuántica completa depende de las firmas ML-DSA en toda la cadena de certificados, desde la raíz hasta los subordinados y los nodos hoja; una jerarquía con una raíz clásica y un subordinado ML-DSA no proporciona la protección que se pretende ofrecer con la migración, por lo que ambos niveles deben implementarse juntos como parte de la misma jerarquía paralela.

Configuración de plantillas de certificado

Una plantilla de certificado necesita dos cambios específicos antes de que sea compatible con ML-DSA:

1. Proveedor de GNC: Configure el proveedor de la plantilla a un proveedor de servicios criptográficos no heredado, específicamente un proveedor de almacenamiento de claves. Los algoritmos post-cuánticos solo están disponibles a través de proveedores CNG, nunca mediante la ruta CryptoAPI heredada.
2. Finalidad de la firma: En la sección "Gestión de solicitudes", establezca "Firma" como "Propósito". ML-DSA solo admite operaciones de firma, nunca cifrado, por lo que cualquier plantilla configurada para cifrado o intercambio de claves no ofrecerá ML-DSA como opción.

Para que los proveedores de CNG sean seleccionables en la plantilla, configure la compatibilidad de la Autoridad de certificación y del destinatario del certificado en al menos Windows Server 2008. Varias plantillas integradas ya tienen por defecto el Propósito: Firma, lo que significa que ML-DSA estará disponible simplemente configurando el Proveedor de almacenamiento de claves en la pestaña Criptografía; para cualquier otra plantilla, cambie primero el Propósito a Firma en la pestaña Gestión de solicitudes. Al configurar las extensiones, confirme que las Directivas de aplicación no incluyan OID relacionados con el cifrado, como Sistema de archivos cifrado o Correo electrónico seguro, y confirme que el Uso de claves no incluya opciones de cifrado como Permitir intercambio de claves solo con cifrado de claves, ya que cualquiera de ellas entrará en conflicto con un algoritmo de solo firma. Para crear una plantilla de firma de código ML-DSA específica, duplique una plantilla de firma de código existente y aplique los mismos cambios de proveedor y propósito.

Configuración de la firma de respuesta OCSP

La comprobación de revocación de los certificados emitidos por ML-DSA debe utilizar respuestas OCSP firmadas por ML-DSA para una protección post-cuántica completa de extremo a extremo. Duplique la plantilla de firma de respuesta OCSP integrada, establezca la categoría de proveedor en Proveedor de almacenamiento de claves y el nombre del algoritmo en el conjunto de parámetros ML-DSA elegido (por ejemplo, ML-DSA:65), otorgue permisos de inscripción e inscripción automática a la cuenta de equipo del respondedor en línea y emita la plantilla desde la CA subordinada configurada para ML-DSA. Añada una nueva configuración de revocación en la consola de administración del respondedor en línea que apunte al certificado de la CA subordinada de ML-DSA para completar la configuración.

Validación y Monitoreo

Antes de considerar un piloto como listo para producción, valide la cadena completa: emita un certificado hoja de prueba desde la CA subordinada de ML-DSA y confirme que el cliente de inscripción (Windows 11, 24H2 o 25H2, con KB5067036 o posterior) lo solicita, recibe y valida correctamente, ejercitando la ruta de inscripción real en lugar de solo inspeccionar los certificados en la consola. Confirme que las respuestas OCSP para ese certificado se validan correctamente utilizando la configuración de firma de ML-DSA. Para la supervisión continua, realice un seguimiento del volumen de emisión de certificados y cualquier fallo de inscripción específicamente en la nueva jerarquía, ya que un piloto de jerarquía paralela necesita su propia visibilidad separada de la supervisión de la CA de producción, y esté atento a los intentos de inscripción basados ​​en CSP heredados contra plantillas solo de ML-DSA, que aparecerán como un patrón de fallo distinto durante el período de transición.

Consideraciones sobre la reversión

Dado que se trata de una jerarquía paralela en lugar de una actualización in situ, la reversión es estructuralmente sencilla a nivel de infraestructura: la producción continúa operando con la jerarquía clásica existente durante todo el programa piloto, sin modificaciones. La principal consideración para la reversión radica en la confianza del cliente y la aplicación: una vez que los clientes comienzan a confiar en la nueva raíz ML-DSA como parte de las pruebas piloto, eliminar esa confianza de forma limpia, si es necesario abandonar el programa piloto, requiere la misma gestión explícita del almacén de confianza que se requirió al agregarla. Mantenga la distribución de confianza del programa piloto limitada a una población de prueba definida, en lugar de implementar la nueva raíz de forma generalizada hasta que la jerarquía esté completamente validada.

Lo que realmente recomendamos

Para las pruebas de laboratorio y el trabajo piloto, comience con ML-DSA-65, a menos que su entorno regulatorio requiera específicamente ML-DSA-87 (CNSA 2.0 o similar), ya que ofrece un menor tamaño de clave y firma, a la vez que proporciona sólidos márgenes de seguridad. Cree la cadena completa de raíz a subordinado a hoja en ML-DSA desde el principio, en lugar de mezclar niveles de algoritmos, ya que una jerarquía mixta no ofrece una protección post-cuántica genuina de extremo a extremo. Limite estrictamente la distribución de confianza durante la fase piloto y valide la ruta completa de inscripción y OCSP con hardware de cliente real antes de expandirse más allá de una población de prueba.

Cómo puede ayudar la consultoría de cifrado

Planificar con precisión qué plantillas de certificados, aplicaciones y dependencias CSP heredadas de su entorno deberán migrar a la nueva jerarquía ML-DSA es el trabajo de inventario que CBOM Secure está diseñado para respaldar, mapeando su conjunto de certificados existente y sus configuraciones de proveedor antes de que comience el programa piloto.

Nuestros servicios de asesoramiento de PQC planifican la implementación de jerarquía paralela, el alcance del proyecto piloto y la secuencia de transición a producción que se describen en esta guía, adaptándose a su entorno AD CS específico y a las dependencias de sus aplicaciones. Para las organizaciones que prefieren que la jerarquía de CA esté gestionada en lugar de ser autogestionada, CertSecure Manager emite y administra certificados ML-DSA, híbridos y clásicos en Microsoft AD CS y otras plataformas de CA desde un único plano de directivas.

Un patrón familiar, con diferencias reales.

La configuración de una jerarquía de CA ML-DSA en AD CS sigue el patrón de dos niveles que todo administrador de PKI conoce: raíz, subordinado, plantillas y OCSP. Las diferencias importantes son específicas y manejables una vez que se sabe dónde buscarlas: el tamaño de la clave en bits, la cadena del proveedor CNG de ML-DSA, el requisito de que solo se utilice la firma y la estricta restricción de que debe tratarse de una jerarquía nueva y paralela, en lugar de una modificación in situ de una CA existente. Configurar correctamente el entorno piloto, validándolo de principio a fin antes de tomar cualquier decisión de confianza en producción, es lo que convierte este ejercicio de laboratorio en una ruta de migración creíble.

Preguntas frecuentes

¿Qué valor de KeyLength debo usar para ML-DSA-87 en Install-AdcsCertificationAuthority?

20736 bits, derivado del tamaño de clave de 2,592 bytes de ML-DSA-87 (2,592 bytes multiplicados por 8 bits por byte). El parámetro KeyLength siempre se especifica en bits, no en bytes, lo que suele ser una causa de errores de configuración.

¿Puedo actualizar mi CA de producción existente a ML-DSA en lugar de crear una nueva jerarquía?

No. No existe una ruta de actualización directa. La compatibilidad con ML-DSA requiere la implementación de nuevas autoridades de certificación raíz y subordinadas, validadas en paralelo con el entorno de producción y posteriormente migradas de forma deliberada.

¿Por qué mi plantilla de certificado no muestra ML-DSA como un algoritmo disponible?

Generalmente, esto se debe a que la plantilla sigue utilizando un proveedor de servicios criptográficos antiguo en lugar de un proveedor de almacenamiento de claves CNG, o a que el campo "Propósito" en "Gestión de solicitudes" no está configurado como "Firma". Ambos cambios son necesarios para que ML-DSA aparezca como algoritmo seleccionable.

¿AD CS admite ML-DSA para la firma de respuestas OCSP?

Sí. Configurar una plantilla de firma de respuesta OCSP firmada por ML-DSA, emitida por una CA subordinada de ML-DSA, permite a los respondedores en línea proporcionar una verificación de revocación posterior a la computación cuántica de extremo a extremo para los certificados emitidos por ML-DSA.

¿Qué versión del cliente necesito para probar la inscripción de certificados ML-DSA?

Un cliente Windows 11 unido a un dominio, versión 24H2 o 25H2, con la actualización no relacionada con la seguridad 2025-10 (KB5067036) o posterior instalada.