ssl_error_bad_cert_domain when subjectAltName extension is missing and Subject CN is encoded as TeletexString

RESOLVED FIXED in Firefox 36

Status

()

defect
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: sawrubh, Assigned: briansmith)

Tracking

({regression})

36 Branch
mozilla36
x86_64
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox36+ fixed)

Details

()

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

5 years ago
STR:
* Open http://www.flipkart.com/, signup.
* After logging in, open this page https://www.flipkart.com/account/orders?link=home_orders or simply navigate to the orders page by clicking on the option available under your name on top right.

What happens:
There is no styling on this page. The page appears styled normally on stable Firefox and Chrome. The CSS for the page is hosted at https://img1a.flixcart.com//www/prod/basic-2130d90d-nogz.css which when I opened in another tab in Nightly gave me the Untrusted Connection notice, when I added the exception and then reloaded the URL (https://www.flipkart.com/account/orders?link=home_orders) in question, it appeared styled normally. When I open this CSS URL in stable Firefox, it opens without any Untrusted Connection notice. Same in Chrome.
https://img1a.flixcart.com//www/prod/basic-2130d90d-nogz.css

img1a.flixcart.com uses an invalid security certificate. The certificate is only valid for *.flixcart.com (Error code: ssl_error_bad_cert_domain
Component: Untriaged → Security: PSM
Keywords: regression
Product: Firefox → Core
Duplicate of this bug: 1089180
Duplicate of this bug: 1089148
Reporter

Comment 5

5 years ago
But why does it then work in stable Firefox and Chrome?
(In reply to Saurabh Anand [:sawrubh] from comment #5)
> But why does it then work in stable Firefox and Chrome?

The server's certificate is missing the subjectAltName extension, which it is supposed to have. Web browsers implement a workaround for the missing subjectAltName extension that uses the CN field of the Subject field instead. Last week, I made a change to that fallback logic so that that fallback logic wouldn't be used in the case where the CN field of the subject was not in UTF8String or PrintableString encoding. In this case, the CN field of the subject is in TeletexString encoding, which is deprecated (by RFC 5280).

Maybe we will undo the change I made last week. But, the best solution for your problem is to contact the CA and ask them to issue you a certificate with the SubjectAltName extension.
Flags: needinfo?(brian)
Summary: Website untrusted in Nightly and not in Firefox Stable → Websites untrusted in Nightly and not in Firefox Stable because subjectAltName extension is missing and Subject CN is encoded as TeletexString
Duplicate of this bug: 1089235
Duplicate of this bug: 1089587
See Also: → 1089519
Several Nightly testers are reporting this problem for live.com and hotmail.com.

Comment 10

5 years ago
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #6)
> The server's certificate is missing the subjectAltName extension, which it
> is supposed to have. Web browsers implement a workaround for the missing
> subjectAltName extension that uses the CN field of the Subject field
> instead. Last week, I made a change to that fallback logic so that that
> fallback logic wouldn't be used in the case where the CN field of the
> subject was not in UTF8String or PrintableString encoding. In this case, the
> CN field of the subject is in TeletexString encoding, which is deprecated
> (by RFC 5280).
> 
> Maybe we will undo the change I made last week. But, the best solution for
> your problem is to contact the CA and ask them to issue you a certificate
> with the SubjectAltName extension.


Maybe we should collect some telemetry about this first?
It may be the case that we need to do some work with CAs (and the CAs will need to work with their customers) before we can make this change.
In bug 1088998 this chrome issue is mentioned: http://code.google.com/p/chromium/issues/detail?id=308330

They've added telemetry there some days ago, maybe worth checking out if they got any preliminary results?
Oh, make that 'a year ago'... 23rd October 2013 ^^

Comment 13

5 years ago
Oh. So maybe someone needs to review the telemetry and suggest how/when to move forward with this. Also, let me know which CAs have the most of these types of certs, and when these types of certs expire. Then I can work with those CAs...

I think FF 36 is too soon for this change, but the telemetry should be able to tell us.
[Tracking Requested - why for this release]:
Duplicate of this bug: 1090486
This is the only non-Akamai-hosted isntance of the problem that has been reported, as far as I can find. (The issue with login.live.com is also regarding an Akamai cert.)

I've updated the code for bug 1063281 to make it so that we'll accept TeletexString-encoded CN-IDs. My understanding is that after bug 1088998 is resolved, Akamai will be in compliance with the BRs and so we can investigate making the change to drop support for TeletexString-encoded CN-IDs and/or CN-IDs completely. However, it isn't a high priority to do so.
Assignee: nobody → brian
Status: NEW → ASSIGNED
Attachment #8513258 - Flags: review?(dkeeler)
Comment on attachment 8513258 [details] [diff] [review]
Add Support for TeletexString-encoded CN-IDs, with test

Review of attachment 8513258 [details] [diff] [review]:
-----------------------------------------------------------------

This looks good - thanks for taking care of this. My only request would be to have a test that we do actually reject TeletexStrings that contain escape sequences.

::: security/pkix/lib/pkixnames.cpp
@@ +389,5 @@
>    // attempt to detect or report malformed UTF-8 (e.g. incomplete or overlong
>    // encodings of code points, or encodings of invalid code points).
>    //
> +  // TeletexString is supported as long as it does not contain any escape
> +  // sequences, which are not supported. We'll reject escape sequences as

Seems like we should have a test for this.

::: security/pkix/test/gtest/pkixnames_tests.cpp
@@ +1069,5 @@
>  // matched against a reference DNSName only need to be added to
>  // DNSNAMES_VALIDITY, and not here.
>  static const CheckCertHostnameParams CHECK_CERT_HOSTNAME_PARAMS[] =
>  {
> +  // This is technically illegal PrintableString is defined in such a way that

nit: '.' after "illegal"?
Attachment #8513258 - Flags: review?(dkeeler) → review+
Duplicate of this bug: 1091040
Duplicate of this bug: 1090652
Target Milestone: --- → mozilla36
It is very difficult to find a reference for TeletexString that clearly states that these are the right escape codes to use, but indirectly through a bunch of Googling and pulling my hair out, I think this is correct.
Attachment #8513258 - Attachment is obsolete: true
Attachment #8513927 - Flags: review?(dkeeler)
Comment on attachment 8513927 [details] [diff] [review]
Add Support for TeletexString-encoded CN-IDs, v2, with more tests

Review of attachment 8513927 [details] [diff] [review]:
-----------------------------------------------------------------

Great - thanks for adding the extra tests.
Attachment #8513927 - Flags: review?(dkeeler) → review+
So far, AFAICT, only https://sverigesradio.se and https://img1a.flixcart.com are the only non-Akamai-hosted sites missing subjectAltName and using TeletexString CN-IDs. Akamai is apparently in the process of replacing all their certs between now and February.
Duplicate of this bug: 1091347
https://hg.mozilla.org/mozilla-central/rev/a87664f1bad4
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Summary: Websites untrusted in Nightly and not in Firefox Stable because subjectAltName extension is missing and Subject CN is encoded as TeletexString → ssl_error_bad_cert_domain when subjectAltName extension is missing and Subject CN is encoded as TeletexString
Duplicate of this bug: 1050302
Possible this patch broke www.marketday.com ?

I get an immediate network error
The connection was interrupted 

Or will Marketday have to update/fix their end ?  Site is accessable in IE11 and latest Chrome.

Site will throw a cert error page on cset: 20141031125700 a264cdd47217
but on cset 20141031131459 12ac66e2c016 I get the network error page.
FWIW, I think this busted wordpress.org as well.  I got this *.wordpress.org message trying to download the latest .tar.gz.
You need to log in before you can comment on or make changes to this bug.