# Unpredictable paths make Certbot completely unusable **URL:** \ **Category:** Client dev\ **Created:** [September 15, 2019, 10:24pm UTC](https://community.letsencrypt.org/t/unpredictable-paths-make-certbot-completely-unusable/102084 "2019-09-15T22:24:23Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Bilge](https://avatars.discourse-cdn.com/v4/letter/b/9de0a6/32.png) [@Bilge](https://community.letsencrypt.org/u/Bilge)\ **Post date:** [September 15, 2019, 10:24pm UTC](https://community.letsencrypt.org/t/unpredictable-paths-make-certbot-completely-unusable/102084/1 "2019-09-15T22:24:23Z")
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](https://github.com/hlandau/acme/blob/master/_doc/SCHEMA.md#synopsis). 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`). ---
**Author:** ![danb35](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/danb35/32/70869_2.png) [@danb35](https://community.letsencrypt.org/u/danb35)\ **Post date:** [September 15, 2019, 10:39pm UTC](https://community.letsencrypt.org/t/unpredictable-paths-make-certbot-completely-unusable/102084/2 "2019-09-15T22:39:00Z")
> [@Bilge](#): > > if we delete `archive/foo.com/fullchain1.pem` ...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`. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [September 15, 2019, 10:40pm UTC](https://community.letsencrypt.org/t/unpredictable-paths-make-certbot-completely-unusable/102084/3 "2019-09-15T22:40:11Z")
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? ---
**Author:** ![Bilge](https://avatars.discourse-cdn.com/v4/letter/b/9de0a6/32.png) [@Bilge](https://community.letsencrypt.org/u/Bilge)\ **Post date:** [September 15, 2019, 10:47pm UTC](https://community.letsencrypt.org/t/unpredictable-paths-make-certbot-completely-unusable/102084/4 "2019-09-15T22:47:47Z")
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. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [September 15, 2019, 10:49pm UTC](https://community.letsencrypt.org/t/unpredictable-paths-make-certbot-completely-unusable/102084/5 "2019-09-15T22:49:10Z")
`--cert-name` works, at least normally. I'm not sure what happens if the directory structure is damaged. Edit: > [@Bilge](#): > > 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. 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. ---
**Author:** ![Bilge](https://avatars.discourse-cdn.com/v4/letter/b/9de0a6/32.png) [@Bilge](https://community.letsencrypt.org/u/Bilge)\ **Post date:** [September 15, 2019, 10:54pm UTC](https://community.letsencrypt.org/t/unpredictable-paths-make-certbot-completely-unusable/102084/6 "2019-09-15T22:54:36Z")
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. ---
**Author:** ![mnordhoff](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mnordhoff/32/22583_2.png) [@mnordhoff](https://community.letsencrypt.org/u/mnordhoff)\ **Post date:** [September 15, 2019, 11:01pm UTC](https://community.letsencrypt.org/t/unpredictable-paths-make-certbot-completely-unusable/102084/7 "2019-09-15T23:01:11Z")
> [@Bilge](#): > > Still, this is weird behavior. Yeah, it is. 🙁 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. > [@Bilge](#): > > 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. That's not how it's designed. The `archive` and `live` directories are always expected to have the same names. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [October 15, 2019, 11:01pm UTC](https://community.letsencrypt.org/t/unpredictable-paths-make-certbot-completely-unusable/102084/8 "2019-10-15T23:01:14Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.