I'm currently a hobbyist trying to learn more about SSL. If I create my own CA for my virtual servers, and trust that CA on my devices, I can then issue certificates for my virtual servers, and my SSL will be sound as long as my CA isn't compromised right?

But now I'm running the risk of my CA getting compromised and a friend I'm learning with in my virtual lab, Eve, gets a hold of this and can now MITM all web traffic, not just the traffic to and from my servers which would happen if they only held the private certs for each virtual server.

Is there a way to trust a sub-CA that can only issue certificates for my virtual servers so that at worst, Eve can only intercept traffic to and from my personal services?

2 Answers 2


Yes, and in fact this is generally how risk gets minimized in large deployments. What you're describing is a two-tier PKI hierarchy. Typically, it starts with the ROOT CA at the top, which serves as the "trust anchor," or the one CA which everything in your domain is going to ultimately trust. Typically, this machine NEVER touches a network in its lifetime. You'll have it generate a self-signed certificate (in the process, it will have generated its own private key with which to sign other certificates).

Then you build what will be a suboordinate (or "online") CA. This one can be network-attached. Generate a key pair (Certificate Signing Request), and place the resulting CSR on some removable media. Sneakernet that media onto the ROOT CA, and have it sign the CSR. The resulting certificate is what gets installed back on the suboordinate CA.

Meanwhile, all your client machines should have the public certificates of each CA (the ROOT CA at minimum) in its "Certificate Trust Store." This is the only way clients will know what to trust.

From this point, you could create as many suboordinate CAs in the same manner described above, and assign them to support whatever you wish... a department, a line of business, a type of device or user account object, a data classification, external partner trust relationships (you can create a sub-Ca specifically for the purpose of signing another organization's sub-CA to create a limited realm of trust between the two networks).

  • I understand, but if the client trusts the trust-anchor CA which can still create Sub-CA and those can still sign for google.com instead of myprivateserver.com . Is there a way to eliminate the risk completely by having the Trust-Anchor on the client be the Sub-CA directly?
    – Ryan Leach
    Oct 13, 2015 at 10:31
  • Two short answers... it's impossible to eliminate risk entirely (we'll see why in a moment) and although the method you described is possible, doing so securely may wind up proving it to be impractical.
    – Daniel
    Oct 13, 2015 at 13:49
  • If you do it the way you describe, you lose out on the benefit of having a quick way to recover from a compromise of the sub-CA. The purpose of having a 2-tier hierarchy is to have BOTH root & sub-CA certificates installed on clients' trust store. That way, if the sub-CA is compromised, you can quickly replace it with one that's automatically trusted because its cert was signed with Root. Best practice is to install both public certificates of the Root and Sub-CA (often called Root and Intermediate certificates which make up the "trust chain") in the client's Trust store. I mean, why not?
    – Daniel
    Oct 13, 2015 at 13:58
  • I was largely wondering if it was possible, since everything naturally seems to document the status quo. As to why not, if I make the "sub-ca" restricted to only my domains, treat that as a trust anchor, can't that also sign further sub-sub-ca's that could be revoked like you described with the advantage that at-worst it's only my private servers traffic that could be compromised since the trust-anchor isn't able to sign for domains outside my control?
    – Ryan Leach
    Oct 13, 2015 at 15:45

If you trust your CA unconditionally, then CA compromise will mean that you may also get compromised.

But only by an ACTIVE Man-in-the-middle. Not by a mere passive listener. -- I mention this because you wrote "Eve". And the "Eve" name is usually reserved for a passive Eavesdropper. And the "Mallory" name is usually reserved for an active Mallicious interceptor.

So, how do you NOT trust a CA unconditionally?

Two of the methods are:

  • Pinning. This allows you to place a more explicit trust on individual certificates. (Rather than the IMPLICIT idea of: I trust EVERYTHING that that CA over there tells me to trust.)
  • Certificate Transparency. Here you don't trust any certificate that has not been publicly LISTED as an issued certificate. This raises the bar for anybody who wants to exploit a CA AND AT THE SAME TIME stay under the radar. With CT the attacker can not have both of these simultaneously anymore.

And your: okay, I'm gonna use a trusted sub-CA instead-idea is similar to pinning at that sub-CA-level.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .