1601227 - firefox doesn't offer to use CA certificates as client authentication certificates

Status: VERIFIED FIXED

(Core :: Security: PSM, defect, P1)

Description

[tglenard]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:70.0) Gecko/20100101 Firefox/70.0

Steps to reproduce:

I have a self signed personal certificate to access my tomcat java apps
Since 71 release, it doesn't work anymore
try to add it again, not work

Actual results:

SSL_ERROR_BAD_CERT_ALERT
when trying to view my personnal certificate, got a page corrupted certificate
no problem with firefox 70.0

Expected results:

See personal certificate

Comment 1

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

What is the value of security.default_personal_cert in about:config?
Also, can you attach the client certificate you're trying to use to this bug? (just the certificate, not the private key)
Thanks!

Comment 2

[tglenard]

Attachment: Personal Certificate

password UqlKV0boKhY=

Comment 3

[tglenard]

security.default_personal_cert is set to true
i attached an exemple of certificate generate with keytool, work fine with previous firefox release since 2 years
thanks in advance

Comment 4

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Thanks! Can you try with a certificate that is marked as X509v3? (that certificate doesn't have a version, so it's implicitly version 1, which means it's a CA certificate, not a client certificate).

Comment 8

[J.C. Jones [:jcj] (he/him)]

[Tracking Requested - why for this release]:
Seeing a bunch of issues from 71

Comment 9

[j94305]

If this is the true reason, Firefox 71 seems to be more strict in the certificates it accepts. Apart from this being a rather obscure feature (in the sense of being hidden), it should be possible to fix the certificates by re-issuing them with the required x509 extensions:
If I have used a configuration file for openssl of this form before:

[ req ]
default_bits = 4096 # RSA key size
encrypt_key = yes # Protect private key
default_md = sha256 # MD to use
utf8 = yes # Input is UTF-8
string_mask = utf8only # Emit UTF-8 strings
prompt = no # Prompt for DN
distinguished_name = email_dn # DN template
req_extensions = email_reqext # Desired extensions

[ email_dn ]
...

[ email_reqext ]
keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = emailProtection,clientAuth
subjectKeyIdentifier = hash
subjectAltName = email:{{EMAIL}}

I should now add some sections for x509v3. In the "req" section:

x509_extensions = x509_reqext
In the "email_reqext" section:
basicConstraints = CA:FALSE
And as a new section this:
[ x509_reqext ]
basicConstraints = CA:FALSE
nsCertType = client,email
keyUsage = critical,digitalSignature,keyEncipherment
extendedKeyUsage = emailProtection,clientAuth
subjectKeyIdentifier = hash
subjectAltName = email:{{EMAIL}}
authorityKeyIdentifier = keyid,issuer

This will create self-signed certificates marked as "Version: 3 (0x2)" and with the X509v3 attributes set:

   X509v3 extensions:
       X509v3 Basic Constraints:
           CA:FALSE
       Netscape Cert Type:
           SSL Client, S/MIME
       X509v3 Key Usage: critical
           Digital Signature, Key Encipherment
       X509v3 Extended Key Usage:
           E-mail Protection, TLS Web Client Authentication
       X509v3 Subject Key Identifier:
           54:26:D5:A7:36:C9:98:52:23:C6:D6:0C:EF:A2:CD:05:F2:0C:C5:C5
       X509v3 Subject Alternative Name:
           email:[e-mail]
       X509v3 Authority Key Identifier:
           keyid:54:26:D5:A7:36:C9:98:52:23:C6:D6:0C:EF:A2:CD:05:F2:0C:C5:C5

Unfortunately, I cannot try this right away myself as the environment where this was tested has incidentially been taken down this weekend. I'll try to test it over the next couple of days, though, and invite others who had these issues to try the extended certificate generation as well.

If this fixes the problems we see, Firefox 71 is actually doing the right thing - it just did not care to inform us of switching from being tolerant to being strict.

Comment 10

[j94305]

Ok guys, I did not want to wait :-) So, I placed the certificate I had generated according to the extended configuration shown above and fired up the NGINX once again...

It works!

Not only does Firefox now display the imported certificate properly (through Options -> Privacy and Security -> View Certificates), it will also offer this certificate as a possible means of authentication when I call the NGINX site.

So, this does not seem to be a "bug" in the narrower sense that was introduced in Firefox 71, it is more a change of handling certificates by being more strict about x509v3 attributes.

Now I can upgrade to Firefox 71 :-)

Comment 11

[tglenard]

Hello,
I use this client authentification for my software, and i have maybe 100 certificates installed on client firefox. It seems I forgot those X509v3 attributes, but that works well for ipad, android phones, i phones, and other navigators.
Too change every certificates, it can take me more than 2 days as we have to do it on each computer. So just let me know, is it planned to revert as previous version, and if yes, how long can it take to have the patch online?
Thanks in advance

Comment 12

[Stephan Krynauw]

Having the same issue on our side as well, will test the above and confirm if it works.

My worry is that it does break backwards compatibility and all client side certificates would need be re-issued.

Comment 14

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Attachment: bug 1601227 - offer to use CA certificates as client authentication certificates r?kjacobs

Bug 1267643 changed how gecko finds client certificates to offer to the user to
use. This change was too permissive, so we reintroduced some filtering in bug
1590888 and bug 1592532. All of these changes together were too restrictive and
filtered out CA certificates, which some users evidently use as client
certificates. This bug removes the restriction that client certificates not be
CA certificates and hopefully arrives at pre-bug 1267643 behavior.

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/054eefbb7fb1
offer to use CA certificates as client authentication certificates r=kjacobs

Comment 16

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/054eefbb7fb1

Comment 17

[Julien Cristau [:jcristau]]

Please request beta uplift when you get a chance.

Comment 19

[gregor]

I tested with the last nightly build and it works again. Thanks!
What does the last comment mean? Who can request a beta uplift and beta means version 72?
I would appreciate that :-).

Comment 20

[d.wagner]

Here it also worked with nightly - I would also appreciate an uplift.
Thank you very much :)

Comment 21

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Comment on attachment 9114984 [details]
bug 1601227 - offer to use CA certificates as client authentication certificates r?kjacobs

Beta/Release Uplift Approval Request

• User impact if declined: Users won't be able to use CA certificates as client authentication certificates.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The changes are small and localized. There's an automated test.
• String changes made/needed:

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9114984 [details]
bug 1601227 - offer to use CA certificates as client authentication certificates r?kjacobs

Fixes a regression causing some users to be unable to use CA certificates as client authentication certificates. Thanks for including an automated test. Approved for 72.0b6.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/baa895188e29

Comment 25

[Daniel Bodea [:danibodea]]

I am not sure I understand this issue completely.

• I have attempted to reproduce it by the following steps:

1. Open affected browser version.
2. Go to "about:preferences#privacy", Certificates section, "View Certificates..." button.
3. In the "Your Certificates" tab, click the "Import..." button and import the certificate from comment 2.
4. Double-click the newly imported certificate.
   Actual: A new browser tab is opened with text:" Certificate Something went wrong. We were unable to find the certificate information, or the certificate is corrupted. Please try again."
   Expected: A pop-up window is displayed with certificate information. (Seen in ESR68)

• I have attempted to verify the fix in the latest Nightly (in both Windows 10 and Ubuntu 18) using the same steps, but it appears that the fix is not correct.

Is there something wrong with my steps for reproduction/verification?

Comment 26

[Daniel Bodea [:danibodea]]

How did you verify the fix? Is there something wrong with my steps above?

Comment 27

[j94305]

@danibodea
I gave configuration files for both, the old method and the correct way of creating certificates, in my comment https://bugzilla.mozilla.org/show_bug.cgi?id=1601227#c9

Can you try to create a v1 and a v3 certificate and test with them again?

I have to admit I have not yet tried any nightly build to verify the issue is fixed. I'll wait for the next release and try then.

Comment 28

[Daniel Bodea [:danibodea]]

Thank you for the information provided in comment 9, but I need more detailed information. I do not possess the required technical skills to create a basic certificate. I need detailed information on how to actually create them and how to use them properly to reproduce the issue.

Alternatively, you could help us by validating the fix in the latest Nightly and Beta builds:
You can download the latest Beta and Nightly from https://www.mozilla.org/en-US/firefox/channel/desktop/ and verify.

Thank you for your contribution!

Comment 29

[gregor]

Preface:
We are using self-signed certificates with CA-Flag=true to establish the ssl connection to the server and to authenticate the client. Before Version 71 it was possible to select such a certificate when opening an URL to a server with a corresponding configuration.

Behaviour in Version 71:
The certificate can be imported and is shown as valid. But when the URL from the server mentioned above is opened, the popup to select the certificate does not appear.

Test:
So, I installed the Beta from Version 72 with the fix and imported the certificate. And now the Popup to select the certificate appears again.

I tested with Nightly(73.0a1 (2020-01-05)) and current Version 72 from Beta, it is still working!

Comment 30

[Julien Cristau [:jcristau]]

Marking verified per comment 29, thanks!

Comment 31

[j94305]

@danibodea:

Unfortunately, the environment where I noticed the problem has been taken down in December and is no longer available. The project has ended.

However, I can share with you the magic of creating certificates. I usually do this in a script, but the essential lines are

name=John_Doe
conf=etc/client-cert.conf
mkdir -p certificates-self

openssl req -new -newkey rsa:4096 -x509 -days 365 -nodes -config $conf -sha256
-passout "pass:" -out "certificates-self/$name.pem"
-keyout "certificates-self/$name.key"

openssl pkcs12 -export
-inkey "certificates-self/$name.key" -in "certificates-self/$name.pem"
-passin "pass:" -out "certificates-self/$name.pkcs12" -passout "pass:"
-name "$name"

The variable conf points to a configuration file of the sort you see in comment 9. One file creates a certificate that fails, the second yields one that works.

You can check the file you created by running this:

openssl x509 -text -noout -in "certificates-self/$name.pem" -passin "pass:" > "certificates-self/$name.info"
cat "certificates-self/$name.info"

It then depends on your web server how you install client certificates. You may also check my original bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1602207

Comment 32

[Benjamin Schneider]

When I tested FF 72 Beta 19 days ago, the client certficate login was working again - see my comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=1605170

After upgrading my production system to FF 72.0 today again the SSL_ERROR_HANDSHAKE_FAILURE_ALERT message appears.

Comment 33

[Benjamin Schneider]

(In reply to Benjamin Schneider from comment #32)

When I tested FF 72 Beta 19 days ago, the client certficate login was working again - see my comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=1605170

After upgrading my production system to FF 72.0 today again the SSL_ERROR_HANDSHAKE_FAILURE_ALERT message appears.

Please ignore my last comment. Everything is working fine with final version 72.

Comment 34

[Daniel Bodea [:danibodea]]

Thank you for making sure that everything is correctly verified.

Comment 35

[Mirta]

Hi! Last month I had the same problem described in this bug with version 71 and client certificates (self signed).
I had to create a new certificate because our system was developed to work only from Firefox and we were in a hurry to get all clients working as soon as possible..
The new certificate worked fine on version 71 but today client pcs are upgrading to version 72 and are getting Expired Certificate error. Our server is rejecting the certificate sent by Firefox 72 as it were expired, but of course it is not. It happens only on version 72.

Comment 36

[Daniel Bodea [:danibodea]]

Mirta, please log a new bug because it seems these 2 issues are only similar. You may mention this bug in the newly logged one, but this one is closed already. Thank you for your contribution!

Comment 37

[Mirta]

Thanks Daniel, I logged bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1608057

Comment 38

[mail]

Attachment: nextcloud.pem

not working cert

Comment 39

[mail]

Unfortunately I get the same SSL_ERROR_BAD_CERT_ALERT when trying to view my server certificate (uploaded for testing), but in parallel Firefox 73 reports that the connection is secure.
The uploaded cert is the complete chain, but the behaviour is the same if it's only the certificate without the chain.

Comment 40

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Please file a new bug with as much information as you can include: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security%3A%20PSM