After having written abundantly about the problems I faced when updating my DiskStation to DSM 6 I am now happy to write about the new features of Synology’s latest OS version. In particular the Let’s Encrypt integration and the ability to configure a reverse proxy right from the GUI.
If you are interested in how to combine these features to easily set up HTTPS access to your Tomcat 7 (and potentially other application servers) on your DiskStation, this if for you.
Haven’t we done that?
If you were following this blog, you might have noticed that I already described both how to get a Let’s Encrypt certificate for your Diskstation and how to use the same certificate to serve your Tomcat apps through HTTPS. If you are not familiar with HTTPS and Let’s Encrypt, I invite you to read these older posts upfront.
The approach described in my two older posts worked just fine and allowed me to encrypt all traffic coming to my DiskStation with a trusted certificate months before Synology integrated Let’s Encrypt support directly into DSM. However the described method had a few shortcomings:
- Let’s Encrypt client did not run on the DiskStation itself
- manual process to generate and import certificates
- separate manual process to create keystore for Tomcat
- repeat both manual processes every 90 days for renewal
For these reasons my old way of doing this could not be a long term solution.
Thankfully DSM 6 integrated Let’s Encrypt support, which allows fully automated certificate creation and renewal for their DSM 6 compatible products. However this takes care of Synology’s own web applications and the things you serve from your DiskStation through Synology’s Web Station, only. In my old setup I allowed direct access to Tomcat by forwarding its HTTPS port and thus had to configure HTTPS support in Tomcat separately.
This means although DSM 6 automatically creates and renews certificates, I would still be required to do the manual steps I described in my old post to use the certificate for Tomcat, too. To avoid this I needed to somehow make Tomcat accessible through the internet using HTTPS without requiring Tomcat itself to handle HTTPS connections directly. This is where the new reverse proxy feature comes into play!
What is a reverse proxy?
WikiPedia offers the following defintion:
[…] a reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers.
These resources are then returned to the client as though they originated from the proxy server itself.1
So this means you can have a reverse proxy to handle all client requests, do the HTTPS encryption and decryption and thus become your internet facing entry point to another server that actually contains the resources your clients are requesting. The server itself does not need to be accessible through the internet anymore and does not need to take care of HTTPS.
In my scenario Synology’s Web Station (which is basically a pre-configured NGINX web server) would be the HTTPS enabled reverse proxy and Tomcat would be the server. This way we do not need to allow direct internet access to Tomcat and do not need to teach Tomcat how to use our certificate for HTTPS. Instead we have only Web Station taking care of handling HTTPS traffic. Sounds good, right? So let’s see how to get this done!
Get HTTPS: The easy way
First of all we need a Let’s Encrypt certificate, of course. You can do this in DSM 6 by going to Control Panel -> Security and clicking on the tab Certificate. I won’t describe the process, since it is really nothing more than clicking through a wizard and providing a few details. A fellow blogger already described in detail how to use this new feature. Check out his post here!
There is only one thing to note: During certificate creation be sure to provide an alternative name, that is the domain you want to use for accessing your Tomcat apps. So if you have a domain like
you.myds.me, you could use something like
tomcat.you.myds.me as an alternative name.
Once you are done, you can access all web sites and applications on your Synology through HTTPS! So
https://you.myds.me would serve whatever you have as index inside your web folder,
https://you.myds.me/photo would grant you HTTPS access to your Photo Station and so on.
Now on to setting up the reverse proxy feature for your new
Once logged in to DSM go to Control Panel -> Application Portal and click on the tab Reverse Proxy. There you can setup the reverse proxy feature for redirecting HTTPS requests hitting
https://tomcat.you.myds.me to your local, HTTP Tomcat address (
localhost:7070 by default).
The configuration should look like in the following screenshot:
Hit ok to apply these new settings, but don’t call
https://tomcat.you.myds.me just yet! For Tomcat and its deployed applications to work correctly, there is one more action to take.
Our last step is to reconfigure Tomcat’s default HTTP connector to let it know the proxy port and the scheme, because Tomcat needs to be explicitly told that it’s being proxied through port 443(SSL)!2
Tomcat’s connectors are configured inside the server.xml file, which in my case is located in
So connect to your DiskStation through SSH, find the server.xml file, locate the currently active port 7070 connector and add the attributes proxyPort and scheme like highlighted in line 5 and 6 of the following example:
<Connector port="7070" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8" proxyPort="443" scheme="https" />
Save your changes to the server.xml file, restart Tomcat (you can use DSM Package Center for that) and voila!
You can now access Tomcat through HTTPS by calling
https://tomcat.you.myds.me! If you have an app deployed to Tomcat, let’s say Jenkins, you can access it through HTTPS by calling
Reaping the rewards
Congratulations! You can now access all your DiskStaion’s websites and applications – even the ones served with Tomcat – through HTTPS using a valid Let’s Encrypt certificate. And the best thing about it: This was a one time setup!
The certificate will be renewed by DSM 6 automatically. You will not need to recreate the certificate yourself nor will you need to change anything in Tomcat.
This is exactly the lazy-friendly, long term approach I was looking for!