Replace vSphere 7 with Tanzu Certificates

When setting up your vSphere 7 with Tanzu environment, its a good idea to update the default certificate shipped from VMware with your own certificate. This is a good security practice to ensure that your credentials are protected during logins, and nobody likes to see those pesky certificate warnings in their browsers anyway, am I right?

Create and Trust Certificate Authority

This section of the blog post is to create a root certificate. In many situations, you won’t need to do this since your organization probably already has a certificate authority that can be used to sign certificates as needed. Since I’m doing this in a lab, I’m going to create a root certificate and make sure my workstation trusts this cert first. After this, we can use the root certificate to sign our vSphere 7 certificates.

To create the CA certificate and Private key, download and install openssl and then run the command below, replacing the CN with your own Root Certificate Name.

openssl req -nodes -new -x509 -days 3650 -keyout ca.key -out ca.crt -subj "/CN=HollowLabRoot”

After running the command you should have a ca.crt and ca.key file created in your working directory.

After the root certificate has been created, you need to distribute this certificate to any machine that will access your vSphere 7 with Tanzu API endpoints. On my mac, I’ve open the CA.crt file which opened the Keychain Access program.

Double click the certificate to open the settings and change the When using this certificate setting to Always Trust.

When you finish, there should be a little blue checkmark next to the certificate demonstrating that it’s trusted. Now, any certificates signed by this root certificate, will be automatically trusted by this workstation.

Generate Certificate Signing Request

In the vCenter UI, navigate to the Supervisor Cluster that you’ve created and click the Configure tab and then the Certificates menu item. You should see a Workload platform MGT tile. Under Actions click Generate CSR.

Fill out the information relating to your own organization and then click Next.

On the last screen, click the DOWNLOAD button to download the certificate signing request.

I downloaded my CSR and named it v7wt.csr and placed it in my directory with my CA cert and key.

Lastly, it is probably a good idea to check the certificate signing request to make sure it looks ok. We can also check the Subject Alternate Name (SAN) properties on the cert at this time. You can view the csr by running:

openssl req -text -noout -verify -in v7wt.csr

Sign the Certificate Request

Create an openssl config file. I’ve named mine ext.cnf. An important part of this config file is to have the [alt_names] section updated so that it matches the SAN properties from the signing request. If you leave these off, you may strip off this SAN information during the signing and the cert will not be trusted by today’s browsers.

Replace the DNS.1 and IP.1 values to match your own CSR.

keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
basicConstraints = CA:FALSE
nsCertType = server
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
subjectAltName = @alt_names
[alt_names]
DNS.1       = sup.hollow.local
IP.1       = 10.10.201.65Code language: PHP (php)

Once your config file is created, you can use the CA certificate and CA key to sign the CSR.

openssl x509 -req -in v7wt.csr -CA ca.crt -CAkey ca.key -out v7wt.crt -CAcreateserial -days 365 -sha256 -extfile ext.cnf

After running the above command you should now have a v7wt.crt and you can inspect it to make sure it still includes your SAN properties.

openssl x509 -in v7wt.crt -text -noout

Replace the Certificate

You now have a valid certificate and are ready to replace the existing VMware certificate with your own. Go to the Supervisor cluster in vCenter again, and this time select Replace Certificate from the same location where you generated the CSR.

Copy the certificate, or upload from your workstation’s file system. Then click the Replace button.

When you’re done, you should see that the certificate was replaced.

To verify that everything is working the way you want it to navigate to the Kubernetes API Endpoint webpage for one of your namespaces. When opening the page, you should not get a warning about the untrusted certificate. Inspecting the certificate should show the correct chain and that it’s valid.

If you’d like to check your cli access now as well, try running a kubectl vsphere login command to see if you still need the --insecure-skip-tls-verify flag set. You shouldn’t need to use this anymore since your endpoint has a trusted certificate now.

Summary

In this post you created your own root certificate, generated a certificate signing request from vCenter, and then signed that certificate request with your root CA. Lastly you replaced the VMware certificate with your own and tested to validate you can access the Kubernetes API Endpoint without using the insecure-skip-tls-verify option. It feels good to get rid of those certificate warnings doesn’t it?