Concurrent invocations of certbot using webroot


#1

I am using nginx and webroot plugin. I have a service which pre-fetches certs if the number of certs in the DB goes below a certain number. It uses randomly generated hostnames.

Now when this service invokes certbot, there could be a custom client(our own client where the cert needs to be installed) hitting this service requesting a cert for a particular hostname. Which means there could be a scenario where there are multiple invocations of certbot. I do provide certbot with unique values for --config-dir, --logs-dir and --work-dir parameters.

The one thing I am worried about is that since certbot creates ~/<path_to_webroot_dir>/.well-known/acme-challenge directory when requesting for a cert and deletes it once the cert is issued, there is a small window where there could be multiple files under acme-challenge directory(due to multiple certbot invocations) and a race condition is created where the first one to go through deletes the acme-challenge directory and leaves the others in limbo basically the domain ownership challenge fails.

Is there a way around this? Why does certbot delete the acme-challenge directory. It can just delete the challenge file I suppose.


#2

Short answer: Putting an empty .keep file (or something like that) in .well-known/acme-challenge should be enough to prevent certbot from deleting the directory.

certbot instances only delete the files they actually created. Following that, certbot uses the os.rmdir to delete acme-challenge, which only works if the directory is actually empty. In case another certbot instance has created other files when rmdir is invoked, or if some other files exists in that directory for some reason, certbot will log that occurrence and continue, so you’d be fine.

I think it’s one of those design decisions that a) isn’t important enough to force users to make an explicit choice about the behaviour and b) no matter what default option you pick, you’re only going to make half of your user base happy. Someone’s bound to not like the fact that the client is leaking directories. :smile:


#3

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