If someone was to issue a certificate after compromising my DNS or host, how could I revoke the certificate that was issued if it was issued for multiple domains where some domains were not under my control?
As an example, a certificate was generated that covered two domains (example.com and example.org). I have control over over one of those domains (example.com), but not the other (example.org). How can I revoke this certificate?
Once you’ve validated control of all the domain names in the certificate you want to revoke, you can download the certificate from crt.sh, then proceed to revoke the certificate as if you had issued it
Seems to require you to verify you have control of all domains which wouldn't always be possible.
Revocations should be done via API whenever possible. I'm not actually sure offhand what the answer to your question about two names is, but I will investigate.
Requests for revocation may also be done via email, though that may take longer. Please see our CPS for details: ISRG CPS v4.1 - Let's Encrypt
Indeed, if you control all names, you can revoke via the API. If you control fewer than all names, you have to do it via email.
Relatedly, it's risky for a hosting provider to group together names from unrelated customers on a single certificate, since any one of those customers could change their DNS and request the whole certificate be revoked. A lot of hosting providers avoid that scenario for that reason.
Well.. and what would happen if the API were used for revocation in a situation as submitted by OP? Would it serve an error? And would that error include information about how to request revocation via email? Would the requestor be required to submit the account key along with the request?
My understanding, from previous discussion, for the case of key compromise specifically, is that the request needs to be by API and not by email. I guess in the initial post it may depend on exactly what "compromising my DNS or host" means, where like changing the DNS servers listed by the domain registrar but not having access to the original server might be able to get revoked by email, but if an attacker has access to the server with the private key itself then Let's Encrypt isn't obligated to revoke based on an email report? This all is really confusing to me.
In terms of revoking based on holding "all" the names or "any" name, the RFC 8555 spec seems to be saying in section 7.6 that "an account that holds authorizations for all of the identifiers in the certificate" "MUST" be allowed to revoke, but that an implementation might allow other accounts to revoke as well (such as one that just had some of the authorizations for the identifiers).
Thank you all for you inputs. This question is only hypothetical, thankfully!
What I understand is if a malicious party managed to get control of DNS or was able to upload a file on the host, they could quite easily generate a Let's Encrypt certificate that is only able to be revoked through email, thus making the revocation process lengthier and manual.
Is there any security benefit or other reason why revocation requests through the API shouldn't be accepted if control can be verified for any (but not all) domains listed on the certificate?
While we could support it via API, there’s some concern around it being a potential footgun. So automated revocation requires confirming control over all the affected domains.
There is potential abuse either way we go here, so we err on having a human in the loop on our end.
Your questions are interesting. So, don't take this as dismissive.
But, if your DNS or server got compromised someone could wreak all kinds of havoc. Rerouting DNS to other servers, getting certs simultaneously from multiple Certificate Authorities (not just LE), planting code in the server, using it to crawl elsewhere, and so on. Is the protocol for revoking a cert the biggest concern in this situation?
I get it if you are doing a deep dive into this specific topic. But, thought I'd interject anyway.
Cheers
Probably not the biggest concern, but I praise @Securable for at least considering the possibility of having a rogue certificate out there, which should, I think, be part of the work-up for having a host or DNS compromised. And praise certificate transparancy logs
