ADCS PKI Worst Practices: Online "Offline" Root CAs

If I had a dollar for...

For many years I’ve worked fairly heavily with Active Directory Certificate Services on Windows (remember?), running ADCS Assessments against many on-premises implementations. Maybe more than a hundred!

I’m sure you’ve heard various sensible practitioners talk about best practices for various products for years (myself included) and… they often just don’t get followed. Maybe people don’t see themselves as needing best practices? Maybe adequate practice is okay? Maybe it works and we don’t want to touch it practice…?

But there’s a useful opposite, which is the opposite you don’t want to see yourself in: The Worst Practice!

So: my first batch of ADCS worst practices - like those on-prem Security Worst Practices, but more specific.

[Update 2023-12-13: Great to see Microsoft Defender for Identity incorporate some of the ADCS Assessment security checks directly as recommendations, to benefit more customers more broadly!]

If you’re doing any of these, for any reason, stop, and rethink it. If you’re doing all of these, you’re getting it badly wrong - think about setting up a new ADCS instance with known good key provenance and migrating to that. Yes, that’s more difficult than doing nothing. Yes, you might need to.

For Root CAs, the combination of the most severe findings in ADCS Assessments tend to be related to one fundamental assumption:

An “Offline CA” means it’s permanently offline and never connected to a network.

If that’s not true, you can see how the breakages begin:

• Offline (Root) CA is not firewalled

  • For most environments, “turned off (but network-connected when on)” violates the basic principle that an Offline CA is designed to achieve

• Offline (Root) CA isn’t patched/updated (if not properly offline (see above))

  • And not firewalled - see point above*

• Offline Any CA re-uses any common admin password

… because these reduce your confidence that the CA has been secure, and that the private key hasn’t leaked at some stage over the CA’s multi-year lifetime.

If you’ve managed to tick every box so far, if you’re using a Hardware Security Module (HSM), it’s still unlikely your key has leaked (yay!?) though if the HSM is in “keys in the ignition” mode (“just issue anything!”), CA-side subversion might still have been/be feasible.

A core problem is that the term “Offline” can be ambiguous:

• To a PKI architect, it means “air gapped”

• To a system administrator, it can mean “turned off”

• To a layperson, it might seem to mean “broken” or “private”

The distinction between what the architect thinks it means and what the administrator takes it to mean is critical, and is the cause of many of the issues we’ve seen with “offline” PKI roots.

(Disclaimer: While I work for Microsoft, opinions expressed here are my own and are not those of my employer. I mean, they might be, I don’t know! Conspiracy theories are probably my own?)
(Quick shout-out to my friends and former colleagues over at PKI Solutions!)