Let's Encrypt unauthorized 403 forbidden

问题

On the server, Nginx is installed. Let's Encrypt is working well with www.domain.com but is not working with static.domain.com

With PuTTY, when I enter : sudo letsencrypt certonly -a webroot --webroot-path=/var/www/site/domain -d static.domain.com -d domain.com -d www.domain.com

I have the below issue :

Failed authorization procedure. static.domain.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://static.domain.com/.well-known/acme-challenge/c6zngeBwPq42KLXT2ovW-bVPOQ0OHuJ7Fw_FbfL8XfY: "<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>"

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: static.domain.com
   Type:   unauthorized
   Detail: Invalid response from
   http://static.domain.com/.well-known/acme-challenge/c6zngeBwPq42KLXT2ovW-bVPOQ0OHuJ7Fw_FbfL8XfY:
   "<html>
   <head><title>403 Forbidden</title></head>
   <body bgcolor="white">
   <center><h1>403 Forbidden</h1></center>
   <hr><center>"

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A record(s) for that domain
   contain(s) the right IP address.

Somebody know what can be the issue?

回答1:

I got an identical error message from certbot when I tried to install a certificate for the first time on my website.

Check the cause on the web server

I was using apache2, not nginx. I looked at the logs in /var/log/apache2/error.log for apache2 error messages associated with that 403 Forbidden event on my website and I found :

[Sun Aug 26 14:16:24.239964 2018] [core:error] [pid 12345] (13)Permission denied: [client 12.34.56.78:1234] AH00035: access to /.well-known/acme-challenge/5PShRrf3tR3wmaDw1LOKXhDOt9QwyX3EVZ13JklRJHs denied (filesystem path '/var/lib/letsencrypt/http_challenges') because search permissions are missing on a component of the path

Permissions and access problem

I googled this error message and found out that apache2 can't read the directory mentionned above (e.g. /var/lib/letsencrypt/http_challenges) because of incorrect permissions, such as:

$ sudo ls -la /var/lib/letsencrypt/
total 16
drwxr-x---  4 root root 4096 Aug 26 14:31 .
drwxr-xr-x 72 root root 4096 Aug 18 00:48 ..
drwxr-x--- 27 root root 4096 Aug 26 14:26 backups
drwxr-xr-x  2 root root 4096 Aug 26 14:27 http_challenges

So, according to the above line with a dot (.) representing letsencrypt folder with permission rwxr-x---, no one except root user can read its content. To rectify permissions, I just did :

Solution

$ sudo chmod o+rx /var/lib/letsencrypt

which changes the above $ ls command output to :

$ ls -la /var/lib/letsencrypt/
total 16
drwxr-xr-x  4 root root 4096 Aug 26 14:31 .
drwxr-xr-x 72 root root 4096 Aug 18 00:48 ..
drwxr-x--- 27 root root 4096 Aug 26 14:26 backups
drwxr-xr-x  2 root root 4096 Aug 26 14:27 http_challenges

Now, the above line with a dot (.) representing letsencrypt directory indicates rwxr-xr-x, so that "other users" (like user www-data for apache2) can now read and go through letsencrypt directory.

Then certbot worked as expected.

回答2:

I guess you have another webroot for your sub domain and if so just need to specify that webroot. In your example you have the same webroot for both static.domain.com and domain.com.

from https://certbot.eff.org/docs/using.html

If you’re getting a certificate for many domains at once, the plugin needs to know where each domain’s files are served from, which could potentially be a separate directory for each domain. When requesting a certificate for multiple domains, each domain will use the most recently specified --webroot-path

certbot certonly --webroot -w /var/www/example/ -d www.example.com -d example.com -w /var/www/other -d other.example.net -d another.other.example.net

回答3:

I came across a work around, since it is not the solution (not automatic), but it worked.

You can prove your domain ownership using DNS challenge, via The Certbot ;

sudo certbot -d domain.com --manual --preferred-challenges dns certonly

回答4:

I had to remove the AAAA records for my domain as certbot was prefering IPV6. My webhost provider DNS had default AAAA records for www and @ (root of domain).

After carefully examining the /var/log/letsencrypt/letsencrypt.log - down where it says "addressUsed", I saw that it was using an IPV6 address. In my case I don't have any website at www. or the root of my domain that are serviced by an IPV6 address so I removed the AAAA records and saw immediate relief to my problem. Due to dns propagation and record ttl, it may take longer for others to see relief.

certbot will try to connect to you using an IPV6 address if it was able to resolve one even though you're expecting the connection via IPV4 and that was the extent of my problems.

I suggested deleting the log so you have only fresh entries before continuing with the command - sudo rm /var/log/letsencrypt/legsencrypt.log - find the "addressUsed" and verify that it's an IPV4 address and not an IPV6 address. if its an IPV6 address, either forward that address at the gateway to your host and verify you're listening on IPV6 as well OR remove the AAAA records in DNS so that letsencrypt will connect to you using IPV4 address instead.

回答5:

In your server block, add:

# for LetsEncrypt
location ~ /.well-known {
  allow all;
}

回答6:

In case anyone still facing this issue, can try below and it worked for me :

location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
alias /home/nginx/domains/domain.com/public/acme-challenge/;
}

回答7:

In my case I denied access to security related files (/.htaccess, /.htpasswd, etc.) via

location ~ /\. {
  deny all;
}

Which I changed to

location ~ /\.ht {
  deny all;
}

回答8:

I don't want to unnecessarily repeat things, but it seems there are quite some different situations that can cause a 403 at certificate renewal. For me, it had to do with a changed nginx config because of Wordpress / url rewriting. Using Virtualmin btw.

There is a link above in the comments that refers to an issue on Github. One guy explains brilliantly how the location matches in nginx work and gives a solution for the 403. Still, there might be other issues causing this too.

Thus, for me the solution was to include a location match for /.well-known/.

location ^~ /.well-known/ {
    #limit_req            [tighter per-ip settings here]; ## kicked this one out
    access_log           off;
    log_not_found        off;
    #root                 /var/www/html; ## kicked this one out
    autoindex            off;
    index                index.html; # "no-such-file.txt",if expected protos don't need it
    try_files            $uri $uri/ =404;
}

I am no nginx expert at all, so I would encourage you to read the post and check which parameters are needed for your situation.

来源：https://stackoverflow.com/questions/42933438/lets-encrypt-unauthorized-403-forbidden

标签

nginx

encryption

lets-encrypt

unauthorized