bunny-lab/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update deployments/services/authentication/Active Directory/Certificate Services.md
All checks were successful
Automatic Documentation Deployment / Sync Docs to https://kb.bunny-lab.io (push) Successful in 5s
Details

Browse Source
This commit is contained in:
Nicole Rappe
2026-04-26 17:37:04 -06:00
parent 67bdcc687f
commit 0d42617d7f
1 changed files with 528 additions and 193 deletions
Download Patch File Download Diff File Expand all files Collapse all files

721
deployments/services/authentication/Active Directory/Certificate Services.md
View File

@@ -9,272 +9,607 @@ tags:
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 "CA Deployment 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`.
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 a two-tier hierarchy:
- `LAB-CA-01` = Offline Root CA (not domain-joined)
- `LAB-CA-02` = Enterprise Subordinate CA (domain-joined)
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.
The Root CA signs the Subordinate CA certificate. The Subordinate CA handles all certificate issuance. Clients trust the PKI via Group Policy and Active Directory integration.
!!! warning "Critical PKI Revocation Requirement"
CRL Distribution Points (CDP) and Authority Information Access (AIA) are required for this deployment, even if the immediate use case is only LDAPS. Certificate chain validation and revocation checking still occur for CA certificates and issued certificates. If CDP/AIA is missing, invalid, or unreachable, the Subordinate CA service may fail to start with revocation-related errors such as `0x80092013 (CRYPT_E_REVOCATION_OFFLINE)`.
---
!!! note "Certificate Authority Server 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](../../../../workflows/operations/windows/change-windows-edition.md)
- Ensure the server is fully updated
- [Ensure the server is activated](../../../../workflows/operations/windows/change-windows-edition.md#force-activation-edition-switcher)
- Ensure the timezone is correctly configured
- Ensure the hostname is correctly configured
!!! note "Critical Requirement: CRL and AIA"
CRL Distribution Points (CDP) and Authority Information Access (AIA) **are required for all ADCS deployments**, including LDAPS-only environments.
!!! note "Domain Environment Assumptions"
It is assumed that you already have existing infrastructure hosting an Active Directory Domain with at least one domain controller. This document does not outline how to set up a domain controller, you will need to figure that out on your own.
Without properly configured CRL distribution:
- Certificate Services may fail to start
- Certificate validation may fail
- Revocation checking will break
!!! note "PKI HTTP Distribution Assumptions"
This document uses a dedicated HTTP name for PKI publication:
---
- `pki.bunny-lab.io`
## PKI HTTP Distribution (Required)
This DNS name should resolve to the server hosting the PKI publication directory. In this deployment, the HTTP distribution point is hosted on `LAB-CA-02`.
The PKI requires an HTTP endpoint for distributing:
- CRLs
- CA certificates
### Install IIS on LAB-CA-02
```powershell
Install-WindowsFeature Web-Server -IncludeManagementTools
````
### Create PKI Directory
```powershell
mkdir C:\inetpub\wwwroot\pki
```
### Configure DNS
Create:
```text
pki.bunny-lab.io → LAB-CA-02.bunny-lab.io
```
### Validate
```powershell
echo test > C:\inetpub\wwwroot\pki\test.txt
```
Browse:
```
http://pki.bunny-lab.io/pki/test.txt
```
---
## Offline (Non-Domain-Joined) Root CA `LAB-CA-01`
This indirection is intentional. Certificate CDP/AIA URLs are embedded into issued certificates, so they should point to a stable DNS name rather than directly coupling clients to a CA hostname.
## 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.
(Same as your original steps — unchanged)
---
- 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.
- The Root CA still requires properly configured CDP and AIA publication settings. These are configured after the CA role is installed and before the Subordinate CA certificate is issued.
- Click "**Next**" > "**Next**" > "**Next**" > "**Install**"
- Restart the Server
### Role Configuration
We have a few things we need to configure within the CA to make it ready to handle certificate requests.
After installing the Root CA, **configure CDP and AIA BEFORE issuing certificates**:
- 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.
### Configure Root CA CDP and AIA Publication URLs
Before the Root CA issues the Subordinate CA certificate, configure CDP and AIA publication URLs. These settings control what revocation and CA certificate locations are embedded into certificates issued by the Root CA.
!!! warning "PowerShell Syntax"
The following commands are written for PowerShell. Use single percent signs such as `%3%8%9.crl`.
If using `cmd.exe`, percent escaping may differ. Do not paste caret-based (`^`) line continuations into PowerShell.
On `LAB-CA-01`, run:
```powershell
certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl\n78:http://pki.bunny-lab.io/pki/%3%8%9.crl"
```
```powershell
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://pki.bunny-lab.io/pki/%1_%3%4.crt"
```
Restart CA:
Validate the registry values:
```powershell
certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs
```
The CDP value should contain:
```text
C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl
http://pki.bunny-lab.io/pki/%3%8%9.crl
```
The AIA value should contain:
```text
C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crt
http://pki.bunny-lab.io/pki/%1_%3%4.crt
```
Restart Certificate Services:
```powershell
net stop certsvc
net start certsvc
```
Generate CRL:
Generate the initial Root CA CRL:
```powershell
certutil -crl
```
---
Confirm that the CRL is created with the expected name in:
### Publish Root CA Files
From:
```
```text
C:\Windows\System32\CertSrv\CertEnroll\
```
Copy to:
Expected Root CA files include:
```
\\LAB-CA-02\c$\inetpub\wwwroot\pki\
```text
BunnyLab-RootCA.crl
LAB-CA-01_BunnyLab-RootCA.crt
```
Files:
!!! warning "Do Not Proceed Until CRL Generation Works"
If `certutil -crl` fails, or if it generates a literal filename such as `%3%8%9.crl`, stop and correct the CDP/AIA registry values before issuing the Subordinate CA certificate.
* `BunnyLab-RootCA.crl`
* `LAB-CA-01_BunnyLab-RootCA.crt`
## PKI HTTP Distribution Point on `LAB-CA-02`
Before issuing and installing the Subordinate CA certificate, configure an HTTP distribution point that can host Root CA and Subordinate CA CRLs and CA certificates.
---
Although this HTTP endpoint is hosted on `LAB-CA-02` in this guide, clients should access it through the stable DNS name:
## Online Subordinate CA `LAB-CA-02`
```text
pki.bunny-lab.io
```
### Role Deployment
(Same as your original steps — unchanged)
---
### Role Configuration
Proceed with CSR generation as normal.
---
### Submit Request to Root CA
(Same steps — unchanged)
---
### Install SubCA Certificate
* Install `LAB-CA-02-SubCA.cer`
* Import Root CA cert into Trusted Root store
---
### ⚠️ IMPORTANT: Do NOT manually import CRLs
Remove this step from your original process:
> Import CRL manually into Trusted Root store
Replace with:
### Install IIS
On `LAB-CA-02`, install IIS:
```powershell
certutil -verify -urlfetch RootCA.cer
Install-WindowsFeature Web-Server -IncludeManagementTools
```
This validates CRL via HTTP (correct method).
### Create the PKI Publication Directory
On `LAB-CA-02`, create the HTTP publication directory:
---
```powershell
mkdir C:\inetpub\wwwroot\pki
```
## Reissue SubCA Certificate (Critical Recovery Step)
### Configure DNS
Create a DNS record:
If CDP/AIA was configured after initial deployment:
```text
pki.bunny-lab.io -> LAB-CA-02.bunny-lab.io
```
### On SubCA:
or point `pki.bunny-lab.io` directly to the IP address of `LAB-CA-02`.
### Validate HTTP Access
Create a temporary test file:
```powershell
"test" | Out-File C:\inetpub\wwwroot\pki\test.txt -Encoding ascii
```
From another system, validate access:
```powershell
Invoke-WebRequest http://pki.bunny-lab.io/pki/test.txt
```
Or browse to:
```text
http://pki.bunny-lab.io/pki/test.txt
```
Once validated, remove the test file:
```powershell
Remove-Item C:\inetpub\wwwroot\pki\test.txt
```
### Publish Root CA Files to the HTTP Distribution Point
Copy the Root CA files from `LAB-CA-01`:
```text
C:\Windows\System32\CertSrv\CertEnroll\
```
to the IIS directory on `LAB-CA-02`:
```text
C:\inetpub\wwwroot\pki\
```
Required Root CA files:
```text
BunnyLab-RootCA.crl
LAB-CA-01_BunnyLab-RootCA.crt
```
Validate that these files are reachable:
```powershell
Invoke-WebRequest http://pki.bunny-lab.io/pki/BunnyLab-RootCA.crl
Invoke-WebRequest http://pki.bunny-lab.io/pki/LAB-CA-01_BunnyLab-RootCA.crt
```
!!! note "Root CA Offline Model"
After the Root CA files are published to the HTTP distribution point, `LAB-CA-01` can be taken offline again until the next CRL publication, CA renewal, or Subordinate CA certificate operation is required.
## 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.
!!! warning "Enterprise Admin Requirement"
When you are setting up the role, you **absolutely** have to use an "*Enterprise*" Admin account. This could be a service account like `svcCertAdmin` or something similar.
- Navigate to "**Server Manager > (Alert Flag) > Post-deployment Configuration: Active Directory Certificate Services**"
- Under credentials, enter the username for an Enterprise 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 <file-name> 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".
### Role Configuration
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 server on the network any longer than what is absolutely necessary.
!!! warning "Prerequisite Check"
Before the Root CA signs the Subordinate CA request, confirm the following:
- The Root CA CDP/AIA registry values are configured.
- `certutil -crl` succeeds on `LAB-CA-01`.
- `BunnyLab-RootCA.crl` is published to `http://pki.bunny-lab.io/pki/BunnyLab-RootCA.crl`.
- `LAB-CA-01_BunnyLab-RootCA.crt` is published to `http://pki.bunny-lab.io/pki/LAB-CA-01_BunnyLab-RootCA.crt`.
- 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.
- Navigate to "**Server Manager > Tools > Certification Authority**"
- Right-click the CA node in the treeview on the left-hand sidebar (e.g. `BunnyLab-RootCA`)
- Click on "**All Tasks" > "Submit new request...**"
- Browse to and select the subordinate CA’s .req file (e.g. `LAB-CA-02.bunny-lab.io_bunny-lab-LAB-CA-02-CA.req`)
- Click on "**BunnyLab-RootCA > Pending Requests**
- Right-click the request we just imported, and select "**All Tasks > Issue**"
- Click on ""**BunnyLab-RootCA > Issued Certificates**"
- Locate the new subordinate CA certificate, and double-click it.
- Click the "**Details**" tab
- Click the "**Copy to File**" button
- Click "**Next**"
- Choose `DER encoded binary X.509 (.CER)` and save as `LAB-CA-02-SubCA.cer`.
- Export the Root CA certificate:
- Right-click the `BunnyLab-RootCA` node > Properties > View Certificate > Details > Copy to File...
- Save as `RootCA.cer`
- Copy both `LAB-CA-02-SubCA.cer` (the signed subordinate CA cert) and `RootCA.cer` (the root CA cert) to the subordinate CA (`LAB-CA-02`), using a secure method (e.g. USB drive).
- On `LAB-CA-02` (Subordinate CA), Navigate to "**Server Manager > Tools > Certification Authority**"
- Right-click the CA node in the treeview on the left-hand sidebar (e.g. `BunnyLab-SubordinateCA-01`)
- Click on "**All Tasks" > "Install CA Certificate**"
- Browse to and select `LAB-CA-02-SubCA.cer` (*you may need to change the cert file extension filter to `X.509 Certificate`*)
- When prompted for the CA chain or root certificate, browse for and select the `RootCA.cer` you transferred earlier along with the `LAB-CA-02-SubCA.cer`
- Launch `certlm.msc` to open the `[Certificates - Local Computer]` management window
- Right-Click "**Trusted Root Certification Authorities**" > All Tasks > Import
- Click "**Next**"
- Browse to the `RootCA.cer` file exported from `LAB-CA-01`
- Place all certificates in the following store: "Trusted Root Certification Authorities"
- Click "**Next**" and finish importing the Root CA certificate
- Do **not** rely on manually importing the Root CA CRL into a certificate store as the revocation strategy. Revocation should be validated through the HTTP CDP URL embedded in the issued certificates.
- Verify Root CA CRL retrieval from `LAB-CA-02`:
```powershell
Invoke-WebRequest http://pki.bunny-lab.io/pki/BunnyLab-RootCA.crl
```
- Verify the Subordinate CA certificate chain and revocation status:
```powershell
certutil -verify -urlfetch LAB-CA-02-SubCA.cer
```
- Right-click the CA node in the treeview on the left-hand sidebar (e.g. `BunnyLab-SubordinateCA-01`)
- Click on "**All Tasks" > "Start Service**"
- Verify that the CA status is now green (running).
### Configure Subordinate CA CDP and AIA Publication URLs
After the Subordinate CA service is running, configure CDP/AIA publication for certificates issued by the Subordinate CA.
Run the following on `LAB-CA-02`:
```powershell
certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl\n6:http://pki.bunny-lab.io/pki/%3%8%9.crl"
```
```powershell
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crt\n2:http://pki.bunny-lab.io/pki/%1_%3%4.crt"
```
Validate the registry values:
```powershell
certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs
```
Restart Certificate Services on `LAB-CA-02`:
```powershell
net stop certsvc
net start certsvc
```
Generate the Subordinate CA CRL:
```powershell
certutil -crl
```
Copy the Subordinate CA CRL and certificate from:
```text
C:\Windows\System32\CertSrv\CertEnroll\
```
to:
```text
C:\inetpub\wwwroot\pki\
```
Validate HTTP access to the Subordinate CA CRL and certificate after copying them to IIS.
!!! note "Subordinate CA Publication"
The Root CA signs the Subordinate CA certificate. The Subordinate CA signs domain/server/client certificates. Therefore, clients need access to both Root CA revocation data and Subordinate CA revocation data.
## Reissuing the Subordinate CA Certificate After CDP/AIA Corrections
If the Root CA CDP/AIA settings were configured or corrected after the original Subordinate CA certificate was issued, the Subordinate CA certificate must be reissued.
This is required because CDP/AIA values are embedded into issued certificates at issuance time. Changing the Root CA registry values later does not retroactively fix already-issued Subordinate CA certificates.
### Generate a New Subordinate CA Renewal Request
On `LAB-CA-02`, run:
```powershell
certutil -renewCert ReuseKeys
```
Click **Cancel** (offline root)
If prompted to submit the request to an online parent CA, click **Cancel**. This is expected for an offline Root CA workflow. A new `.req` file will be generated locally.
---
### Submit the Renewal Request to the Root CA
Copy the generated `.req` file to `LAB-CA-01`.
### On Root CA:
On `LAB-CA-01`:
* Submit request
* Issue certificate
* Export `.cer`
- Open "**Server Manager > Tools > Certification Authority**"
- Right-click the Root CA node (e.g. `BunnyLab-RootCA`)
- Click "**All Tasks > Submit new request...**"
- Select the new `.req` file
- Go to "**Pending Requests**"
- Right-click the pending request and select "**All Tasks > Issue**"
- Go to "**Issued Certificates**"
- Open the newly issued Subordinate CA certificate
- Click the "**Details**" tab
- Click "**Copy to File**"
- Export as `DER encoded binary X.509 (.CER)`
- Save as `LAB-CA-02-SubCA.cer`
---
### Install the Renewed Subordinate CA Certificate
Copy `LAB-CA-02-SubCA.cer` back to `LAB-CA-02`.
### Back on SubCA:
On `LAB-CA-02`:
Install new certificate:
- Open "**Server Manager > Tools > Certification Authority**"
- Right-click the Subordinate CA node
- Click "**All Tasks > Install CA Certificate**"
- Select the renewed `LAB-CA-02-SubCA.cer`
- Start the Certificate Services service
```
certsrv.msc → Install CA Certificate
```
---
## CRL Publishing Operations
### Root CA
Validate:
```powershell
certutil -crl
certutil -verify -urlfetch LAB-CA-02-SubCA.cer
```
Copy CRL to IIS:
The validation should not return:
```
C:\inetpub\wwwroot\pki\
```
---
### SubCA
```powershell
certutil -crl
```
Copy:
* SubCA CRL
* SubCA certificate
To IIS folder.
---
## Create Auto-Enrollment Group Policy
(Unchanged from your original doc)
---
## Validate Auto-Enrollment
(Unchanged)
---
## Validate LDAPS Connectivity
(Unchanged)
---
## Validation Commands
Run on any system:
```powershell
certutil -verify -urlfetch <certificate>.cer
```
You should NOT see:
```
```text
CRYPT_E_REVOCATION_OFFLINE
```
---
## Create Auto-Enrollment Group Policy
The Certificate Auto-Enrollment Group Policy enables domain-joined devices (*computers, including domain controllers*) to automatically request, renew, and install certificates from the Enterprise CA (in this case, the Subordinate CA `LAB-CA-02`).
## Security & Operational Notes
### Create GPO
- Open the Group Policy Management editor on one of your domain controllers, then "Create a GPO in this domain, and link it here" wherever it will be able to target the domain controllers, this may be at the root, or in a specific OU that holds domain controllers. (e.g. `bunny-lab.io\Domain Controllers` )
- Name the new GPO something like "**Certificate Auto-Enrollment**"
- Edit the GPO
- Navigate to "**Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies**"
- Find and open "**Certificate Services Client - Auto-Enrollment.**"
- Set the Configuration Model to "**Enabled**"
- Check both checkboxes for "**Renew expired certificates, update pending certificates, and remove revoked certificates**" and "**Update certificates that use certificate templates**"
- Click "**OK**"
- Navigate to "**Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities**"
- Right-click the "**Trusted Root Certification Authorities**" folder and select "**Import...**" > Proceed to browse for the `RootCA.cer` that you previously generated. (*copy it to the domain controller if needed from one of the Certificate Authorities*)
- Proceed to import the certificate, clicking-through all of the prompts and confirmations until it finishes the import.
- Navigate to "**Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Intermediate Certification Authorities**"
- Right-click the "**Intermediate Certification Authorities**" folder and select "**Import...**" > Proceed to browse for the `LAB-CA-02-SubCA.cer` that you previously generated. (*copy it to the domain controller if needed from one of the Certificate Authorities*)
- Proceed to import the certificate, clicking-through all of the prompts and confirmations until it finishes the import.
- Run a `gpupdate /force` on your domain controller(s) and give it a few minutes to pull down their new domain controller certificates
* Root CA should remain offline except when issuing or renewing
* CRLs must be periodically regenerated and published
* Automate CRL copy to IIS if possible
* Monitor CRL expiration
!!! note "Reissuing Certificates After PKI Corrections"
If any machine certificates, domain controller certificates, terminal server certificates, NPS certificates, or other service certificates were issued before CDP/AIA was configured correctly, reissue them. Old certificates may continue to work in some paths, but revocation checking and chain validation may be inconsistent.
---
For auto-enrolled certificates, use:
## Key Lessons Learned
```powershell
gpupdate /force
certutil -pulse
```
* CDP/AIA must be configured BEFORE issuing certificates
* HTTP CRL distribution is mandatory
* SubCA certificates must be reissued if CDP was missing
* Manual CRL import is not a valid solution
On affected systems, remove old certificates from `Certificates - Local Computer > Personal > Certificates` if duplicate or stale certificates remain after renewal.
### Validate Auto-Enrollment Functionality
At this point, you need to check that there is a certificate installed within "**Certificates - Local Computer > Personal > Certificates**" for "Domain Controller Server Authentication"
- Load the Certificate - Local Machine (`certlm.msc`) and navigate to "**Personal > Certificates**" > You should see something similar to the following:
| **Issued To** | **Issued By** | **Expiration Date** | **Intended Purposes** | **Certificate Template** |
| :--- | :--- | :--- | :--- | :--- |
| LAB-DC-01.bunny-lab.io | BunnyLab-SubordinateCA-01 | 7/15/2026 | Directory Service Email Replication | Directory Email Replication |
| LAB-DC-01.bunny-lab.io | BunnyLab-SubordinateCA-01 | 7/15/2026 | Client Authentication, Server Authentication, Smart Card Logon | Domain Controller Authentication |
| LAB-DC-01.bunny-lab.io | BunnyLab-SubordinateCA-01 | 7/15/2026 | Client Authentication, Server Authentication, Smart Card Logon, KDC Authentication | Kerberos Authentication |
### Validate LDAPS Connectivity
Lastly, we want to ensure that LDAPS is functioning. By default, once these certs are enrolled on the domain controller(s), LDAPS *should* just work out of the box. To verify this, you can run this command on any device on the same network as the domain controllers. If it comes back successful like in the following example output, then you are golden:
```powershell
PS C:\Users\nicole.rappe> Test-NetConnection LAB-DC-01.bunny-lab.io -Port 636
ComputerName : LAB-DC-01.bunny-lab.io
RemoteAddress : 192.168.3.25
RemotePort : 636
InterfaceAlias : Ethernet
SourceAddress : 192.168.3.254
TcpTestSucceeded : True
PS C:\Users\nicole.rappe> Test-NetConnection LAB-DC-02.bunny-lab.io -Port 636
ComputerName : LAB-DC-02.bunny-lab.io
RemoteAddress : 192.168.3.26
RemotePort : 636
InterfaceAlias : Ethernet
SourceAddress : 192.168.3.254
TcpTestSucceeded : True
```
!!! success "Successful LDAPS Connectivity"
LDAPS should now be functional on your domain controller(s).
### Validate Certificate Revocation and Chain Building
After auto-enrollment and LDAPS validation, export one representative certificate from a domain controller or server and validate it:
```powershell
certutil -verify -urlfetch <issued-certificate>.cer
```
The output should show successful chain validation and should not contain:
```text
CRYPT_E_REVOCATION_OFFLINE
```
Also validate direct access to the Root CA CRL and Subordinate CA CRL:
```powershell
Invoke-WebRequest http://pki.bunny-lab.io/pki/BunnyLab-RootCA.crl
```
Run an equivalent check for the Subordinate CA CRL after confirming the exact generated filename in:
```text
C:\Windows\System32\CertSrv\CertEnroll\
```
## CRL Publishing and Maintenance
CRLs must be generated and published on a recurring basis. If a CRL expires, certificate validation may fail even if the CA services themselves are running.
### Root CA CRL Publishing
Because the Root CA is offline, periodically bring it online only long enough to generate a new CRL and copy it to the HTTP distribution point.
On `LAB-CA-01`:
```powershell
certutil -crl
```
Copy the generated CRL from:
```text
C:\Windows\System32\CertSrv\CertEnroll\
```
to the IIS publication directory on `LAB-CA-02`:
```text
C:\inetpub\wwwroot\pki\
```
Validate:
```powershell
Invoke-WebRequest http://pki.bunny-lab.io/pki/BunnyLab-RootCA.crl
```
### Subordinate CA CRL Publishing
On `LAB-CA-02`:
```powershell
certutil -crl
```
Copy or confirm the Subordinate CA CRL exists in:
```text
C:\inetpub\wwwroot\pki\
```
Validate the URL from a domain-joined system.
### Operational Monitoring
Monitor CRL expiration and publication. Certificate validation failures can occur if CRLs expire, even if certificates themselves have not expired.
Recommended operational tasks:
- Track Root CA CRL expiration.
- Track Subordinate CA CRL expiration.
- Verify HTTP CRL URLs after each publication.
- Keep the Root CA offline except during controlled maintenance windows.
- Document the expected CRL filenames generated in `C:\Windows\System32\CertSrv\CertEnroll\`.
!!! abstract "Raw Unprocessed/Unimplemented Steps"
Publish CRLs regularly, configure overlap periods, and monitor expiration. Enable Delta CRLs on the Subordinate CA, but not on the Root.
Security Recommendations
- Harden CA servers; limit access to PKI admins.
- Use BitLocker or HSM for key protection.
- Monitor issuance and renewals with audit logs and scripts.