1. Typical browsing to www.BankOfAmerica.com got me an ERR_CERT_AUTHORITY_INVALID error. This was with an up-to-date production version of Google Chrome for Mac.
  2. I tried with Safari, and got the same result.
  3. The certificate is good until 2016, so it doesn't appear to be an expiration issue.
  4. It appears that the authority Symantec Class 3 EV SSL CA - G3 is deemed invalid. Trying to browse to twitter.com as well as https://my.symantec.com, brings up the same warning. HTTPS connections to other sites (with GeoTrust, Google and other CAs) work fine.
  5. OTOH, running an SSL checker tool (at sslshopper.com) shows that everything is in order.

Can you reproduce the above behavior? Do you get SSL warnings in your browser(s) at sites like bankofamerica.com and twitter?

Can you explain what is happening?

As for my level of expertise, note that I'm not a dev but an end-user.

Update: - Mac OS X browsers get the trusted root CAs from the OS, and this started right after I installed an Apple security update. So confirming the behavior would likely require OS X 10.8.5 with latest security patches.

  • The mistrust starts with the root CA, "VeriSign Class 3 Public Primary Certification Authority - G5". I can see that a CA with this exact name appears in the OS (Mac's "Keychain" database) as a valid and trusted cert, but its serial number (and therefore SHA-1 and MD5 fingerprints) are completely different form what the browsers see.

  • I wonder, therefore, if Apple's latest security patch broke a good chunk of the web. Ironically, it also broke Apple's OS Software Update because they also rely on VeriSign. I'll sniff around the Apple forums, too.

  • It's worth noting that Chrome says both "the certificate is not trusted" and "your connection is encrypted with obsolete cryptography".

  • This isn't what I was planning to do on Sunday morning... but AFAIK the easiest way to break SSL/TLS is for me as a user to say "eh, I'll just add this CA". When it has to do with my bank and a third of the web, I proceed with caution.

  • I am not seeing the issues you raise. Same CA. Chrome on Mac.
    – schroeder
    Apr 12 '15 at 16:21
  • can't reproduce. firefox 37.0.1 on windows. Test results for the bank. The issues which may be possible are RC4 support, no forward secrecy or SHA-1 on intermediate/server certificate
    – SEJPM
    Apr 12 '15 at 16:33
  • 1
    chrome relies on the OS to supply certificates. Firefox keeps it's own database of root certificates.
    – SEJPM
    Apr 12 '15 at 16:50

Solved. The problem was indeed triggered by installing Apple Mavericks/ML Security Update 2015-004. As mentioned in this Apple release note, it included updates to the certificate trust policy. There was a duplicate certificate installed (with a wrong serial no.), removing it fixed the problem.

The serial number for the cert as published by Apple matched what was installed in the System cert repository, but there was a "VeriSign Class 3 Public Primary Certification Authority - G5" in the "Login" repository. Once I deleted it, everything got back to normal.

There is still some mystery as to why the certificate appeared in the Login repository in the first place, especially since as I just found out, several other people experienced the same exact problem: https://discussions.apple.com/thread/6984765 https://apple.stackexchange.com/questions/180570/invalid-certificate-after-security-update-2015-004-in-mavericks

  • 2
    Whew! Thanks for sharing this. I knew it had something to do with a certificate in my account's keychain after I found out it doesn't happen to an account I newly created on the same Mac. Also narrowed it down to websites using Verisign certificates. Good job, self.
    – radj
    Apr 21 '15 at 5:21
  • 1
    Insane that this also breaks apple's own app store. I'd hate to be a non technical user that this happened to. Thanks for the fix!
    – Jack Casey
    May 15 '15 at 13:14
  • 3
    Worse, this breaks the link to Apple's own discussion page!
    – Joe
    May 15 '15 at 13:20
  • 1
    Thanks a lot! I've lost 2 hours to solve this problem, since a lot of sites were unreachable to look for an explanation/solution! :-/ Jun 1 '15 at 16:58
  • 1
    @AlexSpurling Open Keychain Access. Unlock it with your admin password (see the padlock on the top left). Go to "Login" in "Keychains" pane. Delete the two verisign certificates.
    – thesmart
    Aug 29 '15 at 23:21

There are two chains up to Verisign Class 3 G5. At one point, Verisign was chaining to that root via a longer chain, and some OSes were confused when walking up the AIA versus walking up the chain handed by the server to the client.

This sounds like a significant problem, especially since the combined Symantec properties are the largest tier 1 CAs.

I do not have a Mac, so I was not able to replicate the results. I can confirm that with Safari and Google Chrome in IOS, and with SSL Detective in IOS, I got the expected (good) results.

You are right that adding a certificate as trusted without knowing its provenance and trustworthiness is very dangerous. Good call!

Not the answer you're looking for? Browse other questions tagged or ask your own question.