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. crt.sh | 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:
solr.iges.jp
I ran this command: sudo certbot --nginx -d solr1.iges.jp
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for solr1.iges.jp
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. solr1.iges.jp (http-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from https://www.iges.or.jp/.well-known/acme-challenge/ex_UfY-isZ8-0PAvAD6ulw4YDi-IBeuwmr-mHsQ49HY? [2606:4700:10::ac43:a1a]: "\n404 Not Found\n<body bgcolor="white">\n
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address.
My web server is (include version):
nginx version: nginx/1.14.0 (Ubuntu)
The operating system my web server runs on is (include version):
Ubuntu 18.04.5 LTS
My hosting provider, if applicable, is:
Linode
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.31.0
Note that the Invalid response seems to be coming from another of our domains, and I can't figure out where it might be getting redirected. How can I debug this?
Well the message shows that the original request has been redirected to another FQDN.
You will need to review the vhost config and likely make an exception to not redirect the challenge requests.
There must be some weird dns cache somewhere or something. When I run the same command, I get:
~ curl -Iki solr1.iges.jp/.well-known/acme-challenge/Test-File-1234
HTTP/1.1 404 Not Found
Server: nginx/1.14.0 (Ubuntu)
Date: Wed, 25 Aug 2021 10:07:47 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 178
Connection: keep-alive
Also I noticed that somehow I had a prehistoric version of certbot, so I reinstalled it, but get much the same output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for solr1.iges.jp
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: solr1.iges.jp
Type: unauthorized
Detail: Invalid response from https://www.iges.or.jp/.well-known/acme-challenge/-murAGIIRzUBu2w4fIz_xHdZ6M3H_2bjbH4O8f8K1IE? [2606:4700:10::6816:b1b]: "<html>\n<head><title>404 Not Found</title></head>\n<body bgcolor=\"white\">\n<center><h1>404 Not Found</h1></center>\n<hr><center>ngin"
Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
Sorry, I meant to include my virtual host config from nginx, but I forgot. I'll nclude that here. The previous curl output was run on my laptop terminal, not from the server.
solr1.iges.jp.conf:
server {
server_name solr1.iges.jp;
root /var/www/my-iges-solr.iges.jp/testbed;
index index.html;
autoindex off;
charset utf-8;
error_page 404 /404.html;
error_log /var/log/nginx/error.solr1.iges.jp.log;
access_log /var/log/nginx/access.solr1.iges.jp.log;
# include global/restrictions.conf;
# auth_basic "Authorized access only.";
# auth_basic_user_file /var/www/my-iges-solr.iges.jp/.htpasswd;
# Very rarely should these ever be accessed outside of your lan
location ~* \.(txt|log)$ {
allow 192.168.0.0/16;
deny all;
}
location ~ \..*/.*\.php$ {
return 403;
}
# Block access to scripts in site files directory
location ~ ^/sites/[^/]+/files/.*\.php$ {
deny all;
}
# Allow "Well-Known URIs" as per RFC 5785
location ~* ^/.well-known/acme-challenge/ {
allow all;
auth_basic off;
}
# Block access to "hidden" files and directories whose names begin with a
# period. This includes directories used by version control systems such
# as Subversion or Git to store control files.
# location ~ (^|/)\. {
# return 403;
# }
location /solr {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass "http://127.0.0.1:8983";
}
location /data {
return 403;
}
location /conf {
return 403;
}
location /logs {
return 403;
}
}
It would connect over the internet the server is in a data center, not on the same network as me. I also tried the command from a different linode server and got the same result
The provided piece of the nginx config doesn't show the problem - it must be elsewhere.
If you have trust issues/security concerns (I know I sure do), you can PM the output to me - so the entire Internet doesn't see it.
But I'm certain the problem can be found therein.
Even if it is the right IP address, make sure that nginx is listening on both IPv4 and IPv6.
There are no listen statements shown in the file: solr1.iges.jp.conf