I disagree, based on my own personal experience. This has been coming for a while, with plenty of forewarning.
My employer uses certificates from one of Symantec's brands. Last year, we began to get notices that Chrome et. al. would be distrusting the certificates issued from the old Symantec root this year, and that we would need to claim our free replacements issued from the new trust root that is replacing Symantec's. And it's not been just one notice, we've been getting them regularly. And in addition to the automatic form emails, the sales rep assigned our account personally reached out to us to make sure we were getting this taken care of. We are not a large company, either; we have less than 100 employees. DigiCert is taking this transition seriously.
So IMO, if someone gets blindsided by their website breaking because of the Symantec root distrust, then they have only laziness and/or incompetence to blame, whether it's their own, or that of their website operator. Those who's job it is to make sure that doesn't happen have been warning about it for nearly a year now.
So, for the longest time I assumed the emails were a phishing scam and disregarded them. Only today when I tried testing with Firefox did I realize that several certificate brands were handled by Symantec and that YES I was affected.
So, yes there has been plenty of forewarning, but yet was surprised today.
When I first started looking at this myself, I was surprised at just how many TLS cert brands Symantec held: damn near half of them.
That said, anyone who doesn’t have a big enough IT department to properly manage a certificate should be paying someone else to do it, it’s just that there are a lot of ways that contact information goes stale and documentation gets lost.
Big Corp's Division Z need a cert for their new web site https://www.division-z.example/ and so Bob buys it with his corporate credit card, and gives as contact details firstname.lastname@example.org. He buys, let's say, a Verisign SSL certificate.
Six months later Bob leaves to work at some other company. Bob's email is probably now blackholes, or maybe it's going into a never read "Bob's emails" folder of Bob's previous manager.
DigiCert, being conscientious, send email to email@example.com warning that Verisign certs were a Symantec product (Symantec bought the brand and CA keys from VeriSign, or maybe from some other operator which in turn bought them from VeriSign, long ago)
But that email will either get delivered and silently go unread, or it'll bounce, but leaving no sign it needs to go to anybody else in particular instead of Bob.
Months later the cert stops working, as scheduled, and Steve, who is now responsible for this site, thinks DigiCert is somehow at fault. How were DigiCert supposed to guess that they needed to contact Steve?
Role accounts are the Right Thing™ so that the email goes to the person whose job is to care about the subject, not to some random individual who may not even work there any more. But they aren't enough, you also need mechanisms in place that ensure it's somebody's job to care, otherwise the role account emails just go in a folder and are never read.
So, sure, "incompetence" and not DigiCert's fault, nor Mozilla's but it's very widespread and you should be astonished if you work somewhere that does NOT have this problem in some form (maybe you have SSL certs locked down, but it turns out nobody is making sure you pay the electricity bills for outlying offices, or there's not actually anybody in charge of making sure payroll happens...)
Returning to SSL/TLS certificates though, any medium sized or larger organisation ought to be paying attention to the Certificate Transparency system. To do this properly you need to know all the eTLD+1s your organisation controls (this may be a non-starter in really sprawling organisations, but that's already a problem that needs fixing) but then you can know exactly what certificates exist for your names, who issued them, and why.
In most cases you don't _want_ Bob buying certificates on the company credit card anyway. Not just because it's cost inefficient (ignoring Let's Encrypt bigger organisations can get a commercial CA to cut them a deal for a fixed price or a steep discount per cert in exchange for doing one big Purchase Order rather than hundreds of credit card payments) but because it's organisationally a problem, it has security consequences, and it's another asset you're probably not tracking properly as a business.
But my point was that this is not some reckless sudden move by the browsers or DigiCert. In my observation, they have been earnestly and diligently working in good faith so people don't get bit by the transition.
You don't have to get very big before these issues surface and cause tons of problems and toil.
What's happening is "update your security on the thing that you have already got security on, or else at least two of the most popular browsers will mark it as insecure; also, you will lose points in our search engine".
That said, slippery slopes aren't usually the strongest places from which to wage an argument. We're not talking about what they might do next. We're talking about this specific instance.
Google announced in October 2017 that they will block Symantec certificates in October 2018. Leaving a year to upgrade, fairly reasonable considering most certificates must be renewed early.
However, Chrome blacklisted Symantec since April 2018, 6 months early. Taking a lot of people by surprise.
That plan clearly states that all Symantec-issued certificates with a not-before date before June 1, 2016 would be distrusted in April. Is that not what happened?
www.McDonalds.com is another site with a non-EV certificate that will be blocked by Chrome 70, albeit with the GeoTrust brand instead of Symantec directly. Surely McDonalds has a large enough IT division to have noticed and updated by now if Chrome had been blocking their site since April.
Personally I think it’s bad practice to have a cert last more than a year in the first place, due to a number of both operational concerns and security concerns, but that is neither here nor there.
They really need to update their certificate soon
If it were actually allowed, I would upload some of the certificates and write a blog post to show you.
Paypal has an EV, I don't have EV. Maybe these were not blacklisted. The rest was.
The SSL certificate used to load resources from https://www.paypalobjects.com will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information.
We also received I don't know how many notifications of the impending changes. They were plentiful enough that it got annoying. Assuming one actually has valid email addresses to which attention is paid for these communications.
Nobody on the Internet appears to have noticed but you.
http://www.googblogs.com/distrust-of-the-symantec-pki-immedi... The timeline of alpha and beta releases may have confused you.
I wonder what the root problem was? They didn't care, they didn't think anyone would do anything or they are just a large sloppy corporate who can't run a group properly?
Did Symantec's shareholders get the board responsible for this... replaced? Did they at least get a big cut in their wages given that they're apparently no good at their jobs? Nope.
The Web PKI in my not at all humble opinion is doing a better job of handling this problem today than, for example, many actual bona fide regulators. When Symantec kept trying to offer up little bits and pieces (e.g. let's wind up this lucrative Korean partnership programme we've secretly been running for years that had no effective oversight...) they were told it wasn't enough.
In the end this distrust that you're seeing now was mandatory but it was not intended as a "death sentence" for the Symantec CA function pe se. Symantec were told to go find somebody whose leadership we could trust, and let the trustworthy outfit physically run the CA (with Symantec's brands) while Symantec got their shit together and tried again in a year or two. In the process of negotiating such a deal with DigiCert Symantec instead sold their entire CA business to them, which everybody seems to have (in some cases grudgingly) accepted is a good enough outcome.
DigiCert did a better than might be expected job of this from a technical point of view, and I hope that it works for them commercially as a result.
[Edited for clarity]
They might understand how certificates work but that doesn’t mean they know how to set up an organization with the right incentives to do it correctly.
For users with Certificate Transparency checking (basically, Chrome) any dubious MITM certificates would have to be logged to show up as trusted public certificates. So there would not only be a smoking gun in the sense of the MITM cert being sent to all browsers that connected, it would be permanently preserved.
In addition Mozilla has an ongoing programme of trying to discover all the intermediate CAs that actually exist, partly because this occasions them to find various intermediates that probably _shouldn't_ exist and get them blacklisted. So this means if a intermediate exists and then you say you didn't realise it was being abused, you have the problem of explaining why you didn't report that it exists. If you say it's because you didn't know, it makes things worse - like if you say you didn't tell the IRS about the money because you got it when committing an armed robbery you weren't previously in the frame for - because that means your CA root was used to sign things you don't have a record of, and so obviously we can't trust your root any more...
EDIT: Its also worth mentioning that this isn't just limited Symantec certs but also will include GeoTrust, thawte, & VeriSign certs. Symantec's cert business has now been taken over by DigiCert so there is a means for valid reassurance.
EDIT2: Also it will effect RapidSSL. Totally forgot about them.
The limited distrust (for older certs issued prior to June 2016) was activated in Firefox 60 and Chrome 66 much earlier this year.
Google blacklisted ALL Symantec certificates since Chrome 66, in April. The roadmap announced the change for October but they did it 6 months earlier, ignoring their own roadmap.
As the OP says, organizations using Symantec have already been hit very hard, by surprise.
Paypal.com is still operating with a Symantec signed cert - issued by "Symantec Class 3 EV SSL CA - G3". Works fine in Chrome 68. (and not in Firefox with the security.pki.distrust_ca_policy override set)
"The SSL certificate used to load resources from https://(domain) will be distrusted in M70. Once distrusted, users will be prevented from loading these resources. See https://g.co/chrome/symantecpkicerts for more information."
Everything was being done in 2 waves. First wave was Chrome 66, second wave is Chrome 70. See Google's link above for the specifics.
Source: Chrome's own warnings and that I work for a business that deals heavily in SSL sales.
> In advance of removing all trust for Symantec-issued certificates in Firefox 63, a preference was added that allows users to distrust certificates issued by Symantec. To use this preference, go to about:config in the address bar and set the preference "security.pki.distrust_ca_policy" to 2.
Imagine, for instance, that at some point, LE is the only trusted CA for code-signing. If its root key gets compromised for some reason, how are we supposed to move to a new CA if the auto-updaters cannot trust the old CA anymore?
Do you shard across 20 nations? If so, you have to contend with 20 intelligence agencies. It might make more sense to keep all the eggs in one basket, and have new baskets ready to go if a canary triggers.
I was aware of the Symantec issue and checked my own certs and didn't see their name, but skimming the article I noticed RapidSSL and thought I'd double check and sure enough my certs are about to become bogus.
It would be great if Mozilla would include some wording that instills alarm in site owners about how the site’s information, not just the user’s, is at risk.
For example, most non-malicious site owners probably would not want maliciously altered content served from or made to appear as though it came from their site. Yet most of them are, I suspect, unaware that this is a danger when their site does not use TLS.
It would be great to see Mozilla take this chance to highlight this danger so that the people most in a position to make changes would become aware of this additional good reason to do so.
I'd expect the reseller to inform the buyer about the distrust of these certificates. The SSL reseller we use informed us before April this year.
Here is a better model. You normally register your company with the local government corporate registration authority. The local government knows who this company is, who the corporate registrars are.
One should use a digital ID card to apply to register a company. The founders sign the registration of the company with their personal digital ID. The company is then registered. To apply for a domain name for a company should be digitally signed. The registration government authority should handle certificate of authentic not foreign CA registrars.
All corporations should use Government CAs all other types of certificates can then be issued by Lets Encrypt having proper DNS validation in place should help there too.
All else is broken security by design.
You must be from Estonia. Or on crack. I'm guessing Estonia.
A lifetime of experience has convinced me that we will have hoverboards, hell, self-flying hoverboards, before such a scheme becomes the universal norm.
“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.
> 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.
Well, as we're seeing here, they can only be out of phase to a certain degree before both suffer.
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.
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.
PayPal is a diehard Symantec company and will not abandon anything Symantec related until it is absolutely forced to.
I was getting frustrated because I could not visit Paypal (and Ebay) with Firefox nightly, because thy still use the old Symantec TLS certificates. I wonder whether there is _any_ major party that should be more concerned with their certificates than Paypal.
But, we run root certs from DigiCert with the rest of the chain provided by RapidSSL. However, I have not received any depreciation warnings via email or any notification in the console output on these sites.
Is there a utility available to "check" our sites, in the same way vendors provide utilities to verify your cert installations? Or should I assume that our stack is going to get caught up in this, and move to find alternative certs now?
Apple are yet to state when they will perform the final, total distrust, but it is planned: https://support.apple.com/en-gb/HT208860
Two, the method for update shown here is to upgrade your browser. Not everyone can upgrade their browser. Corporations often lock down browser updates, and take a very long time to upgrade. Sure, it's fine for you to say "that's the corporation's fault, too bad for them!" but the users of those companies still have to suffer in the meanwhile - to say nothing of vendored smartphone OSes with slow updates...
The other problem with upgrading is legacy computers run very old browsers. I don't know if you've tried to browse the web on an old computer with a new browser, but here's a secret: it doesn't work. New browsers have so many "advancements" that they bloat and crawl on older machines. So effectively, the means of being able to use the internet requires you to buy a new machine.
If operating systems immediately shipped patched CA lists, and browsers immediately used them, that would patch the legacy browsers. But it would not prevent sites from immediately breaking. So no matter what, either we wait forever to dis-trust certs, or we break sites.
Clearly we need an option C that will allow site owners to upgrade their keys immediately and without issue, and users to update their CA lists immediately and without issue. ACME is a good start, but it too has issues that need to be solved.
In addition, the whole idea of trusting hundreds of root certs to sign for every domain is just crazy. We need a method to sign certs only by the organization who actually has responsibility for ensuring the ownership of the domain: the registrar.
CAs are a great "hack" because they allow browsers to verify certs of sites without ever putting any onus on the registrar, but they also have a wacky "trust" model. Any of hundreds of organizations can verify who controls the IP space of a domain, one time, and issue a magical assurance of this, which is trusted until the assurance expires in several years. This can be overridden at any time, and it has nothing to do with who actually controls the domain, which is the registrar and the user who registered it. All the current system really verifies is who controlled the DNS at one time, which is merely pointed to by the registrar, and can be hacked independently of the registrar, meaning there are extra attack vectors.
Yes, lots of little extra "hacks" have been added as stop-gaps, like CAA, and Certificate Transparency, the now-defunct HPKP, and the future implementation of cert issuers verifying the DNS and host integrity from multiple ASNs. But these are just to keep the status quo limping on, and ignore the unnecessary risks the current design imposes. We need innovation and better design, not hacks.
Moving on past that, I think you've hit the nail on the head. CAs are about having a root for tree of trust. CAA and DANE are about ensuring that. I'm very curious how you imagine an improved, innovative solution to assuring trust!
I've seen proposals like Namecoin, which are innovative but fail the test of being improved.
> debt-based economy
What do any of those things have anything to do with Symantec certificates being distrusted?
The message screenshotted in the article is a message to the website visitor, not to the domain owner. And not going out of their way to shame Symantec to every visitor to a site with a Symantec cert is probably a decent policy. Even without their cert business, Symantec is a big player that the browser vendors will have to work with in the future.
Chrome announced the depreciation for October but they didn't stick to their own roadmap and blacklisted Symantec since April instead (Chrome 66 release). https://security.googleblog.com/2018/03/distrust-of-symantec...
We had a bunch of RapidSSL certs in-use internally, and were rather pokey in replacing them since they were less-critical internal certs. Everything with the deprecation warnings were exactly as expected and announced.
I follow Mozilla's dev Security list and the CAB Forum mailing lists fairly regularly, can't find any discussions about Google deviating from their announced plan.