Digicert pauses mass certificate revocation due to legal action from customer
bugzilla.mozilla.org
bugzilla.mozilla.org
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.
Staggered rollout sucks (if discussing TLS revocations) or rocks (if discussing crowdstrike), right?
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?
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.
Managing certificates for 3rd party domains through DNS validation is inherently going to be slow because you're at the mercy of those clients, their IT teams and change-control process.
If the only "correct" way is to have fully automatic certificate provisioning (like via HTTP challenge) so that certificates can be reliably replaced within 24 hours of an incident, then the CA/B Forum should make a rule to enforce that. As it is, they allow up to a year on certificates, which sends the opposite message.
Moreover, with regard to risk, you're assuming a priori that PKI-related risks trump all other risks, but that simply does not seem logical: the risk of an outage depends on the sector and the difference in risk between a 1 day and 5 day revocation period, for example, may well be less than the risk assigned to the outage.
If this isn't the case, then the CA/B forum needs to reduce the maximum lifetime of certificates to 1 day so we can be sure all parties are able to meet the revocation window.
> 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.