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:
www.realisemotion.live
I ran this command:
sudo certbot --staging --nginx -d RealiseMotion.live -d www.RealiseMotion.live
It produced this output:
My web server is (include version):
nginx version: nginx/1.18.0 (Ubuntu)
The operating system my web server runs on is (include version):
Ubuntu 22.04.4 LTS
My hosting provider, if applicable, is:
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 1.21.0
The IP addresses for your hostname with and without the www subdomain are different, is that correct? The apex domain has two IP addresses configured and the www just one. And on the latter it seems no webserver is running on port 80.
Now that the above IP address has been removed, it should work.
I was mistaken with regard to port 80. The error "detail": "37.9.59.190: Fetching https://www.realisemotion.live: Connection refused" shows https:// being used, thus there being a HTTP to HTTPS redirect with nothing listening on port 443.
Yes. just saw that. First time I ever had to ponder one of those logs. I missed it. That IP seems to be from where I purchased it (domain) from. I did take a redirect off it on their control panel. Maybe that is what caused the issue?
Thanks for explaining. All helps in my learning curve!
It seems the 162.255.119.248 IP address redirected the validation client from http://realisemotion.live/... to https://www.realisemotion.live/... and the latter was not working ("connection refused"), yet.
So if at the time there was not yet a functional HTTPS webserver running on port 443 (see the "connection refused" error), the problem was the HTTP to HTTPS redirect on the erroneous IP address 162.255.119.248.
Now that HTTPS is working and the erroneous IP address has been removed, everything seems to be working just fine