The short answer
You install a certificate on a Synology NAS from Control Panel → Security → Certificate → Add, either by letting DSM fetch one from Let’s Encrypt or by generating a certificate signing request there, buying a certificate against it, and importing three files back. The built-in option is quicker, but it only speaks the HTTP-01 challenge, so it needs port 80 reachable from the internet, and the only wildcard it can issue is for a Synology DDNS hostname. If either limit applies to you, importing is not the fallback — it is the only route. As of August 2026 an imported public certificate lasts at most 200 days, so expect to repeat it about twice a year.
Almost every guide to this treats the two routes as the same job with a different first step. They are not. One of them ends with a NAS that quietly keeps its own certificate current for years; the other ends with a recurring task in your calendar that has got more frequent twice since 2025. Which one you get is decided before you open Control Panel, by your router, your ISP and the name you want on the certificate.
Should you use DSM’s built-in Let’s Encrypt or import your own certificate?
Use the built-in option if your NAS is reachable from the internet on port 80 under a hostname that resolves publicly, and you do not need a wildcard for a domain you own. It issues a 90-day certificate and renews it without being asked. Import your own certificate in every other case, because DSM’s client implements only the HTTP-01 challenge against a single certificate authority and has no other way to prove control of a name.
HTTP-01 works by having the CA fetch a file over plain HTTP from the hostname in the request. That single sentence is the source of most Synology certificate trouble. Port 80 has to be forwarded to the NAS and reachable from outside your network, which rules out anyone whose ISP blocks 80 on a residential connection, anyone running the NAS behind CGNAT, and anyone whose security position is that a storage appliance does not get an open port on the public internet. None of those are misconfigurations to be fixed. They are the normal state of a lot of NAS deployments.
The DNS-01 challenge would solve it, since it proves control through a DNS record instead of an open port, and it is also the only challenge that can produce a wildcard. DSM does not implement it. You can run a third-party ACME client such as acme.sh on the NAS to get there, which several people do successfully, but that is a setup you own and maintain rather than a DSM feature, and it is worth watching a full renewal cycle complete before you trust it.
What you need before you start
You need four things: administrator access to DSM, a fully qualified domain name that you control and that will appear on the certificate, somewhere for that name to point, and the certificate itself. A certificate cannot be issued for a private IP address or for a made-up internal name like nas.local, so if your NAS currently answers only on 192.168.1.20, sorting out the name is the first job, not the last.
The usual approach is a subdomain of a domain you already own — nas.example.com — pointed at your NAS. It can point at a public address if the NAS is exposed, or at a private address in split DNS if it is not; the certificate does not care which, because validation happens between you and the CA rather than between the CA and the NAS. That is the quiet advantage of the import route: it is the only one that works for a NAS nobody outside your network can reach.
For the certificate itself, a domain-validated certificate is normally the right fit. Nobody is inspecting the organisation details on a storage appliance, and DV issues in minutes against a CSR. Our SSL certificate range covers the validation levels if you want to compare them first, and which SSL certificate do I need walks through the decision in general terms.
How do you generate a CSR on a Synology NAS?
Go to Control Panel → Security → Certificate, click Add, choose Add a new certificate, and select Create certificate signing request (CSR). Fill in the domain name and organisation details, and DSM produces a downloadable archive holding the CSR and a matching private key. Send the CSR to your certificate authority; keep the private key.
The fields that matter on the CSR form
- Common Name — the exact hostname you will type in the browser, such as
nas.example.com. A certificate forexample.comdoes not covernas.example.com. - Subject Alternative Name — add every other name the NAS answers to, one per line. If you reach it as both
nas.example.comandfiles.example.com, both belong here or the second one will warn. - Organisation and country — required by the form. For a DV certificate the CA does not verify them and they do not appear in the issued certificate, so accuracy matters less here than it would for OV or EV.
Generating the CSR on the NAS is the path of least resistance, because the key never leaves the device and DSM produces it without a passphrase, which is what the import step later needs. You can generate the pair elsewhere with OpenSSL if you prefer — the CSR explainer covers the commands — but if you do, strip any passphrase before importing. Synology’s documentation is explicit that an RSA private key cannot be passphrase protected.
How to import the certificate into DSM
Return to Control Panel → Security → Certificate, click Add, choose Add a new certificate, then Import certificate. Three file pickers appear: Private Key, Certificate, and Intermediate Certificate. Attach the key that came with your CSR, the certificate the CA issued, and the CA bundle respectively, then confirm. DSM applies the change and restarts its web services, so the session drops for a few seconds.
The Intermediate Certificate field is labelled optional and it behaves like it: DSM will accept the import without it and show the certificate as installed. What you get is a server that sends an incomplete chain. Desktop browsers often paper over that, because they cache intermediates they have seen elsewhere or fetch them on the fly, so the NAS looks fine on the machine you tested from. Mobile apps, Java clients and command-line tools generally do not, which is why this surfaces days later as “it works on my laptop but DS file won’t connect”. The certificate chain guide explains what the missing link actually does.
If your CA sent one bundle file containing several certificates, that whole file goes in the intermediate field. If it sent them individually, concatenate them into one file in order, leaf-most first, with each -----BEGIN CERTIFICATE----- block on its own line. All three files are PEM text; a quick head -1 on each tells you which is which, since only the key starts with a PRIVATE KEY line. Our certificate file formats guide covers converting a PFX if that is what you were given.
Tick Set as default certificate during the import if this NAS serves one domain. The default is what DSM presents for any connection that has not been pointed at a specific certificate, which on a single-domain box is everything. Leave it unticked if you are adding a second certificate alongside an existing one and intend to bind it to particular services yourself.
How do you assign the certificate to each service?
Open Control Panel → Security → Certificate and click Configure. DSM lists every service that terminates TLS with a drop-down beside it, and you pick which installed certificate each one should present. This is a separate step from importing, and skipping it is why a freshly imported certificate sometimes shows up on the DSM login page while a package on the same box keeps serving the old one.
| What it covers | How it gets its certificate | Watch for |
|---|---|---|
| DSM itself (port 5001 by default) | The default certificate, unless you assign another in Configure | Reached by IP rather than hostname, it will always warn |
| Reverse proxy rules | Each rule appears in Configure under the description you gave it | A new rule starts on the default certificate until you change it |
| Packages that listen on their own port | Listed separately in Configure once installed | Some need their own restart before the change takes |
| Mail, FTPS and similar | Listed in Configure where the package supports TLS | Clients here cache aggressively; test from a cold client |
Reverse proxy is worth calling out because it is how most people end up with several hostnames on one NAS. Rules live under Control Panel → Login Portal → Advanced → Reverse Proxy, and each one you create shows up in the certificate Configure list afterwards. If you are fronting four services on four subdomains, either give each rule its own certificate or cover them all with one certificate carrying every name.
While you are in Login Portal, the DSM tab holds the HTTP and HTTPS ports and the option to redirect HTTP to HTTPS automatically. Turning that on is the difference between a NAS that is available over HTTPS and a NAS that is actually used over it. The HTTP to HTTPS redirect guide covers the same idea on ordinary web servers.
Can you get a wildcard certificate on a Synology NAS?
You can install one, but DSM cannot issue one for your own domain. The built-in Let’s Encrypt integration offers a wildcard only for Synology DDNS hostnames, the xxx.synology.me kind, because Synology controls that zone and can answer the DNS-01 challenge on your behalf. There is no field anywhere in the interface for *.example.com, and no amount of port forwarding changes that, since a wildcard cannot be issued through HTTP-01 at all.
For a NAS fronting several subdomains through reverse proxy, a wildcard is usually the tidier answer: one certificate covers nas, photos, files and whatever you add next month without reissuing anything. Buying one and importing it takes the same three fields as any other certificate. Our wildcard SSL certificates page covers what a wildcard does and does not include — notably that *.example.com covers one level of subdomain, not a.b.example.com.
The alternative is a multi-domain certificate listing each name explicitly, which is cheaper when the list is short and stable and more work when it is not. Every new subdomain means a reissue. Wildcard vs multi-domain sets the two side by side.
How often will you have to redo this?
About twice a year, and it is getting more frequent. As of August 2026 a publicly trusted TLS certificate can be issued for a maximum of 200 days, following CA/Browser Forum ballot SC-081v3, which took effect on 15 March 2026. The ceiling falls to 100 days on 15 March 2027 and to 47 days on 15 March 2029. Every public CA is bound by the same schedule, so changing issuer does nothing to it.
DSM renews a Let’s Encrypt certificate it obtained itself roughly 30 days before expiry, and it needs ports 80 and 443 reachable at that moment to succeed. A renewal that silently fails in the middle of the night is the classic version of this problem, because the certificate keeps working for another month and the failure only becomes visible when it does not. If the built-in route is working for you, check the expiry date in the certificate list occasionally rather than assuming.
An imported certificate has no renewal mechanism behind it at all. DSM will not fetch a replacement, will not warn you as the date approaches, and will keep serving the old one until it expires and every client starts refusing. Put the date in whatever you actually look at — a calendar entry, an expiry monitor, the reminder from whoever issued it — because the NAS will not raise its hand. For the longer arc of this, preparing for shorter certificate lifetimes covers what the 2027 and 2029 steps mean for anything renewed by hand.
Why does the browser still say the certificate is not trusted?
Nine times out of ten it is one of three things: the intermediate certificate was never uploaded, the certificate was installed but never assigned to the service you are hitting, or you are reaching the NAS by an address that is not on the certificate. All three produce a warning that looks identical in the browser and each has a different fix.
Working through it
- Warning says the issuer is unknown or the chain is incomplete — the intermediate field was left empty. Re-import with the CA bundle in place. This is the one that behaves differently between a desktop browser and a phone app.
- Warning names the wrong hostname — you are reaching the NAS by IP, by a name that is not in the certificate’s SAN list, or through a reverse proxy rule bound to a different certificate. Check Configure before suspecting the certificate.
- Old certificate still being served — the service was not reassigned, or it has not restarted. Confirm the assignment in Configure, then restart the package rather than only reloading the browser.
- Import itself was rejected — usually a mismatched key and certificate, or a passphrase-protected RSA key. Verify the pair matches by comparing
openssl x509 -noout -modulus -in cert.crtwithopenssl rsa -noout -modulus -in server.key; the hashes must be identical. - Everything looks right and it still warns — check the system clock. A NAS that lost time badly enough will reject a certificate as not yet valid, and the message points at the certificate rather than the clock.
If your NAS is reachable from the internet, the fastest way to confirm what it is actually sending is to look from outside. Our SSL checker reports the chain a host is serving, which settles the intermediate question in seconds. For a NAS that is not exposed, openssl s_client -connect nas.example.com:5001 -showcerts from a machine on the same network tells you the same thing: count the certificates that come back, and if there is only one, the bundle never made it in.
Getting the certificate for your NAS
If your NAS is on the import route, a domain-validated certificate against the CSR you generated in DSM is normally all it needs, and a wildcard is worth it once reverse proxy gives you more than two or three subdomains. Every certificate we sell is issued by Certum, a publicly trusted CA whose roots already ship in the major browser and operating system trust stores, so nothing has to be installed on the machines and phones that connect to your NAS. Compare the options on our SSL certificates page.
Related reading
- SSL certificate file formats — what to do when the CA sends a PFX and DSM wants three separate PEM files.
- SSL certificate chain explained — why the optional third field is the one that breaks phones.
- Preparing for shorter certificate lifetimes — what the 2027 and 2029 steps do to anything renewed by hand.