2
$\begingroup$

Based on many suggestions I have seen around, this, that.etc. Best practice says to keep the root CA offline for very understandable reasons.

But how can it be truly offline? Doesn't the root ca have a list of int cas that it trusts. so therefore when a user goes to a website the chain has to be completed. So there is a query to the root CA there? I'm sure there is an answer somewhere that i'm missing.

$\endgroup$
1
  • $\begingroup$ A drawback to offline operation is that hosting of a certificate revocation list by the root CA is not possible (as it is unable to respond to CRL requests via protocols such as HTTP, LDAP or OCSP). However, it is possible to move certificate validation functionality into a dedicated validation authority authorized by the offline root CA. I think i have found the answer lol, would still greatly appreciate any input and lmk if my answer is wrong $\endgroup$
    – dobro
    Aug 8 at 4:33

1 Answer 1

6
$\begingroup$

An offline root ca setup could look like this:

Create the root CA

This should be done on an PC disconnected from any external network and in most cases is done on an HSM.

This part is sometimes done in public, to prevent anybody from messing with an root ca (https://www.iana.org/dnssec/ceremonies)

Create 1 or more intermediate CA's

For this step, you are still on your air gapped PC, which contains the root CA or is connected to an HSM.

The procedure is the same as for the root ca, except that the intermediate CA's are signed by the root CA.

Exporting the keys

In this step, the CA's certificate is exported onto a disk (for example an previously blank CD).

It's also the step, where the intermediate CA's will be exported (Public & Private key) [Note: If the intermediate CA's, where also generated on HSM's, these can in most cases just be unplugged and transported to there new owners]

Securing the root CA

Now, that the CA generation and export is finished, you can shutdown the root CA PC/HSM and look it away securely.

Publishing the Key

The last step is to distribute the CA certificate. This can be as simple, as publishing it on your website.

Usage in practice

If a new certificate needs to be created, this can be done by the Intermediate CA's.

Any following revocation of these certificates can therefor also be done by those intermediate CA's.

Since these intermediate CA's can also be online (e.g. connected to the internet), it is possible to use them for OCSP.

As you have previously described, it would be possible to create an intermediate CA, only for OCSP/CLR.

Intermediate CA compromise

In case of a compromise, the root CA can powered on, inside it's air gapped environment, and then be used to sign an revocation of the intermediate CA. This revocation certificate can then again be published, by first transferring it via an secure media to an internet connected device.

$\endgroup$
6
  • $\begingroup$ Thanks for the detailed answer. I guess having a compromised CA is not a common thing, but the procedure you described sounds very manual. Also if the root ca is brought online to sign a revocation wouldn't that be insecure even though it could be just for seconds. $\endgroup$
    – dobro
    Aug 8 at 15:01
  • 1
    $\begingroup$ @dobro it's not brought online - as the post describes it's brought "online" while staying physically disconnected and not receiving any potentially hostile input other that you yourself enter in it. The key issue is that CA-as-the-holder-of-secrets and CA-server-that-answers-requests are (or should be) separate, isolated machines. A system doesn't need to know any secret keys to serve precomputed CA certificates or to validate them or to answer requests about revocation. $\endgroup$
    – Peteris
    Aug 8 at 16:15
  • 5
    $\begingroup$ Instead of "online" perhaps use 'turned on' or 'powered up' to avoid confusion about if it's connected to the internet. $\endgroup$ Aug 8 at 18:22
  • $\begingroup$ @Peteris Ahhh that makes a lot of sense. so we physically shut down the root ca system. Now i do see that in the initial answer but i missed it before. So to confirm, we take down the root ca that holds the keys, but part of the root ca that answers to requests sits in another machine and services those requests. So that means part of the root CA is online? What if that specific part gets compromised, can the attackers use that service to let's say accept arbitrary certificates? $\endgroup$
    – dobro
    Aug 9 at 2:11
  • $\begingroup$ @dobro - The root CA is just a public/private key pair. The private part is kept on the air-gapped system, and the certificate containing the public part is literally loaded onto every computer that installs a major operating system. (Windows, for example) Without the private keys, you can't do anything new with that CA, but anyone who has the public certificate can verify that an intermediate was validly signed by it. $\endgroup$
    – Bobson
    Aug 9 at 16:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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