0

Should I have 3 root CAs, 1 root CA + 3 intermediates, or some other PKI setup for the following situation?

I have three use cases:

  1. Expose a web API over HTTPS (server certificates)
  2. Allow clients to authenticate with a client certificate instead of username/password (external client certificates)
  3. Validate internal servers as clients (internal client certificates)

Every key pair will be used for exactly one of the use cases.

Let us assume I do not need a 3rd party CA and I am instead working with a custom PKI in a closed system. I can see two major ways of supporting this:

  1. 1 root CA with 3 intermediate CAs (one intermediate for each case)
  2. 3 root CAs (one root for each use case)

I have attempted to start #1, but I've found that in order to have openssl s_client test client certificates against a node.js HTTPS server, that I need to validate from intermediate to root, not just intermediate. Which means that client certs between use case 2 and 3 can be interchanged as the root is the trust anchor. I've looked around, but I can not find a way to make the intermediate CA the trust anchor for the node.js HTTPS server.

So, I'm grossly misunderstanding something, I need to move to implementation #2, or a mixture of things.

1

X.509 certificates can provide confidentiality and authentication. That is, they can be used in the encryption of a link, and optionally to authenticate the user or server.

They do not provide authorization. Instead, that is down to the application to deem whether the entity which has authenticated with an X.509 certificate is permitted to access the resources.

That means, that (1) above is fine. Use one root and ensure that authorization is carried out by another means.

However, if you do insist that X.509 certificates should also provide authorization, you'll either need to:

  • Rely on certificate policies to ensure that applications only trust certain certificates - good luck with that one as you'll probably need to code your own applications that check policies;
  • Use a different root certificate for each application; as in (2) above.
  • Agree. Use just one CA unless you have a particular reason to use more than one. – Andrew Schulman Feb 19 '18 at 22:48
  • No authorization angle in my question - so we are on the same page there. – Andrew Martinez Feb 19 '18 at 22:51
  • I'd love to use one root CA - I don't understand how to secure internal client certificates and external client certificates such that they can't be used interchangeably. I would like to trust some intermediate CA as the number and variety of internal client certs and external client certs I need to authenticate can fluctuate. I don't want external client certs to used to connecto internal services. – Andrew Martinez Feb 19 '18 at 22:54
  • It's down to your application to check authorization. If the application trusts any certificate presented to it (from a trusted CA) then you have a problem and your only pragmatic option is (2). If instead, your application retrieves the user login from the certificate and checks that against some form of database for authorization, then you can use (1). Only you know your application portfolio, so only you can decide. – garethTheRed Feb 19 '18 at 23:02

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.