Since Google released Chrome version 56 (January 2017) the warnings against HTTP only sites that collect passwords and personal details as well as HTTPS sites with untrusted SSL certificates has been stepped up; and this can only be a good thing for the web.
It does mean that now accessing your Synology Diskstation over the local network will throw up a selection of security warnings.
There are 3 choices here for the LAN user:
- Ignore the warnings and click through
- Register an Internet FQDN to your local IP
- Create a self-signed SSL and root CA to sign the SSL
I had been at choice 1, but it was getting bothersome.
Choice 2 is the correct (harder) way to do things but has some financial costs. You need a public domain name to so you can create a fully qualified domain name (FQDN) for your Diskstation (something like https://ds.mydomain.com). Next you can generate a valid Certificate Signing Request (CSR) for the FQDN and configure DNS to point back to your local LAN and setup whatever routing is required. This is best if you need to secure a local LAN asset where you do not control all devices accessing the Disktation.
No, you cannot buy a public SSL from a 3rd party Certificate Authority (CA) for an internal IP as the practice was banned in 2016 by the Certificate Authorities Browser Forum to reduce the threat of man-in-the-middle (MITM) attacks.
Choice 3 is what this post is about, but it has some foibles.
- Your Diskstation must have a fixed IP address on your LAN
- You must be able to add or assign certificates to devices you want to approve your SSL
In DSM 6.0 -> Control Panel -> Security -> Certificate
Click “Add” to start the process and choose “Create self-signed certificate”
First you create a Certificate Authority (CA) which is the master key that will sign the site usable SSL.
Second you need to supply the details for the certificate itself.
Creating the self-signed certificate from the Synology control panel has a key step that you must complete or the certificate will be invalid. The Subject Alternative Name (SAN) in the second step must contain BOTH the name of the Disktation on your network (“myDSname”) and its local fixed IP (192.168.1.10)
When I first tried this I gave the SSL certificate common name (CN) field the local fixed IP of my Diskstation and in the SAN field I put ONLY its network name.
When accessing my Diskstation via https://myDSname:5001 all was well, but accessing my https://192.168.1.10 was not recognising the SSL certificate. After some head scratching (because Chrome now hides the SSL detail under the Security menu in Developer tools) the error “SSL_ERROR_BAD_CERT_DOMAIN” made me suspect the SAN name also needed to include my local IP?
Once your certificate has been generated click “Configure” in DSM to set the new certificate to be the default for the system (The internal web server will restart) so that when you attempt to load the Diskstation site the correct SSL certificate will be presented to your browser.
Now you need to export the newly generated certificates from your Diskstation and import the root CA [and the SSL certificate] into your local machines certificate store so that they will be recognised as valid.
This is the contentious issue; passing a self-signed certificate off as being from a trusted CA!
It comes down to who you are willing to trust? In your own house on your local LAN, yes your family are likely to trust you (as the root CA) but a guest to your house might not be willing to, hence the need for 3rd party root CA providers to usually sign certificates.
Once setup in your local certificate store (Trusted Root Certificate Authorities in Windows) browsing to either the Diskstation name or IP you specified in the SAN will show as Secure in Google Chrome and all other good web browsers.