Microsoft PKI – Start Here

This page is intended to be the master table of contents to all of the Microsoft PKI pages within this blog. It will also provide additional information that may help in understanding how to read through these pages, provide outside links, and provide other pertinent info for the Microsoft PKI.

These pages are mostly about building a MS PKI, not managing templates and certificates. I may add some of that later, but it probably will not consist of too much.

This group of pages exists because anyone who has set out to learn the Microsoft PKI will surely have had an abundance of frustration.

For one, finding information is hard. Most of the stuff the Microsoft has published has been moved, superseded, or contains errors. In fact, at this point very little Microsoft published PKI documentation exists for Server 2016 and up. However, most of the published information for Server 2003 and up is still mostly applicable. But I have also found very little help in the PKI pages published outside of Microsoft. A proper PKI is complicated to learn, I suspect that I have a few screw-ups in my pages as well.

Second, the topic of PKI is large. If you don’t understand what a PKI is and the purpose of the servers, you will have a hard time getting a PKI setup and properly working. Do yourself a big favor and first learn as much as possible about certificates and how they are used in an IT infrastructure. Then learn how a PKI works to fill this need. These two things will take time but will also help you get to the point where the instructions contained in these pages start to make sense.

Speaking of making sense of these pages, no attempt was made here to explain things in which a novice can learn from. These were put together as a way for me to remember how to do things. Most of the instructions in these pages I wrote out as I worked with my test bed, trying to learn how to do a proper PKI within the Microsoft world. I do a lot of shortcuts here but anyone with Microsoft server management time should be able to follow along, especially if they followed my suggestions in the paragraph above.

There are a large number of PKI topics and configurations that exist but are not cover here in the blog, such as three tier deployment, OCSP, and web enrollment, just to name a few. Likewise, my notes on certificate management are limited. You get the idea. If you do the learning as suggested above, you will see how much is not covered here, but you will also have an easier time learning the topics not covered here.

PKI Setup Process Order

Using the Microsoft Documentation, here is the order of setup used for both a single tier and a two tier PKI:

Single Tier – From: https://social.technet.microsoft.com/wiki/contents/articles/11750.adcs-step-by-step-guide-single-tier-pki-hierarchy-deployment.aspx

  1. Install Active Directory Forest
  2. Prepare HTTP Web Server for CDP and AIA Publication
  3. Install Enterprise Root CA
  4. Perform Post Installation Configuration On Enterprise Root CA
  5. Install and Configure Online Responder (OCSP Responder)
  6. Verify PKI Hierarchy Health

Two Tier – From: https://social.technet.microsoft.com/wiki/contents/articles/15037.ad-cs-step-by-step-guide-two-tier-pki-hierarchy-deployment.aspx

  1. Install the Active Directory Forest
  2. Prepare the web server for CDP and AIA publication
  3. Install the standalone offline root CA
  4. Perform post installation configuration steps on the standalone offline root CA
  5. Install Subordinate Issuing CA
  6. Perform the post installation configuration on the subordinate issuing CA
  7. Install and configure the online responder
  8. Verify the PKI hierarchy health

Links to pages within this blog:

A list of the more important links: 
https://www.binaryrecon.net/microsoft-pki-my-master-links-to-documentation
Firewall requirements:
https://www.binaryrecon.net/microsoft-pki---port-requirements-for-firewalls
Build out a stand-alone test PKI server using the command line:
https://www.binaryrecon.net/microsoft-pki---single-tier-server-command-line-setup
Build out a stand-alone test PKI server using the graphical interface:
https://www.binaryrecon.net/microsoft-pki---single-tier-server-graphical-setup
Build out a two tier PKI: 
https://www.binaryrecon.net/microsoft-pki---two-tier-configuration
Use pkiview to check for a proper configuration:
https://www.binaryrecon.net/microsoft-pki---pki-health-pkiview
Decommission a CA server that is being replaced:
Note: this does not consider all possibilities. Make sure you understand 
what you need to do beforehand:
https://www.binaryrecon.net/microsoft-pki-decommission-ca-server

Microsoft PKI – Single Tier Server (Command Line Setup)

If you have not already read the first page in this MS PKI series, 
you should do so before continuing.

The following is useful for setting up a single ADCS PKI server in a very small environment such as a lab. It provides instructions using a mixture of both PowerShell and the command line interfaces. It provides examples of the various commands for publishing the CDP/AIA points to computers that are both on and off the domain.

If HTTP is needed to publish CRL/AIA, it must be on a different server (Maybe, I’ve had issues getting CRL/AIA publishing to work on the same server). The requirements can be used from the “Two Tier” setup instructions located on a different page.

Note that a single tier PKI is not typically appropriate in a production environment.

A second page is provided elsewhere that uses a the standard Microsoft GUI for building and configuring the server.

Build up the server and add to the domain.

The CAPolicy.inf is not necessary so as an example it is skipped in this example. The settings will be added via the command line below.

Otherwise: Copy CAPolicy.inf to C:\windows  (%systemroot%) of root CA server. See the Single Tier Server (GUI) page for the example CAPolicy.inf file if needed.

Warning:  If creating a new replacement issuing (including single tier) server, use the CAPolicy.inf with the “LoadDefaultTemplates=0” line added.  When server is ready to issue, manually add the certificate templates.

This is both an enterprise root CA and issuing CA so it must be on the domain before running the following commands.

Install CA Role:

In the PowerShell terminal as administrator:

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools 

Install-AdcsCertificationAuthority –CAType EnterpriseRootCA –CACommonName "ContosoRootCA" –KeyLength 4096 –HashAlgorithmName SHA256 –CryptoProviderName "RSA#Microsoft Software Key Storage Provider"

Post Install Configuration:

Open command prompt as administrator. Don’t make these too short if using LDAP. Consider OCSP instead.

NOTE:  There are many settings.  These are pretty minimal.

Certutil -setreg CA\RenewalKeyLength 4096
Certutil -setreg CA\RenewalValidityPeriod "Years"
Certutil -setreg CA\RenewalValidityPeriodUnits 20
Certutil -setreg CA\AlternateSignatureAlgorithm 0
Certutil -setreg CA\CRLPeriodUnits 1 
Certutil -setreg CA\CRLPeriod "Weeks"  
     -- Next two if CRL Deltas are used (which I usually don't)--
Certutil -setreg CA\CRLDeltaPeriodUnits 1 
Certutil -setreg CA\CRLDeltaPeriod "Days"

Add CDP (CRL Distibution Point) – (The order of these matters):

You may not need all of these. I listed all as examples of how to do them because good examples are hard to find else where. Select only the ones you need and read the examples carefully.

First remove the default CDP points using PowerShell:

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};

Use the following as needed (copy/paste not necessarily a good idea here):

Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer

In “Certificate Authority” (certsrv GUI), check the following:

"Publish CRLs to this location"
"Publish delta CRLs to this location"

In PowerShell window:

Add-CACRLDistributionPoint -Uri "ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10" -AddToCrlCdp -AddToCertificateCdp -PublishToServer

In “Certificate Authority” (certsrv GUI), check the following:

"Publish CRL's to this location"
"Include in all CRLs. Specifies where to publish in the Active Directory when publishing manually"
"Include in the CDP extension of certificates"

In PowerShell window:

Add-CACRLDistributionPoint -Uri http://www.contoso.com/pki/%3%8%9.crl -AddToCertificateCDP -AddToFreshestCrl

In “Certificate Authority” (certsrv GUI), check the following:

"Include in CRLs. Clients use this to find delta CRL locations"
"Include in the CDP extension of issued certificates"

In PowerShell window:

Add-CACRLDistributionPoint -Uri file://\\App1.corp.contoso.com\pki\%3%8%9.crl -PublishToServer -PublishDeltaToServer

In “Certificate Authority” (certsrv GUI), check the following:

"Publish CRLs to this location"
"Publish Delta CRLs to this location"

Add AIA  (Authority Information Access) – (The Order Matters):

First remove the default CDP points using PowerShell:

Get-CAAuthorityInformationAccess | where {$_.Uri -like '*ldap*' -or $_.Uri -like '*http*' -or $_.Uri -like '*file*'} | Remove-CAAuthorityInformationAccess -Force

Use the following as needed (copy/paste not necessarily a good idea here):

Add-CAAuthorityInformationAccess -AddToCertificateAia "ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11"

In “Certificate Authority” (certsrv GUI), check the following:

"Include in the AIA extension of issued certificates"

In PowerShell window:

Add-CAAuthorityInformationAccess -AddToCertificateAia http://www.contoso.com/pki/%1_%3%4.crt

In “Certificate Authority” (certsrv GUI), check the following:

"Include in the AIA extension of issued certificates"

In PowerShell window:

Add-CAAuthorityInformationAccess -AddToCertificateAia file://\\App1.corp.contoso.com\pki\%1_%3%4.crt

Check our work:

Restart certificate services to activate this configuration in a PowerShell window:

restart-service certsvc

Trigger a manual publish of a certificate revocation list:

certutil -crl

C:\Windows\System32\CertSrv\CertEnroll – .crl’s date modified should change when CRL is published.

Check PKI health:

pkiview

Also check “Manage AD Containers” from the pkiview menu.

If CA Object Access Auditing is needed, see the page here.