Certbot-auto failure, nginx server

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:

https://www.chtter.net

I ran this command:

./certbot-auto

It produced this output:

Waiting for verification…
Cleaning up challenges
Failed authorization procedure. chtter.net (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://chtter.net/.well-known/acme-challenge/dgpY8-MLXkC7KMOMnTP0G3K2QCNlRUSq5kLkyy1aKHA: “\n<html lang=“en”>\n\n<meta charset=“utf-8”>\nError\n\n\n

Cannot GET /.well-known/”, www.chtter.net (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.chtter.net/.well-known/acme-challenge/oxDVMFoVv9w6R-32_pA2z2V7aN2TOrN6iMdmc79EBfc: “\n<html lang=“en”>\n\n<meta charset=“utf-8”>\nError\n\n\n
Cannot GET /.well-known/”

IMPORTANT NOTES:

My web server is (include version):

nginx version: nginx/1.10.3 (Ubuntu)

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

Ubuntu 16.04.5 LTS

My hosting provider, if applicable, is:

AWS

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 version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):

certbot 0.30.2

Other
Sorry to raise this as a new topic. I see many similar threads, but none that have helped me. Like many others, this is happening on a site that has been active for years. I have been using certbot-auto to renew on a regular basis. It just stopped working, but there has been no change to the site that would have caused this. The site is currently running, but the certificates will expire in about a week, so I’ll have a problem then. The point, though, is that there is no issue with the domain name, IP addresses, DNS records, etc.

Thanks for any help.

Leigh

2

What was the rest of Certbot's output?

According to the HTTP headers, it's Express, not Nginx.

3

OK, so, there are 2 servers. The http server is express, that’s correct. The https server is nginx.

Here’s the full output.

Requesting to rerun ./certbot-auto with root privileges…
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx

Which names would you like to activate HTTPS for?

1: chtter.net
2: www.chtter.net

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): 1,2
Cert is due for renewal, auto-renewing…
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for chtter.net
http-01 challenge for www.chtter.net
Using default address 80 for authentication.
Using default address 80 for authentication.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. www.chtter.net (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.chtter.net/.well-known/acme-challenge/dxkaECfSorjZe5LzPTL0ZkfqH3ngX7GSjQS3tNGb7K4: “\n<html lang=“en”>\n\n<meta charset=“utf-8”>\nError\n\n\n

Cannot GET /.well-known/”, chtter.net (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://chtter.net/.well-known/acme-challenge/evYw3m5-S5gZARYA1WfLU-ATx0xgmDVwaPqbo8WAMzI: “\n<html lang=“en”>\n\n<meta charset=“utf-8”>\nError\n\n\n
Cannot GET /.well-known/”

IMPORTANT NOTES:
4

Have you tried using the “–webroot -w” option?

5

I have another site that is also using letsencrypt, and on that one the .conf file has a “webroot” entry. In this case, though (and I didn’t create this one) there is no webroot in the .conf file. Here it is, in case that helps. So, the answer is, no. And if I put -webroot in the certbot-auto command, it just says that webroot doesn’t exist.

renew_before_expiry = 30 days

version = 0.27.1
archive_dir = /etc/letsencrypt/archive/www.chtter.net
cert = /etc/letsencrypt/live/www.chtter.net/cert.pem
privkey = /etc/letsencrypt/live/www.chtter.net/privkey.pem
chain = /etc/letsencrypt/live/www.chtter.net/chain.pem
fullchain = /etc/letsencrypt/live/www.chtter.net/fullchain.pem

Options used in the renewal process

[renewalparams]
authenticator = nginx
installer = nginx
account = af775f1e96aed1d7ce152d5d9bc4f4d4
server = https://acme-v02.api.letsencrypt.org/directory

6

The "webroot" and the "documentroot" must match.
You must specify the webroot path with:
--webroot -w /your/actual/site/root/path

So review the virtual host file for that site and replace:
/your/actual/site/root/path
with the path found there for DocumentRoot (apache) or root (nginx).

[I can see/read you are using nginx - but future readers may not be using nginx]

7

Thanks, but still no success.

My actual site root path is /opt/www (at least that’s where the .well-known directory is) but when I use --webroot -w /opt/www I get pretty much the same thing. It behaved a little differently (told me to use certonly, which I did) and asked for the domain names this time (instead of telling me the names, and asking me to use numbers to select which certs I wanted to renew). But at the end of the process, the result was the same. “The client lacks sufficient authorization”, and “cannot GET .well-known”.

Any other ideas?

8

Huh. Well, I tried something else that seemed to actually work. At least, I got a “congratulations” message. So I’m hopeful.

For the “actual site root path” I tried the location of my http server instead. (The two locations are different.) And that seemed to do the trick. So:

./certbot-auto certonly --webroot -w /path/to/http/server

I did a few other things, like making sure that the http server (express in this case) was giving access to the .well-known directory. I don’t know if that was necessary or not, but since it’s working I’m not changing anything anymore.

Thanks to everyone who responded.

Leigh

9

This sounds like the default vhost (or some other vhost) is responding for the cert name(s) you requested.

10

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