Replace vSphere 7 with Tanzu CertificatesAugust 31, 2020
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.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
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
Fill out the information relating to your own organization and then click
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
DNS.1 = sup.hollow.local
IP.1 = 10.10.201.65
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
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.
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?