VMware Validated Design – Automated Deployment with Cloud Builder – Part 4: Generating SSL Certificates

This is part 4 of a series of posts on VMware Cloud Builder.

• VMware Validated Design – Automated Deployment with Cloud Builder – Part 1: Overview
• VMware Validated Design – Automated Deployment with Cloud Builder – Part 2: Environment Prerequisites
• VMware Validated Design – Automated Deployment with Cloudbuilder – Part 3: Deployment Parameters File
• VMware Validated Design – Automated Deployment with Cloud Builder – Part 4: Generating SSL Certificates
• VMware Validated Design – Automated Deployment with Cloud Builder – Part 5: Cloud Builder Deployment & Environment Validation
• VMware Validated Design – Automated Deployment with Cloud Builder – Part 6: Deploy The SDDC

In this post I will cover generating the required SSL certificates for deploying this VMware Validated Design with VMware Cloud Builder.

Friendly warning: This is a long post so maybe get a coffee before reading!

SSL certificates are sometimes seen as a bit of a dark art! Every product seemingly having slightly different requirements, whether its format is PEM, p12, cer, crt…what’s a CSR or a certificate template?

So before I get into generating certs for VMware Cloud Builder I will cover off some basics on some of the terminology you will encounter in the world of SSL certs!

(Disclaimer: Most of these definitions are from Google!)

• SSL:  (Secure Sockets Layer) is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral.
• TLS: Transport Layer Security and its predecessor, Secure Sockets Layer (SSL), both frequently referred to as “SSL”, are cryptographic protocols that provide communications security over a computer network.
• CA: (Certificate Authority) is an entity that issues digital certificates. A digital certificate certifies the ownership of a public key by the named subject of the certificate. Microsoft Certificate Authorities are most common but some customers opt for non Microsoft CAs
• PKI: (Public Key Infrastructure) is a set of roles, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates and manage public-keyencryption.
• Leaf Cert: is what is more commonly known as end-entity certificate and is used in SSL & TLS encryption of HTTP traffic.
• Intermediate Cert: is a subordinate certificate issued by the trusted root specifically to issue end-entity server certificates. The result is a certificate chain that begins at the trusted root CA, through the intermediate and ending with the SSL certificate issued to you
• Root certificate: is part of a public key infrastructure scheme. The most common commercial variety is based on the ITU-T X.509 standard, which normally includes a digital signature from a certificate authority. Digital certificates are verified using a chain of trust.
• Root Chain: All certificates in the signing chain
• Common Name: The Common Name (also CN) identifies the host name associated with the certificate, for example http://www.example.com or example.com
• SAN: (Subject Alternative Names) Additional hostnames that are protected by the SSL certificate. Used when clustering behind a load balancer (vRA, vROPs, vRLI use SANs)
• CSR: A CSR or Certificate Signing request is a block of encoded text that is given to a Certificate Authority when applying for an SSL Certificate. It is usually generated on the server where the certificate will be installed (although this is not always possible when requesting certs before the target server is deployed) and contains information that will be included in the certificate such as the organization name, common name (domain name), locality, and country. It also contains the public key that will be included in the certificate. A private key is usually created at the same time that you create the CSR, making a key pair. A CSR is generally encoded using ASN.1 according to the PKCS #10 specification.
• Private Key: The private key is a text file used initially to generate a Certificate Signing Request (CSR), and later to secure and verify connections using the certificate created per that request. The private key is used to create a digital signature As you might imagine from the name, the private key should be closely guarded, since anyone with access to it use it in nefarious ways. Note again that the private key is really just a text file – however, it’s a really important text file and should be protected accordingly.

Hopefully the above list helps you understand the various terms associated with SSL certs. If not please leave a comment and I will add more detail.

Certificate Requirements for VMware Validated Designs

Here is a quick rundown per product on the certificate requirements. I am a firm believer in automation, but i also believe you should understand what the automation is doing for you.

vCenter Server

• Specific Certificate Template Requirements
  • Certificate template created per VMware KB 2112009
• machineSSL
  • Common Name: vCenter FQDN
  • Required Format: .crt
  • Contains the leaf cert & root chain

Platform Services Controller

• Specific Certificate Template Requirements
  • Certificate template created per VMware KB 2112009
• machineSSL
  • Common Name: Platform Services Controller Load Balancer FQDN
  • Contains SAN attributes for bothPlatform Services Controller appliance FQDNs
  • Required Format: .crt
  • Contains the leaf cert & root chain

NSX Manager

• Specific Certificate Template Requirements
  • None
• Common Name: NSX Manager FQDN
• Required Format: .pfx (Personal Information Exchange) format encrypted with a passphrase
• Contains the private key, leaf cert & root chain

vRealize Automation

• Specific Certificate Template Requirements
  • None
• vRA Appliance
  • Common Name: vRA Appliance VIP FQDN
  • Contains the following SAN attributes:
    • All vRA appliance FQDNs
    • vRA Appliance VIP
    • vRA Web VIP FQDN & both vRA Web Server FQDNs
    • vRA Manager VIP FQDN & both vRA Manager Server FQDNs
    • Required Format: .pem
  • Contains the leaf cert & root chain

vRealize Orchestrator

• • VMware Validated Designs leverages embedded vRealize Orchestrator on the vRealize Automation Appliances so there are no vRO specific certs.

vRealize Operations Manager

• Specific Certificate Template Requirements
  • None
• vRealize Operations Manager Appliance
  • Common Name: vRealize Operations Manager Master VIP FQDN
  • Contains the following SAN attributes:
    • All vRealize Operations Manager  node FQDNs
    • vRealize Operations Manager VIP
  • Required Format: .pem
  • Contains the leaf cert, the root chain & the Key

vRealize Business For Cloud

• Specific Certificate Template Requirements
  • None
• vRealize business for Cloud Appliance
  • Common Name: vRealize business for Cloud FQDN
  • Required Format: .pem
  • Contains the leaf cert, the root chain

vRealize Log Insight

• Specific Certificate Template Requirements
  • None
• vRLI Appliance
  • Common Name: vRLI Master FQDN
  • Contains the following SAN attributes:
    • All vRealize Log Insight node FQDNs
    • vRealize Log Insight VIP
  • Required Format: .pem
  • Contains the private key, the leaf cert, & the root chain

VMware SRM

Previous versions of VMware SRM had a requirement that the common name for each SRM server be the same. But unlike a clustered application where both nodes are specified as SANs, each server cert only requires its FQDN as a SAN attribute. Doing this is still supported but is no longer a requirement.

• Specific Certificate Template Requirements
  • extendedKeyUsage = serverAuth
  • or
  • enhancedKeyUsage = serverAuth
• Use SHA256 or stronger signature algorithms
• The minimum length of the private key is 2048 bits
• The Site Recovery Manager certificate password must not exceed 31 characters.
• Each SRM server cert contains SAN attribute for its own FQDN
• Required Format: .p12 encrypted with a password
• Contains the private key, the leaf cert, & the root chain

So…deep breaths and hopefully you’re still with me!

In an effort to make everyones life easier VMware created a set of scripts to assist in generating SSL certs for each product without you, the end user, needing to keep track of all of the above and we are constantly striving to improve the certificate experience! VMware Validated Design uses a script bundle called CertGenVVD-version.zip. It can be obtained from this VMware KB

Once you have downloaded the zip, extract it to a folder on a windows machine that is part of the same AD domain as the Certificate Authority (I will concentrate this post on Windows based CA as that is most common.) For simplicity in my lab, I am running it on my domain controller, which is also my CA. Before you start please ensure you have reviewed the certificate prerequisites outlined in part 2!

Generating the Input CSV

If you have followed part 3 of this series you will now have a fully populated Deployment Parameters file…if you havent then you can use the template csv files that are included in the zip bundle but if you have a completed deployment parameters file you can just copy the contents of the last tab out to a new file and save it as Region-A.csv (or any other name of your choosing).

Generating the Certificate Signing Request (CSR) config files

Before you can request certificates from your Certificate Authority (CA), you must first create the config files that contain all the required information about the server you are requesting a cert for. To do this you need to run a script from the bundle called CertConfig-version.ps1

Open a PowerShell session and navigate to the directory where you extracted the CertGen bundle.

Run the following

• ./CertConfig-version.ps1 [path to csv]

This will generate the required config files in the ConfigFiles folder in your working directory.

For the next part you have multiple options:

TIP: to display the help function run ./CertGenVVD-version.ps1 -h

• Option 1: Generate CSRs for use with an offline CA
  • This option is useful when you are dealing with a CA that is not accessible or when you or your customers do not allow scripts to run against your CA.

To do this run the following:

./CertGenVVD-version.ps1 -CSR

This will generate the required CSRs that you can then take and submit to your CA to generate the required certificates. Once you have generated all of your certs, place them in the relevant directories and come back and run the following to generate the required per product cert formats.

./CertGenVVD-version.ps1 -CSR -extra

• Option 2: Generate CSRs & request certificates from your CA
  • This option will do all the heavy lifting for you and generate all the certs you need in one operation.

To do this run the following:

./CertGenVVD-version.ps1 -MSCASigned

This will begin the process of generating all certs. You must supply and confirm a passphrase to be used for encrypting P12 certificates.

Important Note: Take note of this PassPhrase as you will need to enter this into the VMware Cloudbuilder Deployment Parameters file on the Deploy Parameters tab. See this post for more information.

Once you supply the PassPhrase the script will download the Root certificates and generate all required certificates. The end of the output gives you a list of all certificates generated

So if you’re still with me you should now have all the certificates, in the required formats, for all components in your VMware Validated Design build.

In the next post i will be moving onto deploying VMware Cloud Builder and validating your environment.