This is the 4th part of my multi-part series on setting up SAML Authentication using the VMware Workspace ONE Access product. In this article, I will quickly cover the Secure Sockets Layer (or SSL) configuration I will be using. If you missed my earlier posts, you can review them here:
- Part 1: Preparation
- Part 1.5: Database Changes
- Part 2: Primary Node Deployment and Config
- Part 3: Load Balancer Configuration
- Part 4: SSL Configuration
- Part 5: Deploy Additional Nodes
As we talked about during the last part, using an evaluation license in my #HomeLab environment presented several key limitations on options for load balancing. Those limitations are directly related to how SSL can be used. In an evaluation license, NSX-T is only in a Limited Export edition configuration–no SSL can be supported. In a Production environment, there are several options for how to handle SSL connections with your load balancer. NSX-T supports the following Layer 7 HTTPS Load Balancing Options:
- SSL Offload: Load balancer terminates the HTTPS connection from the client and connects to the server via HTTP
- SSL End-to-End: Load balancer terminates the HTTPS connection from the client and connects to the server via HTTPS
- SSL Passthrough: Load balancer does not terminate the HTTPS connection from the client and connects to the server via HTTPS
In the #HomeLab use case, we have to use a TCP Load Balancer (as described in the previous article), so we are going to use a variation on the SSL Passthrough configuration. The difference is that we will not be configuring the NSX-T load balancer at all since, in our case, it is just a passthrough device working off of port 443. Our clients will receive the certificate from the server directly as they connect. In addition, this same certificate will be used by admins (me) as I configure each node. So the certificate must support multiple DNS names to support the Load Balanced-DNS name as well as the DNS name for each node. This can be done in 2 ways:
- Use a wildcard certificate that works for any host within the dns domain name (*.darkhonor.net)
- Use a certificate with multiple DNS Subject Alternative Names assigned
I will be demonstrating Option 2. Most of the articles I found online for #HomeLab use demonstrated option 1. So, I’m here to show how to do the other.
CA Server Configuration
As a basis of understanding, I have an Offline Root CA that I built using an Ubuntu VM and an Online Intermediate CA running Windows. I’m using the built-in Microsoft Certifications Services CA for the Intermediate CA. Using the default configuration of the CA, Microsoft does not allow the addition of Subject Alternative Names (SAN) to certificates. According to this article, it is seen as a dangerous security practice. However, with a simple command, you can configure the CA to allow the additions. On your CA, open an Administrative Command Prompt and type the following command:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2Once you’ve set this property for the server, stop and restart the CA services. From here on out, you can just add the SAN data to the request.
Generate Certificate Signing Request
Using one of my Ubuntu Linux clients, I generated a Certificate Signing Request (CSR). I’m using this because it is easier to pull the paired key that is generated alongside the request using Linux than Windows. On your linux system, type the following command as a normal user:
$ openssl req -new -newkey rsa:2048 -nodes -keyout dwsa.key -out dwsa.csrThis will output both the Certificate Signing Request (CSR) and the Private Key that will be used for the certificate. The other options specified are:
- req: Command to manage X.509 Certificate Signing Requests
- -new: Generate a new CSR
- -newkey <arg>: Generate a new Private Key with the CSR using the RSA algorithm and a 2048 bit key
- -nodes: Do not encrypt the Private Key
- -keyout: The filename to output the Private Key
- -out: The filename to output the CSR
This command will generate two human-readable text files. If you review the two new files that have been created, you will see something similar to the following two blocks:
-----BEGIN CERTIFICATE REQUEST-----
<Everything between these lines is the CSR>
-----END CERTIFICATE REQUEST-----
-----BEGIN PRIVATE KEY-----
<Everything between these lines is your Private Key>
-----END PRIVATE KEY-----
Request Certificate
Once you have your CSR and Private Key, you can request the certificate from the CA. The Microsoft ADCS web application makes this process very easy. Click the link to request a new advanced certificate. Copy the contents of the CSR file into the top block as shown below. I have a “Web Server” template that I use for all web certificates. In the attributes block, you will add the following text to add the SAN DNS entries. You will need to have entries for the load balanced dns name as well as for each of the nodes:
san:dns=dwsa.darkhonor.net&dns=dwsa1.darkhonor.net&dns=dwsa2.darkhonor.net&dns=dwsa3.darkhonor.net
When you submit the request, you will be prompted to download and save the certificate itself. In order to load the certificate on Workspace ONE Access, you will need to save the certificate as “Base 64” encoded.
Opening the certificate file, you can view various details.
On the “Details” tab, scroll down to “Subject Alternative Name”. Here you will see all of the assigned SANs
Finally, on the “Certification Path” tab, you can see the full certificate chain and the status of the selected certificate. As long as the Root CA and all Intermediate CAs are trusted by your client, you should see “This certificate is OK”. There will be a problem if it does not know or trust one of the certificates in the chain.
Install New Server Certificate
Now that you have a new SSL certificate and Private Key, you’re almost ready to install the certificate on your Workspace ONE Access node. Remember those other two certificates in the chain? Well, you will need to download those as well and add them to the certificate file. The certificate file is Base 64-encoded, so it can be edited with any text editor. You will download both of the certificates and copy their contents into the new certificate file. You will just add the contents of each of the CA certificates at the end of the file so it is structured like this:
-----BEGIN CERTIFICATE-----
<contents of Workspace ONE Access node certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<contents of Intermediate CA certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<contents of Root CA certificate>
-----END CERTIFICATE-----
Save this file and change the file extension to .pem from the Windows default of .cer. Navigate to the Appliance Configurator page. In my case, it is https://dwsa1.darkhonor.net:8443/cfg. Select the “Install SSL Certificates” tab along the left hand side. Before you can install your new certificate, you have to configure the appliance to trust your internal CAs. Select the “Trusted CAs” tab. You will see a pre-installed certificate as shown here:
You will need to add the Root CA certificate first. Once you have confirmation, add the second certificate for the Intermediate CA. Once both have been added, click “Restart Service.” If everything goes well, you should see the certificates you added in the list:
When you click the “Save” button, the appliance will install the certificate and restart the server. This process can take a while.
Once the service restarts, you should see the valid connection showing in your web browser address bar. The lock symbol represents a secure connection with a trusted certificate.
That’s it for this step. Now that we have a trusted SSL certificate installed on the appliance that will work with all three nodes, we are ready to clone the current node and setup our Workspace ONE Access cluster. Keep an eye out for the next installment which will walk through that process.