From what I understand, the purpose of account keys in the ACME protocol is that once authorized, the person who possesses the account key can then create and revoke certificates without having to further prove their identity.
So in a typical web-server situation, why would I want to add the additional security risk of keeping those keys around, instead of simply creating a new account key and solving a new set of challenges every 60 days? Is there a benefit to reusing the same account key each time?
I can see that with more complex server configurations, where solving the challenge might require manual intervention and/or downtime, that it would be desirable to avoid going through that process each time. (Although, I have to wonder, is it really common to have a server that allows installing new certificates in an automated fashion, but doesn’t allow you to automate the challenge process?)
It seems to me that - if you’re using Apache or Nginx or any other “normal” web server that allows webroot authentication - the most sensible thing would be to create a new account key for every new certificate, and shred it afterwards (or never store it on disk to begin with.)
(Obviously I’m also disregarding the rate limits currently imposed by the Let’s Encrypt beta program.)
To that end, it seems it would also be sensible that when registering an account key, the client should be able to specify “this key is only valid for N hours, or until K certificates have been issued.” Or at least, it should be possible for the client to revoke its own account key and/or authorizations. I have only skimmed through the ACME protocol documentation but I didn’t see either of these features mentioned.
I guess the one other potential benefit of keeping the account key around is being able to revoke certificates without further proving your identity. In an emergency situation you might need to be able to do that in minutes, without even having access to the server to be able to solve challenges. But for a situation like that, you’d presumably want to have a second account key, stored offline and authorized separately from the keys that are used for automatic renewal.
A very insightful question! One of the main reasons accounts are built into the spec is to make Proof of Possession challenge less burdensome. The idea is that, once you’ve passed a Proof of Possession (PoP) challenge for a given FQDN and issued a cert, subsequent authorizations on the same account would not need to pass a PoP challenge again. PoP challenges are not yet implemented, so I can see why account keys may seem extraneous.
Accounts are also useful for subscribers that manage a large number of hostnames and may need to reissue certificates with different configurations of SANs.
Keeping accounts long-term will also make it possible to update contact information (which is currently implemented on the server but not in the default client), to make sure you get expiration emails and other notifications.
I would note that, in the simple case, if you generate an account key and a certificate for single name, keeping the account private key doesn’t pose a greater risk than keeping the certificate private key. If someone can modify your server, they can pass challenges and issue a certificate for the server’s FQDN.
well when I was in manual and I wanted to re-issue a cert (with more domains than the old one) then I was asked for a re-challenge over the old domians (and that wirh new files which made it even more annoying)
but the server should actually issue the challenge or else the client could cheat.
also it would be epic if the server stored (especially for manual mode) each challenge-data of a completed challenge plus the account it belongs to, and if an account that already has challenge-data then it just verifies it’s still in place.
well it’s probably long and I probably dont understand a lot of that but if the client actually issues the challenge anyone could write a client that issues challenges in a way that they already are completed, aka anyone could create certs of the domain that still has my webroot files in place.
the spec is probably tl;du;dr, too long dont understand -> didnt read.
and there is the point. if the server save prevoisly completed tokens of manual mode then at the time when a challenge is requested, the server checks whether or not the account already has a completed challenge, checks whether or not it’s still in place and if it is it just says “I’m okay, I already have checked” or similar.
There’s no still in place. Challenges are removed as soon as they’re validated. But the server could indeed offer an empty combinations array if a previous one is still valid. But it’s actually the responsibility of the client to check that and to skip the challenge.
The holder of an authorized key pair for an identifier may use ACME to request that a certificate be issued for that identifier. The client makes this request by sending a POST request to the server's new-certificate resource. The body of the POST is a JWS object whose JSON payload contains a Certificate Signing Request (CSR) {{RFC2986}}. The CSR encodes the parameters of the requested certificate; authority to issue is demonstrated by the JWS signature by an account key, from which the server can look up related authorizations.
[...] It is up to the server's local policy to decide which names are acceptable in a certificate, given the authorizations that the server associates with the client's account key.
tl;dr: It's up to the server to verify the account key requesting a certificate has previously been authorized (i.e. completed an appropriate challenge) for all identifiers (i.e. domains) included in the certificate.
okay, so the intresting stuff it what does LE do, does it just force through the challenge, or returns it an error.
but it would be epic if the CA could store Manual challenges and when going into manual again that it’s just checked whether the file is still in place. (obviously after we checked that the account key is that same that got the challenge to bein with) and then throw an empty challenge/continue command/whatever
I believe completed challenges are valid for 10 months, meaning you would only have to create a new challenge file every 10 + 3 months. I’m not sure if the client makes use of this yet, though.
well the client doesnt, or at least not in manual.
but if the same challenge would be re-verified after the lifetime of the authorisation ran out it would be epic, since there’s essentially no way someone else having my webroot auth for a domain that I wouldnt own anymore (based on the example of selling a domain later.
That’s the same as for DNS, which is planned to switch to deterministic, but it’s currently not clear whether that’s allowed by the CA/B Forum’s rules. /cc @jsha
