Should CRLs be published for Standalone Offline Root CA?

Question

I'm setting up a two tier PKI Hierarchy in our Windows Server 2012 R2 domain.

A number of tutorials suggest that the root CA should publish its CA certificate and CRL in Active Directory and via HTTP, but I've also seen a suggestion that neither should be published and the CRL should not be updated.

Which is right / best practice?

The commands I was going to use on the Standalone Offline Root CA were:

certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl \n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n2:http://pki.matty.local/CertEnroll/%3%8%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.matty.local/CertEnroll/%1_%3%4.crt"
Certutil –setreg CA\ValidityPeriodUnits 10
Certutil –setreg CA\ValidityPeriod “Years” 
Certutil –setreg CA\CRLPeriodUnits 52
Certutil –setreg CA\CRLPeriod “Weeks”
Certutil –setreg CA\CRLOverlapPeriodUnits 12
Certutil –setreg CA\CRLOverlapPeriod “Hours”
Certutil –setreg CA\CRLDeltaPeriodUnits 0
Certutil –setreg CA\CRLDeltaPeriod “Days”
Certutil –setreg CA\AuditFilter 127

But now I'm wondering if I should omit the CRL bits so that I don't have to manually publish and copy the CA certificate and CRL into LDAP and the HTTP location.

The commands I'd run would therefor be simply:

certutil -setreg CA\CRLPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%3%8%9.crl \n10:ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10\n2:http://pki.matty.local/CertEnroll/%3%8%9.crl"
certutil -setreg CA\CACertPublicationURLs "1:C:\Windows\system32\CertSrv\CertEnroll\%1_%3%4.crt\n2:ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11\n2:http://pki.matty.local/CertEnroll/%1_%3%4.crt"
Certutil –setreg CA\ValidityPeriodUnits 10
Certutil –setreg CA\ValidityPeriod “Years” 
Certutil –setreg CA\CRLDeltaPeriodUnits 0
Certutil –setreg CA\CRLDeltaPeriod “Days”
Certutil –setreg CA\AuditFilter 127

Or maybe (if it's possible/recommended to disable the CRL):

Certutil –setreg CA\ValidityPeriodUnits 10
Certutil –setreg CA\ValidityPeriod “Years” 
Certutil –setreg CA\CRLDeltaPeriodUnits 0
Certutil –setreg CA\CRLDeltaPeriod “Days”
Certutil –setreg CA\AuditFilter 127

Which would mean I'd literally just be starting the Root CA up to authorise a new Issuing CA and nothing else.

How have you done yours and what would you do if you were setting it up from scratch again now?

Answer 1

You should publish the Root CA's CRL otherwise there will be no way to revoke your Issuing CA's certificate if the worse came to the worse and that CA was compromised. Your only option at that point would be to wipe your whole chain (including Root) and build again from scratch. That would also involve ensuring that each relying party has removed the original Root CA certificate from their trust-anchor store - not a trivial task. Without a CRL you lose effective control of all subordinate CAs and end-entities and consequently the trustworthiness of your Root CA.

Note that even with a Root CA certificate CRL, ensuring that every single relying party has the freshest CRL possible after a compromise of the Issuing CA can be challenging. Many relying-parties cache CRLs therefore you'd need to ensure that this cache is cleared on every single one - again not a trivial task.

Things get even more complex due to the fact that many browsers (Chrome, Firefox) don't even check CRLs any more.

Pragmatically, if you publish the CRL and an Issuing CA is compromised, at least you can take the moral high-ground. If a relying-party's software (which you have less or even no control over) doesn't check this CRL for another 6 months then nobody can point the finger of blame at you. However, if you chose not to publish a CRL, you'd have some explaining to do.

You can publish the Root CA's certificate via HTTP but if you do, you should also provide an alternative method for relying-parties to confirm that this Root CA certificate is the genuine one - somehow publish a SHA-1 or SHA-256 hash of the file or the value of the SubjectKeyIdentifier extension of the certificate if present. In a Windows environment it is more common to present the Root CA certificate to the AD administrator who can distribute it to all Windows devices using Group Policy. However, it is useful to have it published so that non-Windows devices can download and install it.

There is no need to publish CRLs in LDAP these days as it's slow and not all relying-parties can access it. Far better to publish to a HA HTTP service.

There is no point in publishing the Root CA certificate in LDAP as any party which will relying on it will have it in it's trust-anchor store. If it doesn't have it in the store, it has either decided not to trust it, or needs to securely add it to it's trust-anchor store first.

So, simply remove all references to the LDAP:// URLs and only keep HTTP:// URL in the CRLDistributionPoint registry key.