Unpredictable paths make Certbot completely unusable

Certbot has a nasty and (undocumented?) habit of creating new certificates in new paths with incremental suffixes. For example, the first certificate for foo.com will be created at /etc/letsencrypt/archive/foo.com, but if we delete archive/foo.com/fullchain1.pem and attempt to regenerate it, it abandons archive/foo.com completely and creates a new archive/foo.com-0001 directory. Subsequent attempts will create -0002 suffixes and so on.

This behavior would actually be fine if the symlink directory was consistent. At first we have live/foo.com pointing to our certificates residing within archive, but when we recreate the deleted certificate it also abandons that directory and creates a new symlink location at live/steam250.com-0001. This completely defeats the point of having a symlink location. The symlink target should be consistent and always point to the latest certificate. When the file locations are unpredictably jumping around like this, there is no way for the web server to pick up the latest version automatically nor for provisioning tools to know what the latest cert is.

Moreover, Certbot’s directory structure is completely undocumented. Contrast this with acmetool, which defines a formal specification for its storage schema. Note also, its live directory always points to the latest version of each domain’s certificate. This absolutely the correct way to go about structuring symlinks, and documenting the process, and is something Certbot sorely lacks. I consider this makes Certbot unusable for anyone not using a Certbot installer workflow (i.e. certonly or manual).

...you're opening yourself up to problems. Don't mess with /etc/letsencrypt.

Here's what's going on. You delete the file in /etc/letsencrypt/archive. This breaks the symlink in /etc/letsencrypt/live. Next time you run certbot, it sees that its directory structure is messed up (because you messed it up), so it creates a new directory.

There's just no reason to be directly messing with files in /etc/letsencrypt/archive.

The intention is that you should use /etc/letsencrypt/live/ and not rely on most other aspects of Certbot’s directory structure (except for cli.ini, the renewal hooks, and anything else I’m forgetting).

You can use “certbot delete --cert-name example.com” to delete a certificate, if you want to.

You can use “certbot --cert-name example.com -d example.net -d example.org ...” to replace a certificate with one that is not a superset of the existing one.

Under most circumstances, Certbot won’t create -0001 directories.

What’s your overarching workflow and goal?

1 Like

From your response, I understand --cert-name should force the directory to be anchored to the directory of the same name; but it is not. Once again, it creates an incremental suffix, despite adding this argument.

There is no workflow in this case, I’m just testing. I expect rerunning Certbot should enable it to “heal” against any missing files or directories created after the first run. But the way it goes about this is incorrect, since it is appending rather than replacing the missing files.

--cert-name works, at least normally.

I'm not sure what happens if the directory structure is damaged.

Edit:

No, Certbot is not designed to heal itself from arbitrary damage. If things are sufficiently corrupt, it will malfunction. If you're manually changing things in /etc/letsencrypt/, you have to be very careful to ensure that everything is consistent. If the filesystem is randomly corrupted or something, you will have to manually fix Certbot's data.

I suppose using the delete command is a better way of testing than deleting random certificate files directly. Still, this is weird behavior. As mentioned, it’s fine to increment the archive directories, but the symlinks in live should be created in an idempotent fashion so they are self-healing. This is easy to do with ln -sf, and I’m sure it’s just as easy in Python.

Yeah, it is. :slightly_frowning_face: Certbot just isn't designed to always react defensively in intuitive ways when its files are corrupt.

It could use more self-checks and explanatory error messages or self-healing.

That's not how it's designed. The archive and live directories are always expected to have the same names.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.