Failed authorization procedure Debian 8 Nginx

Help
1

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: seeknsupply.com

I ran this command: certbot certonly --webroot -w /home/dev/sites/seeknsupply2 -d seeknsupply.com
(as root)

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for seeknsupply.com
Using the webroot path /home/dev/sites/seeknsupply2 for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. seeknsupply.com (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://seeknsupply.com/.well-known/acme-challenge/GzGCl7pKtNAVmWm0rXnpbTz6HOwtuB6o46P4riSA3Fs: "

<meta "

IMPORTANT NOTES:

My web server is (include version): nginx 1.6.2

The operating system my web server runs on is (include version): Debian 8 Jessie

My hosting provider, if applicable, is: DigitalOcean

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): no

The domain points to the correct IP address on my DNS A entry. I am not sure why I have no authorization.

Please let me know if there is something I have missed.

Thanks

2

Certbot places a file to verify your ownership of the domain at /home/dev/sites/seeknsupply2/.well-known/acme-challenge/GzGCl7pKtNAVmWm0rXnpbTz6HOwtuB6o46P4riSA3Fs but the validation server gets a 404 error when it tries to retrieve it from http://seeknsupply.com/.well-known/acme-challenge/GzGCl7pKtNAVmWm0rXnpbTz6HOwtuB6o46P4riSA3Fs.

If you’re sure the /home/dev/sites/seeknsupply2/ path is correct, there is probably an issue in your nginx configuration that prevents this static file from being served. You could create a test file /home/dev/sites/seeknsupply2/.well-known/acme-challenge/test.txt or so and try and access it at http://seeknsupply.com/.well-known/acme-challenge/test.txt to debug it yourself. Or you can share the server block from your nginx configuration and maybe we can identify what the problem could be.

3 Likes
3

Apologies for the delayed response.
I was unable to access the test file from a browser.

Please view my nginx code block for the site.
Nginx config

4

Your nginx configuration proxies all requests to another web server running on port 8000. Since this server is answering your requests and doesn’t know about the certbot validation files, you get an error.

You could pass the webroot for the port 8000 server to certbot, if one exists. But this seems unlikely since you have a /static location rule in nginx.

So you can add the following location block to your nginx configuration, which will tell nginx not to proxy these connections to the port 8000 server:

location /.well-known/acme-challenge/ {
    root /home/dev/sites/seeknsupply2;
}
1 Like
5
[quote="edsns, post:1, topic:48268"] --webroot -w /home/dev/sites/seeknsupply2 [/quote]

You may also want to switch to the Nginx plugin. To do so, remove the --webroot and -w flags above, and add:

--nginx

I believe this should just take care of everything for you, and you won’t need to add a location directive.

If I can ask, were you following a specific tutorial when you chose the --webroot method? Now that --nginx is available, we’d like to encourage people to use it, which may include updating tutorials.
6

I used the guide detailed here: https://certbot.eff.org/#debianjessie-nginx

7

Aha, I just checked with a colleague and discovered that the version of the Nginx plugin available in jessie-backports is too out-of-date, and so our current recommendation is indeed to use --webroot. Sorry for the misleading advice above, please disregard.

8

So I applied this and it worked in regards to displaying the test file.

Before this, I was a little impatient and applied the following to see what would happen:
$ sudo certbot certonly --standalone -d seeknsupply.com.

The terminal did return a successful message. After editing the nginx file according to what you recommended,
I tried again with the original command
certbot certonly --webroot -w /home/dev/sites/seeknsupply2 -d seeknsupply.com

I chose to replace the previous key. All messages return as successful but I am unable to open the site vis https.

Here is the return message:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Cert not yet due for renewal

You have an existing certificate that has exactly the same domains or certificate name you requested and isn’t close to expiry.
(ref: /etc/letsencrypt/renewal/seeknsupply.com.conf)

What would you like to do?

1: Keep the existing certificate for now
2: Renew & replace the cert (limit ~5 per 7 days)

Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): 2
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for seeknsupply.com
Using the webroot path /home/dev/sites/seeknsupply2 for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0003_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0003_csr-certbot.pem

IMPORTANT NOTES:

  • Congratulations! Your certificate and chain have been saved at
    /etc/letsencrypt/live/seeknsupply.com/fullchain.pem. Your cert will
    expire on 2018-03-14. To obtain a new or tweaked version of this
    certificate in the future, simply run certbot again. To
    non-interactively renew all of your certificates, run “certbot
    renew”

  • If you like Certbot, please consider supporting our work by:

    Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
    Donating to EFF: https://eff.org/donate-le

9

What’s weird is when I went to your site, it gives me a “connection refused” error.

10

“certbot certonly” creates certificates, but doesn’t configure software to use them.

If you have a fairly recent version of Certbot – which you probably don’t, on Debian Jessie – using “certbot --nginx” is a good idea; it creates certificates and configures Nginx to use them.

Using certonly, it’s necessary to configure HTTPS in Nginx.

11

Agreed, i’ve always used the certbot command and it’s much better then certonly for NGINX / Apache

12

I tried again with the nginx plugin. It works now thank you very much.

When testing on Qualys, I received a B grade. Do I need to worry about the Diffie-Hellman (DH) key exchange parameters?

13

Weak Diffie-Hellman paramaters make your website susceptible to the Logjam attack. Since a minority of clients use Finite Field Diffie-Hellman Exchange (DHE) these days in favor of Elliptic Curve Diffie-Hellman Exchange (ECDHE), which does not have this issue, SSLLabs only downgrades you to a B rating for this issue.

But it is fairly easy to resolve this.

Copy and paste the contents of the ffdhe2048 section of the Mozilla SSL Configuration Guide to a file /etc/nginx/dhparam.pem or so or generate your own with:

openssl dhparam 2048 -out /etc/nginx/dhparam.pem

And then refer to it in your nginx configuration like so:

ssl_dhparam /etc/nginx/dhparam.pem;
1 Like
14

Thank you so much for this info.

I had never heard about it before so I will do some reading up on it.

15

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