Generating vCenter Solution User Certificates With Custom Names
Many enterprises require replacing all vCenter certificates with Enterprise CA trusted certificates.
vSphere 6.5 has made the certificate updating process so much easier than the complication of the vSphere 5.x days.
Basic vCenter now has a single Machine SSL certificate as well as four Solution user certificates: machine (different from machine SSL), vpxd, vpxd-extension, vsphere-webclient.
Although the Solution user certificates are only used for internal vCenter communication, many enterprise security standards require using enterprise CA issues certificates for everything.
BTW, when you migrate from a Windows vCenter 5.5 to VCSA 6.5 using the excellent migration tool, only the Machine SSL certificate is taken across, the Solution user certificates remain self-signed and may need to be manually updated.
Each Solution user certificate needs to have a unique name.
Also remember, the SubjectAltName must contain DNS Name=machine_FQDN
I used the great guide from Ian Sanderson for updating the certs as a base https://www.snurf.co.uk/vmware/replace-ssl-certificates-on-vmware-psc-v6-5/
You can use the VMware supplied vSphere Certificate Manager in the VCSA (sidebar, you should really be using the VCSA rather than Windows by now!) to generate the solutions user certificate.
/usr/lib/vmware-vmca/bin/certificate-manager
When you select Option 5 and then Option 1 to generate the certificate private keys and certificate signing requests to send off to your Enterprise CA, the tool has a particular format for the signing requests.
As the Solution user certificates for machine, vpxd, vpxd-extension, vsphere-webclient need to be unique, the tool decides to make the Subject field “Common Name” unique with values like:
machine-1d364500-4b45-11e4-96c2-020011c98db3
vpxd-1d364500-4b45-11e4-96c2-020011c98db3
vpxd-extension-1d364500-4b45-11e4-96c2-020011c98db3
vsphere-webclient-1d364500-4b45-11e4-96c2-020011c98db3
Which would result in a certificate subject like:
Subject
Common Name: machine-1d364500-4b45-11e4-96c2-020011c98db3
Organizational Unit: vCenterServer
Organization: WoodITWork.com
Locality: London
State: London
Country: GB
Subject Alternative Names: lonvcenter (dNSName)
lonvcenter.wooditwork.com (dNSName)
Enterprise CAs often need the Common Name to be the FQDN of the server or reject the request.
So, we basically need to use another field for the uniqueness, how about Organizational Unit which was common in the 5.5 days?
There’s likely a way to hack the vSphere Certificate Manager tool to do this but there’s an easier option.
You can use OpenSSL to create your own certificate signing requests. Previously you would have to create a separate OpenSSL configuration file to generate each certificate as not all the options were available directly on the command line and you would need to import the particular config file for each request.
OpenSSL now has a new version out recently, 1.1.1 which has a handy new command line option -addext which allows you to do more with the command line.
To directly generate the 4 x solutions user certificates using OpenSSL 1.1.1 with unique Organizational Unit values, just run.
openssl req -new -nodes -out machine.csr -keyout machine.key -subj “/C=GB/ST=London/L=London/O=WoodITWork.com/OU=vCenter-SolutionUser-machine/CN=lonvcenter.wooditwork.com” -addext “subjectAltName = DNS: lonvcenter, DNS: lonvcenter.wooditwork.com” -addext “keyUsage = digitalSignature, keyEncipherment, dataEncipherment” -addext “extendedKeyUsage = serverAuth, clientAuth”
openssl req -new -nodes -out vpxd.csr -keyout vpxd.key -subj “/C=GB/ST=London/L=London/O=WoodITWork.com/OU=vCenter-SolutionUser-vpxd/CN=lonvcenter.wooditwork.com” -addext “subjectAltName = DNS: lonvcenter, DNS: lonvcenter.wooditwork.com” -addext “keyUsage = digitalSignature, keyEncipherment, dataEncipherment” -addext “extendedKeyUsage = serverAuth, clientAuth”
openssl req -new -nodes -out vpxd-extension.csr -keyout vpxd-extension.key -subj “/C=GB/ST=London/L=London/O=WoodITWork.com/OU=vCenter-SolutionUser-vpxd-extension/CN=lonvcenter.wooditwork.com” -addext “subjectAltName = DNS: lonvcenter, DNS: lonvcenter.wooditwork.com” -addext “keyUsage = digitalSignature, keyEncipherment, dataEncipherment” -addext “extendedKeyUsage = serverAuth, clientAuth”
openssl req -new -nodes -out vsphere-webclient.csr -keyout vsphere-webclient.key -subj “/C=GB/ST=London/L=London/O=WoodITWork.com/OU=vCenter-SolutionUser-vsphere-webclient/CN=lonvcenter.wooditwork.com” -addext “subjectAltName = DNS: lonvcenter, DNS: lonvcenter.wooditwork.com” -addext “keyUsage = digitalSignature, keyEncipherment, dataEncipherment” -addext “extendedKeyUsage = serverAuth, clientAuth”
This will create 4 x private key files
- machine.key
- vpxd.key
- vpxd-extension.key
- vsphere-webclient.key
and 4 x certificate signing request files
- machine.csr
- vpxd.csr
- vpxd-extension.csr
- vsphere-webclient.csr
Which would result in a certificate subject like:
Subject
Common Name: lonvcenter.wooditwork.com
Organizational Unit: vCenter-SolutionUser-machine
Organization: WoodITWork.com
Locality: London
State: London
Country: GB
Subject Alternative Names: lonvcenter (dNSName)
lonvcenter.wooditwork.com (dNSName)
You can also use the easy to use CSR viewer from https://www.entrust.net/ssl-technical/csr-viewer.cfm to check the contents of the .CSR files are correct before sending on to your Enterprise CA.
Once the certs have been created, you can use WinSCP or something to copy up the 4 x .key files you created with OpenSSL and the certificates you would have received from your CA to for example’s Ian’s location /tmp and carry on with the cert replacement using the vSphere Certificate Manager with Option 5 and then Option 2.
Have fun!
Recent Comments