Firmar un CSR sin plantilla en AD CS (Windows Server 2019): ECC/ECDH, Key Usage y escenarios TLS modernos

¿Tu CA de Windows Server 2019 (AD CS) puede firmar un CSR sin plantilla y emitir un certificado ECC con “Key Agreement” y “Key Encipherment”? En este artículo resolvemos ambas dudas con respuestas claras, fundamentos técnicos y pasos prácticos que puedes aplicar hoy mismo.

Índice

Resumen rápido para quien va al grano

Firmar un CSR sin plantilla: no en una Enterprise CA; sí en una Standalone CA (con controles y política propios de la CA).
ECC/ECDH con Key Agreement + Key Encipherment: no es una combinación válida en AD CS. Con ECDH solo procede Key Agreement; Key Encipherment es propio de RSA.
Para TLS moderno: usa ECDSA con Digital Signature. Para compatibilidad con “Key Encipherment”, usa RSA. Para ECDH estático (escenario raro), usa ECC con Key Agreement únicamente.

Contexto de la consulta

La pregunta original plantea dos retos: (1) si una CA de Windows Server 2019 (AD CS) puede firmar una solicitud PKCS#10 (CSR) sin usar plantillas, y (2) si es posible replicar un certificado que muestra curva ECC (ej. ECDH P‑384) con Key Usage que incluye tanto Key Agreement como Key Encipherment. Además, aparece la mención “ECDH348”, que muy probablemente es un error tipográfico de ECDH P‑384.

Conceptos clave en 2 minutos

Enterprise CA vs Standalone CA

Enterprise CA: depende de Certificate Templates. Las plantillas dictan atributos críticos (Key Usage, EKU, longitudes de clave, CSP/KSP, etc.). La CA alineará lo solicitado a lo que establezca la plantilla.
Standalone CA: no usa plantillas. Puedes enviar un CSR “tal cual” y el emisor decide. Aun así, la CA impone su política mínima (no permitirá combinaciones inválidas).

Key Usage vs Extended Key Usage (EKU)

Key Usage (KU): capacidades criptográficas del par de claves (p. ej., Digital Signature, Key Encipherment, Key Agreement).
Extended Key Usage (EKU): propósitos de aplicación (p. ej., Server Authentication, Client Authentication).

Algoritmos comunes en TLS

RSA: puede firmar y cifrar claves (acomoda Digital Signature y Key Encipherment).
ECC/ECDSA: firma digital. Para TLS, se usa junto con un intercambio de claves efímero (ECDHE). El certificado del servidor necesita Digital Signature, no Key Agreement.
ECC/ECDH estático: clave para acuerdo (Key Agreement) sin firma; es poco usado hoy en TLS.

¿Se puede firmar un CSR sin plantilla en AD CS?

Respuesta corta:

Enterprise CA: no. Debes seleccionar una plantilla; la CA aplicará la política de esa plantilla y puede sobrescribir atributos incompatibles presentes en el CSR (SAN, EKU, KU, proveedor criptográfico, etc.).
Standalone CA: sí. Puedes enviar el CSR sin plantilla. La CA aplicará su política, pero no está condicionada por plantillas de AD.

Diagnóstico rápido

Si la interfaz (web de enrolamiento o certreq) te exige nombrar una plantilla o te limita a plantillas publicadas, estás ante una Enterprise CA.
Si lo emitido no refleja lo que pediste en el CSR, es porque la plantilla y la política de la CA han prevalecido (comportamiento esperado).

¿Se puede mezclar Key Agreement y Key Encipherment con ECDH?

No en AD CS. Con claves ECC de tipo ECDH, el uso válido es Key Agreement. Key Encipherment está pensado para cifrar claves de sesión con RSA. Por tanto, AD CS no ofrece una forma admitida de emitir un certificado ECC/ECDH que marque simultáneamente ambos bits (Key Agreement + Key Encipherment).

¿Y para TLS con ECC?

En TLS moderno se usa ECDHE (acuerdo efímero) con autenticación por firma del certificado del servidor. El certificado no necesita “Key Agreement”; necesita Digital Signature. Por eso, la configuración típica es ECDSA con Digital Signature y EKU Server Authentication.

Mapa de decisiones: ¿qué emitir según tu objetivo?

Objetivo	Algoritmo recomendado	Key Usage	EKU típico	Notas
TLS moderno (1.2/1.3) para servidor web	ECC ECDSA (P‑256/P‑384)	Digital Signature	Server Authentication	El intercambio de claves es ECDHE efímero; el certificado solo firma.
Compatibilidad con sistemas que exigen Key Encipherment	RSA (≥ 2048 bits)	Key Encipherment (y opcional Digital Signature)	Server Authentication	Modelo clásico de RSA para cifrado de la clave de sesión.
ECDH estático (casos heredados/poco comunes)	ECC ECDH	Key Agreement	Dependiendo del uso	No mezclar con Key Encipherment; revisar compatibilidad del consumidor.

Pasos prácticos en una Enterprise CA (lo que probablemente tienes)

En una Enterprise CA no podrás emitir sin plantilla. La vía correcta es crear (o duplicar) una plantilla alineada con tu objetivo y enrolarte contra esa plantilla.

Crear una plantilla ECDSA para TLS

Abre Certificate Templates en la consola certsrv.msc de la CA (o certtmpl.msc en un equipo con las herramientas RSAT).
Duplica una plantilla base (p. ej., Web Server) y ponle un nombre claro (ej.: WebServer‑ECDSA‑P384).
En Cryptography:
- Provider Category: Key Storage Provider.
- Algorithm: ECDSA_P384 (o P‑256 según política).
- Hash: SHA‑256 o superior.
En Extensions > Key Usage: marca Digital Signature únicamente.
En Extensions > Application Policies (EKU): incluye Server Authentication (y opcionalmente Client Authentication si será dual).
En Subject Name:
- Si quieres que el solicitante aporte el Subject/SAN: selecciona Supply in the request.
- Si prefieres construir desde AD: Build from this Active Directory information (útil para autoenrolamiento).
En Security: concede Enroll/Autoenroll a los grupos necesarios.
Publica la plantilla: en la consola de la CA, botón derecho en Certificate Templates > New > Certificate Template to Issue.

Crear una plantilla RSA si necesitas Key Encipherment

Duplica Web Server en certtmpl.msc.
En Cryptography: selecciona RSA (≥ 2048 bits) con KSP Microsoft Software Key Storage Provider.
En Key Usage: marca Key Encipherment (y opcional Digital Signature para mayor compatibilidad).
EKU: Server Authentication.
Publica la plantilla y gestiona permisos como en el caso anterior.

Plantilla ECDH (solo si un sistema lo exige)

Duplica una plantilla adecuada (p. ej., User o una personalizada).
En Cryptography, elige algoritmo ECDH_P256/P384 según la política del KSP.
En Key Usage: marca Key Agreement únicamente.
Publica la plantilla. Verifica que el consumidor del certificado soporta ECDH estático.

Cómo enviar la solicitud (CSR) desde el equipo solicitante

Puedes usar el MMC de certificados o certreq. A continuación, ejemplos con certreq usando un archivo .inf.

Ejemplo INF para ECDSA (TLS moderno)

; request-ecdsa-p384.inf
[Version]
Signature="$Windows NT$"

\[NewRequest]
Subject = "CN=[www.ejemplo.com](http://www.ejemplo.com), O=Mi Empresa, C=ES"
KeyAlgorithm = ECDSA\_P384
ProviderName = "Microsoft Software Key Storage Provider"
HashAlgorithm = SHA256
Exportable = TRUE
RequestType = PKCS10
; El KU lo impondrá la plantilla (Digital Signature)

\[Extensions]
; Subject Alternative Name (SAN)
2.5.29.17 = "{text}"
continue = "dns=[www.ejemplo.com](http://www.ejemplo.com)&"
continue = "dns=ejemplo.com"

\[RequestAttributes]
CertificateTemplate = "WebServer-ECDSA-P384"

Genera y envía la solicitud:

certreq -new request-ecdsa-p384.inf request.req
certreq -submit -config "CAHOST\NOMBRE-CA" request.req cert.cer
certreq -accept cert.cer

Ejemplo INF para RSA con Key Encipherment

; request-rsa-2048.inf
[Version]
Signature="$Windows NT$"

\[NewRequest]
Subject = "CN=legacy.ejemplo.com, O=Mi Empresa, C=ES"
KeyAlgorithm = RSA
KeyLength = 2048
ProviderName = "Microsoft Software Key Storage Provider"
HashAlgorithm = SHA256
Exportable = TRUE
RequestType = PKCS10
; Key Encipherment será aplicado por la plantilla RSA

\[Extensions]
2.5.29.17 = "{text}"
continue = "dns=legacy.ejemplo.com"

\[RequestAttributes]
CertificateTemplate = "WebServer-RSA-2048"

¿Y si necesito firmar “ese CSR tal cual” sin plantillas?

La opción es montar una Standalone CA (idealmente offline) para emisiones puntuales o excepcionales. Pasos mínimos:

Instala Active Directory Certificate Services en modo Standalone Root CA (o Subordinate si procede) en un servidor aislado.
Configura la CA (valida periodos, CRL y seguridad). Considera que Web Enrollment es opcional y está deprecado.
Envía el CSR:
- certreq -submit -config "CAHOST\CA-NAME" archivo.req
- Un administrador aprobador lo evalúa y emite manualmente.
La CA podrá aceptar más variedad, pero seguirá rechazando combinaciones inválidas (p. ej., ECDH con Key Encipherment).

Validación del certificado emitido

Siempre valida que la CA impuso lo correcto:

certutil -dump cert.cer

Comprueba:

Key Usage: que corresponde a la plantilla/objetivo (Digital Signature para ECDSA; Key Encipherment para RSA; Key Agreement para ECDH).
EKU: Server Authentication si es un servidor.
Algoritmo: ECDSA_P256/P384 o RSA 2048/3072/4096 según corresponda.
SAN: todos los DNS necesarios.

Errores frecuentes y cómo resolverlos

El certificado emitido no incluye mi SAN/Key Usage del CSR: en Enterprise CA la plantilla manda. Ajusta la plantilla (Subject Name: Supply in the request, EKU/KU coherentes) y vuelve a emitir.
Error al elegir ECDH con KU de cifrado: no mezcles ECDH con Key Encipherment; no es válido en AD CS.
Proveedor criptográfico incompatible: usa Microsoft Software Key Storage Provider (KSP) salvo requerimiento de HSM. Si tu HSM impone su KSP/CSP, ajusta la plantilla para permitirlo.
Autoenrolamiento no entrega certificados: revisa permisos (Enroll/Autoenroll), GPO aplicada, plantillas publicadas y que el equipo/usuario cumple los filtros.
“ECDH348” en la documentación del cliente: probablemente querían decir ECDH P‑384.

Buenas prácticas de seguridad y operación

Separa roles: CA raíz offline y SubCA emisoras online.
CRL/AIA: planifica publicación accesible para clientes (HTTP/LDAP) y la caducidad de CRL/OCSP.
Auditoría: habilita registros de emisión, denegación y renovaciones.
Rotación de algoritmos: ECDSA P‑256/P‑384 o RSA ≥ 2048; evita tamaños obsoletos.
Plantillas versionadas: evita cambios disruptivos creando nuevas plantillas (p. ej., WebServer‑ECDSA‑P384‑v2).

Preguntas frecuentes

¿Puedo conseguir que la Enterprise CA firme un CSR sin plantilla si lo envío por la web?

No. La Enterprise CA requiere plantillas. El formulario de “base‑64‑encoded PKCS#10” no anula ese requisito; al emitir, la CA mapeará a una plantilla publicada.

¿Puedo forzar Key Encipherment con ECC?

No. Key Encipherment está ligado al uso de claves RSA para cifrar material de clave. Con ECC, la vía es ECDSA (firma) o ECDH (acuerdo). AD CS no combina Key Encipherment con ECDH.

Para TLS 1.3, ¿qué debo elegir?

Certificado ECDSA con Digital Signature y EKU Server Authentication, más un intercambio ECDHE efímero en el protocolo. Es la opción preferida por rendimiento y seguridad.

¿Y si un dispositivo heredado exige RSA y ciertos EKU/KU?

Emite una plantilla RSA con Key Encipherment y los EKU que demande (Server/Client Authentication, etc.). Considera mantener coexistencia ECDSA y RSA durante una transición ordenada.

Checklist operativo

Define el objetivo: TLS moderno (ECDSA), legado (RSA) o caso singular (ECDH estático).
Elige el tipo de CA oportuno: Enterprise (con plantillas) o Standalone (para casos especiales sin plantillas).
Prepara la plantilla correcta (algoritmo, KU, EKU, KSP, periodos, exportabilidad).
Publica la plantilla y asigna permisos de Enroll/Autoenroll.
Genera el CSR con certreq o MMC; incluye SAN si corresponde.
Emite y valida con certutil -dump.
Despliegue y pruebas: cadena de confianza, CRL/AIA alcanzables, compatibilidad TLS.

Conclusión

En AD CS de Windows Server 2019, la Enterprise CA siempre emite mediante plantillas, mientras que la Standalone CA permite firmar CSRs sin ellas (aunque bajo su política). Para ECC, recuerda la regla de oro: ECDSA = Digital Signature, ECDH = Key Agreement. Si un requisito te obliga a Key Encipherment, estás hablando de RSA. Con estas pautas y los pasos prácticos anteriores, tendrás certificados coherentes, seguros y alineados con tu caso de uso real.

Nota final: “ECDH348” casi con seguridad se refiere a ECDH P‑384.