Certbot must be run as root but I need it to create the files with a different owner


I use the web server Jetty 11 under Armbian Buster on my own single board computer at home (self-hosting), please note that I don't run it as root for obvious security reasons. I use the following script to install everything from scratch:

I understand that Certbot must be run as root, that's what I do but when I use the command "certbot certonly --webroot", the files it produces are owned by root. This is a problematic constraint in my case because I can't restart my webserver to run it as root and restart it again to run it as the used named "jetty" in the group named "jetty". When Jetty can't read a file owned by root as it runs as "jetty", it stops working, it often doesn't log anything and I have to reinstall almost everything to make it work again (or I have to modify the ownership of the offending files).

Is there a mean to suggest Certbot to create files with a different owner?


You could write a script which would do that stuff and then use --deploy-hook to run said script.

While it's not recommended nor officially supported, it should also be possible to run certbot as a non-root user by either change ownership of the --work-dir , --logs-dir , and --config-dir (by default these are /var/lib/letsencrypt , /var/log/letsencrypt , and /etc/letsencrypt respectively) or set those three directories to other, non-root owned custom directories. See User Guide — Certbot 1.15.0.dev0 documentation for more info about --deploy-hook and the three directory options I just mentioned.

A third option would be to use an ACME client which doesn't require root usage. See ACME Client Implementations - Let's Encrypt for an overview of clients. I believe most of the Bash clients don't require root.


Your first suggestion might fit into my use case but please can you elaborate? Could I use another directory as a fake web root in which "certbot certonly --webroot" could write the files owned by root and use such a deploy hook to change the ownership and to move them into the real web root? My fear is that the deploy hook are run too late. Imagine Certbot generates some files in .acme/ in the fake web root, it checks immediately whether it sees something in the web at the expected location but it doesn't see the expected stuff, it doesn't work. However, if Certbot executes the deploy hook before performing the check, your suggestion will work. I'll look at the documentation. Thank you.

1 Like

The files for the challenge like the webroot plugin should be world readable ("-rw-r--r--"), so no chown or chmod required for that step. I thought you meant privkey.pem as that's the only file only readable by root by default.

1 Like

Sorry, I wasn't accurate enough. The files in ${webroot-path}/.well-known/acme-challenge cause my problem, Certbot creates them with root as an owner but as Jetty isn't run as root, it doesn't work as is.

Shouldn't I use a pre-validation hook in this case in order to move the file(s) into the right location with the correct ownership just before the validation occurs?

That's quite odd, as the .well-known and acme-challenge directories are world readable (drwxr-xr-x) and as I said before, the challenge file itself too (-rw-r--r--). It should be readable by any user, including Jetty's.

That won't be of any use I'm afraid. For example, from the certbot documentation for --pre-hook:

When renewing several certificates that have identical pre-hooks, only the first will be executed.

Also, I doubt it'll run just after when the token file has been generated. I think it will run earlier.

1 Like

Therefore, I'm probably looking at the wrong direction for the root cause of my problem. I'm going to rerun the script without trying to run certbot as root, it should work as you wrote that the challenge file is world readable.

1 Like

Your solution works. The problem was elsewhere. At first, my way of forcing the MAC address to remain unchanged was breaking the network manager after a reboot. Secondly, my registrar keeps showing its parking page when I use www.mydomainname.com instead of mydomainname.com; removing "www" made my script work and as you said, the file in the web root could be read by Jetty :slight_smile: Please note that my DNS zone is correctly configured to point to my web server, there's something really wrong in the DNS management of my registrar.


Great to hear you found the issue! Good luck with your DNS registar.


Thanks. I confirm that my registrar (Gandi) was doing something counterintuitive to me, it redirected www.mydomainname.com to its own parking page even though I set the property named "A" in my DNS zone, the customer service suggested to set a redirect rule in order to redirect www.mydomainname.com to mydomainname.com, which worked as expected. However, I go on generating a single certificate for mydomainname.com as it works and it's simple.

Is ${webroot-path}/.well-known/acme-challenge subjected to changes in the future? I mean, might Certbot use another directory by default in the future? I modified my deployment so that Certbot goes on seeing the challenge file(s) but in a way that allows me to use my root context to do something else, I just hope that it's a future proof solution.

1 Like

I don't think so. If that were to happen, millions of people would be going nuts trying to figure out what changed and why their setup that previously worked suddenly throws errors. It would also deprecate all previous versions of Certbot. :exploding_head:


It could theoretically change as a result of a serious security flaw in hosting providers' environments, or something, but I agree that this change is so costly that it's extraordinarily unlikely at this point (it would be easier to pursue some other workaround if something like that ever materialized).

I could imagine that it could go away if the industry decided to switch to a totally different method for proving control of domain names; for example, in another forum, I talked with some people about whether in the long term it would make more sense to do an "RDAP challenge" completed directly via the domain registrar or using a domain registrar-issued credential, instead of via DNS. Perhaps in 10 years the industry will have switched over to a mechanism like that, in which case the HTTP-01 challenge method might go away entirely. But I should emphasize that this isn't even a proposal yet, never mind a practical reality, never mind an exclusive option (that might upset thousands of companies and millions of users if it were rolled out too abruptly)...

(Edit: I should emphasize that even with a 10-year window there would probably be a tremendous amount of opposition to a change like this.)


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