Let's Encrypt & Synology DSM 6.X

Let's Encrypt & Synology DSM 6.X

Introduction

Synology DiskStations have become an indispensable tool in my work-life balance. The ability to emulate many cloud-like tools such as Dropbox, Evernote, Google Music, and Netflix, has been an invaluable tool in my tech arsenal. It has increased my flexibility and privacy, while lowering my dependency on cloud infrastructure.

All of that functionality comes with a slew of compelling reasons for immediately configuring strong encryption. While the latest versions of the Linux-based DSM OS (or Diskstation Manager) support rudimentary webroot challenge response with Let's Encrypt, they lack support for TLS and DNS challenges. For a user running these devices behind an ISP that blocks port 80 and uses dynamic IPs, this can make deploying Let's Encrypt extremely challenging.

After reading several different articles, which I reference below, the whole process, service, and configuration was simple; however, I couldn't find a single comprehensive resource that gave 100% of the information to successfully configure the service. I have provided my steps with a high-level outline of how to deploy both TLS and DNS challenges.

Requirements

1. I wanted to construct an automated method to managed Let's Encrypt based certificates on my Synology Diskstations which is as close to 'set it and forget it' as possible.
2. I also wanted to minimize the footprint of the client on the DiskStation that interacts with Let's Encrypt, as I didn't want a messy, complicated installation.
3. I needed  the certificate to be centrally installed, so that DSM was could feed the certificate into subordinate services like VPN, HyperBackup, CloudStation, etc

Web References and Research

My Google search foo yielded the following helpful links:

• https://github.com/Neilpang/acme.sh/wiki/Synology-NAS-Guide
• https://www.naschenweng.info/2017/01/06/automatic-ssl-renewal-encrypt-dsm-5-x-synology-ds1010-dns-01-verification/
• http://blog.raorn.name/2017/02/lets-encrypt-certificates-on-synology.html
• https://github.com/Neilpang/acme.sh/wiki/Using-'--pre-hook',-'--post-hook',-'--renew-hook'-and-'--reload-cmd'
• https://letsencrypt.org/docs/

Challenges

My top issue with the solutions that I found were that they only discussed replacing the default certificates and reloading the NGINX service on the diskstation. While only replacing the default certificate does cause DSM to activate the new certificate right away, other services like CloudStation, VPN, and even the DSM Certificate Control Panel screen will fail to show the correct active default certificate. In fact, the DSM Certificate Control Panel will display whatever certificate you had previously installed as active.

Default Certificate Store Location

/usr/syno/etc/certificate/system/default

Solution

Client Software

acme.sh is my Let's Encrypt client of choice for this task, as it has the smallest footprint on the Synology. Nothing needs to be compiled. No dependent packages are required. The use of native shell tools are maximized

Alternative Management of Certificates

DSM Certificate Control Panel creates a unique name for each imported or generated certificate. By default, DSM generates a self-signed certificate to enable SSL-protected services at installation time. This certificate has a long expiration, and my in past experiences, is generated with legacy ciphers and should not be used; however, it appears safe to overwrite files in that location with a set of Let's Encrypt certs and key. By overwriting the existing files in the certificate store, DSM-based actions will trigger the proper certificate to be installed for subordinate services. Here's some additional information on the file structure of DSM certificate stores.

Root Location of DSM Certificate Store

/usr/syno/etc/certificate/_archive

If you perform a directory listing of the root location of the DSM Certificate Store, you will see interesting subdirectories for each of your installed certificates. In this screenshot example, dMYejc is the directory that contains the self-signed default certificates and keys. Upon further inspection, you'll notice 2 configuration files: DEFAULT & INFO. DEFAULT maps the certificate store to the default certificate, while INFO contains the service mappings within DSM.

Files inside of dMYejc correspond as follows:

• cert.pem - certificate file
• chain.pem - CA file
• fullchain.pem - CA chain file
• privkey.pem - private key file
• syno-*.pem - self-generated Synology Certificate Authority CA files. (These files can be removed from all cert stores after acme.sh has replaced the certificates that depend on them.)

Outline of Action Plan

1. Install and configure the acme.sh client.
   • TLS-Challenge
   • DNS-Challenge
2. Generate and replace cert.pem, chain.pem, fullchain.pem, and privkey.pem in the root location of DSM certificate store. 
3. Configure crontab for root user
4. Create DSM-based scheduled task to copy required files into default certificate store location.
5. Manage subordinate services.

Install the acme.sh Client

1. Enable SSH in DSM Terminals Control Panel
2. SSH to Synology DiskStation.
3. sudo -i to root login.
4. cd /root
5. Execute the following commands:

$ export FORCE=1
$ wget -O -  https://get.acme.sh | sh

This will download and install acme.sh in /root/.acme.sh. It will also configure some environmental variables and display some warnings. The warnings can be safely ignored, as they are the result of the limited Linux commands available on the DiskStation. In order for the environmental variables to take full effect, log out of your root session and re-run 'sudo -i' before continuing.

Configure the acme.sh Client for TLS

$ cd ~/.acme.sh/
$ vi account.conf 

1. Prerequisite: TCP port 443 must be open on your Internet router and be forwarding to the IP address of your DiskStation.
2. When editing account.conf make sure you add a line for the variable ACCOUNT_EMAIL='user@domain.com' and replace 'user@domain.com' with your email address. 
3. You may also want to uncomment the line for LOG_FILE, LOG_LEVEL, and AUTO_UPGRADE

Based on my earlier example, dMYejc is the name of my DSM certificate store. 

***Remember, your NAS will have a different name, so you will need to change the code below to reflect your own path and domain name.

./acme.sh  --issue -d YOURDOMAIN.TLD --tls --certpath /usr/syno/etc/certificate/_archive/dMYejc/cert.pem --keypath /usr/syno/etc/certificate/_archive/dMYejc/privkey.pem --fullchainpath /usr/syno/etc/certificate/_archive/dMYejc/fullchain.pem --capath /usr/syno/etc/certificate/_archive/dMYejc/chain.pem --pre-hook "/sbin/initctl stop nginx" --post-hook "/sbin/initctl start nginx" --reloadcmd "/usr/syno/etc/rc.sysv/nginx.sh reload"

This command will generate your generate and install your SSL certificate, as well as manage the starting and stopping of NGINX to allow the TLS-Challenge.

Configure the acme.sh Client for DNS

$ cd ~/.acme.sh/
$ vi account.conf 

1. Prerequisites: You must own your own domain and control its DNS. Also, to automate the challenge response, your DNS must support a method for creating and deleting TXT records via an API. For the purposes of this example, I will only demonstrate this with DNS-hosting from CloudFlare.
2. When editing account.conf make sure you add a line for the variable ACCOUNT_EMAIL='user@domain.com' and replace 'user@domain.com' with your email address. 
3. You may also want to uncomment the line for LOG_FILE, LOG_LEVEL, and AUTO_UPGRADE
4. Additionally, you'll want to add 2 additional lines
   • export CF_Key="MyCloudFlare-Global-API-Key"
   • export CF_Email="MyCloudFlare-Account-Email-Address"

Based on my earlier example, dMYejc is the name of my DSM certificate store. 

***Remember, your NAS will have a different name, so you will need to change the code below to reflect your own path and domain name.

./acme.sh  --issue -d YOURDOMAIN.TLD --dns dns_cf --certpath /usr/syno/etc/certificate/_archive/dMYejc/cert.pem --keypath /usr/syno/etc/certificate/_archive/dMYejc/privkey.pem --fullchainpath /usr/syno/etc/certificate/_archive/dMYejc/fullchain.pem --capath /usr/syno/etc/certificate/_archive/dMYejc/chain.pem --reloadcmd "/usr/syno/etc/rc.sysv/nginx.sh reload"

This command will generate your generate and install your SSL certificate, as well as manage the reload of NGINX post DNS-Challenge.

Configure Crontab for root

$ vi /etc/crontab

Add the following line to the crontab. Remember to use tab for spacing.

32**2root/root/.acme.sh/acme.sh --cron

You should also consider testing acme.sh in cron mode.

$ /root/.acme.sh/acme.sh --cron

If everything goes well, you should see acme.sh report that no action is needed because it isn't time to renew the certificate yet.

Create Scheduled Task to Publish New Certs to System Default Cert Store

Before we setup a scheduled task to manage copying your certificate and keyfiles from their DSM store to the default location, I would recommend launching Control Panel / Security / Certificate and verifying that your self-signed certificate has been replaced by your new Let's Encrypt certificate.

Once your certificate is in good working order, log into DSM on your DiskStation and launch Control Panel. Next, open the Task Scheduler and create a new scheduled task for a user-defined script. I've provided screenshots for configuring the task:

In case that last screenshot is difficult to read, here are the individual lines for the 'Run command' box:

rsync -avzh /usr/syno/etc/certificate/_archive/dMYejc/ /usr/syno/etc/certificate/system/default/
/usr/syno/etc/rc.sysv/nginx.sh reload

I would recommend running this scheduled task manually once to ensure that is working. As soon as it executes, if you reload your browser, you should see the new certificate activate and receive the green padlock.

Managing Subordinate Services

Once the scheduled task has executed, you're now left with a configuration that will manage your future certificate renewals and will install those certificates in the proper location, as well automatically copy those renewed certs and active them in the default system certificate store.

Unfortunately because so there are so many varying that rely on the DSM certificate store web GUI to install and update them, you may have to verify and confirm various dialogs when certificates are updated. Some services, like VPN, are notoriously stubborn about detecting certificate changes, and it may be necessary to add a self-signed certificate for the sole purpose of using the GUI to manually adjust certificate associations from Let's Encrypt to Self-Signed and then back to Let's Encrypt for the certificate to properly register itself with certain services. In some cases, I was only able to update the certificate used by the VPN service after uninstalling and reinstalling it because the certificates are installed in the service only during installation.

Your experience may vary, but in general this seems to be the best-practice for Let's Encrypt for challenge methods not natively supported by DSM.