Certbot --nginx maybe not writing to acme-challenge?

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: phippsfamily.net

I ran this command: certbot --nginx

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for phippsfamily.net

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Identifier: phippsfamily.net
Type: unauthorized
Detail: 45.26.144.103: Invalid response from http://phippsfamily.net/.well-known/acme-challenge/92jITe6Az1PfVdgRffbh0m0wc5BDgS55vzAG2Ck0FvM:
404

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 Cert
bot with -v for more details.

My web server is (include version): nginx/1.14.1

The operating system my web server runs on is (include version): "Rocky Linux 8.10 (Green Obsidian)"

My hosting provider, if applicable, is: (self hosted)

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 5.8.0

I can drop in a temp file to: /var/www/phippsfamily.net/.well-known/acme-challenge and I can fetch it successfully from a couple of different places on the internet. (There is currently a file named 'abc' there that contains a recent datestamp)

In the debug log I can see the following error on the challenge:
"error": {
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "45.26.144.103: Invalid response from http://phippsfamily.net/.well-known/acme-challenge/92jITe6Az1PfVdgRffbh0m0wc5BDgS55vzA
G2Ck0FvM: 404",
"status": 403
},
I should also point out that I've been using letsencrypt on this domain, but this is my first time trying certbot on it.

Well, right now I am getting failures connecting to your server. So, perhaps it is down for service.

But, the --nginx option does not write a file to your local drive. Instead, it modifies the nginx config to return the needed data directly. After the challenge these changes are reversed. The exact changes are shown in the /var/log/letsencrypt log file. After each change it reloads nginx to effect those changes.

A 404 with --nginx is almost always something peculiar in your nginx config. For example, listening on specific IP addresses, typos in the server_name and various other things.

Perhaps checking your nginx error log will help explain the 404.

We can usually identify the problem if you post your nginx config. We'll need the whole thing such as uploading the config.txt file in your home directory resulting from this:

sudo nginx -T >~/config.txt

An upper case T is essential. The file will be somewhat long. The command itself emits just a couple lines but the file has the config.

OK -- it is good to know it is not supposed to write that file directly... I didn't realize that, and it wasn't obvious (to me) from the letsencrypt.log file.

Yes, I've been playing with my nginx.conf file, as it is messy and supports a number of things... I believe the initial problem was because I had a 'listen 8080' section trying to handle the http -- which I now understand probably confuses the nginx module in letsencrypt. I tried switching that to port 80, and now I'm getting unable to connect to server -- probably what you saw. I have ports 80,8080, and 443 being forwarded by my router to the hosting machine. I have firewall opened for 80 and 443 (looks like it was not open on 8080...). I thought I had my default port80 server setup to: return 301 https://$host$request_uri; which I think I had working on a different machine with certbot... so at the moment I'm trying to compare a working system, to a non-working one. I'd rather not post my ugly nginx.conf as it has a lot of cruft in it, and I'd hate someone else to try to wade through it... but I may try to get down to a minimal one and post that if I still can't get things ironed out.

The --nginx option uses an HTTP Challenge. Which means the Let's Encrypt server sends HTTP requests on port 80 to your server to validate your control.

And, often, those arrive in nginx on port 80. Certbot, by default, updates an nginx server_block that listens on port 80 for your domain name (the one(s) in the -d statements).

However, if you forward port 80 from your router to, say, port 8080 on your nginx machine then you need to tell Certbot to update the server_block that listens on this alternate port. You do this with the --http-01-port option.

If Certbot does not find a server block that has the right domain name with the expected port it makes a temporary server block. Sometimes this works and sometimes not. Your initial conditions along with this was probably the reason for initial failures. In any case, it is almost aways a bad idea to rely on Certbot making this temporary server block.

I've seen literally hundreds of nginx configs and pretty easily wade through the cruft. From a Certbot and HTTP Challenge I can focus just on those related parts.

However, you should decide how you want your router and nginx server to interact. That is, do you need to forward on a different port? If so, which one? Are you going to do a similar port mapping for HTTPS on port 443?

Using https://letsdebug.net is a helpful tool with new setups. It can't find all the problems but if you pass that there's a good chance it will work. If not then almost certainly not.

OK -- I've pasted somewhat trimmed down config to: View paste O55TM It seems to have the same problem, so I'm hoping you can see something that stands out to you :slight_smile:

I am forwarding the ports (80,443) from router to same port on server -- so hopefully no special port messing around is needed.

I feel like this is a problem in my router config... as port 80 shows open, from within my LAN -- but is showing closed from outside... I'm still trying to track down the problem...

That nginx config looks okay for Certbot

I agree something is likely wrong in the router. I am getting a "connection refused" trying to reach your domain right now. That is likely your router or a firewall.

Are there other domains on that same nginx that are working? What is one? That might help isolate. Or, try https://letsdebug.net for one that works vs this one

If a request reaches that nginx it should appear in your access_log

/var/log/nginx/access.log

Also check the default error_log

If you don't see anything in those nginx logs then the request is never arriving there

OK -- figured it out... sigh .... my router config was showing that 'http' was being forwarded from outside to my server port 80....however, checking further it looks like I had (long ago) edited the definition of 'http' to reference port 8080... so that's what was being forwarded (and why my previous config had 8080 ports in nginx.conf). So, when I changed those to work better with certbot, I needed to fix my router routing.... Thanks so much for the time and patience to help me work through that.