How to offline an Enterprise Root CA

Question

For internal PKI, I'm a big fan of using Enterprise vs. Stand-alone, for simplicity and ease of management. The problem is, I just can't find definitive answers on how to properly offline it. Most people say to not bother, and their justifications
are vague and nebulous. My Enterprise CAs are NOT DCs. I've given this a lot of thought, and these are the things I think need to be considered...
If you take the Enterprise root CA offline, you'll need to consider three things:
1. Change the Enterprise root CA's CRL publication interval to be longer than the periods for which the Enterprise root CA will be offline, and also probably disable delta CRLs on the Enterprise root CA for simplicity and ease of management. When you do
boot the Enterprise root CA, be sure to publish a new CRL from it into AD.
2. Make sure the Enterprise root CA isn't needed for anything but:
 a. The initial, one-time loading of the root certificate into AD for automatic distribution to clients by ADDS.
 b. Creating certificates for the subordinate/issuing CAs.
 c. Publishing the Enterprise root CA's CRL to AD for reading by the clients.
Is there anything else the Enterprise root CA needs to be online for?
3. By default, every computer account password expires every 30 days. This won't be a problem because when you boot the Enterprise root CA, it'll just change its computer account password if it has expired.
So, having said all of that, should I offline the Enterprise root CA? If not, why?

Answer 1

On Mon, 17 Feb 2014 08:14:20 +0000, Daniel L. Benway wrote:
The real question is whether or not I can or should shut down the Enterprise root CA after it has published the root certificate to AD, after I've created the sub/issuing CAs, and after I've published the root CA's CRLs to AD and changed the root
CA's CRL intervals to appropriate values.
Brian did answer your question. A PKI is all about trust, and the root of
that trust is the private key material of the root CA. The reason one
deploys a standalone, offline root CA in the first place to is to reduce
the possibility of an attack against the root CA's key material and the
accepted method to reduce that attack surface is to ensure that the root CA
is never attached to a network. That does not mean attach it to the
network for a while and then periodically afterwards, never means
never. The minute you attach the root CA to a network, you've reduced the
trust level and once a trust level is reduced, it cannot be increased
without redeploying.
Brian and I have both seen the argument that an offline Enterprise root is
easier to manage than an offline Standalone root and in practice, that
simply isn't the case:
1. Publishing the root CA certificate and CRL of an Enterprise root is, as
you point out, automatic, however, transferring the certificate and CRL via
removable media and then using certutil, given the infrequency of those
operations is a trivial procedure. Operationally you gain very little by
using an Enterprise root here, and taking advantage of the automatic
publication requires that the root be put on the network which defeats the
purpose of keeping it permanently offline in the first place.
2. Since the only certificates that a root should be issuing are for SubCAs
the advantage you get with an Enterprise root being able to use certificate
templates is pointless.
3. Any management functions or benefits you may be able to realize by
having the root joined to AD are obviated by the fact that you're planning
on having it offline and disconnected in the first place.
The bottom line here is that any perceived advantage of having a offline
root being an Enterprise CA as opposed to a Standalone root is defeated by
the simple fact of having it attached to the network at any point in its
lifetime. Security and trust trump ease of management in this case and as I've pointed out the actual ease of management versus the perceived ease of management is minimal at best.
Paul Adare - FIM CM MVP
Minds are like paragliders. They work best when open.