CODEWITHSUNDEEP
nginxhttpslets-encrypt
zwl1619
zwl1619

Reputation: 4232

Using certbot to apply Let's Encrypt Certificate: Failed authorization procedure

I am using certbot to apply Let's Encrypt certificate, my server is centos 7.2 and nginx 1.11.9. what does this mean below?

[root@test ~]# certbot certonly --webroot -w /var/www/www.example.com -d example.com -d www.example.com

Failed authorization procedure. example.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://example.com/.well-known/acme-ch
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>", www.example.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.example.com/.well-known/acme-challenge/k
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>"

IMPORTANT NOTES:
 - If you lose your account credentials, you can recover through
   e-mails sent to [email protected].
 - The following errors were reported by the server:

   Domain: example.com
   Type:   unauthorized
   Detail: Invalid response from
   http://example.com/.well-known/acme-challenge/wGNv57IGJjHQ9wyzzALktpNaPzfnTtN3m7u3QuO4p40:
   "<html>
   <head><title>404 Not Found</title></head>
   <body bgcolor="white">
   <center><h1>404 Not Found</h1></center>
   <hr><center>"

   Domain: www.example.com
   Type:   unauthorized
   Detail: Invalid response from
   http://www.example.com/.well-known/acme-challenge/kFJ0CSuKOdgcT2xmciB4GGNCcnUPoIbpQmA9jOII_Bk:
   "<html>
   <head><title>404 Not Found</title></head>
   <body bgcolor="white">
   <center><h1>404 Not Found</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.
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

I can access example.com and www.example.com,and there is a note in docs: https://certbot.eff.org/#centosrhel7-nginx

Note: To use the webroot plugin, your server must be configured to serve files from hidden directories. If /.well-known is treated specially by your webserver configuration, you might need to modify the configuration to ensure that files inside /.well-known/acme-challenge are served by the webserver.

Is that the reason? How to modify the configuration?

Upvotes: 17

Views: 25655

Answers (5)

Dankyi Anno Kwaku
Dankyi Anno Kwaku

Reputation: 1293

It could be a number of things causing the issue so I have put below some things you should do or check to resolve the issue. Before you start, know your server's IPv4 and IPv6 addresses by running the command below in terminal.

hostname -I

Now, start the steps below.

1. IPv4 DNS Check

Go to https://dnschecker.org and do an A record check for both example.com AND www.example.com if you are setting SSL for the two which you should. They are not the same thing. It's possible for example.com to be showing your website but www.example.com won't be showing your site.

Make sure the DNS results for both are showing the IPv4 of your server address. If they are not, go and set A records that point example.com to your server IPv4 address and set a CNAME that points your www.example.com to your example.com This article shows how. It's quite easy. https://www.hostinger.com/tutorials/dns/how-to-point-domain-to-vps.

2. IPv6 DNS Check

Go to https://dnschecker.org and do an AAAA record check for both example.com AND www.example.com. You may see that the IPv6 address shown is not the IPv6 of your server. It can be that your IPv4 might be okay but LetsEncrypt/Certbot prefers to use IPv6 so if your server has it set up and its, then LetsEncrypt/Certbot might be trying to use it and that is why it is failing.

So if it is a wrong IPv6, go and set AAAA records that point your example.com to your server's IPv6 address. Use this link to help you set the AAAA record. https://support.hostinger.com/en/articles/8899705-how-to-manage-aaaa-records

3. Firewall check. ufw /. Cloudflare

You need to check that http and https is allowed. Login to terminal and run the command below one line after the other.

sudo ufw allow 'Nginx Full'
sudo ufw allow http
sudo ufw allow https

If you have set Cloudflare firewall rules, check that they are not preventing requests.

4. Nginx Configuration File Check

Sometimes it can happen that your nginx configuration file has issues. Check first that no syntax error occurs by running the command below in terminal and it will tell you if it is successful.

nginx -t

After that, open the config file using the command below (edit command to suit your situation.

sudo nano /etc/nginx/sites-available/default

Check that you have the right domain names at your server_name like below

server_name example.com www.example;

Check that root points to the root of your publicly available website

root /var/www/mywebsiteroot;

Check that the syntax is fine with nginx -t and then restart nginx with command below

sudo systemctl restart nginx

5. Rerun certbot

certbot --nginx -d example.com -d www.example.com

Upvotes: 0

paul
paul

Reputation: 479

sudo service nginx stop

then run Let's Encrypt commands, after this run

sudo service nginx restart all

Upvotes: 2

HasilT
HasilT

Reputation: 2609

@user234683 answer helped me a alot.

In my case the problem was with the cloudflare. Somehow cloudflare is not redirecting certbots request to my servers. When I opened /.well-known/acme-challenge on browser it clearly mentioned a cloudflare error. So here what I did, I disabled ssl on cloudflare then renewed certificate on my server - everything finished in two minutes.

Hope it helps someone out there.

Upvotes: 2

user234683
user234683

Reputation: 373

I was having this problem. I figured it out after 4 grueling hours of debugging. If your server supports both ipv4 and ipv6, make sure you have BOTH of these lines in your server configuration:

listen 80;
listen [::]:80;

The [::]: in the second line tells it to listen on ipv6. If you're missing that second line, what will happen is that when you run certbot, the LetsEncrypt server will try to access your server via ipv6. But since your application vhost isn't listening on ipv6, nginx will direct it to the default vhost handler if you have it enabled (since that handler DOES listen on ipv6). Since the default handler can't serve the required challenge file, it will give a 404.

If this doesn't fix your problem: in general, when debugging certbot, make sure the request isn't being handled by the default vhost (or any other vhost). You can check this by adding a log directive to the configuration file for the default vhost, running certbot, and then checking the log file you specified to see if the request from Letsencrypt shows up in there. If this isn't the problem, check if you can access the challenge file from your browser. To do this, you'll need to add the location directives that certbot adds to your application configuration file. Certbot will dump its modifications to the config file in its log file. In my experience, it doesn't actually create the challenge files in /.well-known/acme-challenge. It literally just hardcodes the response for that url into the config file. So recreate that and then check if you can access it from your browser.

Upvotes: 18

Arnon
Arnon

Reputation: 2244

This is a pretty common problem but fortunately should be an easy fix. Let's Encrypt must be able to read from the .well-known directory to verify that your server actually hosts the domain you want a certificate for.

First, make sure you have a .well-known directory in your website root. Set your permissions so that it is readable from the outside; 775 should be perfect.

Then, add this snippet to your virtual host file in Nginx:

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

This will allow any requests to the .well-known directory we just created. Now, try requesting a cert again, and see if it works.

Upvotes: 11

Related Questions