Published on 15 April 2020 by Christopher Lewis. Words: 1846. Reading Time: 9 mins.
Introduction
In this
series
of posts, we will be taking a look at how to configure a Multi-Organization Tenancy (aka Multi-Tenancy) in vRealize Automation (vRA) 8.1.
In this post, we will be looking at how to meet the SSL Certitifcate requirements for configuring vRA 8.1 Multi-Organisation Tenancy. I will cover how many SSL certificates are required, then I will cover which SSL Certificates are required, then I will cover how those can be created easily using vRealize Suite Lifecycle Manager 8.1 and, finally, I will cover how to create certificates manually and import them into vRSLCM 8.1.
For more information on the rest of the posts in this series, click
here
.
SSL Certificate Creation
In this section, we will work through which SSL Certificates need to be created (and what values you need to put in them) to support the Multi-Organization Tenant configuration. I will be using the DNS information we generated from
Part 1
of this series to keep the solution consistant.
One of the key points to consider with vRA 8.1 Multi-Organization Tenancy and SSL certificates is that everytime you add a new Organization (Tenant) a new SSL certificate will need to be created that contains the DNS records of ALL of the Organizations. Once the new certificates have been created, it should replace the existing SSL certificate. If we exclude any SSL certificates on Load Balancers, the easiest way to do this is to use vRSLCM. We will cover that in Part 3 of this series.
How many SSL Certificates do I need?
Within a vRealize Automation 8.1 deployment, there are a number of ways to complete the SSL certificate requirements. At a very high level, these are:
Create a number of Subject Alternative Name (SAN) SSL Certificates, one for component as per requirements.
Create a single SAN SSL Certificate with all the components listed.
Create a single Wildcard SSL Certificate.
Whilst all of the above methods (including the wildcard certificate) are supported, the list I have provided above displays the order of my personal recommended approach. From a security stand point it is always recommended to have a minimal number of items within a SAN SSL certificate so that it is only used for its intended purpose (Option 1). If multiple SAN certificates are two complicated to maintain, then consider a single SAN certificate (Option 2) which provides some limitations to it’s use but is less secure. If you have a total disregard for security or SSL best practices (or are deploying into a dedicate lab enviornment) and don’t want the hassle of multiple SSL Certificates then create a wildcard certificate (Option 3). There are obvious security implications of wildcard certificates make this the last resort and reminds me of a old saying Just because you can, doesn’t mean you should. My strong advice is stay away from wildcard certificates.
For these recommendations in a tabular format (because sometimes that is easier to understand and reference) see below:
Table 1: SSL Certificate Approaches
SSL Certificate Approach
Supported?
Recommended?
Multiple SAN Certificates
Yes
Yes
Single SAN Certificate
Yes
Yes
Wild Card Certificate
Yes
No
In this post, we’re going to be using Option 1 as this should be the most secure method.
Which SSL Certificates do I need to create? (Simple Deployment)
For a Simple Deployment, we are going to be needing two (2) SAN SSL Certificates:
Workspace ONE Access - this certificate contains the WOA Appliance FQDN (DNS A Record) and each Per-Organization FQDN for WOA (DNS A Record).
vRealize Automation - this certificate conatins the vRA Appliance FQDN (DNS A Record) and each Per-Organixation FQDN for vRA (DNS CNAME Record).
Given the above requirements, the following DNS information will be used when generating the vRA 8.1 SSL certificates:
Table 2: SAN Certificate Requirements for a Simple Deployment
Which SSL Certificates do I need to create? (Clustered Deployment)
For a Clustered Deployment, you then need to make a decision on whether to use SSL Passthrough or SSL Termination/Offload on the Load Balancer for WorkSpace ONE Access. Both approaches are supported but SSL Offload is the recommended approach that is documented in the recently released
VMware Validated Design 6.0
.
Therefore the recommendation for the vRealize Automation Cluster is to use SSL Passthrough and the recommendation for the WorkSpace ONE Access cluster is recommended to use SSL Termination/Offload.
When following the recommended approach a minimum of two SSL Certificates are required, for the Workspace ONE Access cluster you will need to decide whether or not to separate out the Load Balancer VIP with additional SSL certificate, the purpose of each certificate is outlined here:
Workspace ONE Access - this certificate contains each of the WOA Appliance FQDNs (DNS A Record), the WOA VIP FQDN (DNS A Record) and each Per-Organization FQDN for the WOA VIP (DNS A Record).
Workspace ONE Access VIP (SSL Offload only) - this certificate contains the WOA VIP FQDN (DNS A Record) and each Per-Organization FQDN for WOA VIP (DNS A Record). This certificate is used for SSL termination on the Load Balancer.
vRealize Automation - this certificate conatins each of the vRA Appliance FQDNs (DNS A Record), the vRA VIP FQDN (DNS A Record) and each Per-Organixation FQDN for vRA VIP (DNS CNAME Record).
Given the above requirements, the following DNS information will be used when generating the vRA 8.1 SSL certificates:
Table 3: SAN Certificate Requirements for a Clustered Deployment
How to create SSL certificates for vRA8 (Simple Deployment)
Now that we understand the requirements around certificates a little better, let us look at how we can generate those certificates. I’m only going to be covering the Simple Deployment, because the steps are essentially the same for the Clustered Deployment, some of the values just change!
I normally prefer to generate the Certificte Signing Request (CSR) file myself, which I think this is a hang up from the vRA 6.x and (early) vRA 7.x days where this was required. We can now do this in vRSLCM, so I will cover both ways to do this.
Within the process of creating a Certificate Request, I’m not going to specify what values you should put it in for Organization (O), Organization Unit (OU) or Country Code (C) as they will be specific to your implementation. But I will give examples that are relevant to the scenario outlined at the start of this post.
We will use the following table during the Certificate creation process:
Table 4: Example CSR inputs for a Simple Deployment
I’m going to cover the creation of certificates for a Simple Deployment. I will include how to create the CSR both using vRSLCM (Workspace ONE Access) and manually via OpenSSL (vRealize Automation). My recommendation would be to choose one method and create both certificates using the same method.
Generating the WorkSpace ONE Access Certificate Request (via vRSLCM)
From the vRSLCM homepage, click Locker.
Select Certificate.
Click Generate CSR.
At the Generate CSR screen, enter a friendly Name for the certificate.
At the Generate CSR screen, enter the FQDN for the WOA Appliance into the Common Name (CN) field.
At the Generate CSR screen, fill out the required fields for Organization (O), Organization Unit (OU) or Country Code (C).
At the Generate CSR screen, select 2048 as the Key Length.
Note: For Workspace ONE Access, you have to use the Key Length of 2048.
At the Generate CSR screen, enter all of the required FQDNs (see the Subject Alternative Names field from the Table 4 above) into the Server Domain/Hostname field.
Click Generate.
Download the PEM file that has been generated.
Note: The downloaded file is a Privacy Enhanced Mail (PEM) file that contains both the CSR and KEY information.
Generating the vRealize Automation Certificate Request (via OpenSSL)
Open your favourite plain text editor (I use VSCode) and create the configuration file as outlined below:
Note: You will notice that from the above cfg file, the fields are remarkably similar to the vRSLCM interface.
Save the file as vra.domain.name.cfg.
Create the RSA Key of suitable length to secure the Certificate using the following OpenSSL command:
openssl genrsa -out "vra.domain.name.key"4096
Generate the CSR file using the CFG and KEY file using the following OpenSSL command:
Now you have created your two CSR files, you can forward them onto whomever is responsible for generating your SSL certificates. If, like me, you have a Microsoft Certificate Authority and you are responsible for minting the certificate (or you are just interested in how the certificate is created), then read on!
Note: The following instructions assume you have created a Microsoft Certificate Services implementation, have enabled Certificate Authority Web Enrollment and have configured a template for VMware services.
Open the idm.domain.name.pem certificate request file and copy all of the text (inlcuding the headers) from —–BEGIN CERTIFICATE REQUEST—– to —–END CERTIFICATE REQUEST—–.
Paste the CSR text into the Saved Request text field, select the appropriate Certificate Template from the dropdown and click Submit.
Select the Base 64 encoded option and click Download Certificate.
Note: If you do not have access to the Sub-Ordinate and CA certificates, then click Download Certificate Chain.
Save the file as a idm.domain.name.cer file.
Creating the vRealize Automation Certificate
Repeat the steps in the previous section using the vra.domian.name.csr file. Be sure to save the certificate file as vra.domian.name.cer.
Bringing it all together!
Thanks for sticking with me! It has been a long post but it is a complicated subject. Hopefully right now you will have 5 important certiciate files. These are:
ca.domain.name - the root CA certificate chain for domain.name
idm.domain.name.key - the Private Key (generated by vRSLCM) used to encrypt the idm ssl certificate.
idm.domain.name.cer - the SAN SSL certificate generated from the CA for Workspace ONE Access.
vra.domain.name.key - the RSA Private key (generated by OpenSSL) used to encrypt the vra ssl certificate.
vra.domain.name.cer - the SAN SSL certificate generated from the CA for vRealize Automation.
Now that we have completed the prerequisites for configuring Multi-Organization tenancy, the next part of this series (Part 3) is where we will actually start enabling Multi-Organization Tenancy in vRA 8.1!
Published on 15 April 2020 by Christopher Lewis. Words: 1846. Reading Time: 9 mins.
