As far as I can tell, this issue would be a problem where all of the following conditions are met:
1. Tenants are allowed to create arbitrary subdomains with arbitrary CNAME values
2. Tenants are not authorized to act on behalf of the TLD directly, only on their respective subdomain
3. Tenants are ostensibly prevented from TLD cert issuance by being explicitly blocked from creating subdomains that start with underscores
For most entities these conditions probably do not hold true anyway. But it could conceivably apply to certain free/dynamic dns providers, for example afraid.org and noip both allow arbitrary CNAMEs (though I checked my noip account and it wouldn't work anyway because of length limits on subdomains).
I would guess that in act fact there are very few entities in existence for which this actually represents a potential threat against them, since it requires a very specific delineation of zone authorizations, but there might be a few.
For most of Alegeus customers I doubt any of this applies, though, they're probably lucky to know their GoDaddy login to add any sort of DNS record, let alone have a whole system in place for less privileged users to create arbitrary CNAME records subject to controls over the use of underscores.
Trying to deploy SaaS apps for customers it sometimes takes 3-4 weeks to get them to make any DNS changes, then at the last minute they CC us into an email with SquareSpace support for some reason (their DNS is on Cloudflare...)
I think the issue is less with SaaS vendors doing cert pinning and more that many SaaS vendors offering deploying on customer domains often rely on those same customers to make the DNS changes for validation, and whenever you introduce another party like that it's exponentially more difficult to actually get things done in a timely matter.
IMO they should just use HTTP challenges to avoid this whole thing, but it's a pretty common pattern I see with a lot of SaaS vendors, even major fintechs.
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.
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?
1. Tenants are allowed to create arbitrary subdomains with arbitrary CNAME values 2. Tenants are not authorized to act on behalf of the TLD directly, only on their respective subdomain 3. Tenants are ostensibly prevented from TLD cert issuance by being explicitly blocked from creating subdomains that start with underscores
For most entities these conditions probably do not hold true anyway. But it could conceivably apply to certain free/dynamic dns providers, for example afraid.org and noip both allow arbitrary CNAMEs (though I checked my noip account and it wouldn't work anyway because of length limits on subdomains).
I would guess that in act fact there are very few entities in existence for which this actually represents a potential threat against them, since it requires a very specific delineation of zone authorizations, but there might be a few.
For most of Alegeus customers I doubt any of this applies, though, they're probably lucky to know their GoDaddy login to add any sort of DNS record, let alone have a whole system in place for less privileged users to create arbitrary CNAME records subject to controls over the use of underscores.