There are a lot of Best Practice documents that recommend having an offline Root CA and an Enterprise Subordinate CA that is signed by the root, for an internal Microsoft AD Certificate Services infrastructure.

I don't understand why having an offline root is recommended here. In the event that your subordinate CA is compromised, you'll be reissuing everything in your domain anyway, since the only thing that your offline root signed is the subordinate's signing cert. I don't understand what value having an offline root adds to this equation.

What is there to gain from this two-tiered approach in this type of situation?

2 Answers 2


Not sure about the particular implementation in Active Directory, but in general X.509 signing it allows for much easier recovery from a compromise.

Its assumed that an on-line CA is much more vulnerable than an offline one. So, let's say your online CA is compromised, and its private key is potentially copied.

You revoke the CA certificate. You go ahead and generate a new keypair, certificate, etc—you have a new online CA now.

Your next step depends on if you have an offline CA or not:

  • If you have an offline CA, you use your offline CA to sign your new online CA certificate. Fairly easy. More secure, too, as its easy enough you'll probably actually do it.

  • If you do not have an offline CA, you go install your new root CA certificate on each and every client machine, phone, tablet,…. (Actually, you don't: you set up an offline CA, and install that instead. Because you learned not to repeat this mistake!) Less secure, because you're going to do your best to avoid this work. ("Are we really sure the private key was stolen?")

Finally, you sign new certificates for the servers, and install them (possibly including the CA chain).

So, in summary, if you have an offline CA, you only have to re-issue certificates for authenticating side (typically, only the server). If you don't, not only do that, you get to install your new root CA everywhere.


My understanding is that it allows for a much quicker response in the event that the online CA is compromised. An updated CRL can be published to invalidate the intermediate CA without all systems needing to be on the network at the time.

I'm sure there is more value to it then that but this is my motivation.

  • Why can't you publish a CRL for a single enterprise CA? Why do you need a subordinate for that?
    – MDMarra
    Apr 9, 2013 at 19:52
  • 6
    Because if your single enterprise CA got compromised and/or had its private key stolen, then you want to revoke it. But a CA cannot revoke itself. Or rather, how is it going to revoke itself and then publish a new CRL using its now revoked cert?
    – Ryan Ries
    Apr 9, 2013 at 20:28
  • 2
    – MDMarra
    Apr 9, 2013 at 21:59
  • 1
    @RyanRies Maybe there is something in a relevant standard saying you can't do that, but if not, there isn't really anything contradictory about that. If you (well, your CA) self-sign a statement that you're not to be trusted anymore, then you're not to be trusted. OTOH, if the person who stole the key signs a statement that you're not to be trusted anymore, then— you're not to be trusted anymore. Same thing. Anyone in control of the private key ought to be able to revoke it.
    – derobert
    Apr 16, 2013 at 21:12
  • I know that this is an old discussion, but aren't CRLs the sticky old way of doing this? Does having online responders change this at all?
    – MDMarra
    May 6, 2013 at 20: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.