Webroot plugin wrong permission on validation files. NGINX 403 Error


#1

Please fill out the fields below so we can help you better.

My domain is: mic-test.obbdev.com

I ran this command: certbot-auto certonly
–webroot -w /var/www/home/mic-test/www/
-d www.mic-test.obbdev.com -d mic-test.obbdev.com
–email email@email.com --non-interactive --agree-tos

It produced this output:

Domain: mic-test.obbdev.com
Type: unauthorized
Detail: Invalid response from
http://mic-test.obbdev.com/.well-known/acme-challenge/G6fOv_JLtWLZKM8IsgLn0gtbQ4bWIwU62R4k4_aguzM:
"

403 Forbidden

403 Forbidden


"

My operating system is (include version): Centos 6

My web server is (include version): Nginx

I can login to a root shell on my machine (yes or no, or I don’t know): yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel):none


Permissions on files when they are created:
ls -la
drwxr-xr-x+ 3 mic-test-www mic-test-grp 4.0K Oct 26 12:06 .
drwxr-x—+ 10 mic-test-www mic-test-grp 4.0K Oct 26 11:48 …
drwxr-x—+ 2 mic-test-www mic-test-grp 4.0K Oct 26 15:00 acme-challenge
ls -la ./acme-challenge/
drwxr-x—+ 2 mic-test-www mic-test-grp 4.0K Oct 26 15:00 .
drwxr-xr-x+ 3 mic-test-www mic-test-grp 4.0K Oct 26 12:06 …
-rw-r-----+ 1 root root 87 Oct 26 12:06 G6fOv_JLtWLZKM8IsgLn0gtbQ4bWIwU62R4k4_aguzM
-rw-r-----+ 1 root root 87 Oct 26 12:06 qiZWrd_tSu5lKnvTmXdbq6N0y_Kamh_bVYqjD9ewecA

If change ownership to mic-test - server will be able work
Or change permissions to something like 755


How to change user or\and permissions on validate files in cert generation process?


#2

Does anyone seen this kind issue
Are validation files creating normaly?

up?


#3

can you place a text file in .well-known/acme-challenge/test with the contents “success” and the reach it at http://mic-test.obbdev.com/.well-known/acme-challenge/test ?


#4

Yes, done

curl http://mic-test.obbdev.com/.well-known/acme-challenge/test

mic-test/www/.well-known/acme-challenge/
touch test
vim ./test
chown mic-test-www:mic-test-grp test
curl http://mic-test.obbdev.com/.well-known/acme-challenge/test
success


#5

excellent - and are you still getting the same error when running certbot-auto ? if it still gives an error of “invalid response from …” can you reach that URL via curl ?


#6

Yes
Detail: Invalid response from
http://mic-test.obbdev.com/.well-known/acme-challenge/5qcS4H3XcJzSmR-aCx0DAVNDejqpeFF_UWZHv0eZuUA:
"

403 Forbidden

Here is a difference, how certbot created it, and how I did test file.

watch ls -la

total 32
drwxr-x—+ 2 mic-test-www mic-test-grp 4096 Nov 1 08:44 .
drwxr-x—+ 3 mic-test-www mic-test-grp 4096 Oct 26 12:06 …
-rw-r-----+ 1 root root 87 Nov 1 08:44 5qcS4H3XcJzSmR-aCx0DAVNDejqpeFF_UWZHv0eZuUA
-rw-r-----+ 1 mic-test-www mic-test-grp 7 Nov 1 08:31 test


How make certbot to set correct permissions/ownership :frowning: ?


#7

Well, at least that identifies the problem. Personally I don’t use certbot, so not sure how to get it to change the ownership / permissions. There is a script plugin being developed, which will allow that, but that hasn’t been released yet.

@pfg will hopefully have a few ideas


#8

It’s rather odd to see the challenge files certbot created are still there. Typically, they would be deleted, even if the challenge fails. Did you do anything to make that happen (in order to make this easier to debug and see the file permissions), or are the files just there?

The files should be created as world-readable, so the ownership as such should not matter.

Could you re-run the client in verbose mode (-vvvvv) and post the logs from /var/log/letsencrypt? Maybe there’s a clue somewhere in there.


#9

watch 'ls -la’
can show files while they are there fr a 2-3 seconds, thats how I can catch them.

http://mic-test.obbdev.com/.well-known/letsencrypt.log


#10

ownership is matter IF you have nginx started as regular user, non root, so nginx can read only directory’s and files which are belongs to him or gorup.

That issue in my case I think.

In same time files are created as 640, instead of 644, and they are not available/readable to any user on server. In additional root:root ownership set.


#11

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