Update: Let’s Encrypt & Synology DSM 6.X
It has come to my attention after receiving some SSL certificate renewal reminders from Let’s Encrypt that my previous article Let’s Encrypt & Synology DSM 6.X needed a follow-up post. While nothing was inherently wrong with my instructions, I noticed that after several Synology DSM updates, all of my acme.sh configuration and /etc/crontab entries had been wiped out. Apparently, the DSM update really clean house on an active configurations. This leaves two possible solutions:
- Disable DSM Updates (bad idea)
- Convert the previous defined solution into something that is persistent.
Disabling DSM updates is a bad for multiple reasons, especially if you care about security and stability. Plus, Synology is always releasing free feature enhancements that make their products and applications better.
Hacking Synology DSM to Enforce Persistent Configuration
Of all the configuration changes that were described in my previous article, only one configuration change persisted: The user-defined script that I had added to the Synology DSM Task Scheduler.
Steps Taken To Remediate Persistent Configuration
- Create a directory called for your scripts and configuration files in a home directory folder. (I used /volume1/homes/admin/syno_scripts)
- Create your account.conf file for acme.sh and copy it to your syno_scripts directory. (Refer to my previous article for how to setup this file)
- Write a shell script to manage the acme.sh installation and place in your syno_scripts directory.
- Write a shell script to manage the acme.sh renewal activities and place in your syno_scripts directory.
- Edit the permissions of the files and/or syno_scripts directory so that the root user can access them, and you can potentially edit them using the handy Synology DSM Text Editor.
- Create scheduled task(s) to enable both user-defined scripts in Synology DSM Task Scheduler.
Script To Manage acme.sh Installation
#!/bin/sh export HOME=/root cd /root || exit sslvar=$(cat /usr/syno/etc/certificate/_archive/DEFAULT) if [ -f /root/.acme.sh/acme.sh ] then echo "Installation Already Exists" else echo "Install acme.sh" export FORCE=1 wget -O - https://get.acme.sh | sh cp /volume1/homes/admin/syno_scripts/account.conf /root/.acme.sh/account.conf /root/.acme.sh/acme.sh --issue -d YOURDOMAIN.TLD --dns dns_cf --certpath /usr/syno/etc/certificate/_archive/$sslvar/cert.pem --keypath /usr/syno/etc/certificate/_archive/$sslvar/privkey.pem --fullchainpath /usr/syno/etc/certificate/_archive/$sslvar/fullchain.pem --capath /usr/syno/etc/certificate/_archive/$sslvar/chain.pem --reloadcmd "/usr/syno/etc/rc.sysv/nginx.sh reload" fi
In a nutshell, the above script determines if acme.sh is already installed. If it is, it prints “Installation Already Exists” and terminates. If DSM has destroyed your installation of acme.sh, it re-installs acme.sh, copies your configuration back into place, and re-initializes acme.sh to manage your certificates.
Script To Manage acme.sh Renewal Activities
#!/bin/sh cd /root || exit sslvar=$(cat /usr/syno/etc/certificate/_archive/DEFAULT) if [ -f /root/.acme.sh/acme.sh ] then echo "Attempt To Renew Certificate" /root/.acme.sh/acme.sh --cron echo "rsyncing Certificates to Default Store" /bin/rsync -avzh /usr/syno/etc/certificate/_archive/$sslvar/ /usr/syno/etc/certificate/system/default/ echo "Reloading NGINX" /usr/syno/etc/rc.sysv/nginx.sh reload else echo "Missing acme.sh" fi
This detects if acme.sh is present. If so, it calls acme.sh as a cronjob. If not, it reports “Missing acme.sh” and terminates.
Conclusion
By utilizing these two scripts and Synology DSM Task Scheduler, your acme.sh-based Let’s Encrypt configuration will now persist beyond Synology DSM updates. How you choose to schedule these scripts is up to personal preference. Also, you may choose to combine both scripts into a single script.
Have fun!
-John
Discover more from Warmest Robot + Warmest Human
Subscribe to get the latest posts sent to your email.