Sunday, December 11, 2016

PKI - ADCS: Health Check - part 1

In February and March 2015, I dedicated nine blog posts to the subject of Public Key Infrastructure with Active Directory Certificate Services.

This was the first of nine posts:

PKI (Public Key Infrastructure) with ADCS, Part 1: Introduction

At this time, I am reviewing some PKI best practices and verification of PKI health with various tools, in particular the PKI Health Tool (or "PKI View").

The subject was in fact already adressed, albeit indirectly, in my original series on posts on PKI:

PKI (Public Key Infrastructure) with ADCS, Part 7: configuration of the subordinate CA

Although I had addressed (very briefly) troubleshooting errors revealed by the PKI Health Check tool, I wanted to take advantage of this review to present a problem that will occur a year or so after the initial PKI installation if we do not manage our certificate services with diligence (expiration of the Root certificate CRL - "certificate revocation list"). In a blog post to follow, I will demonstrate the solution to this problem.


We should verify our PKI after installation (which I did as shown in the second link provided above) and at regular intervals later.

In particular, we want to determine if clients can access certification authority (CA) certificates and certificate revocation lists (CRLs).

Note: I'll use the terms "CA" and "CRL" in the rest of this blog post for concision.


Clients need to access the certificate of the CA that issued the certificate being verified as well as the certificate that provided the issuing CA with its own certificate. This process establishes a "chain of trust" and validates the "certification path" from the certificate being verified to the root CA of the PKI that produced the certificate in question.

We can see this "chain" when we open a certificate and look at the "Certification Path" tab.

Moreover, clients need to access the CRL to see if the certificate has been revoked.

  • The client uses the URL indicated in the certificate's AIA extension (Authority Information Access) to download the certificates needed to establish the chain of trust.
  • The client uses the URL indicated in the certificate's CDP extension (CRL Distribution Point) to access the list of revoked certificates that can no longer be trusted.

PKI Health Tool

If we want to verify the health of the PKI overall (rather than a specific certificate) we can use the "PKI Health Tool". Previously a down-loadable utility, it is part of the Active Directory Certificate Services (ADCS) role since Windows Server 2008.

We can access it in various ways.

We can enter pkiview.msc in the run dialog box and open the tool.

We can also open Server Manager, expand the Roles section: ADCS | Enterprise PKI

At the top level (PKI-ROOT-CA) we can see (in the first example below) that the status is OK. This takes into account all layers below.

Note: there is a green check on the icon of the issuing CA as well. This is always a good sign.

But what if there is a problem? Here is another example:

But what, exactly, is not right?

We need more details. At what level is the problem happening? Is it a problem with one of the CA certificates or with one of the CRLs?

So let's expand the structure and descend to the next level...

We can see the certificate of the Root CA (which is OK). We can also see that the Root CA certificate (necessary for certificate chaining) is available at both the http and ldap locations. On the other hand, the CRL for the Root CA, while available, has expired. Such an error has serious consequences as we can see when attempting to view the details of the subordinate (issuing) CA:

The issuing CA is offline and our PKI is no longer functional.

Note: I demonstrate how to correct this in a future blog post.

Some remarks...

The error icons have color codes that reflect (more or less) the severity of the problem:
  • Yellow - the CRL is expiring (but not yet expired).
  • Red - the CRL has expired or the AIA/CDP location cannot be accessed.
  • Red X - the CA is offline.

The status column provides more details about the error. Besides "OK", we may see:
  • Expiring - the certificate or CRL in question is expiring.
  • Expired - the certificate or CRL in question is expired.
  • Unable to download - the certificate or CRL in question could not be downloaded.

We should also note that we can adjust the number of days or hours for the certification expiration status.

We right-click on the Enterprise PKI icon and select Options

Besides viewing the Certificate Templates (which I would usually access through the Certification Authority MMC), we can view the "AD Containers" that hold certificates:

This can be useful for troubleshooting. In the screenshot above, the status is OK for all certificates in the AIA container. In the next blog post, we will see errors for a CRL in the CDP container.

Server Manager - Active Directory Certificate Services role

In the Active Directory Certificate Services role section of Server Manager, we have access to three useful tools:

  1. Event Viewer (filtered for ADCS related entries).
  2. System Services (where we can verify that services necessary for ADCS are running). Like for Event Viewer, this is the Services administrative tool (services.msc) filtered for ADCS related entries.
  3. ADCS Best Practices Analyzer.

Here is a view of the first two tools (yes, "Events" can be expanded):

The ADCS BPA is rather limited (at least in Windows 2008). There are only 8 checks, for example:


The tools presented so far are graphical tools. We can also use the certutil command line utility, especially if we require a high level of detail.

For example, we viewed a certificate earlier and validated the "chain of trust" to the certificate of the root CA. We can view (and save or output to a text file) much of the background certification validation process with certutil and in particular the following commands:

  • certutil -verify -urlfetch NameOfCert.cer
  • certutil -URL NameOfCert.cer

The output of the first command is quite verbose, possibly as long as this entire blog post. Therefore, I will only present a very brief sample here:

In the section above, certutil validates the AIA and CDP information of the certificate that was designated.

The second command opens a window where we can select various options and verify the URL for the AIA and the CDP (these were presented above):


This concludes my review of some of the tools we can use to verify the health of our Windows ADCS PKI. Although not presented in this blog post, we should remember that ADCS has numerous logging options which could also prove useful in the management and troubleshooting of a PKI. In a future blog post (probably the next one), I will demonstrate how to resolve the problem that caused our subordinate CA to go offline.

1 comment:

  1. I have setup a two tier PKI on server 2016 to run in parallel with server 2008 PKI infrastructure (2008 will be decommissioned once 2016 is up and running) I went into PKIVIEW.MSC console to perform a health check. When I click on the enterprise CA the status is showing "OK" for CA Certificate, AIA Location, CDP Location, Delta CRL Location and OCSP Location.

    But on Enterprise PKI - when I right click and choose Manage AD containers, I cannot find an entry for my New Certificate Server under "CDP Container" tab (old servers are there with base and delta CRL) and also the KRA container is empty. In the active directory sites and services under Services->Public Key Services->CDP; I can see the new issuing CA folder and inside the folder the new CA name listed as cRLDistributionPoint. Under KRA tab the new CA name is listed as type msPKI-PrivateKeyRecoveryAgent.

    Is this normal or am I missing something? If I am missing something how do I fix it.