5

I have a server using a certificate signed by my subordinate (intermediate) CA.

My java based client needs to put either the intermediate or root CA cert in it's truststore so when it communicates with the server it knows it can trust that server cert.

Am I supposed to put the intermediate or root ca certificate in the truststore?

I know intermediate CAs are used to enhance security by protecting the root, so my inclination is to never include the root in anything. But, I'm struggling to understand exactly how this all works.

Enlighten me :)

4

Generally speaking, you should be putting the root cert in stuff. The model generally works like this:

Clients

Have the root cert "pinned" (ie embedded in trust store).

Whevever they validate a cert, it needs to trace back to some cert in their trust store, the number of intermediate certs between the end-cert and the pinned cert should be irrelevant, so there's no reason not to pin a root cert - at least from the client's perspective.

Certificate Authorities

What to do in the case of the CA key being compromised is a big concern for people who run CAs. To make the cleanup easier in the case of something bad, people usually use an "offline root":

  1. Have your root CA sign some subordinate CAs, then unplug the root CA (if the CA is a dedicated physical server), or hide the root private key on a well-protected backup disk and make sure there are no copies floating around. This makes it very hard for hackers to steal the private key.

  2. Do your day-to-day cert issuance, CRL publishing / OCSP, etc off the intermediates. They are connected to the internet and therefore at higher risk of compromise.

  3. In the case of compromise of an intermediate CA, you can fire up your root CA, revoke that intermediate, bring up a brand new intermediate and re-issue all of the legitimate certs that got incidentally revoked.

  4. Servers that were using certs signed by that intermediate will have to install the newly-issued cert since their old ones are now revoked.

  5. Clients will be completely unaffected since they have pinned the root cert, so swapping around the intermediates has absolutely no effect.

As a though-experiment, compare the above to what you would have to do if your root CA key gets compromised. Since it can take months to years for a root to get embedded in the public browsers, vpn clients, other servers, etc it probably means the CA will go out of business.

Advantages of pinning a root, vs pinning an intermediate:

  • The example above illustrates that pinning the root makes it MUCH easier to cleanup from a compromise because you can simply revoke the compromised intermediate, re-issue some certs and move on with your life.
  • There are fewer certs in your trust store. If everybody had to pin every intermediate, everybody's trust stores would be much larger to the point where it could impact the performance of cert validation since searching the trust store would take longer.
  • Load-balancing: by pinning the root you're free to re-arrange the topology of your intermediates, or even put them behind a load-balancer for handling cert requests and the clients won't care.
  • 1
    Funfact (I think Mike already knows this but others may not): Some browsers (like Firefox) automatically download and trust every intermediate CA certificate so installing a root CA is also easier from an administrative stand point as you only need to install one root CA everywhere instead of many intermediates. – SEJPM Apr 4 '16 at 19:41
  • @SEJPM I believe that's called "certificate caching" - ie "this intermediate checked out last time, so the next time I see it, I won't bother validating all the way up to the root". There's debate about whether this is a good idea or not because you're trading performance for not knowing right away if an intermediate gets revoked. – Mike Ounsworth Apr 4 '16 at 19:45

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.