SSL Client Certificate Authentication not working. What am I missing?

[Roman PENA]

I want to enable SSL client certificate authentication using CA API Gateway version 9.3. I have followed the steps described on the documentation but I get the error: "No Client Certificate was present in the request".

 

These are the steps I followed:

1- Created a private key using Policy Manager

2- Exported the key to a .p12 file. 

3- Exported the certificate from the key to a .pem file

4- Created a user into the Internal Identity Provider, the user name matches the certificate CN

5- Assigned the certificate exported on step #3 to the user. Identity Provider -> Certificate Tab

6- Create a very simple GET HTTP service with the following assertions:

       Required SSL or TLS Transport

       Required SSL or TLS Transport with Client Authentication

       Request: Authenticate User: client-user from [Internal Identity Provider]

       Return Template Response to Requestor

 7- Imported the key into my browser (Chrome). Using the .p12 file generated on step #2

 

When I  execute the end-point using my browser I am getting the error "No Client Certificate was present in the request".

 

Normally Chrome should pop a dialog asking to choose a certificate, that is not happening. According the TLS handshaking the Gateway should provide a list of certs, so the client can validate and present its cert.

- The listening port that I am using to be sure it has the option Client Authentication = Optional.

- I tried disabling the TLS 1.0 and did not work

- I changed Listening Port - Client Authentication parameter to Required. When I do this the Gateway does not respond at all.

 

I though that implementing  SSL Client Certificate Authentication was straight forward but looks like I am missing something.

 

Any help will be much appreciated.

 

Thank you,

Roman

[Zhijun He]

Dear Roman,

It could be due to the cache, try clear cache on your chrome, or try incognito window.

 

Regards,

Mark

[Roman PENA]

Hi Mark,

Yes, I had tried with incognito and also with SOAP-UI. Is not cache.

Thank you !

[Mark ODonohue]

Hi Roman

 

I think the problem is the SSL ServerHello is not sending back to the client the DN of the CA Certificates that issued your client certificate - when asking for a client cert the usual protocol is that the ServerHello replies with a list of distinguished names of issuers that the server will accept. 

 

Now the client program (Chrome) in your case then looks to see if it has any client certs that match any of those issuers, and then pops up a dialog to let you choose which one.  Some programs use that DN list to auto select which client cert to send back as well. 

 

That's the normal process, and what I expect is happening with Chrome.  But different client programs do different things, the list is not enforceable on the client side and some programs (PostMan is one example) totally ignores that list of DN's and lets you specify a cert based on the target URL and sends that. 

 

Chrome and other browsers are more normal and use the DN list to filter which certs to allow you to pick from that popup list.  

 

Step 1: 

But before we go there - lets check if the TCP listenr is setup to either option/required for "Client Authentication" - most likely it will be: 

 

 

 

Step 2: 

 

Do you have the CA certificate that issued/signed your client cert request ? 

 

If you can look at the list of Trusted Certificates, the DN list and that have "Sign Client" as usage will be sent to the client in the ServerHello. 

 

 

So if you can load the cert that issued your client certificate, make sure you check the ""Sign Client""  usage option.  Then it should be sent back in the allowable client cert DN lists.  You can have multiple certs marked for "Sign Client" and all their DN's will be sent in he ServerHello.  You can also have no certs marked - but results of that vary depending on the client program.

 

 

At the network layer if you log the SSL handshake (either via wireshark or in java via that -Djava.net.debug=all setting.  You can view the ServerHello returned and it will be something like this : 

 

*** CertificateRequest

Cert Types: RSA, DSS, ECDSACert Authorities: 
<CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US> 
<CN=*.app.prod.e1.dev.ca.com, O="Broadcom, Inc.", L=San Jose, ST=California, C=US> 

 

Here, client certs issued by those two issuer DN's are allowed.

(and ok yes the issuer names there don't look like they should be signing client certs - but they were real ones from a test case :-)

 

There was also an interesting case recently where when the "acceptable" DN list returned was empty it would allow any client cert to be selected, but if there were any entries in the DN list - it would restrict the chosen cert to those from that DN list;  Client suddenly stops sending client certificate t - CA Knowledge 

 

Hope that helps. 

 

Cheers - Mark

[Roman PENA]

Hi Mark,

Great explanation, will work on it Today and let you know the results.

Thank you!

Roman

[Roman PENA]

Hi Mark,

 

Finally, I was able to get back to this issue. I followed your instructions and the two way SSL authentication is working fine now. Only one issue remaining, we have the Gateway nodes behind an F5, and the F5 is ending the SSL handshaking. So, the 2 ways work only if I hit directly the Gateway node (host), it does not work through the load balancer (F5). Working on that with the Network team, if you have any suggestion will be appreciated.

 

Thank you for your help.

[Yanick Girouard]

Sadly, if F5 is in front of the API Gateway, there's no way to "passthru" the SSL/TLS ​handshake to the gateway in order to receive the client certificate. The certificate is not passed as an HTTP header like basic authentication or other auth tokens, it's part of the SSL/TLS handshake, which means it will not be relayed if F5 is answering the request first. F5 needs to be the one doing the mutual SSL authentication and then relay the request to the API Gateway without a certificate unless it can use a specific cert to relay the request to the backend.

[Prem]

Facing same issue. F5 is handling the SSL offloading and not getting the client certificate to Gateway. Please let me know if you find a solution in F5 level to handle this?

Thanks!

[Mark ODonohue]

Hi, 

For : 
   client -> F5 -> API Gateway 

When SSL is not pass through the F5.  Then the SSL session is terminated at the F5, and also any client certificate authentication is part of the handshake with the client -> F5 only and is not visible to the API Gateway. 

The API Gateway does not have any direct interaction with the client (or the client certificate) for authentication purposes and you need to setup the F5 to ask for and validate a client certificate.  

Workaround: 

Now, it is possible for the F5 to collect the client cert or the users DN and pass them onto backend servers via a HTTP header added the the request  - as per : 

https://devcentral.f5.com/s/articles/irule-passing-client-cert-to-node

Then at the backend API Gateway, you can extract the header as the user DN, or the cert that identifies the client. 

Cheers - Mark

[Mark ODonohue]

Hmm, i had more comprehensive answer - but see if this one works : 

 For :  Client - > F5 -> API Gateway

If SSL is not passthrough, then it is terminated at the F5, so the client certificate is part of the handshake with
   Client -- (ssl) --> F5  
And the API Gateway is not involved.

It is possible for the F5 to extract details such as the DN or the base64 encoded client cert and pass that onto the API Gateway via adding the HTTP header to the request as per : 

https://devcentral.f5.com/s/articles/irule-passing-client-cert-to-node

Hope that helps. 

Cheers - Mark

[Philippe Brand]

Then on your Gateway, have a global API checking for SSL Client Certs in plain SSL handshaking or in headers, for various NLBs, such as: