Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If an RSA private key of a root CA is stored offline, how does it revoke certificates it signs?

From looking at OpenSSL config the default_crl_days option seems to indicate that a CRL must be regenerated every x amount of days. For an offline CA, this would seem to mean that someone would have to manually do this on this interval.

Is this correct, or is default_crl_days meant to be a TTL for clients to re-check the CRL? Is there a way of avoiding regenerating the CRL if nothing has changed?

share|improve this question
up vote 4 down vote accepted

A CA must indeed publish CRL regularly, and if the CA is offline, then human intervention is needed. Each CRL has an issuance date (thisUpdate) and a provisional date of next publication (nextUpdate) which everybody uses as an end-of-validity date for the CRL. The next CRL must be published before reaching the nextUpdate date of the current CRL; otherwise, verifiers will begin to reject the certificates.

Common practice is to have an offline root CA which issues relatively long-lived CRL (e.g. one CRL every three months, with a nextUpdate set to current time + 4 months). That root CA is used to issue only a single certificate, for an intermediate CA, which is online, and does the bulk of certificate issuance (and that intermediate CA publishes CRL much more regularly). The offline root CA is kept as a "last recourse": if the intermediate CA is compromised, then the root can revoke it, so there is a "bad period" to suffer (until the end of validity of the current root CRL, at most), but the root key distribution needs not be redone when the new (intermediate) CA is built and started.

A niftier method is to have a semi-offline root CA: the root CA is linked with the outer world through a physically one-way canal (I have done it with an audio cable: the "line out" jack on the server is inherently one-way, so no risk of intrusion coming up that cable). This allows the root to publish CRL often (e.g. one per week, even one per day) without needing human intervention. Actual revocation would still need physical intervention, so an intermediate CA as described above would still be highly recommended.

Note that an offline or semi-offline CA cannot synchronize itself with network time sources, so the root CA clock may drift. Since the CRL have a validity period, this requires some supervision (you can tolerate a drift of a few minutes, so this is no hardship, but you'd better keep an eye on it anyway).

share|improve this answer
Yeah, unfortunately most of us can't afford a local caesium clock. However wouldn't a GPS timesource for maintaining sync be acceptable? – ewanm89 Apr 30 '13 at 19:43
It really depends on your goals and requirements. GPS signals can be emulated so you have to somehow make sure that your receiving antenna is not vulnerable -- which can be complicated because such antenna are often on the roof (receiving GPS signal from a secured server room can be challenging). – Thomas Pornin Apr 30 '13 at 20:03
I was thinking about storing the root key on a USB stick and putting it in a safe. The certificates being signed are client certificates (by an intermediate CA), and is done infrequently. My goal was to only update the CRL when a certificate was actually revoked - but I'm not sure how long CRLs are cached for. – Luke Apr 30 '13 at 20:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.