I don’t like doing things manually. My previous post showing how to replace vRealize Suite Lifecycle Manager certificates using the GUI is straight forward, but it’s far too manual. I’m going to show you how to replace the certificate using the vRSLCM 8.1 API(which you can wrap in a script). You can use any tool to interface with the API. I stick to Postman, curl, or if the application provides it, a Swagger UI.
This post covers the process of replacing a self-signed SSL certificate running on a vRealize Suite Lifecycle Manager (vRSLCM) 8.1 appliance. I’ll be using the UI to show you how to do it. Pre-requisites Make sure you have a defined a certificate template as per https://kb.vmware.com/s/article/2112009 Confirm your user account has the correct privileges to request certificates using Microsoft CA Web Server enrollment. At the least, find someone that can submit and approve it for you.
Note: This post addresses and (hopefully) fixes the cause of the issue found here: vVols Endpoint - Failed to establish connection on ESXi host Recently, one of my customers was trying to refresh the CA store on newly built ESXi 6.7 U3 hosts under a freshly upgraded vCenter Server 6.7 U3 instance. When the admin tried refresh the CA store, they were getting this error message in the vSphere Client:
My customer has successfully rolled out VMware vSphere Virtual Volumes (or “vVols”) in their environment. They’re loving the simplicity of storage management in vSphere, but were a little stuck when they added a pair of newly installed ESXi hosts to their environment. The hosts were not mounting the vVols datastore as expected meaning hosts could not run VMs backed by vVols. All existing hosts were OK. To start, they dug in to the logs at /var/log/vvold.
I had a customer upgrade their vCloud Director environment from v8.20 to v9.5. The upgrade itself went fine, however some tenants were now unable to login. Interestingly, the affected tenants were authenticating against their own LDAP server over LDAPS. All other tenants were authenticating against the Service Provider managed LDAP server. For this particular service provider customer and their tenant, the LDAP server was specified using an IP address instead of a FQDN.
Hello again! Today’s adventures drove me a little wild… Some background first. In my test environment, I have a full vCloud Director v8.10.1 deployment, load balanced with an F5 LTM. The certificates are loaded on the F5 so that traffic is terminated and re-encrypted on it’s way to the vCloud cells. Since deployment, both the http and console FQDNs functioned as expected. This all changed just a few months ago…
After a very successful and quick migration from Windows SSO 5.5 U3e installation to a Platform Services Controller v6.0U3 appliance I was ready to get my VMCA into action. We have a corporate internal Microsoft CA with the VMware certificate templates already created as per VMware KB 2112009. Everything was coming up Milhouse, until CSR generation time using the ‘certificate-manager’ on the PSCs. After stepping through the ‘certificate-manager’ wizard and having the CSR and private key files sent to a directory of my choosing, I quickly inspected the CSR using openssl to make sure I was on the right track:
I was just in the middle of configuring a PSC 6.0 node’s VMCA as an intermediate CA and, in traditional fashion, went to request a certificate from a Windows Server 2008 R2 Microsoft CA using the web enrollment form (as per this VMware KB article). Oddly enough though my brand spanking new vSphere 6.0 machine and intermediate CA certificate templates were missing from the template selection drop down. I had a look around online and found that MS CA v3 certificate templates are not supported in the web enrollment form.