Having problems obtaining an SSL certificate

Help
1

My domain is: selbyironworks.com

I ran this command: sudo certbot --nginx --redirect -d selbyironworks.com -d www.selbyironworks.com
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for selbyironworks.com and www.selbyironworks.com

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: selbyironworks.com
Type: unauthorized
Detail: 2001:19f0:5:4e63:5400:4ff:fe90:6da2: Invalid response from http://selbyironworks.com/.well-known/acme-challenge/FisXBiyRohebtiV_JapUt14sHbX3RTKSceqMIoY40ps: 404

Domain: www.selbyironworks.com
Type: unauthorized
Detail: 2001:19f0:5:4e63:5400:4ff:fe90:6da2: Invalid response from http://www.selbyironworks.com/.well-known/acme-challenge/zQ96OgvwwB2HUM_B2zXvkFSn4PVV0ZvRcbzO26hzqs4: 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 Certbot with -v for more details.

My web server is (include version): Nginx

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

My hosting provider, if applicable, is: vultr

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):

root@vultr:~# netstat -an | grep LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp6 0 0 :::22 :::* LISTEN
tcp6 0 0 :::80 :::* LISTEN
unix 2 [ ACC ] STREAM LISTENING 15966 /run/user/0/systemd/private
unix 2 [ ACC ] STREAM LISTENING 15975 /run/user/0/bus
unix 2 [ ACC ] STREAM LISTENING 15982 /run/user/0/gnupg/S.dirmngr
unix 2 [ ACC ] STREAM LISTENING 15984 /run/user/0/gnupg/S.gpg-agent.browser
unix 2 [ ACC ] STREAM LISTENING 15986 /run/user/0/gnupg/S.gpg-agent.extra
unix 2 [ ACC ] STREAM LISTENING 15988 /run/user/0/gnupg/S.gpg-agent.ssh
unix 2 [ ACC ] STREAM LISTENING 15990 /run/user/0/gnupg/S.gpg-agent
unix 2 [ ACC ] STREAM LISTENING 13326 /run/systemd/private
unix 2 [ ACC ] STREAM LISTENING 13328 /run/systemd/userdb/io.systemd.DynamicUser
unix 2 [ ACC ] STREAM LISTENING 13329 /run/systemd/io.system.ManagedOOM
unix 2 [ ACC ] STREAM LISTENING 13340 /run/systemd/fsck.progress
unix 2 [ ACC ] STREAM LISTENING 13348 /run/systemd/journal/stdout
unix 2 [ ACC ] SEQPACKET LISTENING 13350 /run/udev/control
unix 2 [ ACC ] STREAM LISTENING 13790 /run/systemd/journal/io.systemd.journal
unix 2 [ ACC ] STREAM LISTENING 15285 /run/dbus/system_bus_socket

thank you for your time.

2 Likes
2

Welcome @selbyironworks

A 404 error with the --nginx plug-in is usually something unusual in the nginx server block configuration. Can you upload the config.txt file from this command

sudo nginx -T >config.txt

capital T is essential

Also, I am curious. I see you got a wildcard cert a couple days ago. That would have required using a DNS Challenge. Why are you now switching to --nginx plug-in and HTTP Challenge?

4 Likes
3

I'm still learning about this process, so I appreciate your patience. I'm using the --nginx plug-in and HTTP Challenge because I'm trying to set up a simple static website for my business. I was using Bluehost to make my website, but I didn't need everything they were offering, so I canceled it and I want to make a static website. I'm a noob at this and only know basic Linux

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Thanks again for your help.

4

Please try again with capital T. Thanks for explaining about prior situation

3 Likes
5

root@vultr:~# sudo nginx -T >config.txt

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

6

I am looking for the contents of the config.txt file. Can you upload that?

There is an upload button on the post menu (has an up arrow).

2 Likes
7

I opened the config.txt file and there is nothing in it.

8

config.txt (8.4 KB)

1 Like
9

sorry I think I found it

10

Yes, that's it :slight_smile:
This file

# configuration file /etc/nginx/sites-enabled/selbyironworks.com:

should look like below instead. You are missing the listen statement for IPv6. So, when Let's Encrypt makes an IPv6 HTTP request it goes to your default server instead which is listening for IPv6.

# configuration file /etc/nginx/sites-enabled/selbyironworks.com:
server {
  listen 80;
  listen [::]:80;   # THIS IS THE MISSING LINE
  server_name selbyironworks.com www.selbyironworks.com;

  location / {
    root /var/www/html/selbyironworks.com;
    index index.html;
  }
}
3 Likes
11

Note this:

(it's usually the other way around)

C:\Users\peppe>curl -IL6 http://selbyironworks.com/
HTTP/1.1 200 OK
Server: nginx/1.22.1
Date: Wed, 06 Sep 2023 22:34:30 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Wed, 06 Sep 2023 17:59:43 GMT
Connection: keep-alive
ETag: "64f8be0f-267"
Accept-Ranges: bytes


C:\Users\peppe>curl -IL4 http://selbyironworks.com/
HTTP/1.1 403 Forbidden
Server: nginx/1.22.1
Date: Wed, 06 Sep 2023 22:34:38 GMT
Content-Type: text/html
Content-Length: 153
Connection: keep-alive
2 Likes
12

Did we cross-post?

Yeah, it almost looks like IPv4 in DNS is pointing to a different nginx than what is shown here. I don't see anything in their nginx config to cause that 403.

But, the IPv6 fix I showed should fix the cert problem anyway. Well, at least they need that listen clause for IPv6 so we'll see :slight_smile:

3 Likes
13

I don't know. I noticed the validation failing with an IPv6 and I started checking if that was the same machine on IPv4 -- it looks like it's the same machine.

Also, it answers fine without SNI:

C:\Users\peppe>curl -IL [2001:19f0:5:4e63:5400:4ff:fe90:6da2]
HTTP/1.1 200 OK
Server: nginx/1.22.1
Date: Wed, 06 Sep 2023 22:31:46 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Wed, 06 Sep 2023 17:59:43 GMT
Connection: keep-alive
ETag: "64f8be0f-267"
Accept-Ranges: bytes

C:\Users\peppe>curl -IL 144.202.6.17
HTTP/1.1 200 OK
Server: nginx/1.22.1
Date: Wed, 06 Sep 2023 22:32:57 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Wed, 06 Sep 2023 17:59:43 GMT
Connection: keep-alive
ETag: "64f8be0f-267"
Accept-Ranges: bytes
4 Likes
14

The missing listen explains the cert fail. Your non-sni hit the default server. Not sure why 403 with IPv4 and sni but one at a time

3 Likes
15

Try moving the "root" statement outside the "location" block.

2 Likes
16

That won't affect certbot using Nginx plugin. Maybe it could explain the 403

3 Likes
17

I was trying to fix the 403.

To that end...
I'd also insert the following into that "location" block:
try_files $uri $uri/ =404;

2 Likes
18

As for the --nginx plugin failing...
I'd move the relevant server block into it's own ".conf" file and place it in the included directory.
include /etc/nginx/conf.d/*.conf;

2 Likes
19

Why don't you like it in the sites-enabled folder? It already was its own config file there

2 Likes
20

Thank you everyone, I have resolved the issue.

2 Likes