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.
My web server is (include version): nginx/1.18.0
The operating system my web server runs on is (include version): Debian 11.7
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 2.6.0
Hmm. The log has some unusual error messages but I'm not sure why they result in the final error shown.
I don't see that you had a server block with the server_name for predictions.hopto.org. It looks like Certbot created a temporary one for you. It's best if you already have one.
Does your nginx config test ok? That is, what does this say?
nginx -t
Was nginx running prior to the certbot --nginx command?
EDIT: Had you tried running certbot --nginx before this without having nginx running?
Here are the other errors in the log. Any guesses where these came from? Did you have some of these names in the command you tried? Are these names you have in other files in your conf.d folder?
2023-05-21 18:16:51,770:DEBUG:certbot.util:Not suggesting name "localhost"
certbot.errors.ConfigurationError: localhost needs at least two labels
2023-05-21 18:16:51,771:DEBUG:certbot.util:Not suggesting name "_"
certbot.errors.ConfigurationError: _ contains an invalid character. Valid characters are A-Z, a-z, 0-9, ., and -.
2023-05-21 18:16:51,771:DEBUG:certbot.util:Not suggesting name "192.168.1.110"
certbot.errors.ConfigurationError: Requested name 192.168.1.110 is an IP address. The Let's Encrypt certificate authority will not issue certificates for a bare IP address.
2023-05-21 18:16:53,859:DEBUG:certbot._internal.display.obj:Notifying user: Requesting a certificate for predictions.hopto.org
nginx -t shows that everything is ok and there is a file in sites-enabled with the server_name entry for predictions.hopto.org.
Looking through the logs after further testing I can see that it's not finding the config file, as you say. Not sure why, though. Might it be because nginx is acting as a reverse proxy and is accessed via port forwarding so it not on 80?
A possible further issue is that the end destination is a dancer2 app so does not use static files but I've setup a route to return the contents of the created file - not that it's getting anything at the moment.
Is that file also in sites-available? We recently saw a problem when most config files were in -available and -enabled but one of them was just in -enabled
The nginx config is listening on port 80. Can you explain what you mean by this?
The way the HTTP Challenge works with the --nginx plug-in is that it Certbot makes temp changes to your nginx config. It add a "return" line with the exact value needed to solve the Challenge. There is no file like there is when using --webroot.
Can you show result of these? Just making sure we have a single nginx
All the entries in sites-enabled are symlinks from sites-available to there are matching entries.
With regards my comment about port 80: the setup is router listens on port 80 but forwards to a different port (let's say 1234) on the local server which hosts nginx and this is setup to listen for predictions.hopto.org on port 1234 which then talks to the psgi/dancer2 app via a unix socket.
Output from the commands you requested:
root@plexserver:~# cat /var/run/nginx.pid
141412
root@plexserver:~# sudo systemctl status --no-pager --full nginx
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2023-05-22 12:23:38 BST; 4h 17min ago
Docs: man:nginx(8)
Process: 141410 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Process: 141411 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 141412 (nginx)
Tasks: 5 (limit: 38093)
Memory: 6.2M
CPU: 97ms
CGroup: /system.slice/nginx.service
├─141412 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
├─141468 nginx: worker process
├─141469 nginx: worker process
├─141470 nginx: worker process
└─141471 nginx: worker process
May 22 12:23:38 plexserver systemd[1]: Starting A high performance web server and a reverse proxy server...
May 22 12:23:38 plexserver systemd[1]: Started A high performance web server and a reverse proxy server.
root@plexserver:~# sudo ps -eF | grep nginx
root 141412 1 0 2296 3628 5 12:23 ? 00:00:00 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
www-data 141468 141412 0 2521 4176 2 12:24 ? 00:00:00 nginx: worker process
www-data 141469 141412 0 2521 4176 3 12:24 ? 00:00:00 nginx: worker process
www-data 141470 141412 0 2521 4176 7 12:24 ? 00:00:00 nginx: worker process
www-data 141471 141412 0 2521 4176 6 12:24 ? 00:00:00 nginx: worker process
root 144639 144490 0 1579 644 6 16:41 pts/0 00:00:00 grep nginx
I can see how that worked but your original method would have worked with one adjustment. Sorry I didn't remember it until now.
When using a non-standard port with the nginx plug-in you need to add --http-01-port xxxx to the certbot command. Where xxxx is your non-standard port.
Certbot --nginx plug-in will then add the needed challenge "return" statement to the server block with your domain name and this --http-01-port value.
Thanks Mike. I might move it back to the port forward but there's no real harm leaving it on port 80.
That change, coupled with the added route means that it all plays nicely with dancer2. I'm leaving that there in case anyone, in future, comes across a similar problem.