There are countless “how-to” articles and best practices recommending use of an offline root certificate authority (CA). Though as the title suggests, is this recommendation obsolete?

The context of my question is for small to medium enterprises. NOT large enterprises (or otherwise) with multiple tiers of subordinate CAs.

Revoking a Root CA Certificate, as discussed in previous posts, is a difficult process. It can only be achieved via:

  1. software updates
  2. scripts
  3. configuration management systems
  4. adhoc

The premise of an offline root CA (metaphorically speaking) is to have it on a laptop where it is only brought online to approve a subordinate CA. Otherwise it resides in the highest physical security possible. Should a subordinate CA become compromised, not all is lost since the offline root CA is fine. However the far majority don't include a CRL Distribution Point (CDP) making it impossible to determine what certificates have been revoked. Thus making revocation of an immediate subordinate CA similar to that of a root CA revocation. Nothing was gained by having an offline root CA in the first place.

The alternative is to publish a CDP which seems to make the most sense but no longer allows the root CA to be offline. If the CDP is updated once a month, the worst case scenario is clients will not identify a revoked certificate for an entire month. Meanwhile the administration of this requires staff to boot-up the system and update the CDP monthly. Lengthening this windows (+1 month) only creates a larger window where clients would trust a revoked certificate while shortening this window makes it clear that the system should remain online due to the administrative overhead.

Based on this, it seems offline root CAs should only be used in very large enterprises with multiple tiers of subordinate CAs. Though these are minimal since often they already have a certificate infrastructure and should be considered the exception where offline root CAs are used. The far majority of new rollouts are in the small to medium size networks where the root CA should remain online so it can frequently publish to the CDP. Thus leading me back to my question, is the offline root CA obsolete?

  • I've just checked this site, Google and LinkedIn websites and the certificates issued by their Root CAs all have CRLs. Can you expand on your However the far majority don't include a CRL Distribution Point statement? Commented Jan 17, 2018 at 17:49
  • As I understand it, some browsers (like Chrome) don't even check CRLs. So even if you did have a CRL Distribution Point, it wouldn't help.
    – Ajedi32
    Commented Jan 17, 2018 at 18:13
  • 2
    @garethTheRed This question is asking about internal root CAs in corporate environments. Neither this site, Google, nor LinkedIn fit that description.
    – Ajedi32
    Commented Jan 17, 2018 at 18:16
  • @Ajedi32 is correct on both accounts though not sure about chrome specifically. It is up to the client software to validate certs and this question is regarding corporate environments. Commented Jan 17, 2018 at 19:11
  • @garethTheRed the root certificate is the one in question not client certs or otherwise. While the root cert for many ssl certificate providers do not include a CDP, they have many tiers which make them out of scope. Check the "Trusted Root Certificate Authorities" (or similar) on your own system and you'll see the CDP is absent. Commented Jan 17, 2018 at 20:08

3 Answers 3


I think we need to consider here definitions of the word "offline".

As you suggest, the following are conflicting requirements:

  • Have the Root CA be powered off except when issuing / revoking a Subordinate CA cert.
  • Have the Root CA issue frequent CRLs.

The solution I see deployed most often is to do "soft air-gapping" or "soft offline" through firewalls so that the Root CA can still push new CRLs daily or hourly to be picked up and re-published by the CDP or OSCP responders. Block all other traffic to / from the Root CA machine.

I have even heard of one clever solution where the Root CA pushes CRL data over its audio line-out jack, which is a one-way port at the hardware level.

  • I like your idea of soft air-gapping and the audio line-out is really cool. So much documentation on new PKI deployments are centered around offline CAs that it seems we've reached the Security Monkey Level since true offline CAs should really only be used in multi-tier deployments. Commented Apr 11, 2018 at 17:16

One other thing, there is no reason an offline root CA can't publish it's certificate revocation list (CRL) to another location that is online. The lifetime of a CRL can be extended to a very large time period using this command:

certutil -setreg CA\CRLPeriodUnits 6
certutil -setreg CA\CRLPeriod "Years"

You can also publish Delta CRL's that contain only revocations that have changed since the last full CRL was published.

Now since the only time you are going to revoke certificates from the offline root CA is if something major happens what is the risk of having a huge CRL lifetime, chances are you will never revoke any certificates from your offline host anyway but if you do and you want CRL checks to pick this up you can still have that part in place so if you need it it will work.

Offline CA's is often a debated subject, but if you have one an suffer a major compromise you will be glad you have it, if you don't have it but need it you'll regret it. It's a matter of risk vs reward.

  • 1
    to another location that is online - that's really my point for by doing this the Root CA is no longer "offline". It must be online to publish to that location. So why not keep it online (segregated) and shorten the publishing window? Agree that It's a matter of risk vs reward. as is the case with InfoSec. It just seems like much of the docs on this are regurgitated. Commented Sep 20, 2018 at 21:17

The root CA is never brought online in the sense that it touches a network. Use a floppy drive, USB drive, audio-out jack, etc. Microsoft has documentation ALL OVER and is easy to find, that describes the minimum Production structure as two-tiers at least: an Offline Root and an Online Enterprise Subordinate Issuer. The Online Issuer is where all certs and CRLs are issued from, with the exception being the CRL for the Online Issuer, which is generated on the Offline Root and transferred via ways listed above. You generate that CRL once a year (or whatever you chose that works best for security requirements) and transfer that CRL to the public CDP (certificate distribution point) and that's that. Otherwise the offline root can be powdered off all the time.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .