978797 - Can't access to untrusted sites

Status: VERIFIED FIXED

(Firefox :: Security, defect)

Description

[Sébastien Desvignes]

User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140303030201

Steps to reproduce:

Go to a site with invalid certificate. (ex. https://th-rec-vaxinlog.cloudapp.net/)
Try to add a security exception.



Actual results:

The untrusted connection page appears.
When I click on "Add an exception", the certificate isn't retrieved and I can't confirm the exception.



Expected results:

"Add an exception" should retrieve the certificate and I can confirm the exception.

Comment 1

[moses]

I cannot reproduce this. 
See attachments.


One thing I can think of is that you are running Firefox in permanent Private Browsing.

Follow these steps and see if this works.
*Tools > Options > Privacy > Firefox will: "Use custom settings for history"
*Deselect: [ ] "Always use private browsing mode"

Comment 2

[moses]

Attachment: Able to add it 1.PNG

Here, I am able to verify the certificate.

Comment 3

[moses]

Attachment: able to add t 2.PNG

Certificate is accepted and I am able to access the site.

Comment 4

[Flore Allemandou [:flore]]

Unable to get the certificate on MacOSX Firefox 30 nightly.
It worked until thursday and stopped working since friday. No private mode, no extension, even reset the profile.

It may be specific to the french version.

Comment 5

[Flore Allemandou [:flore]]

One more thing: it's broken on Nightly (30 branch), you tested it on Firefox... Of course it works on Firefox.

Comment 6

[moses]

Mmm missed that critical detail. 

Yep, reproducible on 30. The user might want to create a support thread on the French forum.

Comment 7

[Sébastien Desvignes]

I'm not using "Always use private browsing mode".
I'm using nightly builds every days, and it stopped working since Friday 28th.

Comment 8

[goofy]

Confirmed following steps to reproduce on comment #1 with config
Mozilla/5.0 (X11; Linux i686; rv:30.0) Gecko/20100101 Firefox/30.0

Comment 9

[Flore Allemandou [:flore]]

There is no need to create a support thread anywhere. There's a bug in Nightly, it needs to be reported. Hence this bug. And then hopefully fixed.

Comment 10

[Flore Allemandou [:flore]]

I looked for the regression range:
It worked until Built from https://hg.mozilla.org/mozilla-central/rev/e3daaa4c73dd
Does not work since Built from https://hg.mozilla.org/mozilla-central/rev/626d99c084cb

Comment 11

[Sébastien Desvignes]

Bug 975122 may be related, it was pushed in the regression range.

Comment 12

[Clochix]

This bug doesn't happen on all sites with wrong certificates. I managed to successfully add exception for some page with self-signed certificates.

In the case of th-rec-vaxinlog.cloudapp.net, it seems that the browser is not able to get the server certificate. The output of `openssl s_client -showcerts -connect storage.clochix.net:443` may help.

But it do work on stable channel, and no more on nightly, so I can confirm this is a regression.

Comment 13

[Dana Keeler (she/her) [:keeler]]

It looks like the verification code is returning SEC_ERROR_INADEQUATE_KEY_USAGE. We removed support for adding overrides for certificates with this error in bug 975122 (for "classic" verification). However, it looks like there are some extra steps to fully remove this that weren't done (for one, removing the SEC_ERROR_INADEQUATE_KEY_USAGE case from NSSErrorsService::GetErrorClass seems to fix this, but I notice there are other uses of SEC_ERROR_INADEQUATE_KEY_USAGE in PSM we may have to also address).

Comment 14

[Dana Keeler (she/her) [:keeler]]

Attachment: patch

Comment 15

[Dana Keeler (she/her) [:keeler]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3ccf473bc7a6

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3ccf473bc7a6

Comment 17

[Sébastien Desvignes]

Ok, if I understand correctly, you made SEC_ERROR_INADEQUATE_KEY_USAGE unoverridable, and now, there isn't even the choice to add an exception on the page for this kind of error.
But I don't understand why this certificate trigger an inadequate key usage. It has
"Authentification de serveur web par TLS (1.3.6.1.5.5.7.3.1)" (TLS Web Server Authentication) in its extented key usage, is there something else missing ?

Comment 18

[Dana Keeler (she/her) [:keeler]]

As far as I can tell from stepping through the verification code as it currently works (in NSS), issuer certificates are expected to have the certificate signing key usage (which makes sense). However, since that certificate is self-signed and doesn't have that usage, that's one of the error codes collected. If you administer or can get in touch with the administrator of that server, I recommend you replace that certificate with a properly-issued one. If cost is a problem, there are CAs that issue certificates for free.

Comment 19

[Sébastien Desvignes]

Thanks for the explanation. Don't worry for the server, it's just a test server and I will easily change the certificate for a better one.
It's just surprising that a previously "minor" error (I'm not sure there are minor errors concerning SSL, but that one wasn't even reported before) became fatal one day.

Comment 20

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Sébastien Desvignes from comment #19)
> Thanks for the explanation. Don't worry for the server, it's just a test
> server and I will easily change the certificate for a better one.
> It's just surprising that a previously "minor" error (I'm not sure there are
> minor errors concerning SSL, but that one wasn't even reported before)
> became fatal one day.

We're preparing to replace the code that does certificate verification and there are some minor differences between how the new verification code works and how the old verification code works. In order to prepare for those differences, we started making some changes to the way we process certain certificate errors. The particular change that caused this issue allows us to greatly simplify how we do error processing and the change of behavior was seen as being worthwhile for that simplification, especially because very few sites use certs that will be affected by this change--especially now with David's fix.

Comment 21

[Sébastien Desvignes]

In fact, all self-signed certificate generated by IIS (Microsoft web server) have this error.
So, this makes using Firefox on a IIS testing environment not very nice...

Comment 22

[Stephen Gutknecht]

Can anyone help in using Java BouncyCastle cert creation to get around this?

Firefox Nightly refuses my self-signed certs, but I have a Google Android SDK self-signed cert that works perfectly fine in Firefox Nightly.  I have looked at the properties and done my best to duplicate it, but no luck (reference for a working self-signed cert: /sdk/samples/android-19/legacy/KeyChainDemo/assets/keychain.p12 if you have the Android SDK handy).

My BouncyCastle self-signed cert works fine in Chrome and Firefox 28.0.

I just can not determine which properties the error is refering too. As comment 17 says, I have TLS (1.3.6.1.5.5.7.3.1)" (TLS Web Server Authentication)

Comment 23

[Stephen Gutknecht]

online version of the WORKING self-signed sample from Google SDK: https://github.com/xdtianyu/android-4.2_r1/tree/master/development/samples/KeyChainDemo/assets file keychain.p12 - What's different about this self-signed from the failing ones?

Comment 24

[Craig]

IBM Power Systems Hardware Management Consoles (HMCs) appear to create self-signed certificates that run into this inadequate key usage problem.  Confirmed fine (allowed to add exception) in FF 27 but broken in the current Nightly.  Am I correct in understanding that the current result in Nightly is just "how it will be" and I should expect not to be able to use Nightly/FF to access my HMCs in the future?  I see that this is "RESOLVED FIXED" and that David linked to a code change but I'm not familiar enough with this to know if this means there is a fix in the pipeline (not yet in the Nightly build I've got, which is listed as up to date at the time of this writing) or if that was citing the change that introduced the problem.

Comment 25

[Sébastien Desvignes]

(In reply to Craig from comment #24)
> IBM Power Systems Hardware Management Consoles (HMCs) appear to create
> self-signed certificates that run into this inadequate key usage problem. 
> Confirmed fine (allowed to add exception) in FF 27 but broken in the current
> Nightly.  Am I correct in understanding that the current result in Nightly
> is just "how it will be" and I should expect not to be able to use
> Nightly/FF to access my HMCs in the future?  I see that this is "RESOLVED
> FIXED" and that David linked to a code change but I'm not familiar enough
> with this to know if this means there is a fix in the pipeline (not yet in
> the Nightly build I've got, which is listed as up to date at the time of
> this writing) or if that was citing the change that introduced the problem.

What was corrected in this bug was the fact that the button to add an exception was available for the SEC_ERROR_INADEQUATE_KEY_USAGE error, while this error wasn't overridable (bug 975122)
I've filed Bug 982754 concerning the problem that some certificates trigger SEC_ERROR_INADEQUATE_KEY_USAGE.