845029 - SEC_ERROR_EXPIRED_CERTIFICATE cannot be overridden

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[Dan Merillat]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 Iceweasel/18.0
Build ID: 20130109081357

Steps to reproduce:

Went to a website with an expired certificate, Got "This Connection is Untrusted", clicked add exception.


Actual results:

"This site provides valid, verified identification.  There is no need to add an exception."


Expected results:

This bug should have been resolved years ago.  It's well known, frequently filed, and always closed as invalid/dupe.  PSM rejects a cert but won't allow an override because the exception dialog doesn't check expiration date and considers the certificate valid (right domain, valid chain to a trusted root).

Especially when dealing with web-based hosting, it's impossible to bypass the expired The best resolution would be to get rid of the validity check in adding an exception.   There's basically no reason a user will be at that dialog unless they got an untrusted site warning, so the "sanity check" is counter-productive.

Comment 1

[Dan Merillat]

The problem manifests the second time a certificate expires - On a fresh profile, this will work.  When the admin/you replaces the cert with an updated one then that new cert expires again, then you run into an issue.

Tested by closing the browser, removing the line from cert_override.txt and re-trying. The results were then as expected - I was able to add an exception and proceed to the site.

Again, this can be solved by getting rid of the "sanity check" in the add exception dialog.  Even if it seems valid, allow the user to add an exception - hopefully no other "sanity checks" prevent it from being updated.

Meta:

This probably explains why this is so often closed as INVALID/DUPE - it happens on low-importance sites (non-SSL primary sites that have a SSL administrative interface, for example) where it's likely that this kind of thing will happen every year when the cert expires.  The first time, it will work as expected.  A year later, the cert gets updated, expires again - but the exception is for the first certificate, not the new one, so the SSL layer rejects it. I agree with your security team on that policy, which leaves only the user interface to be fixed.

Comment 2

[Sylvestre Ledru [:Sylvestre]]

I am experiencing this too.
Not being able to be override this prevents me to do my work...

Richard, do you know who could help on this?

Comment 3

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

What site is this on?

Comment 4

[Richard Barnes [:rbarnes]]

Attachment: mkexp.go

In trying to reproduce, I experienced a worse variant.  On connecting to a server with an expired test cert, Firefox correctly produced the "expired certificate" warning and allowed me to open the exception dialogue -- but then clicking "Confirm Security Exception" did nothing!

Comment 5

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

I think that's a different bug, Richard. The certificates generated by that script have empty extension fields (either due to how go encodes certificates or how the script uses the libraries), which isn't RFC 5280-compliant (if the field is present, it must have 1 or more extensions). mozilla::pkix encountered compatibility issues when enforcing this for OCSP extensions, and then that code got re-used when handling certificate extensions, which is why SEC_ERROR_BAD_DER isn't thrown earlier in the process (see bug 991898 and bug 997994). Adding the cert override fails because (one part of) NSS actually does enforce that part of RFC 5280. I filed bug 1247407 to address the UI failure.

Comment 6

[Sylvestre Ledru [:Sylvestre]]

David, it was http://nucleus.mozilla.org/ but it has been fixed now.

Comment 7

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

Dan, are you still experiencing this issue?

Comment 8

[Dan Merillat]

It looks like it was fixed at some point, at least for self-signed certificates.  I don't have the infrastructure to properly test with CA-issued certs, since it needs to expire, be overridden, then expire again to expose the bug.

To be clear - it is the SECOND time a cert expired and override attempted that failed.

If someone can setup a proper test CA and make a site that has a cert that expires and is renewed every few minutes, that would be a proper test.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

I don't think it is fixed.
The issue is that we could not override the error message. Not some website being broken.