Certain third party products such as XenDesktop respect the expiration date on the vCenter SSL certificate. The vSphere Client doesn’t mind so much, nor it appears does the ESX hosts, but when your VDIs suddenly can’t be reached, it’s a bad thing.
By default, vCenter will create a self-signed certificate with just the host name. In our case, since we’re not publishing any SSL services to the public and already have a Microsoft Certificate Authority, we can create and sign our own vCenter certificate. And just like the newer version of vCenter, we’ll set it up for 10 years too.
This can be completed in just under 15 minutes if all the prerequisites are in place. Took me an hour (including this documentation).
Environment Summary
For this process to work, the following assumptions are made:
- Active Directory installed and Certificate Authority installed (in my case, it’s on a Windows 2008 Domain Controller with Certificate Authority and Certificate Authority Web Enrollment )
- DNS used for vCenter and internal FQDN name
- vCenter server part of the domain, Domain Admin access to it
- Using the included web services that comes with vCenter (IIS users on your own for this one)
To test, we’ll use a browser from a workstation and the XenDesktop DDC to validate connection (make sure the root CA certificate is added to the Trusted Roots for the Computer Account on each test and production server)
Prep vCenter
Download OpenSSL for Windows (binaries can be found at: http://www.slproweb.com/products/Win32OpenSSL.html) . You may have to install the 2008 redistributable package first.
Open a command shell and go to c:\temp\vcenter\newssl (create if needed)
Verify the private key exists in: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\rui.key
Copy all the files in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL to a temporary location such as c:\temp\vcenter\oldssl (create if needed)
Generate the new RSA private key (2048 bit) and the certificate request (most important is that the common name must be the FQDN of the server). For the CSR, I normally use the common name value.csr, but since we’re working with rui.*, we’ll use that here too:
C:\temp\vcenter\newssl>c:\OpenSSL\bin\openssl.exe req -newkey rsa:2048 -keyout rui.key -nodes -days 3650 -out rui.csr Loading 'screen' into random state - done Generating a 2048 bit RSA private key .............................+++ ......................................+++ writing new private key to 'rui.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:Georgia Locality Name (eg, city) []:Cumming Organization Name (eg, company) [Internet Widgits Pty Ltd]:Gavin Adams Organizational Unit Name (eg, section) []: Common Name (eg, YOUR name) []:vcenter.peanuts.local Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: C:\temp\vcenter\newssl>dir Volume in drive C has no label. Volume Serial Number is 204A-99B1 Directory of C:\temp\vcenter\newssl 04/16/2010 03:50 PM <DIR> . 04/16/2010 03:50 PM <DIR> .. 04/16/2010 03:50 PM 1,024 .rnd 04/16/2010 03:49 PM 1,675 privkey.pem 04/16/2010 03:50 PM 1,679 rui.key 04/16/2010 03:50 PM 1,005 rui.csr
From the vCenter system, browse to the certsrv URL for your Active Directory Certificate Authority:
Select Request a certificate, advanced certificate request, and then Submit a certificate using base-64…. Past the entire contents of the CSR (open in Notepad) in the Saved Request box, select Web Server for Certificate template:
At this point the certificate will be signed. On the next page select Base 64 encoded then Download certificate and save as rui.crt in c:\temp\vcenter\newssl
From the private key and certificate, create the PFX fie:
C:\temp\vcenter\newssl>c:\openssl\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx
Stop the following services:
VMware VirtualCenter Management Webservices
VMware VirtualCenter Server
Copy all the files in the newssl directory to : C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\ replacing the existing ones. Don’t worry, we backed these up.
Now restart the services in this order (unsure if it matters):
VMware VirtualCenter Server
VMware VirtualCenter Management Webservices
Use browser and navigate to the URL of the vCenter (e.g., https://vcenter.peanuts.local) and verify the certificate is valid. Open the vSphere client and verify all looks okay. After restarting the services, you will need to reconnect to the ESX / ESXi hosts and re-authenticate with root credentials on each server. This is because the SSL trust between the two has changed and a new trust relationship needs to be established. Another reason for a longer term certificate!


Good article puts me in the right direction.
One thing after this the webservice won’t start.
in the log I found following error:
vmware RSA_padding_check_PKCS1_type_2:block type is not 02
For me following kb from Vmware solved the problem:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003070
When you run this enter the password you use to access the DB, So probably the SQL account used for Vsphere
BTW:
This all in combination using Vsphere 4 update 1
VMware says to do the following before bringing the two services back online:
cd vpxd -p
The password is randomly generated.
When prompted for your new password, enter your existing database password.
That gets around the same issue Wikkie mentioned.
Thanks for the great documentation!!
That’s just:
“vpxd -p” from your Virtual Center directory