In this blog post we describe a process to replace a VMware vCenter Server Appliance’s (VCSA’s) self-signed certificate with Certificate Authority-signed (CA-signed) certificate.
VMware has already described such a process in Knowledge Base Article 2057223; however, the process they describe is cumbersome: it requires SSL certificates for four services that the VCSA provides.
- vCenter Server / vCenter Single Sign-On (SSO)
- vCenter Inventory Service
- VMware Log Browser
- vSphere AutoDeploy
We are not interested in replacing the SSL certs for all four services—we are only interested in the replacing the certificate that our web browser encounters we browse to the vCenter (i.e. the vCenter Server / vCenter Single Sign-On (SSO) certificate).
Also, we do not have four CA-signed certificates to install; we have but one wildcard certificate (*.cf.nono.com) available.
This Voids the Warranty!
Following this procedure will result in an unsupported configuration! Wildcard certificates are not supported according to the Knowledge Base article:
“The use of wildcard certificates are not supported with vCenter Server and its related services. Each service must have its own unique certificate”
We feel comfortable in replacing one of the certs with a wildcard certificate in spite of VMware’s prohibition, for we are still maintaining four different certificates for the different services (though one of the services will be using a wildcard certificate).
In Cloud Foundry Engineering the Chrome Web Browser is the most popular browser among the developers, but it is not without shortcomings, especially with regard to self-signed certs.
Google’s Chrome web browser under OS X has difficulty permanently storing exceptions for websites which have self-signed certificates (a complicated work-around would be to visit the site in Safari and store the exception in the System’s keychain). Every time Chrome is restarted and the site with the self-signed cert is visited, the user encounters a warning screen. To make matters worse, a recent Chrome update requires the user to click not once but twice to get past the warning screen.
Chrome’s warning screen when encountering a self-signed certificate. This is particularly irritating under the OS X environment, for Chrome does not have a built-in mechanism to store certificate exceptions
A fix would be to use CA-issued certificates for frequently visited internal servers. It’s trivial to install certificates on most servers, but the vCenter Server Appliance is a more complex install.
In this example we replace our vcenter server’s (vcenter.cf.nono.com) self-signed certificates with CA-signed certificates:
- vCenter’s FQDN (fully-qualified domain name): vcenter.cf.nono.com
- wildcard SSL key: *.cf.nono.com.key
- wildcard SSL certificate: *.cf.nono.com.pem (note that this .pem file includes three certificates: the wildcard cert, the intermediate CA cert, and the root cert).
- we snapshot our vCenter. Really. We have destroyed a vCenter in the past when trying to modify the SSL certificates.
- copy the key, cert, and .pem to our vCenter, and set up our variables:
# set our shell variables (substitute as appropriate)
# copy the key, .pem, and certificate to the vCenter
scp $SSL_KEY $SSL_PEM $SSL_CRT root@$VCENTER_FQDN:
# log into the vCenter
# set our shell variables again
- install SSO and vCenter Server certificate
# stop SSO and the vCenter Server
service vmware-stsd stop
service vmware-vpxd stop
# install the .pem and key
/usr/sbin/vpxd_servicecfg certificate change ~/$SSL_PEM ~/$SSL_KEY
# wait for "VC_CFG_RESULT = 0"
# start up SSO vCenter
service vmware-stsd start
service vmware-vpxd start
Chrome recognizes the CA-signed certificate
- when we click on the “Log in to vSphere Web Client” link we see that we still have self-signed cert.
- reboot the VCSA to fix the vSphere Web Client:
shutdown -r now
- after rebooting, we now see the the vSphere Web Client also has a CA-signed cert:
After rebooting we can see that the vSphere Web Client has a valid CA-signed certificate
Make sure the key, .pem, and certificate files end in a newline (‘\n’, 0x0a, Ctrl-J). When using Github’s gists, for example, it is easy to accidentally omit a newline at the end of the gist.