Client to Apigee with SSL client cert: more questions

[guycrets]

Hi All,

Many questions have been asked about use of client certs for client authentication. But while reading the docs and responses, some questions remain.

1. Is use of a different port number or separate host alias (and DNS) required for the virtual host with ClientAuthEnabled=true? Or can clients continue to call the virtual host without client cert and should the proxy check the client.* variables to see if client authenticated with client cert or not?

2. The docs state: "The truststore holds the client's certificate”. Seems a bit weird that each client cert needs to be uploaded. This also implies that with renewal of the client certificate, the old cert needs to be replaced; and this at exactly the same moment as the client switches, as it will not be possible to have 2 client certs in the truststore with the same (common) name.

3. Apigee seems to provide support for checking certificate revocation, there is an OCSPStaling flag. The URL of the Certificate Revocation List is obtained from the certificate? How does Apigee behave when the CRL cannot be reached (our Apigee on-prem needs to go over forward proxy for outbound connections).

Looking forward to your feedback! KR, Guy Crets

[rmishra]

1. Yes, use of a different host alias (and DNS) or different port is required. Once you configure a virtual host to challenge for a TLS cert (with client auth enabled), any client which does not present the cert does not get a successful TLS connection on that port.
2. When you engage in a two way TLS handshake, you want the server to verify the client, storing the client certificate in the trust store is a way to do that. This is different than validating a server cert/domain cert. When you validate a certificate for https://www.community.apigee.com, it will be enough for you to say "i trust that site because the cert is issued by GeoTrust Global CA (root) which is a well known commercial CA". You can't say that for a client CA , you would never want to say that i trust all client certs issued by GeoTrust Global CA.The difference is subtle but important. To your specific issue, you don't need to have two clients certs with the same CN, the cert validity can overlap , your new cert does not have to begin on/after the old cert expires.
3. I am hoping someone from Apigee answers this part of your question.

HTH

[guycrets]

Thanks for your quick answer on 1.

For 2, my experience with other products/solutions is that indeed all valid client certs will be accepted. Obviously some subsequent authorization is required. Had expected to apply e.g. an LDAP policy after whereby the CN of the client cert is used in the LDAP lookup.

Please also note my question regarding timing complexity to replace old with new client cert.

Looking forward for answer on 3. as well.

PS: incredible how active this community is!

[rmishra]

Validating the CN is a fairly common practice - at least everywhere i have been engaged. You are right about any valid client certs being accepted. My point about replacing the old cert with the new is basically to explain that there isn't a precise moment when you have to replace the certs as long as you do it within the validity of the original cert , your new cert can have an overlapping validity. So, if your old cert expires on Jun-31, and you are issuing your cert today(Jun-18) your new cert could be deemed valid after Jun-18.

When you update the TrustStore through the Management API/UI(still the API), Apigee will roll out your upgraded Truststore to all your Nginx routers. I have never seen a noticeable outage during the rollout on an on-prem deployment.

[guycrets]

So validation of a client cert is not based on hash, serial number or other unique value?

Under the assumption that old and new client cert have indeed an overlapping validity:

- can upload new cert already into Apigee while client continues to use the old?

- or the other way around: client already uses new cert and old client cert is still in Apigee's truststore?

So comparison of client cert send by client and client cert in trust store is only based on common name and issuer or so?

[guycrets]

For my question #2, did some tests with Apigee on-prem version 4.17.09.00.

1. Have created test client certs "demoa" and "demob" with the tool KeyStore Explorer
2. Created a "demoCA" with the tool SimpleAuthority
3. Created CSR's for demoa/demob
4. Signed CSR's in SimpleAuthority, resulting in demoa.cer and demob.cer both signed by demoCA
5. Uploaded certs demoCA.cer and demoa.cer into Apigee truststore
6. curl -v --key demoa.key --cert demoa.cer https://<testproxy>; works as expected
   
7. curl -v --key demob.key --cert demob.cer https://<testproxy>; ALSO WORKS, although demob.cer is not in the Apigee truststore.
   

This behavior is in line with doc:

During two-way TLS authentication, client authentication succeeds when the server sends client_cert_1 to the client as part of the TLS handshaking process.

Alternatively, you have a second cert, client_cert_2, signed by the same cert, ca_cert. However, you do not upload client_cert_2 to the truststore. The truststore still contains client_cert_1 and ca_cert.

When the server passes client_cert_2 as part of TLS handshaking, the request succeeds. This is because Edge allows TLS verification to succeed when client_cert_2 does not exist in the truststore but was signed by the a cert that exists in the truststore. If you remove the CA certificate, ca_cert, from the truststore then TLS verification fails.

And also in line with this earlier post. If only I had found this post sooner or had info been present in the docs!

So either the CA cert is in the truststore and authentication should be implemented in the proxy leveraging SSL/TSL environment variables or each client cert is added to the truststore individually.