CODEWITHSUNDEEP
nginxencryptionlets-encryptunauthorized
Dealeo - Jerome Mansbendel
Dealeo - Jerome Mansbendel

Reputation: 319

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?

Upvotes: 9

Views: 27527

Answers (12)

Parth Mangukiya
Parth Mangukiya

Reputation: 11

I am facing same issue and found solution, simply change .well-known directory permission to 755

Upvotes: 0

KamWebDev
KamWebDev

Reputation: 377

You can add permissions for your apache/httpd user inside public folder:

cd /var/www/example/    
mkdir -p .well-known/acme-challenge  
chmod 775 -R .well-known
chown apache:apache -R .well-known
cd .well-known
setfacl -d -m u::rwx,g::rwx,o::rwx acme-challenge

Upvotes: 0

Aminah Nuraini
Aminah Nuraini

Reputation: 19146

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

Upvotes: 0

fguillen
fguillen

Reputation: 38772

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

Upvotes: 0

esco_
esco_

Reputation: 81

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.

Upvotes: 0

lonix
lonix

Reputation: 20509

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

Upvotes: 0

Ethan Ducre
Ethan Ducre

Reputation: 31

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.

Upvotes: 3

PKumar
PKumar

Reputation: 546

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

Upvotes: 0

Lilly-R B
Lilly-R B

Reputation: 213

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.

Upvotes: 11

Thomas
Thomas

Reputation: 388

In your server block, add:

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

Upvotes: 3

Paulo Henrique
Paulo Henrique

Reputation: 499

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

Upvotes: 2

Chris
Chris

Reputation: 8647

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

Upvotes: 1

Related Questions