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

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[dattaz]

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

Comment 1

[Clément Lefèvre]

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.

Comment 2

[Paul Silaghi, QA [:pauly]]

Confirmed in 37.0a1 (2014-12-07) Win 7

Comment 3

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

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.)

Comment 4

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

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.

Comment 5

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

Attachment: patch

Thanks for the input, Brian. What do you think of this?

Comment 6

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

[Tracking Requested - why for this release]:

Comment 8

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

https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=a3184e10a8e9

Comment 9

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

Thanks for the review!
https://hg.mozilla.org/integration/mozilla-inbound/rev/1165556f34c3

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1165556f34c3

Comment 13

[David Hrbáč]

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/.

Comment 14

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

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

[David Hrbáč]

Hi David, thank for the quick reaction. Will post into #1138273.

Comment 16

[liuk001]

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

[David Hrbáč]

I can confirm that suggested modification of tinyca settings solves the issue. Thank you liuk001, whoever you are :)