In response to the question, Can I use an existing private key or Certificate Signing Request (CSR) with Certbot?, the FAQ claims:
However it does not provide any indication of how to actually do this. Scouring the manual finds the --key-path option, but Certbot completely ignores this option - it doesn’t even check if the path exists - and generates its own private key anyway.
Further reading the FAQ finds the passage: Certbot will not accept a private key as input and generate a CSR for you. I don’t remember seeing that before, perhaps it was recently added, but this is exactly what I am trying to do. If this isn’t possible, it begs the question why not, and further, what is the --key-path option even supposed to do in that case?
My understanding is the private key dictates your account and I want to be in control of my account, such that if I format a machine, I can still have a copy of the private key to renew and revoke certificates. Since I deploy with provisioning tools, I can ensure such a private key is present for Certbot’s use, if only it would actually use it. Since it does not, I would have to copy the generated account key back off the target machines to the host, which is not a valid deployment workflow (it’s backwards).
It’s nothing special. I just deploy with Ansible, where Ansible could be any other provisioning tool. I understand certificate keys are irrelevant in a self-service system, but I am interested in maintaining a consistent account key, which seems contradictory to Certbot’s poorly documented attitude towards its view on the disposability of keys. I think it should support maintaining a specific account key that can be externally generated.
Certbot always maintains the same account key – but it does not have a provision for specifying a custom account key or importing account data from elsewhere.
Edit: To rephrase, a Certbot installation maintains the account information in /etc/letsencrypt/accounts/. If you independently install Certbot on two computers, without copying that directory, they will generate two different accounts with two different keys. That’s fine, unless you’re treating them as ephemeral or otherwise creating so many that it’s a rate limit issue.
Who knows? Disk failures are a thing. The purpose of provisioning is that the machine can be restored to a consistent state at a whim, so it should be acceptable to format the box and refresh it many times with consistent results. With Certbot’s attitude to keys, however, clearly this leads to inconsistency. Whether or not it matters remains to be seen, but I’d rather be in control, particularly of account keys.
What kind of question is that? For starters, the keys don't live under accounts, they live in keys, and for another, the directory structure is unpredictable and undocumented, which is a very compelling reason why not to provision into Certbot's directory structure.
A question that's trying to come up with a way to meet your extremely idiosyncratic requirements.
Yes, actually, the account key does live there.
I think this has already been pointed out, but to reiterate: unless you have a rate limit exemption, there is no harm whatsoever in generating a new ACME account when you deploy a new server--there's simply no reason to care about keeping the same key.
Good point–in such a case you could also run into rate limit issues. Put /etc/letsencrypt on persistent storage. But if that blows up, there’s no harm to generating a new account. Or, as you’ve already said a couple of times, back up/restore /etc/letsencrypt to avoid the problem completely.
Although production servers would not be wiped so often (in my particular use case), I do however provision very frequently to clean Vagrant boxes to test the provisioning, whose disks will be dumped and reset on each such provisioning.