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