Closed
Bug 1088998
Opened 10 years ago
Closed 10 years ago
ssl_error_bad_cert_domain on some Akamai-hosted sites (developer.nvidia.com, schwabcdn.com) due to lack of subjectAltName and TeletexString-encoded Subject CN
Categories
(CA Program :: CA Certificate Root Program, task)
CA Program
CA Certificate Root Program
Tracking
(firefox35 unaffected, firefox36 affected)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox35 | --- | unaffected |
firefox36 | --- | affected |
People
(Reporter: alice0775, Assigned: kathleen.a.wilson)
References
Details
(Keywords: regression)
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
Reporter | ||
Updated•10 years ago
|
Summary: Unable to load developer.nvidia.com, "(Error code: ssl_error_bad_cert_domain" displayed → Unable to load developer.nvidia.com, "Error code: ssl_error_bad_cert_domain" displayed
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.
Assignee: nobody → kwilson
Blocks: BR-Compliance
Component: Security: PSM → CA Certificates
OS: Windows 7 → All
Product: Core → mozilla.org
Hardware: x86_64 → All
Version: 36 Branch → other
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.
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)."
Updated•10 years ago
|
Summary: Unable to load developer.nvidia.com, "Error code: ssl_error_bad_cert_domain" displayed → ssl_error_bad_cert_domain on some Akamai-hosted sites (developer.nvidia.com, schwabcdn.com) due to lack of subjectAltName and TeletexString-encoded Subject CN
Comment 5•10 years ago
|
||
Also https://sc.imp.live.com/, which affects the appearance of https://login.live.com.
Comment 6•10 years ago
|
||
Bug 1089527 mentions two other sites with Baltimore Cybertrust Root which are showing ssl_error_bad_cert_domain.
Assignee | ||
Comment 7•10 years ago
|
||
Steven, Please look into these issues, and comment in this bug about them.
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.
(Mail to kwilson bounced)
If this is an issue, please contact me. rsalz at akamai.
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)
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.
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.
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.
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.
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).
Comment 25•10 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!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•8 years ago
|
Product: mozilla.org → NSS
Updated•2 years ago
|
Product: NSS → CA Program
You need to log in
before you can comment on or make changes to this bug.
Description
•