Reinstalled Server, Now Fails Challenge

Help
1

The system was working - at least, certbot was - then was reinstalled from scratch, so the challenge info was wiped out. How do I restore it?

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. https://crt.sh/?q=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: motsstodon.social

I ran this command: sudo certbot -v certonly --nginx --agree-tos --no-eff-email --staple-ocsp --preferred-challenges http -m rogerk@queernet.org -d motsstodon.social

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Plugins selected: Authenticator nginx, Installer nginx

Requesting a certificate for motsstodon.social

Performing the following challenges:

http-01 challenge for motsstodon.social

Waiting for verification...

Challenge failed for domain motsstodon.social

http-01 challenge for motsstodon.social

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:

Domain: motsstodon.social

Type: connection

Detail: 216.252.162.125: Fetching http://motsstodon.social/.well-known/acme-challenge/CSRUBqnjEaoju5DOdxKS6A1W7Ply_KAnARSCa8-Rwwk: Error getting validation data

My web server is (include version):

Nginx 1.24

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

Rocky 9.1

My hosting provider, if applicable, is:

Self

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

2.6.0

2

Have you opened up port 80 on your server's firewall, if any?

Is nginx listening on port 80?

$ curl -i motsstodon.social
curl: (7) Failed to connect to motsstodon.social port 80 after 796 ms: Couldn't connect to server
3 Likes
3

Firewall is open, yes. I just shut down Nginx when I edited the config - it can't listen unless I comment out https... But the failure is not just from that - the http-01 challenge was wiped out in the reinstall.

4

Well, certbot certonly --nginx requires nginx to start up and listen on its ports.

I suggest getting nginx into a state where it can start up, then trying again.

5 Likes
5

However this is what I see; filtered Ports, not Open Ports

$ nmap -Pn -p80,443 motsstodon.social
Starting Nmap 7.80 ( https://nmap.org ) at 2023-05-13 14:51 UTC
Nmap scan report for motsstodon.social (216.252.162.125)
Host is up (0.029s latency).

PORT    STATE    SERVICE
80/tcp  filtered http
443/tcp filtered https

Nmap done: 1 IP address (1 host up) scanned in 0.48 seconds
2 Likes
6

OK, ports are open now. Doesn't change the activity. Cert won't issue because Nginx -t won't test because cert file doesn't exist.

7

It sounds like your certs were deleted also. If you don't have a backup of those you will need to remove the HTTPS server block(s) from nginx that you no longer have the certs for. Then, re-run certbot.

For more instruction on safely removing certs see below. I know it's too late for you to safely remove them but it has helpful info on restoring your failing nginx.
https://eff-certbot.readthedocs.io/en/stable/using.html#safely-deleting-certificates

3 Likes
8

I now see them as closed

$ nmap -Pn -p80,443 motsstodon.social
Starting Nmap 7.80 ( https://nmap.org ) at 2023-05-13 18:02 UTC
Nmap scan report for motsstodon.social (216.252.162.125)
Host is up (0.029s latency).

PORT    STATE  SERVICE
80/tcp  closed http
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 0.47 seconds
2 Likes
9

[rogerk@motsstodon ~]$ sudo firewall-cmd --permanent --list-services
cockpit dhcpv6-client http https ssh

10

Your ports will show closed until you have nginx running.

You can check that with

sudo netstat -pant | grep -i listen | grep -Ei 'nginx|:80|:443'
4 Likes
11

Closed means nothing's listening. Filtered means it's firewalled.

12

I think that's the other way.
Filtered means nothing's listening responding. Closed means it's firewalled [rejected].

3 Likes
13

Correct. Vicious cycle. It can't run till the certs are there. The certs can't be issued till it's running.

There was a server with this name and IP before, for which Letsencrypt issued certs with an http-01 challenge. I reloaded the server from scratch. It is no longer able to respond to the challenge, unless someone tells me if I can reconstruct the challenge from logged attempts.

Otherwise, is there a way to convince let's encrypt to start from scratch? Or to use a different sort of challenge?

14

Use any cert in place of the missing one.
That will get the web server going.
That will get you a real cert.

2 Likes
15

Running on port 80, it issued a new cert, and we're (mostly) up - I now need to get past the bug in the Hoot about setting up an admin account (pre-4.0 directions) then do a toot then deploy the indices.

16

Both 80 and 443 seems to be operational now.
See: SSL Server Test: motsstodon.social (Powered by Qualys SSL Labs)

3 Likes
17

Yes, they're operational, but serving a blank page. I'll close this topic and open another.

18

Filtered is usually due to a firewall blocking the packets entirely. Closed is usually the response of the OS and NOT the firewall.

5 Likes
19

open = An application is actively accepting TCP connections, UDP datagrams or SCTP associations on this port.

closed = A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it.

filtered = Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software.

5 Likes
20

What this normally looks like at the TCP level:

open - client sends SYN, gets back SYN+ACK

closed - client sends SYN, gets back RST

filtered - client sends SYN, gets no response (communications apparently disappear)

The open case is the remote OS saying "an application here is ready to talk to you on that port"; the closed case is the remote OS saying "no application here is ready to talk to you on that port"; the filtered case is the remote OS not saying anything at all (or a router or firewall intentionally hiding the reply).

(There is also a fourth host unreachable case in which a remote router sends back a reply via ICMP indicating that the remote host could not be reached, also including a more specific ICMP reason code which is unfortunately usually not displayed by most software. In the absence of a firewall, a server which is turned off or nonexistent should traditionally result in an explicit host unreachable reply from some router, so it can be distinguished from filtered which involves no reply at all from any device.)

@Rip's explanation is probably more helpful than mine for many people, but I thought I'd add these extra details for people who are accustomed to using tcpdump or Wireshark, or thinking of trying them out in the future.

6 Likes