ACME RESPONSE isn't hashed

[augjoh]

When replying to a challenge, the response should be a SHA256 hash. acme_email responds with the raw value instead:

-----BEGIN ACME RESPONSE-----
awLYLYhYGF2QzIVrudy0Kh0xpD99Gik0eKm2kugoatr49G3Q6n1jFsRgyGqgTxSmt9GAW-kMqiy510M1hWA.5AjSXX1bYClIzYsCdpFAcQU4vbpw2pLjRKQpeKyKTYA
-----END ACME RESPONSE-----

[polhenarejos]

The specs of RFC 8823 claim:

3.0.6: The ACME client concatenates "token-part1" (received over email)
        and "token-part2" (received over HTTPS [RFC2818]) to create the
        ACME "token" and calculates keyAuthorization (as per Section 8.1
        of [RFC8555]).  Then, **it returns the base64url-encoded SHA-256
        digest** [RFC6234] of the key authorization.  The MUA returns the
        base64url-encoded SHA-256 digest obtained from the ACME client
        in the body of a "response" email message.  The "response" email
        message structure is described in more details in Section 3.2.
        If the MUA is ACME-email-aware, it MUST NOT respond to the same
        "challenge" email more than once.
3.2.7: The text/plain body part (whether or not
       it is inside multipart/alternative) MUST contain a block of lines
       starting with the line "-----BEGIN ACME RESPONSE-----", followed
       by one or more lines **containing the base64url-encoded SHA-256
       digest** [RFC6234] of the key authorization, calculated from
       concatenated token-part1 (received over email) and token-part2
       (received over HTTPS)

The response must contain the base-64 of the hash, not the hash itself.

In the code, we do not implement the routines of creating the digests and responses, as it is performed in the core of Certbot. In this sense ACME Email and ACME HTTP share the same procedure on creating the responses. The differences come from obtaining the two tokens.

[augjoh]

@polhenarejos Sorry, I wasn't clear about this. As you can see in the example ACME RESPONSE sent from acme_email, there is a dot . inside and it is too long to be the base64url encoding of a 32-byte SHA256 hash. It looks like, as if it were

<token-part1><token-part2>.<thumbprint-account-key>

but it should be:

base64url(SHA256(<token-part1><token-part2>.<thumbprint-account-key>))

[polhenarejos]

You were right. Now it is fixed in the client and in the ACME server. Thanks!

Fixed in dc7a5aba16e085733ca477d3125514f223ca6061