0 Flares 0 Flares ×
In a previous post I explained how to publish VAC (Veeam Availability Console) web service over Internet, to allow administrators and tenants to consume it. This time, we’ll complete the publishing by adding a proper SSL certificate to the Web Interface.
Complete the setup of the web server
After the Web Service is exposed over Internet, it can be immediately reached via a web browser over its public IP address and TCP port 1280. But we want to make things easy for our users, so as in any web server, first we setup a DNS record for it to be easily remembered:
So, now our address is https://vac.virtualtothecore.com:1280. Easy, but it can be even better. We can use http redirection to let people just write the URL, and be automatically redirected to the correct TCP port. We’ll see later, we need TCP port 80 open anyway for the certificate automatic renewal.
So, once we have also opened TCP port 80 in our firewall, and let our default website be visible, we create a small redirect page. I may be an old school guy, but I still prefer to use a simple redirect page rather then URL Rewrite modules or the likes. In this way, is super convenient to change any configuration by simply and quickly editing the web page itself.
In the root folder of the website, directly in the filesystem, I create a new default.aspx file and I open it with a text editor. Inside it, I place this code:
Response.Redirect ("<a href="https://vac.virtualtothecore.com:1280/">https://vac.virtualtothecore.com:1280</a>")
With this small code, now everytime I write in a browser vac.virtualtothecore.com, I’m automaticaly redirected to the VAC homepage. Or better said, to this page:
That’s because the certificate that’s installed by default in the VAC web interface is self-signed. We need a real certificate.
Install and automatically update a Let’s Encrypt certificate in IIS
I talked already about Let’s Encrypt certificates and how to automatically install and update them, in regards to Veeam Cloud Connect. This time however, since we are already using IIS, instead of a manual challenge verification against a TXT resource record in our DNS, we’ll try to completely automate the process against IIS itself. And instead of using ACMESharp, I’m going to use an even simpler tool, partially based on ACMEsharp itself: Windows ACME Simple (WACS).
All operations are to be executed in the server running the VAC web interface. First, we download the latest release and we put all the software in a folder that is easy to remember and use, like c:\acme. The tool has one executable letsencrypt.exe that can be run from the command line, either in interactive mode or unattended/scripted. We’ll first run it in interactive mode to see the available options:
As you can see, there’s a clear and easy menu to be used. Since this is a new installation, we’ll start by creating a new certificate:
The tool allows us to first create the binding that’s needed to assign the new SSL certificate, and then after a few simple questions completes the certificate creation and installation in a few seconds. If we check IIS we see it immediately:
and obviously, if we now try to login into the VAC web console, we have no certificate error anymore:
Once the certificate is installed, we will need to renew it. There is a “renewal date” that is set after 55 days from th certificate installation; what it means? Well, you can eventually run in interactive mode this command to verify and complete the renewals:
Every certificate that is at least 55 days old (remember, Let’s Encrypt certificates expire after 90 days, so we have 35 days to renew them here) is renewed by the command. But in reality, we don’t even have to schedule this command: if you noticed the output of the command line I posted above, as soon as the first certificate is created the tool also creates this exact daily scheduled task, to be executed every day at 09.00.
This way, we are sure that our VAC web interface will always have a validated and trusted SSL certificate.
PS: this can be used also to install the certificate into the VAC API interface, since it’s another IIS website after all!