Hi all.
I just found out my certificates on my Raspberry Pi 3 based Dietpi server expired some days ago and it seems they are not renewing automatically.
I set them up using the built-in dietpi-* applications and they seemed to work fine for a long time. Distro is continuously updated to the last version.
How can I check what went wrong?
go to dietpi-letsencrypt and try to renew your certificate
If the renewal does not work, the error output of dietpi-letsencrypt could be helpful.
dietpi@DietPi:~$ sudo dietpi-letsencrypt
DietPi-LetsEncrypt
─────────────────────────────────────────────────────
Mode: Running Certbot
This is the complete output of the command (real domain names obfuscated on purpose). I have 3 domains on the list. I don’t know if this can matter.
From what I read it says possible firewall error but I have port 80 and 443 properly routed through my router (I can access my web applications from outside home) and no firewall is running on the raspberry pi.
[ OK ] DietPi-LetsEncrypt | Nginx webserver detected
[ OK ] DietPi-LetsEncrypt | Desired setting in /etc/nginx/sites-available/default was already set: server_name XXX.duckdns.org;
[ OK ] DietPi-LetsEncrypt | systemctl restart nginx
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator nginx, Installer nginx
Cert is due for renewal, auto-renewing...
Renewing an existing certificate for XXX.duckdns.org and 2 more domains
Performing the following challenges:
http-01 challenge for XXX.duckdns.org
Waiting for verification...
Challenge failed for domain XXX.duckdns.org
http-01 challenge for XXX.duckdns.org
Cleaning up challenges
Some challenges have failed.
IMPORTANT NOTES:
- The following errors were reported by the server:
Domain: XXX.duckdns.org
Type: connection
Detail: xxx.yyy.zzz.www: Fetching
http://XXX.duckdns.org/.well-known/acme-challenge/y1m1PqrD1VpDqk21mtMZsQKomOEXkiyrox-ekl2abrc:
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...
Press any key to return to the DietPi-LetsEncrypt menu ...
Basically, letsencrypt server is not able to connect to your DDNS to verify your domain. This could have various reasons. Are you sure your DDNS is pointing correctly to your public domain and double check port forwarding. As well, have a look to the log file located at /var/log/letsencrypt/letsencrypt.log
I have basically the slightest knowledge oof what a DDNS is or how to configure it on my Pi.
What I know is that I can access the websites on my Pi from outside my home (of course I get a certification expired error) so I guess port forwarding is ok.
I can access or provide the log file you pointed me to, but unfortunately I’m not able to fully understand what’s going wrong by reading it.
you need to have port 80/443 open and forward from your router to DietPi. This is a setting you need to very yourself on your router. Important is port 80 to allow letsencrypt the access.
The log is located at /var/log/letsencrypt/letsencrypt.log. Simply copy it to your computer.
Telnet to port 80 works fine from my office to my Rpi at home, and I can see the web apps via browser so 443 is forwarded too.
I copied the letsencrypt.log to my computer.
I can paste the log. Unfortunately it doesn’t tell me anything that to my knowledge can be the root cause of the situation. I see json data floating around but I’m not expert enough to understand much of how letsencrypt/certbot works.
From my little knowledge I guess that certbot validates that a domain name is mine by trying to contact my Pi from the letsencrypt servers pointing to a sort of secret file. If they can reach it then they have the proof that I’m not lying about being the owner of the domain. And that’s where it fails.
"error": {
"type": "urn:ietf:params:acme:error:connection",
"detail": "aaa.bbb.ccc.ddd: Fetching http://XXX.duckdns.org/.well-known/acme-challenge/3ugrr2J-yHA3XoHsSpMm2AFVAff6ke5tbgzKKoJ0AJo: Timeout during connect (likely firewall problem)",
"status": 400
},
Since everything else except for the certificate works on my Pi by remote as it used to (I can reach the web apps, I can connect via SSH…) I think the issue is on certbot only and port forwarding is set correctly.
Unfortunately I need help going forward from this.
@Tarrasque: Do you have another device on your site set to the same Certbot domain certificate?
I guess I had some issues when I tried to have several devices with Certbot (but retained to only have one single then).
I finally found the solution!!
It wasn’t dietpi-letsencrypt’s fault. The real “culprit” was dietpi-ddns instead.
I have 3 domains linked to my certificate managed by dietpi-letsencrypt: 2 are associated to a DuckDNS account (and token), the 3rd, which is the default server, to another different DuckDNS account.
The catch is that when I configured the domain naame sync with the IP with dietpi-ddns, I didn’t know that the second configuration would not add to the first (the default server) but wiped it out instead.
So, the default XXX.duckdns.org domain had not out of sync with the current IP for a while, and I didn’t notice because I rarely use it, because the web apps I use most are on the other 2 domains (and the other DuckDNS accountt), and that was the only one I checked.
Now that I manually set upm the correct IPs in the outdated DuckDNS account, everythinbg is working fine.
So I have now a question (implementation request?). Is there a way to handle multiple providers/accounts in diepi-ddns? If not, how do people manage the situation? Could the feature be added to dietpi-ddns?
Thank everybody very much for support.
hmm we just offer the possibility to update multiple domains. You can enter a comma-separated list of domains that shall point to this system, but they need to belong to same account.
To solve your issue, you can follow official DuckDNS docs to setup an own cron job for the missing domain Duck DNS - install Just follow the Linux or Pi part. At the end dietpi-ddns is not doing anything else than creating a cron job similar way 
Yes, now I know that, and I’ll use a custom cron job like I always did.
Still, I think that having dietpi-ddns limited to just one provider account is very limited.
By my experience, having domains manages by multiple sources is quite a common scenario (one personal on DuckDNS, one for hobby/school linked to my github account, one for my wife…).
A centralized easy app like dietpi-ddns is very much welcome. It only needs those last yards more to be perfect, IMHO
What user’s crontab is modified by dietpi-ddns?
at least on our user base this is not that common
Cron job /var/spool/cron/crontabs/dietpi-ddns
Update script /var/lib/dietpi/dietpi-ddns/update.sh