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

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Saurabh Anand [:sawrubh]]

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.

Comment 1

[Matthias Versen [:Matti]]

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

Comment 3

[Loic]

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a5ee2769eb27&tochange=e37231060eb4

Comment 5

[Saurabh Anand [:sawrubh]]

But why does it then work in stable Firefox and Chrome?

Comment 6

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

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

Comment 9

[Liz Henry (:lizzard) (relman/hg->git project)]

Several Nightly testers are reporting this problem for live.com and hotmail.com.

Comment 10

[Kathleen Wilson]

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

Comment 11

[Johannes Pfrang [:johnp]]

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?

Comment 12

[Johannes Pfrang [:johnp]]

Oh, make that 'a year ago'... 23rd October 2013 ^^

Comment 13

[Kathleen Wilson]

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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

[Tracking Requested - why for this release]:

Comment 16

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

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.

Comment 17

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

Attachment: Add Support for TeletexString-encoded CN-IDs, with test

Comment 19

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

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"?

Comment 22

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

Attachment: Add Support for TeletexString-encoded CN-IDs, v2, with more tests

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.

Comment 23

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

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.

Comment 25

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/a87664f1bad4

Thanks for the quick reviews!

Comment 26

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

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.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a87664f1bad4

Comment 30

[Jim Jeffery not reading bug-mail 1/2/11]

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.

Comment 31

[Nick Alexander :nalexander [he/him]]

FWIW, I think this busted wordpress.org as well.  I got this *.wordpress.org message trying to download the latest .tar.gz.