ACME grew out of early, ad-hoc procedures designed to let CAs issue large numbers of certificates with low overhead. As described in RFC855, these would go something like this:
- Generate a PKCS#10 [RFC2986] Certificate Signing Request (CSR).
- Cut and paste the CSR into a CA’s web page.
- Prove ownership of the domain(s) in the CSR by one of the following methods:
- Put a CA-provided challenge at a specific place on the web server
- Put a CA-provided challenge in a DNS record corresponding to the target domain
- Receive a CA-provided challenge at (hopefully) an administrator-controlled email address corresponding to the domain, and then respond to it on the CA’s web page
- Download the issued certificate and install it on the user’s web server
With the exception of the CSR itself and the certificates that are issued, these are all completely ad hoc procedures and are accomplished by getting the human user to follow interactive natural language instructions from the CA rather than by machine-implemented published protocols.
HTTP validation was the first mechanism, matching the first method of proving ownership in the above. The rest of what Let’s Encrypt added was automating the process (and rearranging it a bit, having the proof of control happen before the CSR, etc.). Years later, the IETF standardized the ACME protocol, and there are other variants that have been (or will be) standardized.
The IETF has published RFC8555 defining the ACME protocol for http-01 and dns-01 validations of dns-name authorizations. These are the sort of ACME authorizations that we usually think of, and which sewer works with. The RFC was published in the spring of 2019, but it wasn’t until near the end of that year that Let’s Encrypt adopted the full v.2 on only their staging server. There’s some elaborate and, from what I can make out, often-shifting schedule for various partial transitions, but I’m not going to try to make sense of them. As of the beginning of 2020, the only immediate effect on sewer was that one could no longer run it against the staging server. The next big change is when that same restriction is rolled out on LE’s production server later in the year. Since sewer v0.8.2, which implemented the final RFC8555 protocol at least well enough to work with LE’s server implementation, our tl;dr is just this:
If you get a failure running an older version of sewer, get v0.8.2 or later. This is a known problem: v0.8.2 or later is the fix.
LE probably accepts RSA keys of a wide range of sizes. Traditionally sewer has used a 2048 bit RSA key by default, with a bits option available in the Client() interface, with no support from the command line. As part of the crypto overhaul, 0.8.4 has introduced support for several sizes of RSA key by name (matching the elliptical curve keys it added). 2048, 3072 and 4096 bit RSA keys can be called for, and the default (for keys not explicitly provided and so generated by the cli program) is changed to a 3072 bit RSA key for both the account key and the certificate key. Either or both can use an externally generated key (of one of these sizes only) or you can (from the cli) change the generated key type & size for each.
SHA256 is the only hash algorithm for signing with an RSA key that LE currently accepts, and so there is no option to change it.
RFC8555 specifies An ACME server MUST implement the “ES256” signature algorithm [RFC7518] and SHOULD implement the “EdDSA” signature algorithm using the “Ed25519” variant (indicated by “crv”) [RFC8037]. As of 0.8.4, sewer supports all the EC curves which LE currently accepts. These are _secp256r1 (P-256 curve using ES256 for signatures) and secp384r1 (P-384 and ES384). So once again there’s no option for changing the signature hashing algorithm.
LE does not currently accept an Ed25519 elliptic key not for any technical reason but because the CAB (?) hasn’t yet added it to their list of approved keys/algorithms. Apparently they see little benefit, and much potential confusion, in accepting such as an account key when they are constrained not to accept one in a csr.
You think RFC8555 is a lot to take in? There is, as they say, much more: this collection of RFCs that describe details referred to but not expounded in good ol’ 8555.
RFC7515 specifies the Json Web Signature and JOSE Header which is used by the ACME protocol.
RFC7517 describes the Json Web Key
RFC7518 describes Json Web Algorithms, a few of which are used in the ACME protocol
RFC7807 describes the JSON structure of an error document such as those used by ACME
RFC8037 covers the ED25519 details (not yet supported in either LE nor sewer).
Oh yes, there’s another RFC for the new TLS authorization method which sewer has (so far) no interest in.