Alice0775 White Reporter
	Description • 10 years ago

STR
1. Open https://developer.nvidia.com/



Regression window(m-i)
Good:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c49d6f338987
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141023134636
Bad:
https://hg.mozilla.org/integration/mozilla-inbound/rev/9d83b21c98e8
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141023142335
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c49d6f338987&tochange=9d83b21c98e8

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	Comment 1 • 10 years ago

The cert chain is:

   *.nvidia.com <- Cybertrust Public SureServer SV CA <- Baltimore Cybertrust Root 

The end entity cert also has OU="Akamai Wildcard SSL" so I assume that this is a cert managed through Akamai.

This certificate does not have a subjectAltName extension, and is thus nonconformant with the baseline requirements.

Further, although currently mozilla::pkix contains fallback logic to use the subject CN when there is no SAN, mozilla::pkix now doesn't accept the the TeletexString/T61String encoding for this fallback. However, that's exactly what this certificate is using. Note that RFC5280 says this: "TeletexString, BMPString, and UniversalString are included for backward compatibility, and SHOULD NOT be used for certificates for new subjects." Also note that the TeletexString encoding is a minefield of potential compatibility/security issues due to its even-more-complicated-than-UTF-8 nature.

See also https://code.google.com/p/chromium/issues/detail?id=308330 about Google's plans to stop accepting certificates that lack the SAN extension.

For all these reasons, and because I think it is easy for Akamai to fix this on the server side, I am moving this to the "CA Certificates" component so Kathleen can work with the CA to revoke the certificate and other similar ones.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	Comment 2 • 10 years ago

Also note that O="NVIDIA Corporation" but OU="Akamai Wildcard SSL", however I doubt that "Akamai Wildcard SSL" is actually an organizational unit of NVIDIA Corporation. That would be another BR violation.

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	Comment 3 • 10 years ago

See bug 443830 comment 4 and bug 458745 comment 3 for why TeletexString decoding is particularly problematic:

"The issue with the www.joes-ssl.com certificate is mainly that it doesn't use an escape sequence to specify that it's using one of the JIS encodings... and while the MS CryptoAPI apparently uses heuristics for figuring out the correct set, NSS always treats TeletexStrings as ISO-8859-1 strings (http://mxr.mozilla.org/mozilla/source/security/nss/lib/certdb/secname.c?mark=654-661#643)."

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	Comment 5 • 10 years ago

Also https://sc.imp.live.com/, which affects the appearance of https://login.live.com.

	Johannes Pfrang [:johnp]
	Comment 6 • 10 years ago

Bug 1089527 mentions two other sites with Baltimore Cybertrust Root which are showing ssl_error_bad_cert_domain.

	Kathleen Wilson Assignee
	Comment 7 • 10 years ago

Steven, Please look into these issues, and comment in this bug about them.

	Steven Medin
	Comment 8 • 10 years ago

All Akamai certs are in the process of replacement between now and February.  Replacements resolve these matters.  Due to the volume of certificates involved, response cannot be accelerated and comply with careful and complete issuance practice.

	Rich Salz
	Comment 9 • 10 years ago

(Mail to kwilson bounced)

If this is an issue, please contact me.  rsalz at akamai.

	Alexandre Vicenzi
	Comment 19 • 10 years ago

I can't login to Outlook.com.

mail.live.com uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer)

	Alexandre Vicenzi
	Comment 20 • 10 years ago

Any HTTPS connection is not working with 36.0a1 (2014-11-07).

This happens with all certificates, facebook, google, mozilla, and so on.

	Alexandre Vicenzi
	Comment 21 • 10 years ago

To reproduce just follow this step: http://docs.telerik.com/fiddler/configure-fiddler/tasks/decrypthttps

I was using Fiddler as a proxy to decript https traffic.

	Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)
	Comment 22 • 10 years ago

Alexandre - did you import and trust the root certificate from your Fiddler proxy? In any case, the error you're getting is different from the one described in this bug. If you are still having problems, please file a new bug.

	Alexandre Vicenzi
	Comment 23 • 10 years ago

I imported, and only fails on Firefox. I just disabled HTTPS decrypt to solve.

Is this a real bug? Fiddler certificates are untrusted I think. But the problem is that I can't add exception is this case. If it's a bug I'll open a new bug.

	Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)
	Comment 24 • 10 years ago

Just so everyone is on the same page, this shouldn't affect Firefox users any more, since minimal support for TeletexString was added in bug 1089104. This bug is intended to track Akamai replacing existing problematic certificates (targeted to finish in February, apparently) (see also comment 1).

	Brian Smith (:briansmith, :bsmith, use NEEDINFO?)
	Comment 25 • 9 years ago

I verified that the current certificates for https://developer.nvidia.com, https://www.schwabcdn.com, and https://sc.imp.live.com are (1) using UTF8String instead of T61String/TeletexString in the end-entity subject DN, and (2) have subjectAltName extensions.

Thanks Akamai!