Whether you’re setting up a VPN server or establishing SSL certificates for your internal websites, there are a lot of reasons to consider setting up your own certificate authority (CA) for your organization. On my current project, we ran into the former situation and quickly realized the widely recommended default of setting up a separate CA for each VPN server would become a management nightmare. For one thing, we need a few separate VPNs to properly segregate our network in Amazon Web Services (AWS). For another, some users need access to multiple VPNs, a few need access to them all, and most need access to just one.
If we had gone with the default setup recommended by the OpenVPN docs, using their easy-RSA tool, we’d have ended up having to issue certificates for each user for each server they needed to be able to connect to. Moreover, when a user with access to multiple VPNs leaves the organization and needs to have their certificates revoked, we would have had to revoke access one certificate at a time. That’s a pretty painful activity especially spread across an organization with 50 users and 3-6 network segments. On the other hand, if we were just establishing an SSL certificate signing authority for internal use, we’d probably not bother with a setup more complicated than a single CA.
One important thing to keep in mind, especially when designing a CA for your organization that will control ingress and egress from your organization’s internal networks, is that the root CA — the CA that establishes the base of the chain of trust for your organization — is absolutely critical. If you leak that CA’s private key, anyone can generate certificates that look like they’re authorized by your organization and those certificates will authorize with any and all of your VPN servers. The best thing to do is to password protect the private key for this CA with a strong, secure, and randomly generated password, and to keep the key and associated CA offline unless it’s absolutely needed — i.e. to sign a new intermediate CA. If the key can’t be accessed, it can’t be stolen.
Beneath the root CA, you’ll want a number of intermediates, one for each purpose for which you’re signing certificates. For example, you don’t want to mix your VPN and SSL certificates. You don’t want a breach of your SSL CA to immediately constitute a breach of all your VPN servers. By segregating by purpose, we can limit the capabilities of an attacker who gains inappropriate access. These intermediates that establish purpose-driven separation should also be highly protected because a breach of one of these CAs means everything beneath them on the CA chart is also compromised.
The level beneath those intermediates normally consists of the leaf CAs that do the bulk of the work for signing server and client certificates, managing revocation lists, and re-signing certificates that have expired and should be updated. One important detail to keep in mind is that if your root CA hasn’t been cross-signed by a CA that’s in the store of trust for your users operating systems, you will need to establish the full chain of trust for your CA when presenting its certificate. This means the CA cert presented by your VPN server can’t just contain the leaf CA’s certificate but must also contain the intermediates and roots that make up the full chain of trust for that CA.
