I stumbled upon this question and answer. I have the same problem as the OP, and am sorry to report that the proposed answer does not resolve it. Certificate in question has been verified by OpenSSL-1.0.2h:

$ openssl verify -verbose -CAfile Forest\ CA\ 2\ RSA.pem -purpose sslclient yubi-sign-test.pem
yubi-sign-test.pem: OK

Here's its content:

 X509v3 extensions:
    X509v3 Basic Constraints: critical
    X509v3 Key Usage: critical
        Digital Signature, Non Repudiation
    X509v3 Subject Alternative Name:
    X509v3 Subject Key Identifier:
    X509v3 Extended Key Usage:
        TLS Web Client Authentication, Code Signing,, 1.2.840.113583.1.1.5, E-mail Protection, Microsoft Smartcardlogin
 Signature Algorithm: sha256WithRSAEncryption

Here's the content of the CA:

    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:TRUE, pathlen:4
        X509v3 Subject Key Identifier: critical
        X509v3 Key Usage: critical
            Digital Signature, Non Repudiation, Certificate Sign, CRL Sign
        X509v3 Extended Key Usage: critical
            Time Stamping, OCSP Signing
        X509v3 Authority Key Identifier:

Yet the current stable Firefox (47.0) is giving me that same message, and refuses to use that certificate for establishing a TLS session (doesn't even offer it among the available certs). It shows this certificate (among others) in Prefs->Advanced->View Certificates.

Needless to say, CA that issued this certificate, was imported to "Authorities" and marked as trusted for all the three options.

The only possible thing that I could think of - this CA does not offer CRL or OCSP, so neither it not the certs it issues have pointers to CRL or OCSP.

One suggestion I got was:

Welcome on Security SE. Do not hesitate to post your question as a new question referencing this one. Details of both the CA and end-user certificates can be helpful. However, before doing so you should try to add the "Key encipherment" key usage to the certificate as a first step. In case it does not help, try to add "Data encipherment" and remove "Non repudiation" (or disable the "Critical" flag on these extensions).

The problem with the above is that we have fairly strict rules on the Key Usage attributes, particularly on certificates that that are provisioned to hardware tokens. So it is not possible for us to, e.g., remove "Non-repudiation" from a Digital Signature cert, or add "Key Encipherment" to it. (Even in the unlikely case that the stupid current-release Firefox would work with such a cert, we wouldn't be able to deploy it.)

I'd appreciate any help.

  • You are trying to use this as a client certificate? Note that Firefox only allows you to select among the certificates that the Server indicated it will accept (which happened as part of the request for the TLS client certificate during TLS handshake)
    – SEJPM
    Jun 24 '16 at 22:35
  • I would reduce the problem space by trying to connect to the webserver with openssl s_client -verbose -CAfile Forest\ CA\ 2\ RSA.pem -cert yubi-sign-test.pem -connect $webserver:$port. If it doesn't work then Firefox is probably right, if it works then Firefox is probably wrong.
    – Law29
    Jun 25 '16 at 0:10
  • keyEncipher would never make a difference on SSL/TLS client cert anyway, only server -- and only server RSA which you don't actually say. Also you don't actually say this cert is on a hardware token, is it? With the key? If so, does Firefox show it as being on the correct 'Security Device'? (And under 'Your Certificates'?) Jun 25 '16 at 13:31
  • Yes I'm trying to use this as a client certificate. Yes, openssl s_client ... appears to work with this cert/key fine (so Firefox most likely is wrong, especially since it refuses to validate certificate that openssl had no trouble validating). Yes, this certificate is on a hardware token (with the key) - and yes, Firefox shows that token on the correct 'Security Devices', and all the certs on it in the 'Your Certificates'. Needless to say, I'm out of guesses.
    – Mouse
    Jun 26 '16 at 2:15

When using client certificates the server sends a list of acceptable CA which issued the client certificate. Based on this list the browser will select the matching client certificate. If there is no client certificate issued by the CA expected by the server you get the error message. Thus the problem might not be the certificate itself, but simply that the server expects only certificates issued by a different CA.

To check which CA the server expects to be used for client certificate you might connect with openssl:

 $ openssl s_client -connect host:443 -servername host
 Acceptable client certificate CA names
  • Thank you, but in addition to Firefox apparent inability to connect, it refuses to validate certificates that are present under the 'Your Certificate'. I strongly suspect the two problems are related, especially since I had no problem connecting to the server using openssl s_client with that same key/certificate. In case it matter (though I think it shouldn't) this key/cert is on a hardware token - but as stated in my comment above, Firefox seems to recognize it correctly.
    – Mouse
    Jun 26 '16 at 2:20
  • @Mouse: openssl s_client -cert... does not actually care which CA the server sends to select the certificate because you already give it the certificate it should use. Thus this test only means that the certificate would work if selected but not that the server sends the correct information to let Firefox select the certificate. Please check instead the list of "Acceptable client certificate CA names" as shown in my example against the issuer of the certificate. Jun 26 '16 at 6:24
  • Steffen, thanks - but I also manually checked the list that the server sent to find the issuing CA there (yes it was there). :-(
    – Mouse
    Jun 26 '16 at 21:02

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.