docs/deployments/services/authentication/Active Directory/Certificate Services.md at 1065d2187484550a0f8844d67bc80dcc62e86220

bunny-lab/docs

Fork 0

Files

Nicole Rappe 0d42617d7f

Automatic Documentation Deployment / Sync Docs to https://kb.bunny-lab.io (push) Successful in 5s

Details

Update deployments/services/authentication/Active Directory/Certificate Services.md

2026-04-26 17:37:04 -06:00

29 KiB

Raw Blame History

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 "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. 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.

!!! 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 - Ensure the server is fully updated
- Ensure the server is activated - Ensure the timezone is correctly configured - Ensure the hostname is correctly configured

!!! 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.

!!! note "PKI HTTP Distribution Assumptions" This document uses a dedicated HTTP name for PKI publication:

- `pki.bunny-lab.io`

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`.

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.

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.

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:

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"

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:

certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs

The CDP value should contain:

C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl
http://pki.bunny-lab.io/pki/%3%8%9.crl

The AIA value should contain:

C:\Windows\System32\CertSrv\CertEnroll\%1_%3%4.crt
http://pki.bunny-lab.io/pki/%1_%3%4.crt

Restart Certificate Services:

net stop certsvc
net start certsvc

Generate the initial Root CA CRL:

certutil -crl

Confirm that the CRL is created with the expected name in:

C:\Windows\System32\CertSrv\CertEnroll\

Expected Root CA files include:

BunnyLab-RootCA.crl
LAB-CA-01_BunnyLab-RootCA.crt

!!! 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.

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:

pki.bunny-lab.io

Install IIS

On LAB-CA-02, install IIS:

Install-WindowsFeature Web-Server -IncludeManagementTools

Create the PKI Publication Directory

On LAB-CA-02, create the HTTP publication directory:

mkdir C:\inetpub\wwwroot\pki

Configure DNS

Create a DNS record:

pki.bunny-lab.io -> LAB-CA-02.bunny-lab.io

or point pki.bunny-lab.io directly to the IP address of LAB-CA-02.

Validate HTTP Access

Create a temporary test file:

"test" | Out-File C:\inetpub\wwwroot\pki\test.txt -Encoding ascii

From another system, validate access:

Invoke-WebRequest http://pki.bunny-lab.io/pki/test.txt

Or browse to:

http://pki.bunny-lab.io/pki/test.txt

Once validated, remove the test file:

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:

C:\Windows\System32\CertSrv\CertEnroll\

to the IIS directory on LAB-CA-02:

C:\inetpub\wwwroot\pki\

Required Root CA files:

BunnyLab-RootCA.crl
LAB-CA-01_BunnyLab-RootCA.crt

Validate that these files are reachable:

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 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:
```
Invoke-WebRequest http://pki.bunny-lab.io/pki/BunnyLab-RootCA.crl
```
  - Verify the Subordinate CA certificate chain and revocation status:
```
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:

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"

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:

certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs

Restart Certificate Services on LAB-CA-02:

net stop certsvc
net start certsvc

Generate the Subordinate CA CRL:

certutil -crl

Copy the Subordinate CA CRL and certificate from:

C:\Windows\System32\CertSrv\CertEnroll\

to:

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:

certutil -renewCert ReuseKeys

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 LAB-CA-01:

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.

On LAB-CA-02:

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

Validate:

certutil -verify -urlfetch LAB-CA-02-SubCA.cer

The validation should not return:

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).

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

!!! 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:

```powershell
gpupdate /force
certutil -pulse
```

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:

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:

certutil -verify -urlfetch <issued-certificate>.cer

The output should show successful chain validation and should not contain:

CRYPT_E_REVOCATION_OFFLINE

Also validate direct access to the Root CA CRL and Subordinate CA CRL:

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:

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:

certutil -crl

Copy the generated CRL from:

C:\Windows\System32\CertSrv\CertEnroll\

to the IIS publication directory on LAB-CA-02:

C:\inetpub\wwwroot\pki\

Validate:

Invoke-WebRequest http://pki.bunny-lab.io/pki/BunnyLab-RootCA.crl

Subordinate CA CRL Publishing

On LAB-CA-02:

certutil -crl

Copy or confirm the Subordinate CA CRL exists in:

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.

29 KiB Raw Blame History Unescape Escape

Purpose

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

Role Deployment

Role Configuration

Configure Root CA CDP and AIA Publication URLs

PKI HTTP Distribution Point on LAB-CA-02

Install IIS

Create the PKI Publication Directory

Configure DNS

Validate HTTP Access

Publish Root CA Files to the HTTP Distribution Point

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

Role Deployment

Role Configuration

Configure Subordinate CA CDP and AIA Publication URLs

Reissuing the Subordinate CA Certificate After CDP/AIA Corrections

Generate a New Subordinate CA Renewal Request

Submit the Renewal Request to the Root CA

Install the Renewed Subordinate CA Certificate

Create Auto-Enrollment Group Policy

Create GPO

Validate Auto-Enrollment Functionality

Validate LDAPS Connectivity

Validate Certificate Revocation and Chain Building

CRL Publishing and Maintenance

Root CA CRL Publishing

Subordinate CA CRL Publishing

Operational Monitoring

29 KiB

Raw Blame History

Offline (Non-Domain-Joined) Root CA `LAB-CA-01`

PKI HTTP Distribution Point on `LAB-CA-02`

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