Let's Encrypt's complex authorization process and multi-name TLS certificates

January 8, 2023

One of the things that people don't like about Let's Encrypt's ACME protocol for getting TLS certificates is that it's complicated (even beyond using JSON Web Tokens (JWT)). Part of this complexity is that it famously requires you to create and register an account, and the actual authorization process to get a TLS certificate for a domain involves this account in a multi-step process. You can readily come up with simpler single-step processes (such as the one in Another look at the steps for issuing a cert), so you can ask why ACME requires its multi-step process. It recently occurred to me that one reason for this is that it probably makes the logic of issuing a TLS certificate for multiple names simpler.

(We think about multiple names in TLS certificates a lot; most of our TLS certificates have at least two names for what boils down to historical reasons.)

A single-step process for getting a TLS certificate for a domain would be to tell the Certificate Authority that you want a certificate (with a given private key), the CA challenges you to demonstrate control of that domain, and when you do it issues you with that certificate. However, extending this process to a TLS certificate for multiple names makes it somewhat more involved. You would have to send the CA the list of names you wanted in the certificate, it would have to challenge you separately to demonstrate control of each domain, and keep careful track of which domains you'd proven control of and which you hadn't. You'd want to carefully consider 'control of domain' timeouts in this process to decide how close together do you have to prove control of all domains; within a few minutes, or a few hours, or a few days? If you'd made a mistake in a domain name, you'd probably have to cancel or abandon the current request and start all over from scratch (re-proving control of all correct names in a second attempt).

The ACME protocol's two step process makes this simpler and more uniform. You create an account, prove that that account has control of one or more domains, and then have that account ask for a TLS certificate for some name or names that it's proven control of within a specific time period. If you ask for a TLS certificate that includes a name you haven't demonstrated control over, the request fails (more or less, it's a bit complicated). The protocol and the server can consider each 'prove control of' request separately and independently, without having to maintain state on how many domains you've proven control of (and how recently) and trigger issuing a TLS certificate when all of the boxes are ticked off.

(Instead it's the ACME client's job to request actual issuance of the certificate, which is when it submits the actual Certificate Signing Request (CSR). I admit I was a little bit surprised to find out that ACME actually uses real CSRs, since they're complicated objects and these days almost all of their contents get ignored by the CA, or maybe cause your request to be rejected.)

Using a keypair to identify the account instead of what would in effect be a (web) cookie means that any leak or interception of the traffic between you and Let's Encrypt doesn't give out information a potential attacker can use to impersonate you (and thus use your identity to get TLS certificates). This is important in a two-step protocol, but not in a one-step one where you tell the CA the keypair you're using for the TLS certificate before it starts authorizing you (all the CA has to do to stop attackers intercepting traffic is to bind all of the results to the future certificate's public key).

(The two-step process could make you pre-commit to a TLS keypair for your eventual certificate or certificates and use that as your identity, but then you'd have to decide in advance what names would be in the eventual TLS certificate.)

PS: The actual ACME protocol steps for getting a TLS certificate don't require you to start in a state where you've already proven control over all of the domains. Instead, the ACME server will tell you if you need to do some authorizations, and starting from a certificate request is the normal flow of establishing them. There's a separate 'Pre-authorization' process that ACME servers can implement that allows you to authorize accounts for names before you make a certificate request.

Written on 08 January 2023.
« Our ZFS spares handling system sort of relies on our patterns of disk usage
Link: X Window System Basics »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jan 8 23:19:14 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.