Constructed GeneralName types such as otherName are not parsed correctly, and the certificate error cannot be overridden.

RESOLVED FIXED in Firefox 37

Status

()

Core
Security
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: dattaz, Assigned: keeler)

Tracking

37 Branch
mozilla37
x86_64
Linux
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox36 affected, firefox37 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
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
(Reporter)

Updated

3 years ago
Flags: needinfo?(clement.lefevre)
(Reporter)

Updated

3 years ago
Summary: can't click on "add exception" with self-signed certificats → can't click on "add exception" with some self-signed certificats

Comment 1

3 years ago
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.
Flags: needinfo?(clement.lefevre)
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.)
Blocks: 1063281
Flags: needinfo?(brian)
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.
Flags: needinfo?(brian)
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.
Created attachment 8533347 [details] [diff] [review]
patch

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+
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=a3184e10a8e9
Thanks for the review!
https://hg.mozilla.org/integration/mozilla-inbound/rev/1165556f34c3
https://hg.mozilla.org/mozilla-central/rev/1165556f34c3
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla37

Updated

3 years ago
Duplicate of this bug: 1111197

Updated

3 years ago
Duplicate of this bug: 1110648

Comment 13

3 years ago
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.

Comment 15

3 years ago
Hi David, thank for the quick reaction. Will post into #1138273.
status-firefox37: affected → fixed

Comment 16

3 years ago
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.

Comment 17

3 years ago
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.