Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

client creates .well-known folder with insufficient permissions #1761

Closed
Kissaki opened this issue Dec 5, 2015 · 15 comments
Closed

client creates .well-known folder with insufficient permissions #1761

Kissaki opened this issue Dec 5, 2015 · 15 comments

Comments

@Kissaki
Copy link

@Kissaki Kissaki commented Dec 5, 2015

I used the letsencrypt-auto client with --webroot --webroot-path.

When the webroot path does not contain a .well-known folder yet, the client creates it as root (current user) with permissions 700. With a webserver running as www-data this will not allow the webserver to serve the challenge files, as it does not have the folder traversal (x) permission.

The subfolder acme-challenge is created with www-data:www-data 777, which is fine.

./letsencrypt-auto certonly --webroot --webroot-path /path/to -d example.com

@dixonwille
Copy link

@dixonwille dixonwille commented Aug 22, 2016

I get the same. I thought I was not configuring something correctly... had to set a watch -t 1 ls -la to see the permissions were set to root...

Loading

@Shnoulle
Copy link

@Shnoulle Shnoulle commented Jan 11, 2017

Maybe best is to have a option for each --webroot-path , --webroot-user.

I use apache-mpm-itk then each of my web server have their own user. To fix the issue i use acl : then all files inside .well-know are readable by my webuser ( setfacl -m d:u:user:rX www/.well-know)

Loading

@tmilev
Copy link

@tmilev tmilev commented Mar 25, 2017

This is a very serious bug.
Please fix it!
It is preventing me from using certbot -I will buy certificates instead.

Certbot MUST not create challenge files that require root to access. I am running a custom webserver which runs without root privileges (I listen to port 80 without root access with a port redirect trick).

Once again, I want to stress out the fact that certbot is losing users (namely, myself) because of this bug.

Loading

@Kissaki
Copy link
Author

@Kissaki Kissaki commented Mar 26, 2017

@tmilev just create the folder with adequate permissions yourself and you’re set. This is an inconvenience, not a blocker.

Also note that it does not create challenge files as root. And that’s the point of this ticket. It creates the folder with only root readable. The challenge step then fails with inadequate permissions.

Loading

@tmilev
Copy link

@tmilev tmilev commented Mar 27, 2017

@Kissaki: I don't think you are right. Here is what I get

./certbot-auto certonly --config-dir /home/ddtester/ace/calculator/certbot/certificates --logs-dir /home/ddtester/ace/calculator/certbot/logsdir --work-dir /home/ddtester/ace/calculator/certbot/workdir --webroot -w /home/ddtester/ace/public_html/ -d calculator-algebra.org -d www.calculator-algebra.org

the result I get is:

Requesting root privileges to run certbot... /home/ddtester/.local/share/letsencrypt/bin/letsencrypt certonly --config-dir /home/ddtester/ace/calculator/certbot/certificates --logs-dir /home/ddtester/ace/calculator/certbot/logsdir --work-dir /home/ddtester/ace/calculator/certbot/workdir --webroot -w /home/ddtester/ace/public_html/ -d calculator-algebra.org -d www.calculator-algebra.org /var/tmp/sclzwtpq9: Zeile 8: CERTBOT_AUTO=./certbot-auto: Datei oder Verzeichnis nicht gefunden

I have no clue why the program is looking for stuff in /var/tmp, but it does.

When run the same command with a "sudo" in the front, I get:

...

The following errors were reported by the server:
Domain: www.calculator-algebra.org
Type: unauthorized
Detail: Invalid response from
http://www.calculator-algebra.org/.well-known/acme-challenge/Iz3v2SYjCcfx1K1SBZhU8f1LuWd_vyiZnlH_brFvv-k:
"Error: file appears to exist but I could not open it.
File display name: /.well-known/acme-challe"

Loading

@stratacast
Copy link

@stratacast stratacast commented Apr 22, 2017

Can someone confirm what the permissions/ownership for the folder and the contents of the .well-known folder are supposed to be? I'm having troubles finding that information

Loading

@mikeshultz
Copy link

@mikeshultz mikeshultz commented May 10, 2017

Using the setgid sticky bit worked for me. Should be good enough to automate, anyway. Though I agree, there should be an argument for a user/group.

Example:

sudo -u lighttpd mkdir -p /tmp/certbot/public_html/.well-known/
chmod g+s /tmp/certbot/public_html/.well-known
certbot certonly --dry-run --webroot -w /tmp/certbot/public_html -d example.com -d www.example.com

Loading

@ppython
Copy link

@ppython ppython commented May 11, 2017

@Kissaki , @dixonwille :
We figured it out, if you're able to, chown the following directories to your "www-data" or equivalent user. Or start a fresh install as "www-data" or equivalent.

  • log directory: /var/log/letsencrypt/
  • working directory: /var/lib/letsencrypt/
  • config directory: /etc/letsencrypt/

@Shnoulle : I also like the idea of a new "--werbroot-user".

@stratacast : the .well-known folder should be accessible by the acme client, it's all that matter (in our case as "root:root" it didn't work, we switched for the equivalent of "www-data".

Loading

@sydneyli sydneyli added this to the 1.0.0 milestone Sep 26, 2018
@stale
Copy link

@stale stale bot commented Jun 6, 2019

To help us better see what issues are still affecting our users, this issue has been automatically marked as stale. If you still have this issue with an up-to-date version of Certbot and are interested in seeing it resolved, please add a comment letting us know. If there is no further activity, this issue will be automatically closed.

Loading

@stale stale bot added the needs-update label Jun 6, 2019
@bmw
Copy link
Member

@bmw bmw commented Jun 13, 2019

This issue has been closed due to lack of activity, but if you think it should be reopened, please open a new issue with a link to this one and we'll take a look.

Loading

@bmw bmw closed this Jun 13, 2019
@wadih
Copy link

@wadih wadih commented Jun 13, 2019

@ppython, @Kissaki , @stratacast , @Shnoulle , @bmw

Got certbot with --apache flag to work on Debian 9 with mpm-itk.

No need for setfacl, sticky bit, changing owners or diluting security anywhere.

I found out that when using --apache it doesn't physically create the .well-known directory within the web directory but simply creates a temporary world-readable alias to /var/lib/letsencrypt/http_challenges/ in the target vhost config.

So it should have worked even with mpm-itk out of the box. But it wasn't working so there was something else.

The reason finally was that /var/lib/letsencrypt permissions in my case was 700 and was thus blocking world path traversability to reach the challenge file which has 755 permission. All other directories up and down were world-traversable. So it is mostly just an oversight by package maintainer and not done on purpose. For a path to be traversable, it needs to have at least the execute bit (1). That means you cannot see the folder's contents, but you can still traverse it if you know the absolute path.

To re-enable traversability to the hard-coded secure path, all I needed was to add o+x to the /var/lib/letsencrypt directory and all worked fine. (all other directories up and down had 755 except that one):

Before:

755 /var/
755 /var/lib/
700 /var/lib/letsencrypt/
755 /var/lib/letsencrypt/http_challenges

So simply doing chmod o+x /var/lib/letsencrypt fixed the issue for me. Permissions became:

After:

755 /var/
755 /var/lib/
701 /var/lib/letsencrypt/
755 /var/lib/letsencrypt/http_challenges

And traversability was restored so the apache mpm-itk specific user thread could reach the hard-coded challenge file by absolute filename successfully now and all the rest worked.

Probably this is due to my umask which sets any new files to be 700 by default, but when I installed certbot, it seems the package maintainer didn't force permission to 755 on /var/lib/letsencrypt upon installation although he did on http_challenges, so it was most likely just an oversight.

Loading

@szpak
Copy link

@szpak szpak commented Feb 4, 2020

Thanks @wadih for your description, it helped me to find a reason of a renewal failure on Fedora 31. However the situation there is a little bit different.

/var/lib/letsencrypt/ has proper 755 permissions (as configured in RPM), but /var/lib/letsencrypt/http_challenges/ (created by certbot) has 700. That causes access via httpd (on sudo certbot renew --dry-run) to fail with:

(13)Permission denied: [client x.x.x.x:x] AH00035: access to /.well-known/acme-challenge/xxxx denied (filesystem path '/var/lib/letsencrypt/http_challenges/xxxx') because search permissions are missing on a component of the path

It might be caused by using a default umask for root which is restrictive (0022) - I wasn't find any place in the source code where that directory is created explicitly (only that).

Sorry for resurrecting that old issue. I might create the new one if you agree it is something worth to follow.

Loading

@bmw
Copy link
Member

@bmw bmw commented Feb 4, 2020

The place where the directory is created is

filesystem.makedirs(self.challenge_dir, 0o755)
which on POSIX systems like Linux filesystem.makedirs is essentially a wrapper around os.makedirs.

While I wouldn't expect the umask of 0022 to cause a problem, a more restrictive umask could. I created an issue to track this at #7741.

Loading

@szpak
Copy link

@szpak szpak commented Feb 4, 2020

While I wouldn't expect the umask of 0022 to cause a problem, a more restrictive umask could.
Sure, I meant 0077.

Thanks for getting the ball rolling.

Loading

@wadih
Copy link

@wadih wadih commented Apr 16, 2020

Sure, I meant 0077

@szpak @bmw , Yes, my default umask for root was 0077. Interesting to see the differences between Fedora 31 and Debian.

Also happening in Debian 10 at the moment which is expected.

I just manually just set the permission. I regularly provision new servers, so when it'll be fixed, I will start noticing it on new servers.

Note that it has to be done after the first certificate has been created, because the directory doesn't exist before that yet.

chmod o+x /var/lib/letsencrypt

Thanks all

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet