Vuoi far firmare alla tua Enterprise CA (AD CS su Windows Server 2019) un CSR ECC/ECDH p‑384 senza indicare un template? Spoiler: non si può. Qui trovi perché, quali sono i limiti tecnici su Key Usage (Key Agreement vs Key Encipherment) e una procedura completa per ottenere il certificato giusto, senza perdere ore.
Il problema, in termini chiari
Un amministratore genera un CSR personalizzato con chiave ECC parametrizzata su ECDH p‑384 e vorrebbe farlo firmare dalla Certification Authority interna (AD CS Root CA) senza specificare un certificate template. La CA, però, rifiuta la richiesta finché non viene scelto un template e, quando si duplica un template per adeguarlo, non si riesce a combinare i Key Usage Key Agreement e Key Encipherment, combinazione che compare nell’esempio di certificato da replicare.
Come funziona davvero AD CS rispetto ai template
In un’infrastruttura Enterprise CA (integrata con Active Directory) ogni certificato emesso deve essere basato su un certificate template registrato in AD. Il template è il veicolo delle policy di sicurezza: definisce algoritmi ammessi, lunghezze chiave, Key Usage/EKU, requisiti del Subject/SAN, permessi di Enroll, ecc. Quando invii un CSR a una Enterprise CA:
- la CA ignora o sovrascrive gli attributi del CSR che non coincidono con il template;
- se la richiesta non presenta (o non viene indicato via attributo) un template valido, la CA risponde con errore e non emette.
Solo una Standalone CA (non integrata con AD) può accettare un CSR senza indicazione di template. Anche in quel caso, però, la CA applica i propri vincoli locali (policy di modulo, impostazioni di crittografia consentite) e, di default, richiede approvazione manuale.
Perché non puoi avere “Key Agreement + Key Encipherment” con ECDH
Qui sta l’inganno che fa perdere tempo: con le chiavi ECC di tipo ECDH il Key Usage consentito è Key Agreement. Il Key Usage Key Encipherment è tipico delle chiavi RSA usate per il trasporto di chiavi (key transport) e non si applica all’algoritmo ECDH, che serve a derivare un segreto condiviso, non a cifrare una chiave pubblica dell’altro estremo.
Ne consegue che:
- una Enterprise CA Microsoft non emetterà un certificato ECC/ECDH con il bit Key Encipherment impostato;
- la combinazione “Agreement + Encipherment” è intrinsecamente incoerente per ECDH e va evitata;
- se ti serve davvero Key Encipherment, devi usare RSA. ECDSA è un algoritmo di firma, non di encipherment: non risolve quel requisito.
Nota di contesto: nelle implementazioni moderne di TLS, specie in TLS 1.3, il certificato del server è usato per firma (Digital Signature). Il trasporto di chiave (Key Encipherment) riguarda i vecchi scambi RSA dell’era TLS 1.0–1.2; con suite ECDHE non è più necessario. Se qualche apparato pretende ancora Key Encipherment per un certificato ECC, il requisito è probabilmente frutto di una verifica obsoleta.
Riepilogo veloce: cosa si può e cosa non si può
| Aspetto | Dettagli |
|---|---|
| Obbligo del template (Enterprise CA) | Ogni richiesta deve riferirsi a un template registrato. Il template fa rispettare le policy; la CA sovrascrive quanto non combacia col template. |
| Standalone CA | Può firmare un CSR privo di campo CertificateTemplate, ma applica comunque i propri vincoli e, di norma, richiede approvazione manuale. |
| Key Usage con ECDH | Supportato: Key Agreement. Non supportato: Key Encipherment. La combinazione Agreement + Encipherment non è valida. |
| Quando serve Key Encipherment | Usa RSA. Con ECC/ECDH non è tecnicamente applicabile; ECDSA non aggiunge Key Encipherment. |
| Come procedere con Enterprise CA | Duplicare un template, abilitarlo per ECC, impostare solo Key Agreement (ed eventuali EKU), pubblicarlo e inviare il CSR con certreq indicando il template. |
Strategia risolutiva consigliata
- Decidi il tipo di CA:
- Standalone CA: firmi senza template, con revisione manuale e vincoli locali. Utile per laboratorio o casi particolari.
- Enterprise CA (scenario tipico): il template è obbligatorio; è l’unico modo “supportato” per governare l’emissione.
- Crea un template ad hoc:
- Duplica un template base (es. Computer o User) con compatibilità recente.
- Imposta l’algoritmo su ECC e, se vuoi usare ECDH p‑384, seleziona Key Storage Provider con ECDH_P384.
- In Key Usage abilita Key Agreement; non selezionare Key Encipherment.
- Aggiungi gli Application Policies (EKU) effettivamente richiesti (p.es. Server Authentication e/o Client Authentication).
- Imposta Subject Name su Supply in the request se il CSR contiene SAN/Subject personalizzati.
- Concedi i permessi di Enroll (e Auto‑Enroll se serve) ai gruppi/utenti interessati.
- Pubblica il template: Certificate Templates → New → Certificate Template to Issue.
- Allinea o rigenera il CSR:
- Se resti in Enterprise CA, non forzare nel CSR impostazioni che confliggono con il template: verranno ignorate o causeranno errore.
- Se il tuo target è un certificato ECC per TLS, considera seriamente ECDSA (firma) al posto di ECDH (accordo chiavi), perché i server usano la firma del certificato; per ECDSA il Key Usage giusto è Digital Signature.
- Invia la richiesta con il template esplicito:
certreq -submit -attrib "CertificateTemplate:NomeMioTemplate" richiesta.csrCosì la CA applica esattamente le regole del template scelto, senza tentare di “interpretare” il CSR. - Se ti serve davvero Key Encipherment:
- cambia algoritmo e usa RSA (Digital Signature + Key Encipherment è la coppia tipica);
- in alternativa, usa una CA esterna non‑Microsoft che consenta override manuali — ma sappi che molti client rifiuteranno comunque combinazioni non coerenti.
Procedura dettagliata — Enterprise CA (Windows Server 2019)
Preparazione del template
- Apri certtmpl.msc sul server CA (o su un server con gli strumenti RSAT).
- Click‑destro su un template base (es. Computer) → Duplicate Template.
- Compatibility: imposta Windows Server 2016/2019 e Windows 10/11 per abilitare pienamente ECC.
- Vai alla scheda Cryptography:
- Provider Category: Key Storage Provider.
- Algorithm: seleziona ECDHP384 se vuoi chiave di accordo p‑384 (oppure ECDSAP384 se punti a un certificato per firma ECC).
- Request hash: SHA‑384 (coerente con p‑384), salvo esigenze diverse.
- Scheda Extensions → Key Usage → Edit:
- per ECDH abilita Key Agreement e disabilita Key Encipherment;
- per un certificato ECDSA da usare in TLS, abilita Digital Signature (niente Key Encipherment).
- Scheda Extensions → Application Policies (EKU):
- aggiungi Server Authentication se il certificato è per un servizio server;
- aggiungi Client Authentication se il certificato è per autenticazione client;
- lascia solo gli EKU necessari: meno è meglio.
- Scheda Subject Name:
- se il CSR fornisce CN e SAN, seleziona Supply in the request;
- se vuoi far generare i nomi dalla directory, usa Build from this Active Directory information (ma il CSR dovrà allinearsi).
- Scheda Security: assegna a utenti o gruppi i permessi Enroll/Autoenroll richiesti.
- Salva. Nella console Certification Authority → Certificate Templates → New → Certificate Template to Issue e pubblica il nuovo template.
Invio e rilascio del certificato
- Verifica il CSR:
certutil -dump richiesta.csr - Invia indicando esplicitamente il template:
certreq -submit -attrib "CertificateTemplate:NomeMioTemplate" richiesta.csrSe hai più CA o un nome non standard, specifica il configurazione:-config "CAHOST\NOME-CA". - Se l’emissione è in modalità manuale, approva la richiesta in Pending Requests.
- Accetta il certificato sul sistema che ha generato la coppia di chiavi:
certreq -accept certificato.cer
Verifica post‑emissione
certutil -v -dump certificato.cer | more- Controlla l’estensione Key Usage: per ECDH deve esserci Key Agreement, non Key Encipherment.
- Controlla gli EKU (Application Policies) siano quelli previsti.
- Verifica la catena, CRL/AIA e gli scopi applicativi (es. TLS, S/MIME, IPsec).
Procedura alternativa — Standalone CA
Se hai margine di architettura (o per laboratorio), una Standalone CA può firmare un CSR che non indica template. Attenzione però: i vincoli del modulo di policy e di crittografia restano e i Key Usage invalidi per l’algoritmo verranno rifiutati.
- Installa una Standalone CA su un server isolato (offline) se vuoi test.
- Configura le impostazioni di accettazione (approvazione manuale consigliata).
- Invia il CSR:
certreq -submit richiesta.csr - Approva e scarica il certificato. Ricorda che l’assenza di template trasferisce su di te la responsabilità di coerenza e sicurezza.
Preparare un CSR “pulito” (consigli pratici)
In Enterprise CA, il template vince sempre. Questo non significa che il CSR non conti: deve comunque essere compatibile col template (Subject/SAN, dimensione chiave quando rilevante, algoritmi ammessi). Un esempio di INF per generare un CSR ECC coerente con p‑384:
; request.inf — CSR per ECDSA P-384 (consigliato per TLS)
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=[www.example.local](http://www.example.local)"
KeyAlgorithm = ECDSA_P384
KeyLength = 384
Exportable = TRUE
RequestType = PKCS10
HashAlgorithm = sha384
; Se devi fornire SAN:
[Extensions]
2.5.29.17 = "{text}"
continue = "dns=[www.example.local](http://www.example.local)&"
continue = "dns=example.local" Se davvero ti serve una chiave di accordo ECDH (per scenari particolari come S/MIME a coppie di chiavi), cambia KeyAlgorithm in ECDH_P384, ma ricordati che quel certificato non sarà adatto come server certificate in TLS: per i server usa ECDSA oppure RSA.
Messaggi di errore tipici e come uscirne
| Errore | Causa probabile | Rimedi |
|---|---|---|
0x80094801 (CERTSRVENOCERTTYPE) – la richiesta non contiene un template | CSR inviato a Enterprise CA senza indicare un template, o template non pubblicato/permessi mancanti. | Pubblica il template e invia con -attrib "CertificateTemplate:Nome"; verifica i permessi di Enroll. |
0x80094800 (CERTSRVEUNSUPPORTEDCERTTYPE) – template non supportato | Template duplicato con impostazioni incompatibili (es. Key Usage non coerenti con l’algoritmo). | Adegua Cryptography e Key Usage: per ECDH lascia solo Key Agreement, rimuovi Key Encipherment. |
| Il certificato emesso non rispecchia il CSR | Comportamento atteso in Enterprise CA: prevale il template. | Verifica e, se serve, modifica il template; evita di “combattere” con il CSR. |
Checklist rapida di progetto
- Scenario TLS moderno: preferisci ECDSA p‑256/p‑384 con Key Usage Digital Signature e EKU Server Authentication.
- Compatibilità legacy: se qualche dispositivo pretende Key Encipherment, usa RSA; valuta i costi di compatibilità vs sicurezza/performance.
- Enterprise CA: crea un template dedicato, pubblichilo, invia il CSR con
certreq -submit -attrib "CertificateTemplate:...". - Standalone CA: usala solo se sai perché ti serve e accetti l’onere di revisione manuale.
- Validazioni: ispeziona sempre Key Usage, EKU, SAN nel certificato emesso (
certutil -v -dump).
Domande frequenti
Posso “disattivare” l’obbligo del template su Enterprise CA?
No. È un pilastro architetturale di AD CS: i template impongono le policy di emissione centralizzate. Il bypass richiederebbe declassare la CA a Standalone, perdendo integrazione con AD e le automazioni enterprise.
Posso forzare la CA a emettere ECC/ECDH con Key Encipherment?
No. Non è un limite “di Microsoft” arbitrario: è un vincolo tecnico coerente con gli standard. Key Encipherment è legato all’uso RSA per key transport; con ECDH si deriva un segreto condiviso. Sono paradigmi diversi.
Mi serve davvero ECDH per TLS server?
In generale no. Il certificato del server deve firmare (Digital Signature). Usa ECDSA (o RSA) per il certificato; ECDHE farà l’accordo delle chiavi in modo effimero durante il handshake.
Non vedo il mio nuovo template nella pagina di enrollment
Assicurati di averlo pubblicato nella CA, che il livello di compatibilità non escluda i tuoi client, e che gli account abbiano permessi di Enroll. La replica AD potrebbe richiedere qualche minuto nei domini grandi.
Guida passo‑passo: esempi concreti
Esempio A — Certificato TLS ECC moderno (ECDSA p‑384)
- Duplica un template Computer con compatibilità Windows 2016/2019.
- Cryptography: ECDSA_P384, hash SHA‑384.
- Key Usage: Digital Signature (solo).
- EKU: Server Authentication (e Client Authentication solo se serve anche mTLS).
- Subject: Supply in the request.
- Pubblica il template e invia:
certreq -submit -attrib "CertificateTemplate:TLS-ECDSA-P384" richiesta.csr
Esempio B — Certificato di accordo chiavi ECC (ECDH p‑384)
- Duplica il template e imposta ECDH_P384.
- Key Usage: Key Agreement (solo).
- EKU: dipende dall’applicazione (es. Document Encryption in scenari specifici). Evita Server Authentication se non è davvero un server TLS.
- Invia il CSR con il template dedicato.
Esempio C — Devi avere Key Encipherment
- Duplica un template RSA (o cambia Cryptography su RSA con dimensione chiave adeguata, es. 3072).
- Key Usage: Digital Signature + Key Encipherment.
- EKU: Server Authentication se è per TLS.
- Invia e verifica la presenza del bit Key Encipherment nel certificato emesso.
Trucchi operativi e buon senso
- Non replicare ciecamente certificati “di esempio”: verifica che la combinazione di Key Usage ed EKU abbia senso per l’algoritmo scelto.
- Template separati per scopi diversi: TLS server, mTLS client, firma codice, S/MIME — ognuno con KU/EKU minimali.
- Evita over‑provisioning (es. mettere tutti gli EKU): riduce la sicurezza e può rompere la compatibilità.
- Usa p‑256 se la compatibilità è prioritaria; p‑384 se cerchi un margine di sicurezza maggiore e i client lo supportano.
- Documenta in modo sintetico le scelte nel campo Properties → General → Template display name/description.
Checklist di verifica finale
- Ho scelto l’algoritmo giusto? TLS server: ECDSA o RSA. ECDH solo per accordo chiavi in scenari speciali.
- I Key Usage sono coerenti? ECDH → Key Agreement; ECDSA → Digital Signature; RSA (TLS legacy) → Digital Signature + Key Encipherment.
- Gli EKU sono minimi e corretti? Solo quelli necessari.
- Il template è pubblicato e i permessi sono corretti? Enroll/Autoenroll impostati.
- Il CSR è coerente? Subject/SAN, hash, key size e provider in linea con il template.
- Verifica con
certutil -v -dumpe prova l’uso reale (es. handshake TLS).
Conclusione
Con AD CS su Windows Server 2019 la regola è semplice: in Enterprise CA non esistono emissioni “senza template”. Se la tua richiesta è ECC/ECDH, il certificato potrà avere Key Agreement ma non Key Encipherment. Per ottenere davvero un certificato con Key Encipherment devi passare a RSA, oppure riconsiderare il requisito (spesso non più necessario in TLS moderno). Seguendo la procedura qui sopra—template ad hoc, invio con certreq e verifiche—otterrai certificati coerenti, sicuri e compatibili senza dover combattere con il CSR.
Appendice — Comandi utili
# Elenco configurazioni CA disponibili sul client
certutil -config - -ping
Invio della richiesta forzando il template
certreq -submit -attrib "CertificateTemplate:NomeMioTemplate" richiesta.csr
Accettazione del certificato rilasciato (installa catena nel personal store)
certreq -accept certificato.cer
Ispezione dettagliata di CSR/certificato
certutil -v -dump richiesta.csr
certutil -v -dump certificato.cer Appendice — Decisore rapido
| Se vuoi… | Allora… |
|---|---|
| Un certificato server TLS moderno con ECC | Usa ECDSA con Digital Signature e EKU Server Authentication. |
| Un certificato con Key Encipherment | Usa RSA (Digital Signature + Key Encipherment). Evita ECC/ECDH per questo scopo. |
| Firmare un CSR senza template | Usa una Standalone CA e approvazione manuale; in Enterprise CA non è possibile. |
| Replicare un certificato “Agreement + Encipherment” su ECC | Non è supportato. Correggi il requisito o cambia algoritmo. |
Best practice finale: modella i template come “contratti” tra sicurezza e operatività. Un template ben fatto evita decine di ticket futuri e ti protegge da errori sottili (come chiedere Key Encipherment con ECDH).