Let's Encrypt unauthorized 403 forbidden

Asked 21/3, 2017 at 16:49 Answered 1/6 at 15:22

nginx encryption lets-encrypt unauthorized

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?

Merlon answered 21/3, 2017 at 16:49 Comment(1)

Had so many issues and was led everywhere until I tried installing certbot with snap . Remove all other installations and install it and it works incredibly easily. certbot.eff.org/instruction – Giuseppinagiustina 25/6, 2022 at 2:53

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.

Melli answered 26/8, 2018 at 22:32 Comment(0)

In your server block, add:

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

Melanochroi answered 28/8, 2017 at 20:55 Comment(1)

I changed mine a bit, but why wouldn't this one work anymore? – Farrar 14/11, 2019 at 10:14

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.

Scala answered 16/1, 2019 at 10:9 Comment(1)

Thanks. It was 2 days of pain until I found your msg. 👏 – Apyretic 29/8, 2023 at 16:47

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

Bluebonnet answered 11/7, 2017 at 21:13 Comment(0)

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

Leaguer answered 21/3, 2017 at 16:59 Comment(6)

Thank you very much Chris! I did what you told me :

sudo certbot certonly --webroot -w /var/www/site/domain/ -d domain.com -d www.domain.com -w /var/www/site/domain/wp-content/uploads/ -d static.domain.com

but I have the same issue 403 Forbidden – Merlon 21/3, 2017 at 17:5

I see a lot of thread with similar errors, It seems there are many possible issues. Is there .htaccess file in the domain's webroot? – Leaguer 21/3, 2017 at 17:19

No there is no .htaccess file in the domain's webroot. – Merlon 21/3, 2017 at 17:41

I'm having the same issue, having check this link .well-known ACME challenge files blocked 403 Forbidden in some Nginx configurations that suggests that the problem lives in the nginx.conf file? I tried to edit it but it's readonly. Have you come to a solution? – Bluebonnet 11/7, 2017 at 4:56

@PauloHenrique No, and I have more experience with Apache than Nginx, so cannot investigate, sorry. – Leaguer 11/7, 2017 at 11:24

@PauloHenrique You probably don't need it anymore, but thanks to your link, I found an answer that worked for me. I added it as an answer here. – Farrar 14/11, 2019 at 11:49

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/;
}

Sponsor answered 3/11, 2018 at 19:20 Comment(0)

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;
}

Linstock answered 27/9, 2019 at 7:46 Comment(0)

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.

Farrar answered 14/11, 2019 at 10:27 Comment(0)

In my case was a problem with a CAA record.

I have overseen the error, which was clear about this:

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: mydomain.com
  Type:   caa
  Detail: CAA record for mydomain.com prevents issuance

Removing the CAA record and all worked fine

Dichlamydeous answered 1/5 at 19:5 Comment(0)

In my case, I use Laravel and it thoughts the document root as the Laravel files folder. In Laravel case, Apache access folder and the Laravel code folder are different.

I had to change DocumentRoot to /var/www/html in files /etc/apache2/sites-available/<mydomain>.com.conf and /etc/apache2/sites-available/<mydomain>.com-le-ssl.conf and restart apache2. I use Ubuntu so I restarted using sudo systemctl restart apache2

Isotherm answered 1/6 at 15:22 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Check the cause on the web server

Permissions and access problem

Solution

Recommended topics

Hot tags