Microsoft PKI Implementation Guild

Overview

Active Directory Certificate Services (AD CS) provides customizable services for issuing and managing digital certificates used in software security systems that employ public key technologies. The digital certificates that AD CA provides can be used to encrypt and digitally sign electronic documents and messages. These digital certificates can be used for authentication of computers, users or device accounts on a network. Now lets buck up and dig into this Guild on Microsoft PKI implementation.

The administrator that will be implementing PKI will need to be added to the ‘Enterprise Admins’ group.

By the end of the guide you will have a fully functional Microsoft Private Key Infrastructure. 

Logical Design

• Deploy a Two-Tier Hierarchy
• Deploy an Offline Root CA server
• Deploy an Issuing CA server
• Deploy two (2) CDP servers
• Implement High Availability
• Deploy an Issuing CA in the primary AD Site
• Deploy HTTP, OCSP roles on a different server that there Issuing CA
• Implement the following PKI Security Roles
  • PKI Admins
  • PKI Cert Managers
• Keep the Root CA Offline

Infrastructure Design

The design creates tiered, and highly available infrastructure.

• Since there are no administrative or policy boundaries, and all Issuing CAs are performing the same task, there is no requirement for a middle tier of intermediate CAs
• The offline root CRT is copied to the production CDP
• The offline root CRL is copied to the production CDP
• The offline root CA keys are protected by keeping the system offline
• Enterprise CAs automatically publish CRLs to each of the HTTP_CRL systems
• The production CDPs should be accessible from all endpoints for access to the CRL HTTP publication
• Additional issuing CAs and/or web services servers can be added to scale the solution in the future if required

Conceptual Design

Two-tier with High Availability

The first thing we are going to do is create a few security groups in active directory. I will be creating a new OU named PKI for these groups.

• PKI Admins (used for anyone that can manage the PKI servers)
• PKI Cert Mangers (used for anyone that can create certs on the issuing CA)
• PKI Approved LDAPs (used for the Kerberos Authentication template)
• PKI Computers (used for the Computer template)
• PKI Approved Users (used for the User template)
• PKI Approved Web Servers (used for the Web Server template)

The administrators that you would like to have access to the PKI servers will need to be add to the PKI Admins security group. We will be removing the ‘Domain Admin’ group from the servers.

The next steps will be to spin up four servers running Windows 2019 with the desktop experience. Below are the spec that I used. I would not go below these spec for CPU and RAM, but you can always add more.

Server 1 will be the Root CA Server. After PKI deployment is complete this server will not be joined to the domain, stay offline (except for OS updates), have the NIC disconnected (if using a virtual server) and have no DNS entry. I also change the default Administrator account name. The required ports are DNS-53, RPC-135, 137 and 139.

• OS: Windows 2019 with desktop experience
• CPUs: 2
• RAM: 8Gb
• 60Gb ‘C’ drive (Thin provisioning is fine)
• Non-Domain joined (WORKGROUP)

Server 2 will be the Enterprise Issuing CA. This server will be the subordinate CA for the Root CA server. This server will be domain joined and stay powered on. The required ports are DNS-53, RPC-135, 137, 139 and DCOM 49152-65535.

• OS: Windows 2019 with desktop experience
• CPUs: 2
• RAM: 8Gb
• 60Gb ‘C’ (Thin provisioning is fine)
• Domain joined
• LOCAL Administrators
  • Add Enterprise Admins
  • Exclude Domain Admins
  • Add PKI Operators Security Group
    • Only those permitted to manage the PKI should be members of this group and all access to the PKI servers and PKI operators group should be audited and monitored.

Server 3 and 4 will be for HTTP-CRT and online responder. The required ports are HTTP-80, HTTPS-443, LDAP-389 and 636.

• OS: Windows 2019 with desktop experience
• CPUs: 2
• RAM: 8Gb
• 60Gb ‘C’ (Thin provisioning is fine)
• 40Gb ‘E’ (Thin provisioning is fine)
• Domain joined
• LOCAL Administrators
  • Standard access restrictions
  • Add PKI Operators Security Group
• Only those permitted to manage the PKI should be members of this group and all access to the PKI servers and PKI operators group should be audited and monitored.

Configuring the CDP servers

---

1. Log on to the ‘CDP Server’ with an Enterprise Admin account
2. Create a new folder named ‘CertEnroll’ on the ‘E’ drive 
3. Share this folder with the ‘Advanced Sharing’ and grant Permissions to the ‘Cert Publishers’ group and enable ‘Change’ permissions. 
4. On the security tab of the new folder add ‘Cert Publishers’ group and then in the Allow column select Change permission.
5. Now from the ‘Server Manager’ choose ‘Manage’, then ‘Add Roles and Features’
6. On the ‘Select server roles’ screen, expand ‘Active Directory Certificate Services’
7. Choose ‘Online Responder’ 
8. We also need to select ‘Web Server (IIS)’
9. Now just finish out the wizard and reboot the server if needed 

Create CertEnroll Virtual Directory in IIS

1. Open the IIS manager
2. In the ‘Connections pane’, right click on ‘Default Web Site’ and select ‘Add Virtual Directory’
3. In the new dialog box enter an alias name of ‘CertEnroll’ and enter the physical path.
4. Now expand ‘Default Web Site’ and choose ‘CertEnroll’
5. Double click ‘Directory Browsing’, then on the far right ‘Actions’ pane, choose ‘Enable’

Optionally you can choose to enable double escaping in IIS. Allowing double escaping makes it possible for the web server to host Delta CRLs. For more information, see PKI Solutions KB article 942076.

6. From an elevated command prompt change directories into the ‘inetsrv’ folder

cd %windir%\system32\inetsrv\

7. Now enter the bellow command and press enter

Appcmd set config "Default Web Site" /section:system.webServer/Security/requestFiltering -allowDoubleEscaping:True

8. Now restart IIS by entering the below and pressing enter

iisreset

Create CNAME (PKI.<FQDN>) in DNS

For this step you will need to make a new CNAME record. The alias name is PKI, for the FQDN enter the FQDN of the Primary CDP server and include a dot at the end. Including the termination “.” in the FQDN will be needed if Delta CRLs are going to be used.

Installing and Configuring the Root CA (Standalone)

---

Creating a CAPolicy.inf for the standalone offline root CA

1. Log onto ‘Server 1’, Root CA as a local administrator
2. Create a new .inf file named ‘CAPolicy.inf’ at ‘C:\Windows\’  
3. Open notepad with elevated permissions and brows to your newly created file. 
4. Now add the below information to the file

Signature="$Windows NT$"
[Certsrv_Server]
RenewalKeyLength=4096 
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=30
AlternateSignatureAlgorithm=0

Please note that 'AlternateSignatureAlgorithm=1' is not compatible with Windows SP and Windows Server 2003 certificate client computers. In addition, most 3rd party applications do not recognize alternate signature formats. The CAPolicy.inf contains various settings that are used when installing the Active Directory Certification Service (AD CS) or when renewing the CA certificate. The CAPolicy.inf file is not required to install ADCS with the default settings, but in many cases the default settings are insufficient. The CAPolicy.inf can be used to configure CAs in these more complicated deployments. Any entries in CAPolicy.inf file that is misspelled with be ignored. 

Install the Standalone Offline Root CA role

1. From the Server Manager dashboard, choose ‘Add roles and features’
2. On the ‘Select Server Roles’ page select ‘Active Directory Certificate Services’, then choose ‘Next’
3. Now On the ‘Introduction to Active Directory Certificate Services’ page, choose ‘Next’
4. On the ‘Select Role Services’ page, ensure that ‘Standalone’ is selected and choose ‘Next’
   • Note: Enterprise option is grayed out as this server is not joined to a domain
5. On the ‘Specify CA Type’ page, ensure that the server you are on is selected, then choose ‘Next’
6. On the ‘Set Up Private Key’ page, ensure that ‘Create a new private key’ is selected, then choose ‘Next’
7. Change the default ‘RSA 2048’ on the ‘Configure Cryptography for CA’ page to RSA 4096, then choose ‘Next’
8. On the ‘Configure CA Name’ page, under ‘Common name for this CA’, enter ‘Root CA’, and click ‘Next’
   • A Distinguished Name Suffix is optional for the root CA. This will be configured in a later step. 
9. On the ‘Set Validity Period’ page, under ;Select validity period for the certificate generated for this CA’, enter 30. Leave the selection box set to ‘Years’, then choose ‘Next’
10. ON the ‘Confirm Installation Selections page, review the settings, and choose ‘Install’
11. Review the information on the ‘Installation Results’ page to verify that the installation is successful and click ‘Close. 

Preforming Post Installation Configuration for Root CA

1.  From an elevated command prompt type the following commands:
   • Note that the Enterprise Issuing CA should receive a 20 year lifetime for its CA certificate. Auditing for all CA related events is configured (CA\AuditFilter 127)

Certutil -setreg CA\DSConfigDN "CN=Configuration,DC=<DOMAIN>,DC=<Top-Level domain>”
Certutil -setreg CA\CRLPeriodUnits 30
Certutil -setreg CA\CRLPeriod "Years"
Certutil -setreg CA\ValidityPeriodUnits 20
Certutil -setreg CA\ValidityPeriod "Years"
Certutil -setreg CA\AuditFilter 127

Configure the Authority Information Access (AIA)

1. Open an elevated PowerShell and type the below command:
   • make sure to replace the ‘<FQDN>’ place hold with your FQDN

certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%4.crt\n2:http://pki.<FQDN>/CertEnroll/%3%4.crt"

2. Validate the AIA configuration by running this command:

certutil -getreg CA\CACertPublicationURLs

Configure the CRL Distribution Point (CDP)

1. Open an elevated PowerShell and type the below command:
   • make sure to replace the ‘<FQDN>’ place hold with your FQDN

certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n2:http://pki.<FQDN>/CertEnroll/%3%8%9.crl"

2. Validate the AIA configuration by running this command:

certutil -getreg CA\CRLPublicationURLs

Restart AD Certificate Services

1. Open an elevated PowerShell and type the below command:

Restart-Service -name CertSvc -Verbose

Publish new certificate revocation lists (CRLs)

1. Open an elevated PowerShell and type the below command:

Certutil -crl

Installing and Configuring the Enterprise Issuing CA

---

Generate a Customized Object Identifier

1. Log onto ‘Server 2’, Enterprise Issuing CA
2. Open an elevated PowerShell and type the below command:
   • This will create an OID for then next bit of code we will run

#---
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(4,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(9,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(14,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(19,4),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(24,6),"AllowHexSpecifier")
$Parts+=[UInt64]::Parse($guid.SubString(30,6),"AllowHexSpecifier")
$OID=[String]::Format("{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}",$prefix,$Parts[0],$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oid
#---

Create an Enterprise CAPolicy

1. Create a new .inf file named ‘CAPolicy.inf’ at ‘C:\Windows\’  
2. Open notepad with elevated promotions and brows to your newly created file. 
3. Now add the below information to the file: 
   • Make sure to add the OID from the previous step
   • Make sure to replace <FQDN> with your FQDN

[Version]
Signature="$Windows NT$"
[PolicyStatementExtension]
Policies=InternalPolicy
[InternalPolicy]
OID= #Placed the new OID generated from the previous step
URL=http://pki.<FQDN>/certenroll/cps.txt 
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0

Publish the Root CA Certificate

1. Copy the Root CA Certificate and CRL from ‘C:\Windows\System32\CertSrv\CertEnroll’ to the root of the C drive (C:\)
2. Rename the Root CA ‘.crt’ file to match the ‘.crl’ file
3. Open an elevated PowerShell ISE and run the below commands:
   • make sure to replace <Root-CA>.crt and <Root-CA>.crl with the name used in step 2

certutil -f -dspublish "C:\<Root-CA>.crt" RootCA
certutil -f -dspublish "C:\<Root-CA>.crl" RootCA

Publish the Root CA Certificate and CRL to PKI CNAME Record

1. Copy the ‘<Root-CA>.crt’ and ‘<Root-CA>.crl’ to the ‘CertEnroll’ fold on each CDP server

Add Root CA Certificate and CRL to local store

1. Open an elevated PowerShell and enter the below commands:
   • These commanded need to be ran from the root of ‘C’
   • Make sure to replace <Root-CA> with the name you created in the steps above

certutil -addstore -f root "<Root-CA>.crt"
certutil -addstore -f root "<Root-CA>.crl"   

Install Subordinate Issuing CA Role

1. Ensure that you are now logged onto <Sub CA>, server 2, with administrator privilege’s
2. From the Server Manager dashboard, choose ‘Add roles and features’
3. On the ‘Select Server Roles’ page select ‘Active Directory Certificate Services’, then choose ‘Next’
4. Now On the ‘Introduction to Active Directory Certificate Services’ page, click ‘Next’
5. On the ‘Select Role Services’ page, select ‘Certification Authority’. If you see ‘Add Roles Wizard’, click ‘Add Required Role Services’ and choose ‘Next’.
6. On the ‘Specify Setup Type’ page, ensure that ‘Enterprise’ is selected, and then click ‘Next’
   • Enterprise option will be greyed out if you are not logged on as Enterprise Admin or do not have local administrator permission
7. On the ‘Specify CA Type’ page, select ‘Subordinate CA’, and then click ‘Next’
8. On the ‘Set Up Private Key’ page, ensure that ‘Create a new private key’ is selected, and choose ‘Next’
9. Leave the defaults on the ‘Configure Cryptography for CA’ page, then click ‘Next’
   • Important: When installing in a production environment, the CSP, Hash Algorithm and Key length selected must support application compatibility requirements
10. On ‘Configure CA Name’ page, clear the existing entry for ‘Common name for this CA’ box, and enter ‘Sub CA’, then select ‘Next’
    • Note: You do not have to name this ‘Sub CA’, you could use the FQDN of this server if you wanted to
11. On the ‘Specify CA Type’ page, select ‘Subordinate CA’, and then click ‘Next’ 
12. On the ‘Set Up Private Key’ page, ensure that ‘Create a new private key’ is selected, and then click ‘Next’
13. Leave the defaults on the ‘Configure Cryptography for CA’ page, then click ‘Next’
14. On ‘Configure CA Name’ page, clear the existing entry for ‘Common name for this CA’ box, and enter ‘Sub CA’, then select ‘Next’
    • Note: Distinguished Name Suffix is automatically populated and should not be modified
15. On the ‘Request certificate from a parent CA’ page, select ‘Save a certificate request to file and manually send it later to a parent CA’ option then click ‘Next’
16. Leave the defaults on the ‘Configure Certificate Database’ page, and then click ‘Next’
17. On the ‘Confirm Installation Selections’ page, click Install
18. Review the information on the ‘Installation Results’ page to verify that the installation is successful and then click ‘Close’
    • Warning: The following warning message is expected: “The Active Directory Certificate Services installation is incomplete. We will be using the ‘Sub CA.req’ file to obtain a new cert. We will install this cert in upcoming steps
19. Rename the CA Request, removing the leading part up to the underscore

Submit and Issue the Subordinate CA Certificate

1. We will need to copy the ‘.req’ file to the Root CA server
   • Depending on your environment this could be difficult due to the server not being domain joined
2. Log into the Root CA server
3. Open an elevated PowerShell ISE and enter the following commands:
   • make sure to replace the <> with the path to your ‘.req’ file
   • Warning – Pay attention to the Request ID number that is displayed after you submit the request. This number is required when retrieving the certificate

certreq -submit "<.\Sub CA.req>"

4. In the ‘Certification Authority List’ dialog box, ensure that ‘Root CA’ is selected
5. Open a new mmc window and add the ‘Certification Authority (Local)’ snap in
6. Expand ‘Root CA’ and select ‘Pending Requests’. In the details pane, right-click the ‘Submitted Request’ > click ‘All Tasks’, then ‘Issue’
7. Return to the PowerShell ISE prompt to accept the issued certificate by running the following command:
   • Replace <Request ID> with the ID from step 3
   • The newly issued certificate can be found at ‘C:\’ of the Root CA

certreq -retrieve <Request ID> "C:\<Sub CA>.crt"

8. In the ‘Certification Authority List’ dialog box, ensure that ‘Root-CA’ is selected
9. Copy the ‘Sub CA Certificate’ to the root (C:\) of the ‘Sub CA’
10. Delete all other PKI related files in the ‘C:\‘ on ‘ROOT CA’
11. No log back into ‘Sub CA’/server 2
12. Open a new mmc window and add the ‘Certification Authority (Local)’ snap in
13. Open the Certification Authority console tree, right-click ‘Sub CA’, and then click Install CA Certificate
14. In the ‘Select file to complete CA installation’, navigate to your ‘C’ drive. Ensure that you are displaying ‘All Files (*.*)’ and click the ‘Sub CA.crt’ certificate. Click ‘Open’
15. In the console tree, right-click ‘Sub CA’, click ‘All Tasks’, and then click ‘Start Service’

Perform Post-Deployment Configuration for Enterprise Issuing CA

---

Configure Certificate Revocation and CA Certificate Validity Periods and Auditing

1. On the ‘Sub CA’ server open an elevated PowerShell and enter the following code:
   • Note: CA\AudtiFilter 127 enables all forms of auditing. You can use this setting to enable specific or all auditing events for CA

Certutil -setreg CA\CRLPeriodUnits 8
Certutil -setreg CA\CRLPeriod "Hours"
Certutil -setreg CA\ValidityPeriodUnits 10
Certutil -setreg CA\ValidityPeriod "Years"
Certutil -setreg CA\AuditFilter 127

Important: The default setting for Validity Period is 2 years in the registry. Adjust this setting accordingly to meet your needs of the entity certificate’s lifetime issued from Sub CA.

Important: The overlap period for CRLs is the amount of time at the end of a published CRLs lifetime that a client can use to obtain a new CRL before the old CRL is considered unusable. The default setting for this value is 10% of the CRL lifetime.

2. Back in the mmc, ‘Certificate Authority’ on the ‘Sub CA’, right-click ‘Revoked Certificates’, select ‘Properties’ and ‘verify/change’
3. Disable (uncheck) ‘Publish Delta CRLs’
   • Warning – You must manually de-select the “Publish Delta CRLs “ in the Certificate Authority console.

Configure the Authority Information Access (AIA)

1. Still on ‘Sub CA’ open an elevated PowerShell and enter the bellow:
   • make sure to replace <FQDN> with your FQDN

certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%4.crt\n2:LDAP:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.<FQDN>/CertEnroll/%3%4.crt"

2. Verify AIA configuration by running the following code:

certutil -getreg CA\CACertPublicationURLs

Configure the CDP

1. Still on ‘Sub CA’ open an elevated PowerShell and enter the bellow:
   • make sure to replace <FQDN> with your FQDN
   • also make sure to replace ‘CDP1 and CDP2’ with your CDP server names

certutil -setreg CA\CRLPublicationURLs "65:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl\n79:LDAP:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n6:HTTP://pki.<FQDN>/CertEnroll/%3%8%9.crl\n65:file://\\CDP1.<FQDN>\CertEnroll\%3%8%9.crl\n65:file://\\CDP2.<FQDN>\CertEnroll\%3%8%9.crl"

2. Verify the CDP configuration with the bellow code:

certutil -getreg CA\CRLPublicationURLs

3. Publish the CRL with the following:

certutil -crl

Install the Online Responder Role Service

---

Installing OCSP role on to CDP servers

This must be done on all CDP servers

1. Ensure that you are now logged onto <CDP>, server 3-4, with administrator privilege’s
2. From the Server Manager dashboard, choose ‘Add roles and features’
3. On the ‘Select Server Roles’ page expand ‘Active Directory Certificate Services’, and choose ‘Online Responder’, then click ‘Next’
   1. Note: If the ‘Add role services and features required for Online Responder’ page appears, click ‘Add Required Role Services’ and then click ‘Next’. Then, on the ‘Web Server (IIS)’, click ‘Next’
4. On the ‘Confirm Installation Selections’ page, click ‘Install’. Click ‘Close’ when the installation is complete

Add OCSP URL to Issuing CA AIA path

1. log onto <Sub CA> as an Administrator
2. In the ‘Certification Authority’ console, right-click ‘Sub CA’, and click ‘Properties’
3. On the ‘Extensions’ tab, under the ‘Select extension’, select ‘Authority Information Access (AIA)’, and then click ‘Add’
4.  In ‘Location’, enter the below url:
   • Make sure to replace <FQDN> with your FQDN

http://PKI.<FQDN>/ocsp

5. Select Include in the online certificate status protocol (OCSP) extension

Warning – A common misconfiguration is to select both checkboxes in the Extensions tab, which is incorrect. Ensure that Include in the online certificate status protocol (OCSP) extension checkbox is the only one selected.

Configure and Publish the OCSP Response Signing Certificate

1. Still logged onto the Issuing CA
2. In the ‘Certification Authority’ console
3. Right-click on ‘Certificate Templates’ and then click ‘Manage’
4. right-click ‘OCSP Response Signing’ template and then click ‘Duplicate Templates’
5. On the new ‘Properties of New Template’ dialog box, select the ‘General’ tab
6. Name the new template ‘New OCSP Response Signing’
7. On the ‘Security’ tab add both of your CDP servers 
8. Grant ‘Read’ and ‘Enroll’ permissions
9. Close ‘Manage Certificate’ Templates snap-in
10. Right-click ‘Certificate Templates’, select ‘New’, select ‘Certificate Template to Issue’
11. In the ‘Enable Certificate Templates dialog’ box, click ‘New OCSP Response Signing’

Configure Revocation Configuration on the Online Responder

1. Logon to the ‘CDP’ server
2. Open ‘Server Manager’
3. From the ‘Tools’ menu, select ‘Online Responder Management’
4. Right-click ‘Revocation Configuration’ and then click ‘Add Revocation Configuration’
5. On the ‘Getting started with adding a revocation configuration’ dialog box choose ‘Next’
6. In Name, enter the following: ‘Name of your Sub CA’
7. On the ‘Select CA Certificate Location’ page ensure that ‘Select a certificate for an Existing enterprise CA is selected’
8. On the ‘Choose CA Certificates’ page, ensure that ‘Browse CA certificates published in Active Directory’ is selected, and then click ‘Browse’
9. On the ‘Select Certification Authority’ dialog box, ensure that your new ‘Sub CA’ is selected
10. Leave the defaults on the ‘Select Signing Certificate’ page
11. On the ‘Revocation Provider’ page, click ‘Provider’
12. Review the list for ‘OCSP Responder’ to download CRLs in the form of LDAP and HTTP locations. Do not change the base CRL’s. Make sure to change the order to HTTP then LDAP
13. Clear the ‘Refresh CRLs based on their validity periods’ check box
14. In the ‘Update CRLs at this refresh interval (min)’ box, enter 15

Note – Modifying this setting to download CRLs at a faster rate than the CRLs normal expiration makes it possible for the OCSP responder to rapidly download new CRLs rather than use the last downloaded CRLs normal expiration date. Production needs may differ from the value chosen here.

15. On the ‘Signing’ page, ‘Hash algorithm’, select ‘SHA256’

Validate the Revocation Configuration Status

1. Still on the CDP server in the ‘Online Responder Management’ console
2. Select ‘CDP server’ under ‘Array Configuration’ on the left
3. In the center panel make sure that ‘Signing Certificate’ says ‘Ok’
4. Just below this make sure that you see ‘The revocation provider is successful using the current configuration’

Verify OCSP Configuration

1. On the ‘Sub CA’ ‘Issuing CA’ server
2. Open the PKI Enterprise mmc snap-in
3. You will see your ‘Root CA’
4. Review the current status
5. If ‘PKI Enterprise’ displays error, you will need to revoke the latest ‘CA Exchange’ certificate.
6. Then run the fallowing command from an elevated command prompt:

certutil -cainfo xchg

7. Now right click on the ‘PKI Enterprise’ and choose ‘Refresh’
8. There should now be no errors

---

You are now done installing, configuring and setup your new PKI. You can now shutdown the ‘Root CA’ server. I would recommend working with you cyber security team to determine how often they would like you to update the ‘Root CA’. If you have any questions please consider creating an account and leaving a comment. I will be release a few more how to guides in the future for:

Installing and Configuring a Web Enrollment on your CDP server or Standalone server

PKI GPO Configurations

Backup your PKI Infrastructure