We have an application here using client certificate authentication. This has been working without any issues for years, but now several clients are experiencing the following issue in FF and Chrome but not (yet) in IE: The "choose client certificate" dialog does no longer appear and so they are redirected to a username/password login page. So i assume, the browser does not recognise the installed client certificate as suitable for the CA names sent by the server.

what i have checked:

  1. No certificate (server or client) has expired.
  2. nginx is sending the correct CA names to the client. I checked that using openssl s_client ....
  3. I have read the FF changelogs to find anything that would sound related to client certificates, but nothing so far that could explain this problem

what i have tried:

  1. I removed the "ssl_client_certificate" and "ssl_verify_depth" from nginx config, and the choose client dialog in the browser was there again, only this time displaying all installed certificates including the one for our application. After choosing the right certificate the login succeeded and the application worked without problems.
    This led me to the conclusion that something with the CA names sent to the client might be wrong and the certificates themselves are ok.
  2. As I mentioned earlier not all clients are experiencing this issue, so i installed a client certificate from a working client and one from a non working client on a test machine. I should note that both certificates are issued by the very same CA (the working certificate is just a few months older). And guess what: When i try to access the application, the "choose certificate" dialog appears, but it shows only one certificate (the one from the working client). If i remove the "ssl_client_certificate" directive again from the nginx config i can choose (and successfully login with) any of the two certificates. This in contrast to (1.) looks like there is an issue with one of the certtificates

And now all i can do is to quote Mr. Sumner-Miller: "Why is it so?"

I hope, someone has experienced a similar problem before, as the only other option I have is to dig into FF's source and see how the list of suitable client certificates is built. The behaviour of that client certificate dialog must have recently changed, so what i'm going to do next is to downgrade FF on my test machine until it works again.


Server: centOS 7, nginx 1.19.0, openssl 1.1.1f

Client: Firefox 77, Chrome 83 on Ubuntu 19.10, and several versions of Windows

nginx config:

ssl_verify_client optional_no_ca;
ssl_client_certificate /etc/ssl/certs/waf_client_ca.pem;
ssl_verify_depth 2;


  • the "optional_no_ca" is there because the verification of the client certificates is handled outside of nginx for "historical reasons". the browser behaviour does not change if i set it to "yes" or "optional".
  • It would be really bad if I had to replace all those certificates, so yes: i already thought about setting up a brand new CA and issue new certs for all the clients, but there are thousands of them so i really try to avoid this. At least until i know exactly what's wrong with at least some of the existing ones.

Ok, after digging into the FF sources and some more searching on information security i found the solution:

On https://security.stackexchange.com/questions/68491/recommended-key-usage-for-a-client-certificate philippe lhardy describes the certificate checks perfomed by libnss and the criteria that have to be met:

  • EKU AND KU are NOT set.
  • KU is not set AND EKU is set to clientAuth AND cert is NOT a CA.
  • KU contains digitalSignature AND EKU is NOT set
  • KU contains digitalSignature AND EKU is set to clientAuth AND cert is NOT a CA.

This post is from 2015 and seems to be not quite correct anymore, as the EKU has to be set to clientAuth, otherwise the certificate is not displayed in the dialog. It is not sufficient anymore just to set the KU field. It is somewhat strange though as it seems that this check is not performed if the server does not transmit any CA names... Maybe someone knows and can explain why this is so.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.