Synology SSL Certificate – a guideline

Ever struggled with securing access to your (Synology) NAS box through use of SSL and web server certificates? Well – here’s why you struggled; and maybe also how not to struggle anymore … have fun 🙂

A few things to know first

As always: The boring things go first! There’s some knowledge captured in them, but if you’re the impatient one (like me ;)) -> get over it!

What is:

• SSL/TLS: secure socket layer – now more correctly referred to as “transport layer security” – is a crypto protocol which on the one hand ensures that the web server’s identity which is accessed is securely confirmed and on the other hand supports encryption of the connection between a client (browser) and a web server.
• a cert (certificate): (for the purpose of this article let’s keep it with it being) a file that holds identity information of the webserver where it comes from as well as supports creation of a public key for encryption
• a CA: “certificate authority” – a company or entity which is capable of signing a certificate to confirm its validity; this could be a Root-CA – in that case being the last in a -> “certificate chain” – or an Intermediate-CA, thus being able to sign certs but itself needing to be signed by a Root-CA; CAs are presented through certs themselves (so, you’ll see a whole bunch’o’ different cert files handled here)
• a private key: the private – confidential, not to be distributed – part of pair of keys for symmetric encryption; one party encrypts content by using a public key and sends that content to the other party, which is capable of decrypting the content by use of its private key. Obviously the sending party must use a public key that corresponds to the private key
• a certificate chain (cert chain): a chain of certificates, the first in the chain being used for the actual purpose (e.g. encrypting traffic, confirming identity), the last one representing and confirming the ultimately trusted party. Each cert in a chain confirms the correctness of its respective successor
• a SAN cert: a “Subject Alternate Names” certificate file; this is a certificate confirming a web server’s identity by more than one specific name (URL), e.g. yourbankaccount.com; login.yourbankaccount.com; mobile.yourbankaccount.com; yourbankshortname.com; … whatsoever … (note: the use of SANs with your server’s cert only depends on how you’ve configured DNS and IP addresses to access the server; if there’s only one URL for your server, you won’t need that)

What happens when surfing https in your browser?

The “s” in https says: This is an SSL connection.

• When accessing a web server via https, your browser expects a cert being presented by the server.
• This cert is checked in 2 ways:
  • (1) can I trust tis cert to be what it says to be and
  • (2) is it telling me the true identity of the server that I am accessing

So, if e.g. you’re going to https://www.yourbankaccount.com and the cert holds “www.yourbankaccount.com” and your browser can read from the cert chain, that it can trust this cert, all will be fine and you can safely access that server.

How can trust be established?

As explained above, trust is confirmed through a chain of certificates. The last cert in the chain (say: the Root-CA cert) says “yes, that cert you’re showing me is OK”; the next one (say: the intermediary) says “yes, that next one is OK, too” … and so on until eventually the first cert – the one having been presented to your browser – is confirmed to be OK.

In other words: At least the last cert must be one that the client (your browser) can say of: “I can trust you!”

And how could it do that: Because, that last cert in the chain is one of a commonly trusted, public CA; commonly trusted authorities are e.g. Symantec (who purchased Verisign), Comodo, GoDaddy, DigiCert, … (wikipedia has a list plus some references to studies and surveys).

And finally: How can YOU get hold of a cert for YOUR web server, that is confirmed by one of those trusted certificate authorities? By paying them money to sign your cert. As simple as that.

Do you wanna do that just for your home disk station? No – of course not.

And this is were self-signed certificates kick in …

Now: What does Synology do?

Your disk station (whatever vendor, most probably) offers browser access for administration and so … plus a lot of other services that can be (and should be) accessed via SSL, hence: you need a cert. Synology has certificate management in the control panel (rightmost tab in “Security”).

The following screenshot shows the options that are available when clicking “Create certificate”:

Create certificate options briefly explained (with steps that happen when executing them):

1. Create a self signed certificate:
   1. In the first step, enter data for the root certificate (see screenshot; mind the headline!)
   2. Second step: Enter data for the server certificate itself (here’s a screenshot also for this; note, that you can even use IP addresses in the SAN field at the end – more on this a little later or – sic! – further above)
   3. When hitting apply, the disc station generates 2 certificates + their corresponding private keys and
   4. uses the first one to sign the second one
   5. Eventually, both are applied to the disc station’s web server and the web server is restarted (all in one single go; expect to be disconnected briefly)
   6. Once you’re back online in the control panel, the “Export Certificate” button allows download of both certificate and corresponding private keys (keep the private keys really, really – REALLY! – secluded!)
2. Create certificate signing request (CSR) – this is a file to be sent to a certificate authority for signing and creation of a corresponding certificate:
   1. The only step to be done is to provide data for a server certificate (same information as in step 2 of (1) above)
   2. When done, click next and the disc station generates the CSR file + its corresponding private key
   3. Eventually the results are provided for download
   4. Download the files; in theory, you could now send them to a trusted CA. All CAs got slightly different procedures and charge slightly different rates for doing this
3. Renew certificate:
   1. When clicking this option, a new CSR + private key of the existing certificate (the one already loaded) is generated and
   2. offered for download
   3. Same as step 4 in (2) above applies for the downloaded files
4. Sign certificate signing request (CSR) – this allows to use the root certificate, that you could e.g. have created in (1) above, to create another certificate, which you could e.g. have created a CSR for in (2) above:
   1. The only step to execute is to select the CSR file,
   2. enter a validity period and
   3. specify alternate names for the target server (if need be)
   4. Again – upon completion – download of the resulting files is offered

That last step would e.g. allow you to generate only 1 root certificate (by using option (1) above) and use that for signing another server certificate of a second disc station. Note, that the respective CSR file needs to be generated in that second disc station. As a result in this case (after having downloaded everything) you should have:

• 1 ca.crt file + corresponding ca.key file
• 2 server.crt files + corresponding server.key files

The second server.crt + server.key file would be the one to be uploaded into your second disc station by using the “Import certificate” button right next to “Create certificate” in the control panel.

What did I do in fact?

In order to secure my 2 disc stations I executed the following steps:

• “Create certificate” – (1) above – on the first disc station
• Download all files
• “Create CSR” – (2) above – on the second disc station
• Download all files
• Execute “Sign cert” – (4) above – on the first disc station with the results of the “Create CSR” step just before
• Again, download everything
• “Import cert” on the second disc station with the results from the signing operation just before

Now both my disc stations have valid certificates + corresponding private keys installed and working.

Does that suffice?

Well, not quite. How would any browser in the world know that my certificates can be trusted? Mind, we’re using self-signed certs here; the CA is my own disc station; this is nowhere mentioned in any trusted cert stores of any computer (hopefully ;)).

What I can do next is distribute the cert files to clients that I want to provide with secure access to my disc station.

On an OS X client:

• Open the “Keychain Access” app
• Import the .crt files from before (NOT the .key files – these are highly private to your disc station – do never distribute those!)
• For the certificate entry resulting from the ca.crt file
  • Ctrl+click on the file
  • From the menu chose “Get Info”
  • Expand the “Trust” node
  • Set “When using this certificate” to “Always Trust” (as you can safely trust your own CA cert)

The 2 other cert files should now read “The certificate is valid” in the information on top.

On a Windows client:

• Open the Management Console (click “Start” -> type “MMC”)
• Insert the “Certificate” snap-in for “Computer Account” -> “Local Computer”
• Expand the “Trusted Certificate Authorities” node until you can see all the certificates in the middle pane
• Right click the “Certificates” node
• Go to “All tasks” -> “Import…” and
• Import the ca.crt file
• Expand the “Trusted Sites” node until you can see all the certificates in the middle pane
• Right click the “Certificates” node
• Go to “All tasks” -> “Import…” and
• Import both the server.crt files
• Close MMC w/o saving; you’re done here

With that, the respective client now trusts your disc station servers; browsers on your client would not issue a security warning anymore, when accessing your disc station.

Does that solve everything?

Well … ähm … no!

Because I’ve used SAN certificates with my disc stations and because Google Chrome does not support SAN certificates correctly, Chrome still issues a security warning – a pretty weird one telling me that the cert was issued for server abc.def.com while the server presents itself as abc.def.com; well, Google, you better work on that 🙂

But Apple Safari and Microsoft Edge securely route access to my DSs – and that’s pretty neat 🙂

And is this the ultimate solution?

Well … I guess … not so, because: I cannot really easily distribute all my cert files to anyone who’d possibly need to access my disc stations. This is were commonly trusted, public CAs come into play. Money makes the world go ’round, isn’t it?