Hello.
I’m trying to set up Lets Encrypt on a Pi 3 Model B to enable external access to Nextcloud and keep getting the same “timeout during connect” error message - failing the acme challenge. I’m looking for suggestions to troubleshoot this.
LetsEncrypt error message:
http://[my No-IP name].ddns.net/.well-known/acme-challenge/5T74yv4u7tdb8xB99M5B_b9rgjDlOURNi2ScRzRRSyE:
Timeout during connect (likely firewall problem)
As background, I’ve been using No-IP Dynamic DNS service for a few years to connect to another RPi running NextcloudPi with self-signed certs and port 443 forwarding through my Netgear router. As I recall, NextcloudPi provides self-signed certs by default. This works reasonably well, once you get past the expected browser complaints.
Note that I cannot get Lets Encrypt set up on NextcloudPi either - - same timeout error message.
The NextcloudPi unit and the dietpi unit are on the same local network, both connected to the Netgear ORBI router via wired Ethernet.
I changed port forwarding for 443 and 80 to the dietpi internal IP (vice the NextcloudPi unit). This port forwarding appears to work, at least for port 80, as I can see the HTTP non-secure Nextcloud logon page on the dietpi via the No-IP URL. As expected, HTTPS won’t connect without a cert.
I’m not aware of any firewall on dietpi but have fail2ban installed.
The Netgear ORBI router doesn’t have a traditional firewall, far as I can tell. There is a setting for NAT security (open or secure). No change in either setting.
Where else might I look to adjust a setting or relax a restriction?
Thanks!
Creating a bug report/issue
Required Information
- DietPi version | v8.14.2
- Distro version | bullseye
- Kernel version | Linux DietPi 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux
- SBC model | RPi 3 Model B (aarch64)
- Power supply used | (EG: 5V 1A RAVpower)
- SD card used | SanDisk Extreme 32 GB
Additional Information (if applicable)
- Software title | dietpi-letsencrypt, CertBot
- Was the software title installed freshly or updated/migrated?
- Can this issue be replicated on a fresh installation of DietPi?
← If you sent a “dietpi-bugreport”, please paste the ID here →
- Bug report ID |
echo $G_HW_UUID
Steps to reproduce
- …
- …
Expected behaviour
Actual behaviour
Extra details
Basically following to check and to ensure
- DDNS is pointing to correct external IP address
- Port forwarding on port 80/443 correctly pointing to DietPi device
What web server you are running? Maybe it’s needed to remove your self singed certificated configuration first and set installation back to plain HTTS.
Thanks for the prompt reply.
Am using Lighttpd on the DietPi, as part of the LLMP package likely installed with Nextcloud.
To clarify, I have two different Raspberry Pis. One has a current version of NextCloudPi and uses the default self-signed certs for HTTPS.
The other RPi has dietpi installed with Nextcloud and Pydio. I have not tried to create or add any self-signed certs to this one. I can access both services locally but without encryption.
Both RPi’s are on the same local network, connected to the Netgear ORBI router by Ethernet cable.
I added some clarifying comments to my OP.
The No-IP DDNS appears to work, as I can connect to the other RpI running NextcloudPi via the NoIP URL if I forward ports to that device’s internal IP. HTTPS works there because of the self-signed cert.
Similarly, if I forward ports 443 and 80 to the DietPi unit, I can at least connect via HTTP to the default Lighttpd page or Nextcloud login page, so I assume port forwarding is working for port 80.
Is there something unique about the No-IP service I need to consider or change?
Could my ISP be blocking something?
Thanks.
If you forward port 80/443 to the DietPi device running native Nextcloud, you are not able to execute dietpi-letsencrypt?
1 Like
Yes, that sounds right. If I forward 80/443 to the dietpi device that has Nextcloud and try execute Lets Encrypt/Certbot, I get the timeout error every time when LetsEncrypt does the acme challenge on the supplied DDNS domain.
Yes, I can share logs. Which logs and how to best upload or post them in a reply?
BTW, I decided to start fresh by reflashing the SD card, as I’ve been running this RPi for a month or so to become more familiar with the dietPi environment.
I installed only Nextcloud (mainly to get lighttpd to test https connections) and LetsEncrypt.
I still saw the same acme general challenge timout with LetsEncrypt.
Defaul log setting was RAMlog #1, so log was cleared before I could check it. Changed to RAMlog #2 for more persistence.
simply run dietpi-letsencrypt and post the output. Remove personal information like domain name.
DietPi-LetsEncrypt
─────────────────────────────────────────────────────
Mode: Running Certbot
[ OK ] DietPi-LetsEncrypt | Lighttpd webserver detected
[ OK ] DietPi-LetsEncrypt | systemctl start lighttpd
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Requesting a certificate for [myURL].ddns.net
Performing the following challenges:
http-01 challenge for [myURL].ddns.net
Using the webroot path /var/www for all unmatched domains.
Waiting for verification...
Challenge failed for domain [myURL].ddns.net
http-01 challenge for [myURL].ddns.net
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: [myURL].ddns.net
Type: connection
Detail: [external IP address]: Fetching
http://[myURL].ddns.net/.well-known/acme-challenge/PWWXOUEBj6OWJ_2VXHFzReI6WeoJpv4ReZiZOZVxOrk:
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.
[FAILED] DietPi-LetsEncrypt | Certbot failed, please check its above terminal output. Aborting...
Let’s try to replicate the steps manually LetsEncrypt is doing 
mkdir -p /var/www/.well-known/acme-challenge
echo 'this works' > /var/www/.well-known/acme-challenge/PWWXOUEBj6OWJ_2VXHFzReI6WeoJpv4ReZiZOZVxOrk
curl -IL 'http://[myURL].ddns.net/.well-known/acme-challenge/PWWXOUEBj6OWJ_2VXHFzReI6WeoJpv4ReZiZOZVxOrk'
You could try as well to open http://[myURL].ddns.net/.well-known/acme-challenge/PWWXOUEBj6OWJ_2VXHFzReI6WeoJpv4ReZiZOZVxOrk from outside your local network using a mobile device.
Here is the response in terminal to the curl -IL:
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Accept-Ranges: bytes
ETag: "1997863067"
Last-Modified: Thu, 23 Feb 2023 02:38:17 GMT
Content-Length: 11
Date: Sat, 25 Feb 2023 19:09:03 GMT
Server: lighttpd/1.4.59
I can reach and open the file from the Firefox browser on my smartphone and it displays the “this works” text when downloaded. I had to add a .txt extension to the file to make it easier to display on the phone, as Firefox was adding a .bin extension when it offered to download the file.
Regardless, I can reach the http://[myURL].ddns.net/.well-known/acme-challenge file from outside the network.
To reconfirm this, added text to the acme-challenge file and was able to see the new text from the phone.
usually this should allow Lets Encrypt to do exactly same. Can you check for active configurations.
ls -la /etc/lighttpd/conf-enabled
total 8
drwxr-xr-x 2 root root 4096 Feb 19 17:59 .
drwxr-xr-x 4 root root 4096 Feb 19 17:59 ..
lrwxrwxrwx 1 root root 33 Feb 19 17:52 10-fastcgi.conf -> ../conf-available/10-fastcgi.conf
lrwxrwxrwx 1 root root 33 Feb 19 17:59 10-rewrite.conf -> ../conf-available/10-rewrite.conf
lrwxrwxrwx 1 root root 41 Feb 19 17:52 15-fastcgi-php-fpm.conf -> ../conf-available/15-fastcgi-php-fpm.conf
lrwxrwxrwx 1 root root 45 Feb 19 17:59 99-dietpi-dav_redirect.conf -> ../conf-available/99-dietpi-dav_redirect.conf
lrwxrwxrwx 1 root root 42 Feb 19 17:59 99-dietpi-nextcloud.conf -> ../conf-available/99-dietpi-nextcloud.conf
lrwxrwxrwx 1 root root 38 Feb 19 17:52 99-unconfigured.conf -> ../conf-available/99-unconfigured.conf
That all looks good. I’m running out of ideas why certificates are not created. Maybe @MichaIng has some other.
No idea either. Need to test this in general with Lighttpd, as I remember the same issue was reported some weeks ago.
Success! I was able to install Lets Encrypt certs after a few workarounds and may have found a root cause - - missing lighttpd openssl module.
-
I used certbot in manual mode to specify a DNS challenge instead of an ACME challenge to get the certs issued. When instructed by certbot, I added a TXT file with a specific string to the DNS record at the DynamicDNS provider’s website (No-IP) to validate the domain.
See How to use Let's Encrypt DNS challenge validation? - Server Fault as a starting point.
-
Certbot initially give me error message about a “CAA record preventing issuance.”
I checked the DNS records for that domain at No-IP and discovered a CAA record (flag?) already existed for letsencrypt. I deleted the CAA and then I was able to get the certs.
This made me wonder if letsencrypt was working better than I thought. Why would this flag already be set?
-
Since certbot doesn’t install the certs in manual mode, I created the necessary lighttpd conf files and edited lighttpd.conf as needed, per guidance here:
self signed sertificate
-
The lighttpd service wasn’t restarting after these additions and edits. I checked the syntax of the files and then used “journalctl -xe” to find that that mod_openssl.so was missing. So, I used “apt install lighttpd-mod-openssl” to install it.
Then I was able to restart the lighttpd service and the certs worked.
-
I then tried running dietpi-letsencrypt and it saw the existing valid certs and asked if I wanted to renew/reissue them.
-
Additional info: Looking at /etc/letsencrypt/keys, I noticed there were already about 12 key files, dating back to February 19, when I first started trying letsencrypt on this fresh dietpi install. Looking at /etc/letsencrypt/csr, there are also the same number of cert request files.
Maybe the ACME validation was working and the keys were being issued, but the process wasn’t completing because of the missing openssl module?
@Joulinar @MichaIng Thank you for your time, patience, and support.
dietpi-letsencrypt installs this package automatically, after the certificate has been received. It is however not needed for obtaining the cert in the first place, since the ACME server accesses via HTTP (of course, nothing else is available).
You worked around the failing ACME webroot challenge by using the DNS challenge. Can you check whether the webroot challenge works now?
certbot renew --force-renewal --webroot -w /var/www
1 Like
Yes, that forced renewal worked with no errors.
I cleared cache on my browser and confirmed the issue date/time had changed on the Lets Encrypt cert displayed by the browser.
There is also a new key file in /etc/letsencrypt/keys.
Could that CAA flag in the DNS record be a factor, if that was already present before trying Lets Encrypt on this dietpi device? Would that type of error message get passed (be visible in terminal) in the dietpi-letsencrypt script?
A CAA record in your providers DNS settings, which does not list Let’s Encrypt as permitted CA, would be indeed a good reason why it failed in the first place. I’d however also expected a different error message then, respectively that the ACME server reports the conflicting CAA record before even trying to prepare the challenge.
Probably the /var/log/letsencrypt/letsencrypt.log would have contained this information, but this log file contains a whole lot of details, so it takes time to find the real error within it 
.
Yes, the letsencrypt.log is already over 5000 lines with only about six days of activity. More than I can digest on a Monday morning.
Regarding the CAA error, I did receive a fairly clear error message from certbot:
The following errors were reported by the server:
Domain: [myURL].ddns.net
Type: caa
Detail: CAA record for [myURL].ddns.net prevents issuance
BTW, I remembered that I did try another free DDNS service from dynu.com and saw the same ACME challenge timeout errors. I’m not familiar with that service, so didn’t dig deep into their options.
Now that I have valid Lets Encrypt certs installed, I’ll take a break from the troubleshooting to become more familiar with dietpi overall.
I can do a fresh install later to see if I can replicate this issue and will be happy to share logs if helpful.
1 Like