How do I revoke a certificate if I have neither the account key nor the private key to the certificate? I can prove server control, but running letsencrypt revoke -d student.andover.edu --cert-path revoke.pem results in:
The client lacks sufficient authorization :: Revocation request must be signed by private key of cert to be revoked, or by the account key of the account that issued it.
Please see the logfiles in /var/log/letsencrypt for more details.
There should be a way to revoke previously-issued certificates based on proof of domain ownership/server control, since it is very possible that the legitimate owner would not have access to the credentials used to issue an unauthorized certificate.
The certificate that I am trying to revoke has the serial number 03:bd:0a:09:ea:88:19:f5:ae:f1:61:c9:99:f9:00:6f:23:9f.
If I’m reading Let’s Encrypt’s Certificate Policy and the ACME(-01) draft (the protocol behind Let’s Encrypt) correctly, any account key that’s authorized for all the domains appearing on the certificate you’re trying to revoke should be able to do so. That means you’ll have to demonstrate ownership first, which is not something the revoke command will do for you.
Ironically, the easiest way to get valid authorizations for your domains would be to use the client to get another certificate. Just getting an authorization without actually issuing a certificate is not a very common use-case, so there’s no dedicated command for that, though there’s technically nothing in ACME that would prevent this from working.
@pfg Unfortunately although it's specified in the current ACME draft Boulder doesn't implement support for authorizing a revocation request in the manner you're describing. This wasn't called out anywhere previously but I've added it to our list of "ACME divergences":
Boulder does not allow for revocation of a certificate by an account key that is authorized for all DNS names in a certificate when that account did not create the certificate.
@cpu, thanks for posting that clarification. Do you think it would be more accurate to say that Boulder considers the private key authorized to revoke rather than the public key? After all, the general public that possesses the public key isn’t permitted to perform revocations as a result.
@schoen You're correct - that's the intention of what I mean when I said the public key is authorized :-). I specifically chose to say public key in this instance primarily to match the ACME specification language where it says:
The server SHOULD consider at least the following keys authorized for a given certificate:
the public key in the certificate.
an account key that is authorized to act for all of the identifier(s) in the certificate.
Perhaps we should consider amending the draft language to highlight the private key?
I see. In this case, if a certificate is mis-issued (issued by an individual without proper authorization), how would the legitimate admin revoke the certificate, if they do not have the private key used to request the certificate?