> Root cause: Symantec was willfully disregarding industry regulations by issuing trusted certificates without proper authorization.

Source: https://sslmate.com/certspotter/failures

“Willfully” is the key word here. The business side of running a CA is fundamentally at odds with the security side. A few short-sighted decisions by business-minded managers with their eyes set on profits can completely eviscerate the security side of a company, and it’s possible that nobody remains at Symantec who has the combination of security knowledge + internal political power + will.

There’s also the Trustico fiasco. Trustico revoked 50,000 Symantec-issued certificates in a shockingly bad way. Because policies allowed for certificates with compromised public keys to be revoked, Trustico intentionally compromised the private keys in order to achieve the desired revocation.

https://groups.google.com/forum/#!topic/mozilla.dev.security...

> As one of Symantec's former largest partners - my personal opinion and personal experience is that Symantec is a company that thrives on recklessness and one that I wouldn't trust nor deal with.

You can see more bad behavior here—Symantec is seen as a reckless company, and Trustico (recklessly) cuts ties with Symantec for its business needs. Both actors are bad enough that their relationship reflects poorly on both of them.

I’m sure there are some people who could fix this problem in six months, but I bet they don’t work for Symantec or don’t have the power to do it.

The problem is that they repeatedly mismanaged and violated the BRs.

There’s only so many screw ups you can accept from a CA before you simply can’t trust them to do the right thing. Given that Trust is the basis of the entire CA system there isn’t really an option but to distrust the CA.

Note that multiple CAs have been distrusted in the past, and they were more or less instantaneous distrust. Symantec was a huge CA, and that got them through multiple errors that would have probably resulted in distrust for smaller CAs, and even the final distrust has had something like a years notice.

The base issue is trust, not some technical issue.

They repeatedly violated the trust placed in them. They'd have to fire the entire chain of command that allowed those to happen, retool their processes, and probably post a sizable bond before many folks would give them a second chance.

But really, who needs them? We need fewer registries, or in the alternative many, many, many more.

Sold and DigiCert has been reissuing new certs. Unfortunately they can’t change them for you. Poor operators won’t know until the rug is finally pulled from under them. DigiCert and browser vendors have done a decent job of telegraphing the changes..

Given how wide-spread the issues were, I'm not surprised that they couldn't turn it around within six months, even if they had the will from management to do so (which it isn't clear they did!).

Just to be clear : there is no "fix this issue" because the problem is with certs issued _in_the_past_. The only fix is to re-issue the cert and replace the existing one on servers with the new one. This fwiw is easy to do, if you know you need to do it. But then presumably folks running SSL endpoints already knew they had to keep on top of expiry dates, cipher suites and so on so this is just one extra aspect to watch out for. Explicitly tested and reported via ssllabs, of course.

They've already sold the division. They don't care and probably never did.