Tuesday, December 13, 2016

PKI - ADCS: Health Check - part 2 (problem resolution)

We encountered a problem with Active Directory Certificate Services in my previous blog post:

In this blog post, we will attempt to resolve it.


So what was the problem?

It looks like the CRL of the root CA has expired (it was published in two places - on a web share (http) and in Active Directory (ldap)):

What about the CRL of the subordinate CA?

It is hard to see because the subordinate CA (issuing CA) is offline and no details are displayed:

But let's look in some other places, like "Manage AD Containers" (please consult the previous blog post if you do not know what or where this is). Everything looks fine until I come to the "CDP Container" tab:

I notice that both the CRL published by the root CA and the CRL published by the subordinate CA have expired. Both CAs will have to publish a new CRL and we will have to copy (by one method or another) the offline root CA's CRL to the subordinate CA.

Even so, I'm wondering if I cannot start the ADCS service and obtain more information?

The short answer is... No.

At one point, I attempted to start the service. This fails: 

Note: if we had not already determined that the expired CRL(s) is the problem, the reference to the revocation function is yet another pointer in this direction.

I attempt to publish the CRL on the subordinate CA. Maybe we can update the CRL at this level and make at least some progress?

Note: seriously, I would not have bet much on that option since the ADCS service is not even running...


We could (but should not) disable revocation checking.

First of all, does it even resolve the problem?

We disable revocation checking with this command (and then restart the ADCS service):

certutil -setreg ca\CRLFlags +CRLF_REVCHECK_IGNORE_OFFLINE

At first glance, this seems to improve matters.

After restarting the service, the subordinate CA is able to publish a new CRL (I repeated the same process as above) and I can expand the PKI Health Check tool:

Note the green check on the "Machlinkit Issuing CA" and compare with the previous screenshots.

At least the CRL of the issuing CA is up-to-date (status is OK from top to bottom):

But this is not a good solution for several reasons:

It only disables revocation checking on our subordinate CA. All other clients will continue to attempt to consult the CRL (which will result in failure since the CRL of the root CA is still not available).

Even if we were stubborn and disabled revocation checking on all clients (perhaps with a registry edit via Group Policy), we would prevent a critical security function from taking place. It would be impossible to reject compromised certificates. If the credibility of our PKI is important, disabling CRL would precisely destroy this credibility.

As it is very poor practice to disable revocation checking, I will re-enable it with this command:

certutil -setreg ca\CRLFlags -CRLF_REVCHECK_IGNORE_OFFLINE

As you might have expected (if you realize that both CRLs must be valid - 1 out of 2 is not enough), the subordinate CA goes offline again, once revocation checking is re-enabled and the ADCS service (certsvc) restarted.

We must publish an updated CRL from the root CA. There is no (acceptable) method to avoid this.

So I start and logon to the offline root CA (in my case, this is a virtual machine with no network adapters).


Once we have logged into the root CA, we can trigger the publication of a new CRL with one of two methods...

At the command line:

certutil -crl

Or in the Certificate Authority MMC:

We attempted this in one of the screenshots above - it's the same place and process on the root CA. We then copy the CRL file to the subordinate CA with removable media ((virtual) floppy, USB, etc.).

Note: it is worth specifying that the new CRL published on the root CA can be found in this location:


We will copy (or publish) the CRL file to three locations on the subordinate (issuing) CA:
  1. The (local computer) certificate store of the subordinate CA
  2. The web share indicated in the CDP record.
  3. Active Directory

The web share is the most simple operation. It is a matter of copying the CRL file to the location indicated:

I predict that if the CRL is available even in one location, the subordinate CA will detect it when I restart the ADCS service.

This is indeed what happens.

If we expand PKI View to the issuing CA, we notice, first of all, that we can descend to this level now, even though revocation checking was re-enabled. We also notice (see the screenshot below) that the CRL in the http location has a status of OK:

However, the CRL published to Active Directory is still in the "expired" state.

We still need to publish the CRL of the root CA to the local computer store of the subordinate CA as well as Active Directory. The commands below allow us, respectively, to achieve that double objective:

certutil -addstore -f Root C:\PKI\PKI-ROOT-CA.crl

certutil -dspublish -f C:\PKI\PKI-ROOT-CA.crl

Of course, you would adjust the path to the CRL to indicate the location to which you copied the CRL of the root CA.

Here is a screenshot of the operation:

Now if we consult the PKI Health Check tool, the status is OK for the entire system and the Machlinkit issuing CA is online (note the green check):

No comments:

Post a Comment