I was a technical lead for a project involving a) governments and b) lots of income from taxpayers, and I noticed this warning about Symantec certs a while ago from a Qualys scan I ran on the third-party payment website. I told my manager and our client about this several times before being laid off, and I would bet they never did anything about it. I'm wondering how this is affecting them.

When it actually /breaks/ something they'll divert resources to fixing it.

I've received those emails as well. The emails came from our domain registrar. We don't buy certificates from our domain registrar. Adding to the confusion the email refers to Symantec certificates of which we don't have any, I even double checked the certificate chain and Symantec wasn't involved.

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.

I'm curious if you received the same emails I did. We got ours from our cert vendor, so I suppose that's as about as direct as it can get. If your domain registar was crafting their own, then I could see how you might have gotten blindsided. There's always a risk of information loss when the game of telephone comes into play.

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.

This is a good point, and to add to this, some companies don’t take communication channels between the company and their certificate provider seriously. Sometimes the CA is left with the email address and phone number for someone who left the company over a year ago, and if you don’t have a good technical contact, you can spend a lot of time calling around until you find somebody who knows what’s going on with SSL.

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.

Well, a specific example that's going to bite _plenty_ of medium to large sized corporations is that you have a pattern like this:

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 bob@bigcorp.example. 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 bob@bigcorp.example 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.

Oh I know that it's widespread, it happened here; the guy who's job it was to care left and didn't pass on knowledge when he did. It is because there was a a role account assigned to comms about TLS certs that the notices were, well, noticed. I've worked in large orgs where comms are even worse.

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.

Question: with such big news going on for such a long time, how does not even one person -- whether manager or otherwise -- just take 5 seconds to ask if they are prepared for it? It's not like the reporting on this was just in some dark corners of the internet... /some/ people in a given company should have at least heard something was going to happen to Symantec certificates.

Because there are tickets to close before the whistle.

I will add that in many "bigger orgs" they rely on external services/audits to identify certs signed outside of their process and use tools of the trade (like CAA records) to restrict certs being generated willy-nilly. If you are in a large org that does not do this -- raise it to the CSO. The fact that there are rogue certs in an org that may fail because of this CA removal action is the least of the orgs concerns.

Exactly. Just about every organization I've worked for has gone through a consolidation phase where DNS registration and certificate issuance is consolidated and formalized.

You don't have to get very big before these issues surface and cause tons of problems and toil.

Didn't Hotmail have some problem where microsoft took over and forgot to pay for the domain name [0]?

[0] https://whoapi.com/blog/5-all-time-domain-expirations-in-int...

Also, there is a warning in Chrome dev tools console.

I understand the rationale behind all of this, but I would get pissed off if Google sent me an email that basically says "do what we tell you to do or we will take your website offline"

That would be bad. It's not what's happening.

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".

I don't disagree with their existence being a near monopoly at this point.

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.

You mean this roadmap? https://security.googleblog.com/2017/09/chromes-plan-to-dist...

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?

https://www.republicservices.com/ is a site with a non-EV Symantec-branded certificate from August 2017 and it still works in Chrome 69 (and is blocked in Chrome 70 with a NET::ERR_CERT_SYMANTEC_LEGACY error).

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.

Is it possible that you’re using a canary version of Chrome? Check chrome://version/, for me I see version 69 and I can go to https://www.paypal.com/ and see that the Symantec EV cert is still valid, which was issued in 2017. In particular, if you see version 70, I would expect you to get errors visiting PayPal, just like the roadmap says.

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.

This is not my experience -- can you show an example of a site with a cert that has been untrusted early from chrome? They specifically call out the types of certs and their sign dates in the timeline and everything I have seen has matched this timeline. They have, however, had very verbose logging warning in console that the cert on a given site _will be_ distrusted well ahead of time.

Are you sure? Paypal.com's Symantec-issued certificate still works in Chrome, at least on my PC: https://www.paypal.com/

Can confirm here PayPal's Symantec Class 3 EV SSL CA - G3 signed certificate validates in Chrome 68 and 69 but returns NET::ERR_CERT_SYMANTEC_LEGACY on Chrome 70

They really need to update their certificate soon

When I visit paypal and open up the console I see the following warning :

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.

Uh, we used to use them, and switched in June. Our certificates behaved normally. I have no idea what was going on with yours, but clearly "all certificates" were not.

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.

I’m not sure what’s the point of posting this conjecture 20 times without providing any pointers for people to check if it is actually true.

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.