Last week, I described a gloomy situation: all public TLS certificate providers log your requests. By browsing through the subdomains, one can get their respective IP addresses. If one of them points to your home route, they know your general location. gloomy situation I analyzed several solutions and decided to use wildcard certificates, which don't leak subdomain information, while continuing to use Let's Encrypt. My solution caters to my Synology NAS, as it's the one I'm using. Synology Getting a Wildcard Certificate for Synology NAS The Synology UI allows configuring Let's Encrypt for automated certificate renewal. But you can get wildcard certificates only for Synology subdomains: Only domains of Synology DDNS support wildcard certificates issued by Let's Encrypt. Only domains of Synology DDNS support wildcard certificates issued by Let's Encrypt. It's time to become creative. The most widespread Let's Encrypt client is Certbot, but a surface search reveals it doesn't run on Synology. Underneath, Let's Encrypt delivers certificates via the Automatic Certificate Management Environment protocol. Lots of clients already implement the Automatic Certificate Management Environment (ACME) protocol. acme.sh looked like an interesting candidate: Automatic Certificate Management Environment clients acme.sh An ACME protocol client written purely in Shell (Unix shell) language.
Full ACME protocol implementation.
Support ECDSA certs
Support SAN and wildcard certs
Simple, powerful and very easy to use. You only need 3 minutes to learn it.
Bash, dash and sh compatible.
Purely written in Shell with no dependencies on python.
Just one script to issue, renew and install your certificates automatically.
DOES NOT require root/sudoer access.
Docker ready
IPv6 ready
Cron job notifications for renewal or error etc.

-- An ACME Shell script: acme.sh An ACME protocol client written purely in Shell (Unix shell) language.
Full ACME protocol implementation.
Support ECDSA certs
Support SAN and wildcard certs
Simple, powerful and very easy to use. You only need 3 minutes to learn it.
Bash, dash and sh compatible.
Purely written in Shell with no dependencies on python.
Just one script to issue, renew and install your certificates automatically.
DOES NOT require root/sudoer access.
Docker ready
IPv6 ready
Cron job notifications for renewal or error etc. An ACME protocol client written purely in Shell (Unix shell) language. Full ACME protocol implementation. Support ECDSA certs Support SAN and wildcard certs Simple, powerful and very easy to use. You only need 3 minutes to learn it. Bash, dash and sh compatible. Purely written in Shell with no dependencies on python. Just one script to issue, renew and install your certificates automatically. DOES NOT require root/sudoer access. root/sudoer Docker ready IPv6 ready Cron job notifications for renewal or error etc. -- An ACME Shell script: acme.sh An ACME Shell script: acme.sh Icing on the cake, acme.sh provides a Docker image. At the same time, Synology offers a Docker runtime. I thus decided to implement certificate renewal with the acme.sh Docker image. Here's how I proceeded. acme.sh acme.sh Go to the Docker menu. In the opening window, click on Container, then Create. It opens a Create Container window. Click on Download and search for neilpang/acme.sh. Docker Container Create Download neilpang/acme.sh We will need to create two containers out of it: one for requesting a new certificate, and one for managing the update of the certificate on the NAS. Prerequisites Before we go further, we need: To get a token with permissions to edit the DNS records:
In my case, it's Cloudflare. You can check the process for other providers on the acme.sh wiki.
Go to the Cloudflare UI. Create an API token with the template to Edit Zone DNS. Set a relevant name. Then, set the Zone Resources to the following:| Include | Specific zone | <your.domain> |
Write down the token value in a secure place, as you won't be able to access it later!

Prepare an account for the Synology:
For security purposes, we want to run the containers with a dedicated account.
Check the section Create a user in Synology DSM in this post and follow its instructions. It's what I did, and it worked exactly as described. To get a token with permissions to edit the DNS records:
In my case, it's Cloudflare. You can check the process for other providers on the acme.sh wiki.
Go to the Cloudflare UI. Create an API token with the template to Edit Zone DNS. Set a relevant name. Then, set the Zone Resources to the following:| Include | Specific zone | <your.domain> |
Write down the token value in a secure place, as you won't be able to access it later! To get a token with permissions to edit the DNS records: In my case, it's Cloudflare. You can check the process for other providers on the acme.sh wiki. acme.sh wiki Go to the Cloudflare UI. Create an API token with the template to Edit Zone DNS. Set a relevant name. Then, set the Zone Resources to the following: Cloudflare UI Edit Zone DNS | Include | Specific zone | <your.domain> | <your.domain> Write down the token value in a secure place, as you won't be able to access it later! Prepare an account for the Synology:
For security purposes, we want to run the containers with a dedicated account.
Check the section Create a user in Synology DSM in this post and follow its instructions. It's what I did, and it worked exactly as described. Prepare an account for the Synology: For security purposes, we want to run the containers with a dedicated account. Check the section Create a user in Synology DSM in this post and follow its instructions. It's what I did, and it worked exactly as described. this post Requesting the Certificate Go back to the Synology UI, more specifically, the Docker menu. Click on the Create button. It opens a wizard with several screens: Docker Create When you run the container, it will create the required files in the homes/certadmin folder. homes/certadmin ls -ltr /volume2/homes/certadmin ls -ltr /volume2/homes/certadmin total 8
drwxrwxrwx+ 1 root root 210 Jun 26 07:58 '*.frankel.ch_ecc'
drwxrwxrwx+ 1 root root  56 Jun 26 08:38  ca
-rwxrwxrwx+ 1 root root 494 Jul  5 14:30  http.header
-rwxrwxrwx+ 1 root root 154 Jul  5 14:30  account.conf total 8
drwxrwxrwx+ 1 root root 210 Jun 26 07:58 '*.frankel.ch_ecc'
drwxrwxrwx+ 1 root root  56 Jun 26 08:38  ca
-rwxrwxrwx+ 1 root root 494 Jul  5 14:30  http.header
-rwxrwxrwx+ 1 root root 154 Jul  5 14:30  account.conf If it doesn't work, you can access the logs by selecting the image and clicking on the Details button. The log tab shows the logs, broken up by day. Here's a log sample of a successful run: Details [Sat Jul  5 12:30:17 UTC 2025] Verification finished, beginning signing."
[Sat Jul  5 12:30:17 UTC 2025] Let's finalize the order.
[Sat Jul  5 12:30:17 UTC 2025] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/2489606761/402920873611'
[Sat Jul  5 12:30:19 UTC 2025] Downloading cert.
[Sat Jul  5 12:30:19 UTC 2025] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/05a220cfe82f0e3576f8230d7f62a58dd28b'
[Sat Jul  5 12:30:19 UTC 2025] Cert success.
-----BEGIN CERTIFICATE-----
  REDACTED
  REDACTED
  REDACTED
  REDACTED
  REDACTED
  REDACTED
-----END CERTIFICATE-----
[Sat Jul  5 12:30:19 UTC 2025] Your cert is in: /acme.sh/*.frankel.ch_ecc/*.frankel.ch.cer
[Sat Jul  5 12:30:19 UTC 2025] Your cert key is in: /acme.sh/*.frankel.ch_ecc/*.frankel.ch.key
[Sat Jul  5 12:30:20 UTC 2025] The intermediate CA cert is in: /acme.sh/*.frankel.ch_ecc/ca.cer
[Sat Jul  5 12:30:20 UTC 2025] And the full-chain cert is in: /acme.sh/*.frankel.ch_ecc/fullchain.cer [Sat Jul  5 12:30:17 UTC 2025] Verification finished, beginning signing."
[Sat Jul  5 12:30:17 UTC 2025] Let's finalize the order.
[Sat Jul  5 12:30:17 UTC 2025] Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/2489606761/402920873611'
[Sat Jul  5 12:30:19 UTC 2025] Downloading cert.
[Sat Jul  5 12:30:19 UTC 2025] Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/05a220cfe82f0e3576f8230d7f62a58dd28b'
[Sat Jul  5 12:30:19 UTC 2025] Cert success.
-----BEGIN CERTIFICATE-----
  REDACTED
  REDACTED
  REDACTED
  REDACTED
  REDACTED
  REDACTED
-----END CERTIFICATE-----
[Sat Jul  5 12:30:19 UTC 2025] Your cert is in: /acme.sh/*.frankel.ch_ecc/*.frankel.ch.cer
[Sat Jul  5 12:30:19 UTC 2025] Your cert key is in: /acme.sh/*.frankel.ch_ecc/*.frankel.ch.key
[Sat Jul  5 12:30:20 UTC 2025] The intermediate CA cert is in: /acme.sh/*.frankel.ch_ecc/ca.cer
[Sat Jul  5 12:30:20 UTC 2025] And the full-chain cert is in: /acme.sh/*.frankel.ch_ecc/fullchain.cer Deploying the Certificate We will use the same image to deploy the certificate, albeit with a different configuration. The image uses the files created by the previous image to update the TLS certificate used by the Synology web app. Scheduling the Run of the Images In an ideal world, you'd run the first image, and a successful run would trigger the run of the second image. Unfortunately, Synology doesn't lend itself to this, or to be precise, I didn't find a way to achieve it. Instead, I relied on a simple workaround: schedule the second image run one day after the first image run. In the Synology UI, open the Control Panel and search for the Task Scheduler. Click on the Create button. Select Scheduled Task > User-defined script, as there's no dedicated Docker run item. Create Scheduled Task > User-defined script Here's how to configure it: The script uses the synowebapi command. I stumbled upon the command; parameters are self-explanatory, but I didn't find the documentation. You need to create two scheduled tasks and change the task name as well as the image name in the command. synowebapi For scheduling, space out one day between getting a new certificate and deploying it. That should give enough time and doesn't change the result. Note that because images run to completion, i.e., they don't loop, Synology will send a warning notification similar to the following, regardless of whether the run was successful or not: i.e. Docker container neilpang-acme-deploy-cert stopped unexpectedly. Go to Docker for more information. Docker container neilpang-acme-deploy-cert stopped unexpectedly. Go to Docker for more information. After running the two Docker images in turn, your NAS will be using a joker certificate. Summary In this post, we implemented a solution to avoid leaking subdomain information when requesting a TLS certificate: requesting wildcard certificates with acme.sh from Synology. The solution isn't perfect: you can use wildcard certificates on any subdomains, but it represents a security risk if someone steals them. acme.sh Besides, I stored the secrets as environment variables for configuring Docker images. However, in my context, these are acceptable risks. Note that this approach doesn't remove any previously logged requests. The only workaround is to move to another place, or, barring that, change your Internet Service Provider. To go further: To go further: Synology DSM 7 with Let's Encrypt and DNS Challenge
ACME.sh 3rd party deploy plugin for Synology DSM 
How to issue Let's Encrypt wildcard certificate with acme.sh and Cloudflare DNS
How to use DNS API
Synology: Schedule Start & Stop For Docker Containers Synology DSM 7 with Let's Encrypt and DNS Challenge Synology DSM 7 with Let's Encrypt and DNS Challenge ACME.sh 3rd party deploy plugin for Synology DSM ACME.sh 3rd party deploy plugin for Synology DSM How to issue Let's Encrypt wildcard certificate with acme.sh and Cloudflare DNS How to issue Let's Encrypt wildcard certificate with acme.sh and Cloudflare DNS How to use DNS API How to use DNS API Synology: Schedule Start & Stop For Docker Containers Synology: Schedule Start & Stop For Docker Containers Originally published at A Java Geek on September 28th, 2025 Originally published at A Java Geek on September 28th, 2025 A Java Geek

Cloudflare

The Day I Learned My NAS Was Traceable Through TLS Logs

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Too Long; Didn't Read

Download free Tech Leaders Productivity Report!

Privacy for Subdomains: Here's What You Should Be Focusing On

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

37 Stories To Learn About Dns

5 Best Website Categorization Tools

5 Fundamental Steps to Deploying a Website

Android’s Going Secure

16 Best Practices For Securing Your APIs with Apache APISIX - Part 1

37 Stories To Learn About Dns

5 Best Website Categorization Tools

5 Fundamental Steps to Deploying a Website

Android’s Going Secure

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps