Authentication problems with truststore containing multiple client certificates

[#1]

Our application uses client certificates for authentication. Various partners will provide us certificates for upload to our Apigee truststore.

We are currently testing with two client certificates in the Apigee truststore. One passes authentication; one fails. When the request fails we get

{StatusCode: 400, ReasonPhrase: 'Bad Request', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:{  Connection: close  Date: Wed, 09 Nov 2016 22:27:50 GMT  Server: Apigee  Server: Router  Content-Length: 224  Content-Type: text/html}}

I can't figure out the relevant difference between the certificate that fails and the certificate that works.

1. The certificate that doesn't work is marked as "valid" in the Apigee truststore in the TLS Certificates screen.

2. The non-working certificate for the customer was generated the same way as the one that works, and signed with the same key. The two certificates differ only in valid date, expiration date, serial number, common name, locality, state, and country.

3. The situation happens regardless of which certificate was the first one in the truststore (i.e., whether I put the good certificate in first and then the other certificate, or the inverse).

4. Requests with the non-working certificate continue to fail even if it is the only certificate in the truststore.

Any ideas how we can troubleshoot this further? Since we have to ask Apigee support to bounce gateway servers every time we change the configuration of the truststore, this isn't easy to test.

[adas]

@pblair can you mention your org name and virtual host. Since this is ssl related, you might be better of engaging with the Apigee support team. Few things you want to check on the certificate before that:

- expiry date

- common name

- your sslinfo settings in the proxy or target servers

We might have to do a debugging session where we capture tcp dumps and analyze them to see the ssl handshake level information, so opening a support ticket and working with the Apigee Support team would be the recommended approach, once you have made sure there's nothing wrong with your certs.

[#3]

Yes, at this point I'm also working with the support team on this. All of the items you mentioned have been checked out.

[gaurav_bhandari]

@pblair,

The best way to test is to take TCP DUMPS (Netwprk packets) and analyse them via Wire Shark or ask APIGEE Support team to analyse.

Also, can you please share the screenshot of the certs that are working and the certs that are not working.

[#5]

Thanks. We do have a ticket open. I'd prefer not to attach screenshots of these certificates on an open forum; however, in the TLS Certificate Details screen in the Apigee Edge console:

1. Both the working and non-working certs have a green checkmark with "Valid" next to Status.

2. Both are valid from a date in the past, and expire in 2017.

3. Both have basic constraints CA:FALSE.

4. Both have serial numbers that are 9 hex octets.

5. Both have the same issuer.

6. Both have a common name, organization, locality, state/province, and country. Both do not have alternative names or an organization unit.

In addition, both give an OK response when running openssl verify -verbose -CAfile ca.crt client.pem.

[#6]

This behavior occurred because the distinguished name one of the client certificates was the same as that of the signing certificate authority. This is apparently treated as if it were a self-signed cert. In this particular case the "self-signed: cert was accepted and the other one rejected.