User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20141207030205 Steps to reproduce: Go to https://blog.imirhil.fr/ and try to add exception Actual results: Pop-up for adding a exception is not show Expected results: This pop-up should be show. It's works well with some other self-signed certificates => https://linuxfr.org/ for example
Summary: can't click on "add exception" with self-signed certificats → can't click on "add exception" with some self-signed certificats
Looks like it's happening on "untrusted" certificate authorities like CACert rather than self-signed certificate. I Was able to reproduce it on OS X, with some websites using CACert, not on self-signed ones. Would be a good idea to test on other "untrusted" authorities.
Component: Untriaged → Security
Product: Firefox → Core
Confirmed in 37.0a1 (2014-12-07) Win 7
Status: UNCONFIRMED → NEW
Ever confirmed: true
That site's certificate has a subjectAltNames extension with an 'otherName' entry that is encoded with a tag identifying it as 'CONTEXT SPECIFIC | CONSTRUCTED | 0', whereas we're expecting it to be 'CONTEXT SPECIFIC | 0'. Interestingly, mozilla::pkix implements directoryName as 'CONTEXT SPECIFIC | CONSTRUCTED | 4', so I'm not sure if our implementation is correct. Brian, do you have any insight on this? (The other thing that's going on is if we encounter an unexpected error in our certificate override processing code, it's possible to set the error to an overridable error but behave as if it's not overridable, resulting in this confusing UI state.)
Thanks for pointing this out. It probably should have "| CONSTRUCTED". I guess all the ones where the value is a SEQUENCE should have "| CONSTRUCTED" added.
Summary: can't click on "add exception" with some self-signed certificats → Constructed GeneralName types such as otherName are not parsed correctly, and the certificate error cannot be overridden.
Thanks for the input, Brian. What do you think of this?
Assignee: nobody → dkeeler
Status: NEW → ASSIGNED
Attachment #8533347 - Flags: review?(brian)
[Tracking Requested - why for this release]:
status-firefox36: --- → affected
status-firefox37: --- → affected
Duplicate of this bug: 1109616
Attachment #8533347 - Flags: review?(brian) → review+
Thanks for the review! https://hg.mozilla.org/integration/mozilla-inbound/rev/1165556f34c3
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Can you please modify the Target Milestone? Seems that we are affected by this bug. We have our own CA. Since FF36 we are not able to use our web sites with certificates. FF 36 keeps telling us SEC_ERROR_BAD_DER at our webs, e.g. https://webmail.zmservis.cz/. I can browse with Chromium and IE11 with no error. Even FF 35 does not complain. Our CAs are at http://ca.pudu.cz/.
Hi David - looks like the certificate presented by that site has an empty subjectAltName extension. RFC 5280 says "If the subjectAltName extension is present, the sequence MUST contain at least one entry." We might change how we handle these sorts of conditions in bug 1138273.
Hi David, thank for the quick reaction. Will post into #1138273.
status-firefox37: affected → fixed
I can confirm that we have solved the problem with FF36 re-issuing the certificate and ensuring that the subjectAltName is completely absent or with at least one entry. Since we use TinyCA for our internal private CA you have to change the default from the Advanced configuration (see for example this post: http://www.pietrobattiston.it/creating_ssl_certificates_for_multiple_domains_or_subdomains_with_tinyca). HTH.
I can confirm that suggested modification of tinyca settings solves the issue. Thank you liuk001, whoever you are :)
Duplicate of this bug: 1106000
You need to log in before you can comment on or make changes to this bug.