Would signing the key authorization with the ACME private key increase security?

Help
1

My understanding after reading about HTTP-01 with Let's Encrypt and Certbot is as follows:

  1. Cerbot creates a request for a new order of a certificate, signed with ACME account privaye key using JSON Web signature. Certbot sends that new order request to the CA (i.e., Let's Encrypt).
  2. The CA creates a challenge token and sends it to Certbot.
  3. Certbot concatenates the hashed ACME account public key to the token, that's called the key authorization string. Certbot writes the key authorization to, for example, /var/www/html/.well-known/acme-challenge/<token>.
  4. The web server must serve this file via HTTP.
  5. The CA requests this file from the web server.
  6. Certbot creates a key pair for the domain and a certificate signing request (CSR), signs the CSR with the ACME private key and sends it to the CA.
  7. The CA gets the CSR, verifies the signature using the ACME public key and issues a certificate.

Would it increase security if Certbot signed the key authorization string with the ACME private key in step 3? Intuitively, it seems to tie the token file served by the web server more strongly to the ACME account.

2

No.

The reason you concatenate the public key hash to the key authorization string, is to guard against an attacker who replaces your token with their token, if they manage to MITM your connection to the ACME server.

By introducing a step which is performed with your key offline, you don't become 100 % reliant on what the server tells you.

Even if the ACME server would somehow accept a challenge with someone else's token, but your public key (which it don't - it will always use the current public key of the account when doing the challenge) the attacker would not be able to neither submit your challenge for validation, nor submit a CSR, nor download the complete certificate, since the attacker don't have your private key.

You can see it like in some countries, when you online order alcohol for pickup, you don't need to prove your age online, you just type your ID card number in a box. Thats because, when you come and pick up the alcohol, you have to show the actual ID (sign the request at certificate pickup). Thats because, they know that since a person needs to be ablet to show the ID being entered when picking up, thus they don't need to verify the ID at point of purchase. So in this way, its enough to type the "public key" of the ID - in this case the ID card number.

3

Some additional "color" just in case ... http-01 is not a Let's Encrypt or Certbot invention. It's spec is defined as part of the ACME protocol here: RFC 8555 - Automatic Certificate Management Environment (ACME).

ACME is an industry standard and applies to every ACME client (like Certbot) and ACME Server (like Let's Encrypt).

6

Yes, the thumbprint system also prevent another attack vector:
servers that simply echo the challenge back by for example a script, which could allow anyone to issue certificates.

By introduce data that the web server cannot know, it creates a security barrier.

The current solution actually allows you to do this - you can configure the server to echo back the token in a challenge but append the public key hash to the end.

Like this:

<Directory "/var/www/html/.well-known/acme-challenge/">
    RewriteEngine On
    RewriteRule "^([-_a-zA-Z0-9]+)$" "$1" [E=challenge:$1]
    ErrorDocument 200 "%{ENV:challenge}.BqQJage_cyu-9wgFBUX5nqy7VbKOrbMpAbGzav8Vd7M"
    RewriteRule ^ - [L,R=200]
</Directory>

In this way, it becomes kind of like DNS-PERSIST-01 but for HTTP-01. But the appended key then prevents this to become an all-issue.