4 ms·
Digicert pauses mass certificate revocation due to legal action from customer
- gnabgib 2y agoDiscussion (119 points, 24 hours ago, 27 comments) https://news.ycombinator.com/item?id=41104504 https://news.ycombinator.com/item?id=41104504
- frakkingcylons 2y agoThe key excerpts from Digicert: > While we have deployed automation with several willing customers, the reality is that many large organizations cannot reissue and deploy new certificates everywhere in time. We note that other customers have also initiated legal action against us to block revocation. > Temporary Restraining Orders (TROs) are designed to be temporary while the facts are figured out. Courts routinely grant these to prevent material harm. TROs are legally binding. We did receive a TRO in connection with this revocation.
- deleted 2y ago[deleted]
- olliej 2y agoAlegeus Technologies LLC: https://www.courtlistener.com/docket/68995396/alegeus-technologies-llc-v-digicert/ https://www.courtlistener.com/docket/68995396/alegeus-techno... It looks like a healthcare provider, so exactly the kind of company you would want to have shitty IT and security infrastructure. A++ work. Absolutely stellar.
- Arnt 2y agoStaggered rollout, by any chance? Staggered rollout sucks (if discussing TLS revocations) or rocks (if discussing crowdstrike), right?
- lol768 2y agoIf your monitoring is good, you can still stagger it over a number of hours instead of days.
- Arnt 2y agoI had a customer with excellent monitoring and one daily peak per market, say six or eight hours of overall peak. Any rollout that started after a peak and completed before the next wasn't really staggered.
- alex34778 2y agoIt looks that they provide SaaS solutions with FQDNs on client domains, so you have algeus.client1.com or algeus.client2.com, etc. The problem then is that they'd have to coordinate with IT at each of those clients to complete DNS validation for certificate issuance, which isn't so much a problem when expirations or reissuance needs are staggered and predictable, but in cases like this the ONLY realistic way to have avoided this scenario would have been to use a different issuance method in the first place (like via HTTP validation). I don't know that I'd call "manual DNS validation of certificates on behalf of clients deploying your SaaS app" inherently a shitty IT practice per se, I think there's better options but only in situations like this does it pose a real challenge. Regarding Algeus, I'll be controversial and say they're doing the right thing overall: Given the nature of their clientele and the certain negative impact on healthcare services caused by abrupt revocation of those certificates, and given the actual tangible risk (use by malicious parties of unauthorized certificates) is arguably N/A as we know now by legal filing they did in fact authorize the certificates, using the law as a tool to avoid a major impacts is what they SHOULD do for their clients. They're not negatively impacting the security of anyone else because they the TRO only affects Algeus anyway, and their clients shouldn't be ultimately on the hook to such a degree for DigiCert's screw-up. tl;dr if the TRO gives Algeus an extra several days to avoid major healthcare-related service impacts, what is the downside? Is data going to get exfiltrated over this? What threat actor could even theoretically take advantage of this knowledge?
- unixfg 2y agoEven better Digicert is using the order as cover to give all of their customers extra time.
- olliej 2y agoThe point is not "this time there's no risk", the point is basic PKI safety means you need to be able to handle certificate revocation immediately. If you can't handle it today when there's "no risk", you also can't handle it when it's actually compromised. Algeus, are not doing the right thing: the right thing overall would be them running their services correctly, and being able to do basic service maintenance correctly, like having a fast turn around for revocation. If they did not want to be subject to basic requirements of using publicly trusted certificates, they should have been running their own root that does not impact the security of PKI for everyone else. Using a lawsuit to avoid their responsibility simply means next time this happens they'll do the same thing.