Home > vCenter, VMware > Generating vCenter Solution User Certificates With Custom Names

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

  1. machine.key
  2. vpxd.key
  3. vpxd-extension.key
  4. vsphere-webclient.key

and 4 x certificate signing request files

  1. machine.csr
  2. vpxd.csr
  3. vpxd-extension.csr
  4. 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!

Categories: vCenter, VMware Tags: , , ,
  1. No comments yet.
  1. No trackbacks yet.
 

Time limit is exhausted. Please reload the CAPTCHA.