Today I wanted to start working on an open source Let's Encrypt client that processes CSRs in a database and feeds back the certificates. I thought the Let's Encrypt system would be straight forward, but the devil is in the detail. I wanted to clarify some things before planning based on misconceptions. I know many things are pretty Beta, but I am also willing to help with documentation after getting a grip on all those things.
ACME Standard
ACME-Accounts
The client generates an asymmetric key pair and associates this key pair with a set of contact information
A few statements I would love to see verified or corrected:
- This account/key thing is pretty important. But I haven't seen a clear naming convention. I will refer to it as ACME-Account.
- The ACME-Account key is even more security sensitive then the TLS-Keys. TLS-Keys can be replaced regularly at least every 90 days. Also, the certificates for a key can be revoked in contrast to ACME-Accounts keys.
- It is very important to backup ACME-Accounts (while keeping them safe at the same time).
- It is good practice to create an ACME-Account per registered domain. If a domain should be handle by another server or is sold, the account can be handed over.
Questions:
- If a ACME-Account is lost, can the proof of possession be redone with a new account?
- How does account recovery work? I remember a Let's Encrypt talk at DebConf where it has been mentioned that this might only be possible with an EV certificate detour. Is something like this already in place? There is this MAC and contact method in the specs but it looks like it's up to the policy of the CA using ACME what is accepted? Where is this documented for Let's Encrypt?
- Is there a way to replace an ACME-Account key? I found key roll-over in https://ietf-wg-acme.github.io/acme/#rfc.section.6.4 but not in https://tools.ietf.org/html/draft-ietf-acme-acme-01#section-6.3.1. Which version is "correct"? I also found the statement that roll-over is not supported in the (acme?) source code.
Authorization
I was confused by this line
Before a client can issue certificates
I think the client should issue a CSR and the server then issues a certificate.
Supported ACME Features
Is there a list of features supported by the Let's Encrypt server? I read that DNS-01 (would help if this term appears in the heading in the standard) is now available on staging but I didn't found an overview of the ACME features supported by Let's Encrypt and Let's Encrypt Staging.
ACME Python Libs
I found it a bit hard to get started with the acme and the letsencrypt API. There is no real documentation what feature sets they have and on which level of abstraction they work. The letsencrypt documentation does not properly explain the parameter of functions http://letsencrypt.readthedocs.org/en/latest/api/account.html. For example RegistrationResource is actually a class of the acme lib. With the acme lib I am a bit lost. Do I need to understand JOSE to start hacking? As I already founds different ACME specs, which one is implemented? Is there a mapping between python functions and the specs? Is the implementation complete? Do I want to use the letsencrypt or the acme lib? For example I would be fine if the letsencrypt API manages my accounts in /etc/… but I don't want it to handle Apache configs nor key creation etc. But is account config handling even exposed via the API?