How to validate clients based on certs in Apigee Edge ?

Has anyone here built a solution to validate clients based on certs?

For example, each client (partner apps - not end users) would have a different client cert to be sent to Apigee for authentication? Like mutual, but with several diff client certs - wondering how the configs should be on the vhosts.

~~Q:S:TC~~

Solved Solved
2 5 1,649
1 ACCEPTED SOLUTION

Not applicable

You may want to look at a related problem we had here: https://community.apigee.com/questions/35123/authentication-problems-with-truststore-containing.html

I do not believe we were able to successfully have individual client certificates in Apigee's truststore rather than the signing certificate. Trusting the signing certificate trusts all certificates signed by that certificate, so that you wouldn't be able to deny access only to specific certificates by removing them from the truststore. In addition, at the present time Apigee does not support Certificate Revocation Lists to bar access to certain certificates.

One thing you can do, if you control the certificate issuance, is to create a key-value mapping from some attribute of the certificate (e.g., the common name) to some id or flag which can be used further down the Apigee pipeline to control access. If you do this, you need to make sure that no certificates you issue share the same relevant attribute.

View solution in original post

5 REPLIES 5

Not applicable

You may want to look at a related problem we had here: https://community.apigee.com/questions/35123/authentication-problems-with-truststore-containing.html

I do not believe we were able to successfully have individual client certificates in Apigee's truststore rather than the signing certificate. Trusting the signing certificate trusts all certificates signed by that certificate, so that you wouldn't be able to deny access only to specific certificates by removing them from the truststore. In addition, at the present time Apigee does not support Certificate Revocation Lists to bar access to certain certificates.

One thing you can do, if you control the certificate issuance, is to create a key-value mapping from some attribute of the certificate (e.g., the common name) to some id or flag which can be used further down the Apigee pipeline to control access. If you do this, you need to make sure that no certificates you issue share the same relevant attribute.

+1, Thank you @pblair , It's helpful.

Not applicable

As @pblair mentioned, we cannot have different client certs if they signed by different CAs.
My observations:

#1 You can either have complete chain or the signing certs (root + intermediate) without the leaf and the client can just send the leaf cert as part of the handshake.

#2 For self-signed, you are the CA of yourself, so you can just upload your own cert, which is the CA

#3 Private cloud - if you change a truststore or remove a cert from the truststore (There is no need to delete the old cert, we can just upload the new one with all the client certs), a restart of routers is required though.

Some questions here:

Re #2. How could we use this approach to solve the problem posed by the original post? Suppose we are our own CA and signing all client certs with our CA root certificate, which we put into Apigee's truststore. This will trust all certs signed by that CA. This means that it does not allow selective access by clients depending on their certificate, or revocation of specific client certificates. Either all signed by that CA are allowed, or none.

Re #1. I read somewhere that it's possible to have just an intermediate cert in a truststore on the server side if the client presents the entire certificate chain in the handshake. Does Apigee allow this? If so it might solve the issue, since our root CA could generate one intermediate certificate per client certificate. (This supposes Apigee allows multiple intermediate certs in the truststore.) If we wanted to "revoke" one client's certificate without revoking certificates issued for other clients, we could then just remove the intermediate cert for that client from the truststore. The intermediate certs for the other client would remain in the truststore and continue to permit connections by the other clients.

Re #3. Doesn't this apply to public cloud as well -- i.e., that changing a truststore requires restarting the routers? Also, there is mention in the documentation about using references to keystores/truststores -- I got the impression that using a reference makes it possible to point a reference to a different truststore without restarting the routers. Is this true?

@pblair

Re #2, you are correct that it doesn't solve the problem but am just sharing my observations. We will end up creating a different truststore and Virtualhost in this scenario.

Re#1, I get your point and completely agree but as of now we need the complete chain including the root CA. (leaf is optional) . Let me explore more about this.

Re #3, Cloud, support will handle that.
Talking about references, you are true.
If you use references for keystore or truststore and if you modify them, you don't need restart of the routers.

ref : http://docs.apigee.com/api-services/content/creating-virtual-host#usingreferencestoakeystoreortrusts... and http://docs.apigee.com/api-services/content/update-or-replace-ssl-certificate#updateatlscertificatei... for more info.

If you see anything that doesn't work as expected, pls let us know or raise a support ticket.

cc @Arjav Goswami