Certbot renew leaves behind empty .well-known dirs

I created a cert using --webroot for multiple domains. Some of the domains share the same directory, e.g. acme.com and www.acme.com. This worked fine. Last night I had my first automated renewal. This also worked fine, except I got a bunch of messages about “Unable to clean up challenge directory”. Checking the filesystem I found .well-known directories in all the webroots. They were all empty, so the acme-challenge subdirectories and the randomly-named challenge files were successfully removed, just not the upper-level directory.

Manually removing the .well-known dirs was easy enough, but certbot should really be doing that itself.

Certbot won’t remove .well-known as other applications/services might also be using it.

2 Likes

Ok, I guess, although when I write code it cleans up when it creates.

Actually the warning messages were about the .well-known/acme-challenge subdirs, not the .well-known dirs. It would remove one, proceed to another domain that used the same webroot, try to remove that one, fail because it was already gone, and show a warning. This seems like a common case, so those warnings should be suppressed.

The concern for “cleaning up” a shared resource such as a directory in a Unix system with a name that doesn’t belong to the application is that there’s a non-negligible risk of conflict during a race. If it so happens that another program wants a .well-known/ directory, but hasn’t yet used it for anything, that program may be unable to create it (because certbot has it) and then later find it no longer exists (because certbot “cleaned up”)

The IETF keeps a database of assignments it has made…

https://www.ietf.org/assignments/well-known-uris/well-known-uris.xml

and some vendors rather than go through the IETF just choose their own URIs under .well-known/ which isn’t a problem so long as the names they choose don’t conflict with what you might reasonably expect.

https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html

2 Likes

:+1:Cleaning up what your code creates is so often forgotten that it almost seems like a lost art now. Still, if you create /tmp/my-dir, cleaning up probably would cause one or two issues if you tried to remove /tmp/my-dir and /tmp. :thinking:

On most *nix systems /tmp “should” already exist, and using it for its intended purpose is fine. If, somehow, it don’t already exist, leaving it behind can be considered a “service” to the next person who tries “mkdir /tmp/my-dir” rather than “mkdir -p /tmp/my-dir”

While it’s relatively new, eventually most websites will have a /.well-known directory and others may assume it is already there when trying to use it, (maybe that’s why it’s well-known,) and not “cleaning” that out should be looked at the same was as not removing /tmp.

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