Closed Bug 1436062 Opened 3 years ago Closed 3 years ago
[meta] Example sites, using certs issued before 2016-06-01 by Symantec CAs that are affected by the distrust plan
For debugging/analysis purposes, it might be useful to have a list of sites that trigger the console warning that was added in bug 1409259. I suggest to add a few URLs to this bug. I've visited a few sites that are listed on this recent report: https://arkadiyt.com/2018/02/04/quantifying-untrusted-symantec-certificates/ However, I didn't see the warning message in the console, using Firefox 58 on Fedora 27.
Possibly some of the sites mentioned in that report have already been updated. As of today, for example, the warning can be seen for these sites: https:// blackberry.com https:// citirewards.com
I've clarified the subject. The sites on this page should use certificates that were issued before 2016-06-01. This way, the sites can be used for testing the console warning in Firefox 58 and 59, and also for testing the distrust of those sites in Firefox 60 and later.
Summary: [meta] Example sites that show the console warning for Symantec CAs affected by the distrust plan → [meta] Example sites, using certs issued before 2016-06-01 by Symantec CAs that are affected by the distrust plan
Matt, could you trigger a Canary run for a current Nightly to also help us identify currently-affected sites from the change in Bug 1434300?
To be clear, are all changes now part of current Nightly? And this will cause an error - not just the console warning?
Flags: needinfo?(mwobensmith) → needinfo?(jjones)
Precisely. We expect SEC_ERROR_UNKNOWN_ISSUER. (You can try https:// tesla.com/ in Nightly)
(In reply to J.C. Jones [:jcj] from comment #3) > Matt, could you trigger a Canary run for a current Nightly to also help us > identify currently-affected sites from the change in Bug 1434300? To those following along, there's a partial run in https://bugzilla.mozilla.org/show_bug.cgi?id=1434300#c81 thanks to CR.
Looks like CR beat me to it. Initially I did a scan of 10k sites and found the same results as she did. Working on a full scan of all top sites now.
We ran a scan across the Umbrella Top 1M list the other day. The full host list is captured in attachment 8953758 [details], the full JSON scan log is available as attachment 8953757 [details], and there is a list of affected root certificates in bug 1434300#c91. Please note that websites are getting fixed as we speak.
Hi, I am a French user of Nightly, and this government website : https://monespaceprive.msa.fr which has a certificate signed by Symantec, has recently started returning SEC_ERROR_UNKNOWN_ISSUER. The same certificate is trusted by Firefox as of the current build, and I see no console warning there when loading the site. Information regarding the certificate is: Common name: monespaceprive.msa.fr SANs: monespaceprive.msa.fr Organization: CAISSE CENTRALE MUTUALITE SOCIALE AGRICOLE Location: Bagnolet, Seine Saint Denis, FR Valid from May 19, 2015 to July 18, 2018 Serial Number: 5da41e981fcd45cc018e2ea9438523f1 Signature Algorithm: sha256WithRSAEncryption Issuer: Symantec Class 3 Secure Server CA - G4 Common name: Symantec Class 3 Secure Server CA - G4 SANs: DirName: CN = SymantecPKI-1-534 Organization: Symantec Corporation Org. Unit: Symantec Trust Network Location: US Valid from October 30, 2013 to October 30, 2023 Serial Number: 513fb9743870b73440418d30930699ff Signature Algorithm: sha256WithRSAEncryption Issuer: VeriSign Class 3 Public Primary Certification Authority - G5 Should I be getting in touch with them directly? I'm not exactly up to speed on what is going on with Symantec's certificates here… Let me know if you need any more information. Regards, Mark.
Mark: The certificate on https://monespaceprive.msa.fr does need to be replaced. If you would like to reach out to them, this is a good reference: https://www.symantec.com/connect/blogs/information-replacement-symantec-ssltls-certificates
¡Hola Kal! Is this why the map area at https://capmetro.org/planner/?#!P|TP!S|AIRPORT!Z|CAPITOL!start|yes is just a huge block of empty blue? Is this why I see MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED at https://www.dps.texas.gov/DriverLicense/movingtotexas.htm ? All these are on current Nightly, more precisely Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 ID:20180306220120 ¡Gracias! Alex
(In reply to alex_mayorga from comment #13) > ¡Hola Kal! > > Is this why the map area at > https://capmetro.org/planner/?#!P|TP!S|AIRPORT!Z|CAPITOL!start|yes is just a > huge block of empty blue? > This one works for me, so hard to say. > Is this why I see MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED at > https://www.dps.texas.gov/DriverLicense/movingtotexas.htm ? > Yes.
Warnings for these 2 as of today: https://www.orange.fr/ https://www.hsbc.fr (via https://mstdn.fr/@BoF/100550761038101132)
odeon.co.uk cineworld.co.uk myvue.com
bofa online banking billpay page breaks on this.
[Tracking Requested - why for this release]: Major web sites that are broken due to a new security feature shipping in Nightly 63
Note: The title of the bug says "Before 2016-06-01", but all of those examples are about "After 2016-06-01". This aligns with the timeframe for Chrome 70 (which Dev and Canary are on) and Chrome 63, as announced at: - Chrome: https://security.googleblog.com/2018/03/distrust-of-symantec-pki-immediate.html - Firefox: https://blog.mozilla.org/security/2018/07/30/update-on-the-distrust-of-symantec-tls-certificates/ I'm not sure if the bug wranglers would rather direct people to a new bug for this subsequent "total distrust of Symantec", which is what Nightly 63 has recently enabled.
If we need to maintain such a list at all, it should be on a different/new bug IMO. This was specifically about the previous phase of the distrust.
I have filed Bug #1484006 for Firefox Nightly users to report their problems due to the current phase of the distrust of the old Symantec roots. I am closing this bug, since it is no longer relevant.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.