Bug: Certbot ignores custom private key files

In response to the question, Can I use an existing private key or Certificate Signing Request (CSR) with Certbot?, the FAQ claims:

Yes.

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?

Hi @Bilge

what’s the command you have used?

You have to use the --csr parameter, not the --key-path.

Public/private key pair -> create a CSR -> reuse this CSR every 60 days.

1 Like

However, using the --csr option disables most of Certbot’s normal certificate management features, including automatic renewal.

You should really figure out how to change your key, or use a different ACME client.

Certbot’s --reuse-key option makes Certbot generate a new key once when first creating the certificate and then reuse it when renewing afterwards. Would that work for you?

Why do you want to use a custom key?

1 Like

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).

Let’s Encrypt ACME account keys and certificate keys are completely separate.

(Certbot stores your account information, including the keypair, in /etc/letsencrypt/accounts/.)

Certificate keys don’t dictate much of anything. Their only significance is that they are one of several ways to revoke a certificate. Let’s Encrypt doesn’t give them any effect on renewal.

Even accounts are fairly disposable*. Don’t actually treat them as ephemeral – Let’s Encrypt has rate limits – but if you lose your accounts, it’s not a problem. You can just register new ones.

(In particular, it’s not a problem for multiple accounts to validate and issue certificates for the same name.)

* Unless you have rate limit adjustment applied to your account.

Can you explain more about your setup, and how you manage Certbot, accounts and certificates?

1 Like

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.

Read the Text again, the account key and the private key of your cert are different things

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.

I guess I have no choice but to embrace total key disposability.

Is something going to happen to your /etc/letsencrypt/?

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.

Like I said, it’s not the end of the world to lose /etc/letsencrypt/, but you also shouldn’t consider it ephemeral.

It’s efficient and friendly.

There are the rate limits.

Depending on your setup, not having certificates can cause difficulties. (Like, a web server configured to use a certificate file that doesn’t exist will refuse to start.)

It would be unfortunate to need certificates right when Let’s Encrypt has some sort of outage.

Is there a reason you can't deploy specific contents to /etc/letsencrypt/accounts/?

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.

Account keys live in accounts.

Certificate keys are accessed via the symlinks in live; as an implementation detail, the files currently live in archive.

The copies of certificate keys in the keys directory are actually only used for a few seconds while certificates are being issued.

You don’t have to consider the details of the directory structure if you back up all of /etc/letsencrypt/.

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.

It is a problem if your servers are completely ephemeral and frequently replaced, though.

(Like, for example, a container system that wipes and rebuilds after every commit.)

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.

1 Like

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.

Would it work to use the Let's Encrypt staging environment (and Certbot --staging option) for that?