How to automate publication of CRL and CRT files to CDP and AIA location?

Question

I'm setting up Two-Tier PKI for the first time in our Windows Server 2012 R2 environment and I've read several tutorials on setting this up. Some of the methodology is very different, but I've chosen to go with the guide at http://www.rebeladmin.com/2018/06/step-step-guide-setup-two-tier-pki-environment/.

One thing that several guides I've read agree on is that a copy of the Offline Root CA and Enterprise CA CRT and CRL files should be made available via IIS/HTTP, for example - http://pki.mydomain.local/CertEnroll (and also published to Active Directory). Obviously I'm going to have to manually copy and publish files from the Root CA, but how should I manage publishing the CRL and CRT files to the CDP/AIA location for serving up via HTTP?

The tutorials suggest creating a shared folder at C:\CertEnroll and copying files from C:\Windows\system32\CertSrv\CertEnroll\ into that directory, for hosting via IIS/HTTP, but why can't files be published to that directory in the first place, so that I don't have to manually copy them each time the CRL is updated - every 13 weeks as they've suggested?

EDIT: On a side note, is it even necessary to publish CRL and CRT files via HTTP if they're also in Active Directory / LDAP?

Answer 1

You shouldn't really install the webserver (IIS in your case) on the same server as the CA any more than you should install the CA on a server which provides other services (DCs are a common one).

Instead, stand-up another server for IIS. Better still, stand-up two and load balance them.

Create a share (such as cdp$) on the IIS (or IISes if that's the correct term) and make sure that this share is writable by members of the CertPublishers group. This group is automatically created when you install ADCS and populated with all CAs in the forest.

On the ADCS CA's properties dialogue on the Extensions tab, add the path to this share, as well as the variables that create the CRL filename, as a CDP entry. Something similar to:

file:\\iis1.example.com\cdp$\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

and ensure that Publish CRLs to this location is ticked for this entry.

Every time your CA publishes a CRL, it will push a copy to this share. That share needs to be published in IIS and a URL which points to the CRL file published in the certificate issued by this CA.

Therefore, on the same dialogue as before create an entry similar to:

http://iis1.example.com/cdp/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl

and ensure Include in the CDP extension of issued certificates is ticked. Note that if you want a more generic name and/or you're using a load-balancer, you can change the hostname element above to anything as long as you configure DNS so that it resolves to the correct server or load-balancer. Maybe something generic, such as pki.example.com?

So that relying-parties can find the Enterprise Issuing CA certificate when misconfigured servers don't send them, add something similar to the following to the AIA extension on the same tab as above:

http://iis1.example.com/cdp/<CaName><CertificateName>.crt

and ensure Include in the AIA extension of issued certificates is ticked.

You do not need to add a file:// entry for the AIA extension as the CA certificate only changes once every x years, so you can manually upload the Enterprise Issuing CA certificate to IIS.

You also manually upload the CRL from the Root CA to this same IIS server, but you should:

• Have previously added a similar http entry to the one above on the Root CA so that the correct URL is embedded in the enterprise issuing CA certificate.
• Ensure that the CA Names differ so that you end up with different filenames (to avoid overwriting CRLs).

You do not need to publish the Root CA certificate in IIS as every relying-party should have this certificate in their trust-anchor store already.

Finally, you should avoid AD/LDAP or any other directory service for publishing CRLs as not all relying parties can access them - stick to HTTP.