It's possible to use a Synology Diskstation's Certificate generation functionality to create a set of privately scoped (non-FQDN) self-signed SSL certificates that you can use to provision internal network services so that connecting to them does not cause your browser to throw warning messages (or in the case of Chrome, prevent you from connecting at all).
Usually, when you add network devices to your personal private network, they are refereneced by IP addresses as naming requires either maintaining individual host files on each machine or setting up DNS. The first is pretty cumbersome; the second seems like overkill (unless you're a masochist, which I have been in the past). As an alternative, I considered using locally scoped names associated with fixed IPs associated via a light-weight DNS resolver (in my case, using unbound
running on my Raspberry Pi with Pi-Hole).
WARNING: This is clearly a HACK and is not intended to be used for production environments. If you need full SSL certificates on your internal network, you'll need to configure split-horizon DNS with a FQDNs and a certificate provider (probably LetsEncrypt if you're trying to do this for free, which Diskstation supports).
-
Click on
Add
. This should bring up theCreate certificate
dialog. ChooseAdd a new certificate
and clickNext
. -
Fill in the
Description
(something which identifies this local cert). Choose theCreate self-signed certificate
option and clickNext
. -
Fill in the root certificate details and click
Next
. -
Specify the
Subject Alternative Name
which should match the local non-FQDN name of the machine on your network. ClickNext
.
WARNING: The certificate MUST have a
Subject Alternative Name
which matches the the local non-FQDN name or Chrome (not Firefox) will show an insecure connection when access this machine although https is being used.
-
Right click on the new certificate and choose the
Export certificate
option. This will download all of the certificates into anarchive.zip
file. -
Unpack the
archive.zip
file. This should contain the following files:syno-ca-privkey.pem
- The private key for the generated root certificaatesyno-ca-cert.pem
- The public key for the generated root certificateprivkey.pem
- The private key for the generated server certificate (which matches theSubject Alternative Name
/local non-FQDN)cert.pem
- The public key for the generated server certificate (which matches theSubject Alternative Name
/local non-FQDN)
- Import the
syno-ca-cert.pem
public key (either by clicking on it or using theImport Items
option in Keychain Manager.
NOTE: You will be asked to provide your administrative password as these items are being added to the machine's keystore. These should be stored in the
System
Keychain.
-
The
syno-ca-cert.pem
is the self-signed root certificate responsible for being the certificate authority for additional certificates. Trusting this certificate means that additional certs which use this as their CA will automatically be trusted. -
To set this to
Always Trust
, select the root certificate in the Keychain Manager and right-click toGet Info
. This should bring up a dialog box. Note that there are two sections -Trust
andDetails
. Expand theTrust
section and in thewhen using this certificate
field, selectAlways Trust
.
- The
cert.pem
is the self-signed server certificate that can be used to establishhttps
connections to the machine. Follow the import procedure you used for the root certificate. Unlike the root certificate, you will NOT need to set theTrust
on this certificate explicitly as it will be inherited from the root certificate previously configured.
You can use this procedure to create SSL certificates for other machines on your network.
Follow the instructions above to create a new self-signed certificate. We will be reusing the original the ORIGINAL generated root certificate (syno-ca-cert.pem
) and private key (syno-ca-privkey.pem
) to create a certificate signing request (CSR) for this new certificate.
% openssl
-
Navigate to
Control Panel
->Security
->Certificates
on the DSM and click theCSR
button. -
In the
Create certificate
dialog box, select theSign certificate signing request
option and clickNext
.NOTE: Ensure that you use the correct certificate root you generated previously to ensure that the new certificaate is associated with this self-signed CA.
-
Upload the CSR generated via
openssl
in the previous step. Ensure that theSubject Alternative Name
matches the local non-FQDN name of the server you are associating with this certificate. -
Download the signed certificate.
-
Import the
cert.pem
into Keychain Manager. Because this certificate was signed by the root certificate already grantedTrust
, this certificate should JUST WORK (fingers crossed).
- The DSM does NOT allow you to specify the certificate
Validity Period
for the root certificate/orignal cert. Strangely, it does allow you to specify it when using theCSR
functionality.
- provide the
openssl
command to generate the CSR
it seems the option to create a self-signed certificate no longer exists... why would Synology people do this?