[alex34778]

It 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?

[olliej]

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

[alex34778]

Regarding "the right thing overall would be them running their services correctly", what was it that they did incorrectly?

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.

[unixfg]

Even better Digicert is using the order as cover to give all of their customers extra time.