This is a really stupid situation all around. To issue a cert for a client (say example.com), the CA sends a random number challenge to the client (say 1234567

This is a really stupid situation all around. To issue a cert for a client (say example.com), the CA sends a random number challenge to the client (say 12345678). The client then responds by making a DNS record for _12345678.example.com but due to a bug, DigiCert accepted 12345678.example.com instead. Apparently there's a rule that says any such certs must be considered mis-issued and must be revoked by the issuing CA within 24 hours. The CA talked to some clients who said it would be too much trouble to replace their cert on such short notice. One of those clients filed a lawsuit with the court system, which responded by issuing a restraining order telling the CA not to revoke the cert. First of all, this is a dumb reason to revoke certs. It's difficult to imagine a situation where any of the mis-issued certificates correspond to an actual compromise of somebody's website by a bad actor. But we can perhaps give the benefit of the doubt: I think the intent here is a fail-safe procedure is implemented so revocation is triggered by a broad class of circumstances, which is constructed so that it's easy to check. Second, this is a dumb thing for a website to file a lawsuit about. If you have to replace the cert on your website because your CA made a booboo, the engineer-hours needed to change out your new cert are far less than the lawyer-hours needed to try to work through the court system. Third, it's dumb for people to blame DigiCert for the TRO. The TRO was filed by a service provider called Alegeus. If DigiCert doesn't follow the TRO, they'll be in contempt of court. Theoretically, a DigiCert employee who presses the "Revoke" button at this point could be sent to jail for it! Fourth, a certificate revocation is basically a signed message that says "News Flash: I think this certificate might not correspond to this website." A court preventing the publication of such a message is equivalent to a court preventing a newspaper from publishing an article. This is called "prior restraint" and it has a high bar in the US. Prior restraint analysis was not performed by the court before the TRO was issued. I think the court violated DigiCert's due process rights (by not analyzing whether prior restraint applies) and DigiCert's free speech rights (by not denying the TRO as it would be prior restraint). (That browsers have a hair-trigger response to certain kinds of news flashes and will take drastic action isn't the fault of the publisher of the news.) Fifth, it's obvious there ought to be some technical means to prevent this kind of situation in the future: What is the protocol to handle a case of a CA refusing (or court-ordered not to) revoke certs known to be compromised? I think you need to have a system that allows a quorum of CA's not including the issuing CA to speedily revoke certificates, or an entire CA. (A public real-time quorum of a dynamic set of validators passing messages they want to reach consensus on: Perhaps this is a good use case for a blockchain?) Of course you also have to deal with the problem of, what if the next TRO targets the entire validator set? You'd need to be sure those participants are jurisdictionally diverse (or anonymous) so it would be difficult for a single entity to compromise the entire system at once.