Let's encrypt - how to

Software SW tweaks
22

I found a German documentation stating that “0 & 7 stand for Sunday”. (http://www.synology-wiki.de/index.php/Cron) So the 6 in my case stands for Saturday.

But what gets me a little bit puzzled, is, that calling crontab doesn’t show Let’s encrypt timetable:

root@ds213+:~# vi /etc/crontab
MAILTO=""
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin
#minute hour    mday    month   wday    who command
0   0   1   *   *   root    /usr/syno/bin/syno_disk_health_record
0   0   *   *   *   root    /var/packages/MailServer/target/bin/syno_clean_junk --clean
0   1   *   *   *   root    /var/packages/MailServer/target/bin/MailScanner/clean.quarantine
0   3   *   *   *   root    /tmp/synoschedtask --run id=4
0   5   *   *   2   root    /tmp/synoschedtask --run id=5
0   3   *   *   *   root    /tmp/synoschedtask --run id=2
0   0   *   *   0,1,2,3,4,5,6   root    /tmp/synoschedtask --run id=1

Are there different cron-jobs running in parallel?

23

See crontab -l to view user’s cron table and/or crontab -e to edit it :wink:

24

Hi, I just came across your guide.
I wonder why are you doing it in so complicated way. All I had to do to get a Let’s Encrypt certificate was to unfirewall ports 80 and 443 from the WAN side and call acme.sh like this:

/root/.acme.sh/acme.sh --issue -w /www/ --reloadcmd '/root/.acme.sh/lighttpd-reload.sh' --keylength ec-256 -d <domain name>

The script /root/.acme.sh/lighttpd-reload.sh is just combining private key and certificate into a single file that can be read by lighttpd and then reloads lighttpd . I’ve covered the details long time ago and today I confirmed it still works as expected, plus no changes to Foris is necessary anymore.

I believe there’s no need to stop the lighttpd before every renewal nor to change any firewall rules. Am I missing something?

25

Well, the certificate issuance itself is not so much different. You are using one command with custom script in reloadcmd parameter. I am using two standard acme.sh commands to issues an install. And restart of lighttpd all around in the script.

You approach to open firewall is something I do not want to allow. I have lighttpd listening on non-standard ports (from WAN perspective) so 80 and 443 are permanently closed. So I need to dynamically update firewall to allow them for a while. And acme.sh itself is running its own server listening on port 443 - because of that I am turning lighttpd off before whole procedure.

I was not able to make acme.sh finish when port 443 was not free. And th firewall opening is matter of personal decision if you want to have it permanently open or not. Advantage is that very similar approach can be reused for other devices in LAN.

26

Thanks for explanation. I somehow expected that when somebody wants to deploy a Let’s Encrypt certificate, they indeed want to have the service publicly accessible. Now I see I was wrong. :slight_smile:

27

Since Turris OS 3.9 there is different handling of configuration files of lighttps.

See updated community documentation:
https://doc.turris.cz/doc/en/public/letencrypt_turris_lighttpd

1 Like
28

I took some inspiration from that community documentation and put it all together as part of this repo: https://github.com/davidjb/turris-omnia-tls. This setup aims to simplify the configuration by using the Acme.sh client’s hooks as much as possible and improve TLS config following Mozilla’s recommendations.

One key change is that I don’t run lighttpd on port 80, so there’s no possibility of accidentally exposing the Foris/LUCI interface to the Internet if the firewall changes associated with Acme.sh were to fail or otherwise be interrupted.

Suggestions/pull requests are welcome; likewise the licence is permissive so have at it.

1 Like