2

I have two intermediate CAs that each sign certificates for their client users, like this:

             ROOT CA
             /      \
            /         \
           /           \
   Intermediate A    Intermediate B
     /                  \
  Client A               Client B

I run a service, Service A, that validate clients using Intermediate A's certificate chain. So, Client A connects to Service A and is authenticated. I want to set up a Service B that uses Intermediate B's chain so that it doesn't trust clients who present certs signed by Intermediate A.

If Client B has a cert signed by Intermediate B and this person attempts to connect to Service A (which uses Intermediate A's chain), will it be authenticated?

Improve this question

1 Answer 1

Reset to default
1

TL;TR: it depends on the exact configuration of which CA's are trusted in each service.

Authentication means that a trust chain to a locally trusted CA can be built. This means:

  • If service A trusts only intermediate A but not the root CA then it will trust any certificates signed with intermediate A but no certificates signed with intermediate B because no trust chain can be built from intermediate A to certificates signed by intermediate B. Similar is the behavior of service B.
  • If service A instead or additionally trusts Root CA then it will trust any certificates signed directly or indirectly by Root CA as long as it has knowledge of the necessary intermediate certificates. Thus if client B sends its client certificate and also the issuer certificate (i.e. intermediate B) then service A will trust it because it can build the trust chain.

Note that the last statement is only true if service A does not employ any additional restrictions. These restrictions might include a limit for the length of the trust chain: if service A accepts only certificates directly issued by its trusted CA then sending the certificate and intermediate for B will not make it trust client B. The restriction might also include an explicit distrust of intermediate B in which case it will also not accept the certificate from client B.

Improve this answer
3
  • Thanks. I don't know if this will work but I need to try removing the root CA's certificate from the chain that service A uses to authenticate clients. My hope is that will still allow client A to authenticate but will deny client B. If that doesn't work, I think my only other option is to create a completely separate root CA/intermediate CA for service B and use that.
    – Chris Snell
    Oct 8, 2016 at 5:10
  • You could also verify in the backend. Eg, in the code for B application, you only accept certificates directly signed by B, and in code for A application, you only accept certificates directly signed by A. This means a B client will be able to do a successful SSL handshake to service A, but the backend application on Service A will reject the user. This can be done by examining certain server variables to find out if the client certificate is signed by intermediate A or B.
    – sebastian nielsen
    Oct 10, 2016 at 1:03
  • This can also be accomplished by using a single root and signing directly from the root, by putting the value such as it can be examined by the server. For example, you could set OU=A for A service and OU=B for B service (on the end entity certificate). A good thing with examining rights in the backend code instead of in certificate level, is that you can return a user-friendly message, like "You isn't authorized here. Did you mean [link to correct service]?" (instead of "Page cannot be loaded").
    – sebastian nielsen
    Oct 10, 2016 at 1:05

You must log in to answer this question.

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