8. SSL management
VAC uses SSL certificates to secure two types of external connections:
- Agents and Veeam Backup servers connecting to the VAC Service via Cloud Connect
- users interacting with the Web Interface (or the API interface, if exposed)
In this chapter, we will explain how to configure and maintain both types of certificates.
8.1 Cloud Connect certificates
Any VAC management agent, both those running in Veeam Agent for Windows and Veeam Backup and Replication, connects over Internet to its assigned Veeam Availability Console using the SSL tunnel created by Veeam Cloud Connect. That’s why VAC requires at least a Cloud Gateway to properly work.
NOTE: In a VAC installation controlling multiple Cloud Connect servers, we are referring to the installation that is local to the VAC server itself.
For this reason, the management of this certificate is not done through VAC but directly into Veeam Cloud Connect.
Providers can learn how to manage and even automate SSL certificates in Veeam Cloud Connect in the dedicated chapters of the Cloud Connect Reference Architecture, available here:
- 9.1 SSL Certificates generation: https://www.vccbook.io/9.advanced/9.1-ssl_certificates.html
- 9.2 SSL Automation with Let’s Encrypt Certificates: https://www.vccbook.io/9.advanced/9.2-lets_encrypt.html
8.2 Web Interface certificates
VAC WebUI is a website installed inside Microsoft IIS Server. For this reason, we can use IIS technologies to protect this website using SSL.
By default, the installation also creates and applies to the website a self-signed certificate. This is a quick and easy solution for the initial tests, but it’s not acceptable when the system goes into production, as the certificate will raise security warnings in any web browser:
The reason is that we are trying to connect to vac.virtualtothecore.com, while the certificate is signed for vacweb01.virtualtothecore.local, that is the internal name of one of the WebUI servers.
So, we need a proper certificate signed for the domain name we are using over public internet.
8.3 Resellers and custom DNS names
To complicate things, in VAC v3.0 also resellers can setup their own custom DNS name as part of the branding capabilities. Let’s supposed we have a reseller that uses a domain draas.it, the portal branding could be like this:
The reseller will also configure its DNS resource record to match the IP of the VAC web interface.
But this is not enough; when customers will connect to VAC, even if it was previously configured to validate the dns name vac.virtualtothecore.com, they will receive again a security warning, since the certificate will not be valid for vac.draas.it.
For a fully functional setup, the provider will need to configure the SSL certificate to support every custom dns name that may have been configured by any reseller.
To discover any created DNS names, service providers can run this Powershell script to query the VAC database:
# Variables
$DBServer = "sql_vac.virtualtothecore.local"
$databasename = "VAC"
$Connection = new-object system.data.sqlclient.sqlconnection
$Connection.ConnectionString ="server=$DBServer;database=$databasename;trusted_connection=True"
### Connect to Database and Run Query
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand #setting object to use sql commands
$SqlQuery = "SELECT [WebApplicationUri] FROM [VAC].[VeeamBR].[BrandingSettings]"
$Connection.open()
$SqlCmd.CommandText = $SqlQuery
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$SqlCmd.Connection = $Connection
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$Connection.Close()
$list = $DataSet.Tables | Out-String -Stream | Select-String -Pattern "https"
$list = $list -replace 'https://' -replace '/'
$list
The script will return a list like this one in our lab:
vac.virtualtothecore.com
vac.draas.it
These are the domains that we will need to validate in our new certificate, the first one is the general DNS name used by the service provider, and we also have an additional custom DNS name created by the a reseller using VAC.
8.4 Prepare IIS for Certificate validation
We will use Let’s Encrypt SSL certificates to protect our Web interface. One of the tests that Let’s Encrypt does to validate the ownership of a website is to test a connection towards it. However, this connection is hardcoded to TCP port 80, so we need to configure our environment to accept inbound connections not just to port 1280, but also 80.
This is not done towards the WebUI but towards the default IIS website by the way.
Depending on the frontend solution a provider is using, the needed steps to obtain this result may vary; it’s up to their networking/security team to configure the system accordingly.
8.5 Let’s Encrypt automated certificate management
We will use Windows ACME Simple (WACS), also known as win-acme, as the tool to configure the certificates automatically. It not the goal of this document to explain the ACME libraries or Let’s Encrypt certificates.
From the github repository, we first retrieve the latest version of the tool, and we unzip it into a new folder that we create into the Web server, like c:\acme. Note that in a scale-out configuration, the certificate we create on one Web server must also be installed into the second server.
The tool can be executed interactively or in unattended mode. Among its options, WACS can accept as input multiple targets, that could be IIS sites, bindings, or even a list of hosts to be passed manually. Since VAC doesn’t bind the custom DNS names to the IIS website, we will use the manual option.
By using the list we retrieved in the previous paragraph as an input, we can create a new certificate for our IIS website:
As we can see, the validation as been completed successfully, because the DNS names are pointing to this website and because of the step we described in paragraph 8.4; then, the certificate has been retrieved and installed into the website we specified, that is the ID2 corresponding to the Veeam Availability Console Web UI.
Also, WACS has already created a Scheduled Task to renew automatically this certificate:
This type of certificate is called Subject Alternate Name (or SAN), a digital security certificate which allows multiple hostnames to be protected by a single certificate.
If a reseller changes its DNS custom name, or a new one is added, the procedure has to be executed again and the new list has to be passed to the tool. This can be done in unattended mode running the tool with its paramenters, that can be found here: https://github.com/PKISharp/win-acme/wiki/Command-line.
Now, if we visit the website using both the provider URL or the reseller URL, the certificate appears correctly:
