DigiCert gives unlucky folks 24 hours to replace doomed certificates after code blunder DigiCert has given unlucky customers 24 hours to replace their SSL/TLS security certificates it previously issued them – due to a five-year-old blunder in its backend software. After that period, the digital certs – which are used for providing encrypted HTTPS connections for websites among other things – will be revoked and …
And browsers (the most common clients) trust far too many CAs already.
PKIX has always been a problem. It will be a problem for as long as it's being used. There's no obvious viable alternative. (No, web3 is neither viable, nor a reasonable alternative.)
These are the sorts of things you do in testing... and they've been firing those guys for years--wholesale. And surprise, the machine breaks when you don't do enough testing on the mechanisms that make it go.
Features are cool and all, but we need folks to test what they think they are already doing... all the time. This looks like testing by inspection... they need to automate this and regression test their code daily. (and not fire the person that maintains that code!)
Screw DigiCert. They amended their ToS to say any money on account would revert to them on a certain day. We called them up and they reassured us that would not happen. Sure enough, on that date, they seized over 4K of our cash. Poof, gone!
Could not get any account managers on the line, emails were bouncing, heard multiple people had been laid off and no one knew what was happening. Eventually got credit, (they said they were being 'generous') but had to use the credit within 30 days and the credit only applied to existing certs that were expiring in next 90 days. Fortunately, we had one. Took weeks of persistent calls / emails that they ghosted us on.
Screw em.
Aside from Let's Encrypt (which has always run with minimal staffing and as much automation as possible), the major CAs seem to be cutting costs viciously. That appears to be what happened to Entrust — they cut staff so much that they couldn't follow CA/BF requirements, and couldn't even respond coherently when Mozilla and Google complained. When Google dropped them from the trust collection, they finally caved and hired some expertise back in.
Margins on the CA business seem to be very thin, particularly once everyone clued in to the fact that pricey EV certs are a waste of money for most purposes, and the CSWG's attempt to mandate EV certs for code signing fell through. (Microsoft does require an EV certificate for kernel-mode driver signing, but not for Authenticode signing of user-mode code, and outside Windows code signing is a mishmash of varying requirements.)
Meanwhile, ACME-based free DV certificates for websites, once popularized by Let's Encrypt, hollowed out the HTTPS certificate business. Many organizations have their own in-house CA for internal TLS and other uses. And personal certificates for S/MIME and the like never caught on widely.
The CAB rules requiring revoking all the certs in 24hrs is such a disproportionate response to this. It's going to cause an immense amount of flat out work for all the admins of sites and cause untold amounts of outages and lost transactions for users of these certs. This is different to the CrowdStrike cockup because they haven't accidentally revoked all the certs, the 24hr requirement could be longer.
Shouting about how certificates are the backbone of the internet and there must be no tolerance for error isn't helpful. Why can't there be a more proportionate response measured against the actual risk that is caused by the error? Sure, if they've issued certs with *no* domain validation then revoke them all, but for something like this really they could pay a fine to someone and revoke the certs in 14 days or something which would give everyone a lot more time to resolve this.
I pity all the admins with these certs - it's them that is being punished by this excessive response.
The thing is, the rules are the rules. Security is important, CAs cannot just make it up as they go along. If CAs were allowed to do that, then they would make choices that increase their profits but reduce security on the Internet for all of us. We know this from how CAs behaved before the CAB Forum rules existed.
If you want a longer duration, then you can ask CAB Forum to change the rules for handling future incidents. Including clear rules for when a longer duration is allowed and when it's not. Writing such rules is really hard.
However, for now, CAs must follow the rules as written. CAs that break the rules can be removed from web browsers, which is basically a death sentence - all their certificates stop working.
I'd also note that the problems caused to customers, are because they chose a CA vendor who wasn't following the rules. (Although they didn't know that). If this causes some customers to seek a refund, or switch to a different CA, then that is the market punishing the CA vendor for not following the rules.
> The thing is, the rules are the rules. Security is important, CAs cannot just make it up as they go along. If CAs were allowed to do that, then they would make choices that increase their profits but reduce security on the Internet for all of us. We know this from how CAs behaved before the CAB Forum rules existed.
Related to this, Deutsche Telekom's Root CA have been trying to use "it's vacation time" and "personal reasons" for delays in meeting CAB forum rules regarding revoking misissued certs and they've been lambasted for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1877388
Exactly. The CA/BF doesn't permit exceptions because if they did, everyone would ask for an exception, and the CA/BF would be under constant pressure to grant them. And then the CA/BF Basic Requirements would just be a bunch of suggestions that CAs would ignore, and PKIX would be even worse than it currently is.
Hammer meet nail !
It's a competitive industry. Those that can automate and scale will survive, those that find a niche that allows them to make a profit in that niche will survive, eventually the rest will fail.
Meanwhile, the big driver is that majority of customers who think "price" and "value" are the same thing - so will always buy from the cheapest without any thought as to what implications that might have.
"...how CAs behaved before the CAB Forum rules existed."
Very good point.
"...the market punishing the CA vendor for not following the rules."
Financial punishment. The only kind that they understand, the only kind that will have any effect.
And it isn't just CA vendors. It's the whole steaming pile.
Our new architecture redirected all validation through separate services instead of the legacy monolithic code structure. The code adding an underscore prefix was removed from CertCentral and added to some paths in the updated system.
The underscore prefix addition was not separated into a distinct service.
I see they have an Enterprise Architect - how did he miss the UnderscoreAtStartOfSubDomainService?
Well, yes, that would have been simpler, but on basically any other descriptor (better, more likely to actually get used, more functional, less frustrating, less corrupt, ...) it would have come out worse. Perhaps the only simpler method that would be anywhere close to secure is if certificates were granted by domain registries, mainly because a lot of certificates are granted because the person requesting them has DNS control. Even then, there are reasons to prefer something else.
> This will affect "approximately 0.4 percent of the applicable domain validations we have in effect,
> " the certificate authority said in a July 29 advisory. The Register has asked exactly how many
> domains this represents, and we'll let you know if DigiCert can come up with a number.
https://crt.sh/cert-populations -> 19,895,486 * .004 = around 80K
So essentially somebody decided to fix what wasn't broken (or was there a scaling problem?) and do so in the most complex way they could think of. And then fail to review something which was extremely critical.
Let me guess. The developer of the original code was someone with a thorough grounding in the intricacies of certificate generation but was no longer with the company because they wanted younger, digital native, developers to work on this exciting new project.
The choice of just a leading underscore to avoid the chance of clashing with existing records seems a bit silly anyway. Why not e.g. digicertdcv_123456789.example.com or similar, so (a) there's even less chance that someone would have created any such record for any other purpose, (b) it's immediately obvious what that record was for when you later look at the DNS zone, and (c) the lack of the prefix would be far more visually obvious than just an underscore missing?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
