Synopsis: After the first year of deployment of one of my two-tier Enterprise PKI environments, I noticed that certificates were generating weird errors, new certificates could not be issued automatically, nor could certificates be requested manually.

Here is an image of what the subordinate certificate authority looked like in Server Manager; showing CDP Location #1 expired.

Here was an error that prompted my investigation, when requesting a certificate manually.

Status: Request denied
The revocation function was unable to check revocation because the revocation server was offline.  Error Constructing or Publishing Certificate.  The request ID is 640.

Here were some of the errors in event viewer on the subordinate CA:

Event ID: 48
Level: Warning
Revocation status for a certificate in the chain for CA certificate 0 for My CA0 could not be verified because a server is currently unavailable.  The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).

Event ID: 100
Level: Error
Active Directory Certificate Services did not start: Could not load or verify the current CA certificate. My CA The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).

Revocation status for a certificate in the chain for CA certificate 0 for My CA could not be verified because a server is currently unavailable.  The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613).

Upon inspection, it turns out the CDP Location for the subordinate certificate authority had expired.

According to a couple technet article I stumbled across, if i ran certutil -CRL, it would renew the CDP location and all would be happy.  Not surprisingly, I received another error:
CertUtil: -CRL command FAILED: 0x800706ba (WIN32: 1722)
CertUtil: The RPC server is unavailable.

Solution: When setting up my PKI environment, the CDP was manually published to the Subordinate CA for security reasons (the Root CA should be turned off most of the time).  That being said, manually generating a new CRL from the Root CA, coping it over to the Subordinate CA's directory that is publishing the CRL, and restarting the Active Directory Certificate Services service did the trick for me.

To manually generate the CRL from the Root CA

1.  Open up Active Directory Certificate Services (Start->Administrative Tools->Certification Authority)
   
2. Under Certificate Authority, expand your CA, right click on Revoked Certificates, and select All Tasks -> Publish.
   
3. Click New CRL when the Publish CRL dialog box pops up and click OK
   
   
4. Navigate to the directory where the CDP gets published via Windows Explorer
   1. The default directory for this is usually at C:\Windows\System32\CertSrv\CertEnroll
5. Copy the YourCAName.crl file to an external hard drive to copy over to your subordinate ca.

Importing the CRL on the subordinate CA

The latest CRL is fetched from a published website.  In this case, I needed to replace that CRL so the service could properly startup/continue processing certificate.  To do so, I logged into the server hosting the CRL file, opened up IIS, and browsed to the area hosting the CDP.  Last, I copied the CRL file we generated on the Root CA to this directory.

1. Remote to the machine hosting the CRL file
2. Open up IIS Manager (Start->Administrative Tools->Internet Information Services (IIS) Manager
   
3. Expand the server, Sites, Default Web Site, and right click on CDP, select Explore
   
4. Copy the CRL we generated from the Root CA to the directory that just opened (if your certificate authority was working before, replace the old CRL with this one).

Restarting the service

1. Click Start->Administrative Tools->Services
   
2. Right click on Active Directory Certificate Services and select Restart (or Start if the service blew up like mine)