Understanding RFC8555 authorization

For responding to a challenge I need:
keyAuthorization = token || '.' || base64url(Thumbprint(accountKey))

Where accountKey is the key used to open the account, not the webserver private key used to generate the CSR...

Since the thumbprint is the same for both the public and private key, this only ensures one knows the public key.
The confirmation that one knows the account private key is soley based on the JWT signatures that are part of all the transactions.

So the ONLY place one needs to verify control over the end server private key in the whole process is in generation of the CSR?


1 Like


The Certificate Authority isn't technically obliged to verify that the subscriber controls the private key of the corresponding certificate. Hence the ACME protocol doesn't have a mechanism, other than the CSR. Let's Encrypt does verify the signature on the CSR though.

This also has the benefit of allowing protected key flows, where the ACME client isn't actually in control of the private key, e.g. it is obtaining a certificate on behalf of a HSM or similar.


This isn't part of Authorization, but the Server Private Key can also be used in ACME to revoke a Certificate.

If the Private Key is unavailable, ACME/LetsEncrypt also supports using the Account Key that issued the Certificate, or creating a new certificate with identical domains with a second Account and using that account to revoke.


Correct. And in fact, not even that step requires control over the private key! Lots of folks post their CSRs publicly (e.g. committing them to a GitHub repo) either purposefully or accidentally. It's totally possible to submit someone else's CSR, for which you did not and never could produce the signature, during your own Finalize request.

This is why Let's Encrypt refuses requests to revoke for reason keyCompromise which are only authenticated by the ACME account key: we don't actually know that you control the private key corresponding to the certificate, so we can't believe you when you say it's compromised. We only do keyCompromise revocations when the revocation request is signed by the certificate private key itself, immediately proving control over that key.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.