docs/Workflows/Windows/Windows Server/Roles/Active Directory Certificate Services.md

Purpose

This document outlines the Microsoft-recommended best practices for deploying a secure, internal-use-only, two-tier Public Key Infrastructure (PKI) using Windows Server 2022 or newer. The PKI supports securing S/MIME email, 802.1X Wi-Fi with NPS, and LDAP over SSL (LDAPS).

!!! abstract "Environment Breakdown" The environment will consist of at least 2 virtual machines. For the purposes of this document they will be named LAB-CA-01 and LAB-CA-02. This stands for "Lab Certificate Authority [01|02]". In a two-tier hierarchy, an offline (you intentionally keep this VM offline) Root CA signs a single "Subordinate" Enterprise CA certificate. The Subordinate CA is domain-joined and handles all certificate requests. Clients trust the PKI via Group Policy and Active Directory integration.

In this case, `LAB-CA-01` is the Root CA, while `LAB-CA-02` is the Intermediary/Subordinate CA.  You can add more than one subordinate CA if you desire more redundancy in your environment.  Making them operate together is generally automatic and does not require manual intervention.

!!! note "Provisioning Assumptions" - OS = Windows Server 2022/2025 bare-metal or as a VM
- You should give it at least 4GB of RAM.
- Change the edition of Windows Server from "Evaluation" to "Standard" via DISM - Ensure the server is fully updated
- Ensure the server is activated - Ensure the timezone is correctly configured - Ensure the hostname is correctly configured

Offline (Non-Domain-Joined) Root CA LAB-CA-01 Role Deployment

This is the initial deployment of the root certificate authority, the settings here should be double and triple checked before proceeding through each step.

• Provision a non-domain-joined Windows Server
  • This is critical that this device is not domain-joined for security purposes
• Navigate to "Server Manager > Manage > Add Roles and Features"
  • Check "Active Directory Certificate Services"
    • When prompted to confirm, click the "Add Features" button
    • Ensure the "Include management tools (if applicable)" checkbox is checked.
  • Click "Next" > "Next" > "Next"
    • You will be told that the name of the server cannot be changed after this point, and it will be associated with WORKGROUP > This is fine and you can proceed.
  • Check the boxes for the following role services:
    • Certification Authority
    • Certification Authority Web Enrollment
      • When prompted to confirm multiple times, click the "Add Features" button
      • Ensure the "Include management tools (if applicable)" checkbox is checked.
        • There are additional steps such as Configure AIA and CDP extensions with HTTP paths and Publish root cert and CRL to AD and internal HTTP, but these do not apply to an LDAPS-only deployment, and are more meant for websites / webhosting. (current understanding)
  • Click "Next" > "Next" > "Next" > "Install"
  • Restart the Server

Offline (Non-Domain-Joined) Root CA LAB-CA-01 Role Configuration

We have a few things we need to configure within the CA to make it ready to handle certificate requests.

• Navigate to "Server Manager > (Alert Flag) > Post-deployment Configuration: Active Directory Certificate Services"
  • You will be prompted for an admin user, in this example, you will use the pre-populated LAB-CA-01\Administrator
  • Check the boxes for Certification Authority and Certification Authority Web Enrollment then click "Next"
  • Check the "Standalone CA" radio box then click "Next"
  • Check the "Root CA radio box then click "Next"
  • Check the "Create a new private key" radio box then click "Next"
  • Click the dropdown menu for "Select a crypotographic provider" and ensure that "RSA#Microsoft Software Key Storage Provider" is selected
    • Microsoft Software Key Storage Provider (KSP) is the latest, most flexible provider designed to work with the Cryptography Next Generation (CNG) APIs. It offers better support for modern algorithms and improved security management (such as support for key attestation, better hardware integration, and improved key protection mechanisms).
  • Set the key length to 4096
  • Set the hash algorithm to SHA256
  • Click "Next"
  • Common Name for this CA: BunnyLab-RootCA
  • Distinguished name suffix: O=Bunny Lab,C=US
  • Preview of distinguished name: CN=BunnyLab-RootCA,O=Bunny Lab,C=US
  • Click "Next"
  • Specify the validity period: 10 Years then click "Next" > "Next" > "Configure"

You will see a finalization screen confirming everything we have configured, it should look something like what is seen below:

Field	Value
CA Type	Standalone Root
Cryptographic provider	RSA#Microsoft Software Key Storage Provider
Hash Algorithm	SHA256
Key Length	4096
Allow Administrator Interaction	Disabled
Certificate Validity Period	<10 Years from Today>
Distinguished Name	CN=BunnyLab-RootCA,O=Bunny Lab,C=US
Certificate Database Location	C:\Windows\system32\CertLog
Certificate Database Log Location	C:\Windows\system32\CertLog

!!! success "Active Directory Certificate Services" If everything went well, you will see that the "Certificate Authority" and "Certification Authority Web Enrollment" both have a status of "Configuration succeeded". At this point, you can click the "Close" button to conclude the Root CA configuration.

Online (Domain-Joined) Subordinate/Intermediary CA LAB-CA-02 Role Deployment

Now that we have set up the root certificate authority, we can focus on setting up the subordinate CA.

• Navigate to "Server Manager > (Alert Flag) > Post-deployment Configuration: Active Directory Certificate Services"
  • Under credentials, let it automatically populate a domain admin. (e.g. BUNNY-LAB\nicole.rappe)
  • Click "Next"
  • Check the following roles (we will add the rest after setting up the core CA functionality)
    • Certification Authority
    • Certification Authority Web Enrollment
  • Check the "Enterprise CA" radio box then click "Next"
  • Check the "Subordinate CA" radio box then click "Next"
  • Check the "Create a new private key" radio box then click "Next"
  • Click the dropdown menu for "Select a crypotographic provider" and ensure that "RSA#Microsoft Software Key Storage Provider" is selected
    • Microsoft Software Key Storage Provider (KSP) is the latest, most flexible provider designed to work with the Cryptography Next Generation (CNG) APIs. It offers better support for modern algorithms and improved security management (such as support for key attestation, better hardware integration, and improved key protection mechanisms).
  • Set the key length to 4096
  • Set the hash algorithm to SHA256
  • Click "Next"
  • Common Name for this CA: BunnyLab-SubordinateCA-01
  • Distinguished name suffix: DC=bunny-lab,DC=io
    • This will be auto-filled based on the domain that the CA is joined to
  • Preview of distinguished name: CN=BunnyLab-SubordinateCA-01,DC=bunny-lab,DC=io
  • Click "Next"
  • Select the "Save a certificate request to file on the target machine" radio button
    • This will auto-populate the destination to something like "C:\LAB-CA-02.bunny-lab.io_bunny-lab-LAB-CA-02-CA.req"
  • Click "Next" > "Next" > "Configure"

You will see a finalization screen confirming everything we have configured, it should look something like what is seen below:

Field	Value
CA Type	Enterprise Subordinate
Cryptographic provider	RSA#Microsoft Software Key Storage Provider
Hash Algorithm	SHA256
Key Length	4096
Allow Administrator Interaction	Disabled
Certificate Validity Period	Determined by the parent CA
Distinguished Name	CN=BunnyLab-SubordinateCA-01,DC=bunny-lab,DC=io
Offline Request File Location	C:\LAB-CA-02.bunny-lab.io_bunny-lab-LAB-CA-02-CA.req
Certificate Database Location	C:\Windows\system32\CertLog
Certificate Database Log Location	C:\Windows\system32\CertLog

!!! quote "Pending Certificate Signing Request" You will see a screen telling you that the Certification Authority Web Enrollment was successful but it will give a warning about the Certification Authority. The Active Directory Certificate Services installation is incomplete. To complete the installation, use the request file to obtain a certificate from the parent CA [The RootCA]. Then, use the Certification Authority snap-in to install the certificate. To complete this procedure, right-click the node with the name of the CA, and then click "Install CA Certificate".

Online (Domain-Joined) Subordinate/Intermediary CA LAB-CA-02 Configuration Deployment

At this point, we will need to focus on getting the certificate signing request generated on LAB-CA-02 to LAB-CA-01 (the rootCA), this can be via temporary network access or via a USB flashdrive.

!!! danger If using a USB flashdrive is not viable, don't leave the RootCA on the network any longer than what is absolutely necessary.

• Once the certificate signing request file C:\LAB-CA-02.bunny-lab.io_bunny-lab-LAB-CA-02-CA.req is on LAB-CA-01 (RootCA) we can proceed to get it signed.
  • PLACEHOLDER

!!! warning "Under Construction" Section is still being written during lab deployment.

I will go over setting up additional roles **AFTER** documenting the process of getting the certificate signing request from `LAB-CA-02` to `LAB-CA-01`

!!! abstract "Raw Unprocessed/Unrefined Steps - Do Not Use" 3. Online Subordinate CA Setup Steps: 2. Generate CSR, sign with Root CA, import signed cert. 3. Configure AIA/CDP extensions for CRL publication. 4. Enable role separation and auditing. 4. Certificate Templates and Autoenrollment Configure certificate templates for the following use cases: • - S/MIME Email: Use separate templates for signing and encryption. Enable key archival for encryption. • - 802.1X Wi-Fi: Use 'RAS and IAS Server' for NPS, and 'Workstation Authentication' for clients. • - LDAPS: Use 'Kerberos Authentication' template for domain controllers. Enable autoenrollment via GPOs under Public Key Policies for both Computer and User configuration. 5. CRL and Revocation Management Publish CRLs regularly, configure overlap periods, and monitor expiration. Enable Delta CRLs on the Subordinate CA, but not on the Root. 6. Security Recommendations • - Harden CA servers; limit access to PKI admins. • - Use BitLocker or HSM for key protection. • - Enforce strong cryptographic settings: RSA 2048+, SHA-256. • - Monitor issuance and renewals with audit logs and scripts.