Let's Encrypt Challenge failed

Help
1

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: interlope.ovh

I ran this command:

certbot certonly --nginx

It produced this output:

root@nginx:/etc/nginx/conf.d# certbot certonly --nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
No names were found in your configuration files. Please enter in your domain
name(s) (comma and/or space separated)  (Enter 'c' to cancel): wiki.interlope.ovh
Requesting a certificate for wiki.interlope.ovh
Performing the following challenges:
http-01 challenge for wiki.interlope.ovh
Waiting for verification...
Challenge failed for domain wiki.interlope.ovh
http-01 challenge for wiki.interlope.ovh
Cleaning up challenges
Some challenges have failed.

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: wiki.interlope.ovh
   Type:   connection
   Detail: xx.xx.xx.xx: Fetching
   http://wiki.interlope.ovh/.well-known/acme-challenge/tokenxyz:
   Timeout during connect (likely firewall problem)

   To fix these errors, please make sure that your domain name was
   entered correctly and the DNS A/AAAA record(s) for that domain
   contain(s) the right IP address. Additionally, please check that
   your computer has a publicly routable IP address and that no
   firewalls are preventing the server from communicating with the
   client. If you're using the webroot plugin, you should also verify
   that you are serving files from the webroot path you provided.

My web server is (include version):

nginx version: nginx/1.18.0

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

Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye

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.12.0\

I can access http://wiki.interlope.ovh but i can't get the certificates. Any ideas ?

DNS entries are not the issue :

root@nginx:/etc/nginx/conf.d# dig wiki.interlope.ovh

; <<>> DiG 9.16.37-Debian <<>> wiki.interlope.ovh
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43170
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;wiki.interlope.ovh. IN A

;; ANSWER SECTION:
wiki.xx.ovh. 1459 IN CNAME wan.interlope.ovh.
wan.xx.ovh. 1459 IN A xx.xx.xx.xx

;; Query time: 4 msec
;; SERVER: 192.168.22.53#53(192.168.22.53)
;; WHEN: Sun Jun 04 16:58:36 CEST 2023
;; MSG SIZE rcvd: 94

And since it is available on web with http, i really don't think it could be a firewall issue (opnsense)

2

I can't connect to your domain with HTTP. The Let's Debug test site is helpful in testing changes (https://letsdebug.net)

If you are sure your firewalls allow all inbound traffic you might check with your ISP to ensure it allows inbound requests on port 80 (not all do) and that it doesn't use CGNAT which would prevent such inbound requests too.

You say you can see it but did you try from inside your own network or the public internet? Try a cell phone with wifi off to use the carrier's network.

2 Likes
3

I can't connect to your domain with HTTP. The Let's Debug test site is helpful in testing changes [(link here](https://wiki.interlope.ovh/))

That's because you are trying with https... that i can't have since i can't get the certificates from let's encrypt.

You say you can see it but did you try from inside your own network or the public internet? Try a cell phone with wifi off to use the carrier's network.
I tried from behind my opnsense to dig/wget http://wiki.interlope.ovh, i tried from LTE on my phone. Both are working

4

I tried it :

ANotWorking
ERROR
wiki.interlope.ovh has an A (IPv4) record (88.163.255.43) but a request to this address over port 80 did not succeed. Your web server must have at least one working IPv4 or IPv6 address.
A timeout was experienced while communicating with wiki.interlope.ovh/88.163.255.43: Get "http://wiki.interlope.ovh/.well-known/acme-challenge/letsdebug-test": context deadline exceeded

Trace:
@0ms: Making a request to http://wiki.interlope.ovh/.well-known/acme-challenge/letsdebug-test (using initial IP 88.163.255.43)
@0ms: Dialing 88.163.255.43
@10000ms: Experienced error: context deadline exceeded
IssueFromLetsEncrypt
ERROR
A test authorization for wiki.interlope.ovh to the Let's Encrypt staging service has revealed issues that may prevent any certificate for this domain being issued.
88.163.255.43: Fetching http://wiki.interlope.ovh/.well-known/acme-challenge/hWiu5wLnMdNoTJiQYbI7maufrdmtopptPbEs8Nfi4P4: Timeout during connect (likely firewall problem)

But it is kinda weird :

root@nginx:/etc/nginx/sites-enabled# curl wiki.interlope.ovh
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

And it is not resolving locally :

root@nginx:/etc/nginx/sites-enabled# ping wiki.interlope.ovh
PING wan.interlope.ovh (88.163.255.43) 56(84) bytes of data.
5

That's from your local network not the public internet.

And, no, I wasn't trying from HTTPS. The link to the Let's Debug test site was HTTPS

I tried from several regions around the world and none could reach your domain with HTTP. You might have a very strict geographic based firewall if you can see it from the public internet.

4 Likes
6

Okay this was probably the cache.

I kinda found a way by using sudo certbot certonly --manual --preferred-challenges dns -d www.wiki.interlope.ovh and not using http-01 since i saw in the test that dns was working.

I guess i could say that it works ? Could you confirm it ?

7

Neither HTTP on port 80 nor HTTPS on port 443 is working for me. Timeouts.

Please check any system that can block access from the public internet such as firewall(s), NAT routers (portmaps) et cetera. There could even be a geo-blocking present, allowing access from your own country, but not from anywhere else for example.

3 Likes
8

Those are two different domain names. Was that intentional?

You can get a cert using the DNS Challenge but none of us can see your domain from the public internet. If you only want a cert for use on your private network the DNS Challenge is the only way.

I can't confirm you got a cert until the public CT logs are updated and this sometimes takes 24 hours.

3 Likes
9

Okay this is my mistake.
I can't even think straight haha

I'm doing the certbot dns again, currently waiting for it to update.

10

I kinda don't undertand. I finally got the certificates for my wiki.interlope.ovh
/etc/letsencrypt/live/wiki.interlope.ovh/fullchain.pem & /etc/letsencrypt/live/wiki.interlope.ovh/privkey.pem

I've put them into my conf.d/wiki.interlope.ovh.conf file.

Those are the NAT rules of my opnsense which is in the DMZ of my FAI router :

image2
image21233×516 31.1 KB

11

And those are the WAN rules

image
image1235×645 36.7 KB

12

But it looks like https://wiki.interlope.ovh isnt answering at all when it does work locally.

13

What does that "Anti-Lockout Rule" mean?

Also, could you double-check your public IP is still 88.163.255.43? E.g. from a command line you could run:

curl -4 ifconfig.co

By the way, sometimes ISPs also block these kind of ports. Make sure your ISP doesn't block port 80 and 443.

3 Likes
14

There we go :

nginx@nginx:~$ curl -4 ifconfig.co
88.163.255.43
nginx@nginx:~$

As for the anti lockout rule :
After installing the OPNsense firewall and configuring its LAN/WAN interfaces, **it automatically creates a web administration anti-lockout rule and a allow all rule for IPv4 and IPv6** . These rules prevent you from locking yourself out of OPNsense web UI and provide LAN with unrestricted Internet access.

15

port 80 & 443 shouldnt be blocked since i put my opnsense into the DMZ no ?

16

Well, that wouldn't matter if packets from the public internet never arrive at your FAI router.

By the way, what's ProXad? Do you recognise that company?

3 Likes
17

Oh yeah, proxad is a part of my FAI

how do i know if 80 & 443 are blocked ?

nvm :

ubuntu@vps-8a60c978:~$ nmap -Pn -p 80,443 88.163.255.43
Starting Nmap 7.80 ( https://nmap.org ) at 2023-06-04 16:43 UTC
Nmap scan report for 4be54-6_migr-88-163-255-43.fbx.proxad.net (88.163.255.43)
Host is up.

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

Nmap done: 1 IP address (1 host up) scanned in 3.06 seconds
18

Ask your FAI probably. Sometimes they have a knowledge base explaining this kind of stuff, often they don't.

2 Likes
19

Guys !

we may have it.

I called my FAI, asked for a full stack IP. got it right away.

It is now working on my side and i can even use the http method instead.

Can people try it ?

20

It worked for a little while with the IP address 82.64.177.104, but for some reason the hostname is back to 88.163.255.43 (through the CNAME to wan.interlope.ovh) again?

Or maybe my DNS resolver is still caching the old one. Not sure why dig worked for a little while then. curl is still having trouble with resolving the correct IP address..

2 Likes