Microsoft AD CS
Prepare the Windows template, register the CA and issue with the intended key and identity. The in-app Docs include this workflow in English, Croatian and German from 1.0.33.
Documentation for 1.0.33. Screenshots show example data.
1. Choose the authority and key
Use a Windows Enterprise CA and an approved online Windows agent with access to it. Standalone CAs do not use AD certificate templates. Check the issuing CA certificate's public key in Certification Authority. For a subordinate CA, its own certificate signature describes its parent; also inspect a certificate the subordinate actually issues.
2. Prepare a Windows template
In certtmpl.msc, duplicate Web Server and configure the copy. For an RSA web-server example, use these settings:
- ▸General: choose a display name and record the internal Template name, for example
Ens0keyWebRSA. Set validity according to your policy. - ▸Compatibility: choose versions supported by the actual CA and clients. KSP needs at least Windows Server 2008 CA and Vista / Server 2008 recipients.
- ▸Cryptography: Key Storage Provider, RSA, minimum 2048 bits, Microsoft Software Key Storage Provider, request hash SHA256 and alternate signature format unchecked.
- ▸Request Handling: Signature and encryption.
- ▸Subject Name: Supply in the request.
- ▸Extensions: Server Authentication application policy, Digital Signature and Key Encipherment key usage.
If the provider category is disabled, review Compatibility. For a legacy CSP template, select Microsoft RSA SChannel Cryptographic Provider with at least 2048 bits and remove the DH provider. Determined by CSPis expected in that mode. Template settings do not replace selecting RSA when ens0key generates the external CSR.
ens0key generates the key on its server and sends only the CSR through the agent to ADCS. Enrollment does not require the Windows template's private-key export option; the key remains encrypted in the ens0key vault.
3. Grant enrollment rights and publish
Grant Read + Enroll on the template to the actual submitting identity. A LocalSystem agent normally authenticates to a remote CA as its computer account, such as DOMAIN\AGENTHOST$; a domain service account needs its own rights. Check the CA's Request Certificates permission too. Enrollment does not require CA administration; revocation has separate permissions.
Restrict enrollment because Supply in the request accepts requested names. The agent submission expects immediate issuance; Windows CA manager approval or authorized-signature requirements need a separate manual process. ens0key's approval workflow is independent.
In certsrv.msc, open the intended CA and choose Certificate Templates → New → Certificate Template to Issue. Publish your copy and confirm it is listed. Creating a template alone does not publish it. Use its internal name in requests.
4. Register the CA
Under PKI → Certificate authorities, register Microsoft ADCS, select the Windows agent and discover or enter the CA configuration <CA host>\<CA common name>. Select a suggested template or type a published internal name. Registration shows progress and retains the form on failure; correct the error and retry.
Confirm CA cert imported, or use Fetch CA cert. Check the full issuing chain, including root and intermediate certificates. Discovery alone does not prove RPC/DCOM enrollment access. Template suggestions are saved at registration; a newly published name can be typed without deleting and recreating the CA integration.
ens0key 1.0.33 · Example data
5. Issue and inspect
In Enroll → Issuance, choose the authority and template, enter identity, then key and validity. For the example above select RSA 2048, a Common Name such as service.example.com, the same DNS SAN and, if clients connect by IP, an IP SAN such as 192.0.2.150. DNS and IPv4/IPv6 fields accept comma- or whitespace-separated values. An IP entered as a DNS SAN is not an X.509 IP SAN; adding a name does not create a DNS record.
ADCS template and CA policy control actual validity. Inspect the issued certificate in Inventory: key algorithm/size, Server Authentication, DNS/IP SAN types, dates, issuer, signature, complete chain and private key availability. Approval retains the requested key and template; renewal creates a new key with the existing algorithm and size.
For controller deployment continue with the Catalyst 9800 guide. The product builds the encrypted PKCS#12; no manual private-key export is needed for that workflow.