I'm having trouble making vCenter Server 4.0 use my new SSL certificates for vSphere Client connections. I followed the directions in the vSphere vServer Certificates PDF guide and put the new rui.crt, rui.key and rui.pfx files into this folder:
C:\Users\All Users\Application Data\vmware\VMware VirtualCenter\SSL (Windows Server 2008)
If I connect to the vCenter Server console via the FQDN with IE, it DOES use my newly issued SSL Certificate, not the self-signed one that is generated during the installation process. However, if on the vCenter server I launch the vSphere Client and attempt to logon, I get a certificate warning. If I view the certificate, it's the self-signed one created during the install process.
So part of vCenter Server is using my new SSL certificate, but not the connectivity to the vSPhere client. I didn't see any special instructions in the PDF guide to make vSPhere client work.
This is a fresh install of vCenter Server 4.0 on Server 2008 x64, not an upgrade. I've rebooted the vCenter server multiple times to ensure the old certificates were flushed from memory.
Thoughts?
A couple things here... Do you have the update manager plugin loaded in your vSphere client? It uses a different set of certificates. Two, after you replace your virtual center 4 certificates you need to run "vpxd -p" to reencrypt database con string password and also restart the virtual center and web service services. Also, you are most likely going to run into a bug. If the health service in vc 4 stops working (red x's, missing services) you need to edit the vc ADAM instance using LDP.exe and manually replace the tomcat ssl thumbprints for the health service. I would provide instructions but I am using an iPhone to type this and I don't have the notes. I had an open vmware SR for this issue (bug to be fixed in vc 4 update 1).
Josh,
Would you mind sharing the detailed instructions you received to fix the health status errors?
We ran into the same bug, after installing our own certificates on the vCenter 4 server.
Thanks and kind regards,
Harold
Here is the workaround until bug fix in U1.
<----
Health service tried to login to vws by certification; however, server certificate validation fails. The validation failed because the thumbprint value of "vmw-vc-SSLThumbprint" attribute under CN=<GUID>.visvc,CN=<GUID>,OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware,DC=int and under Dn: CN=<GUID>.vpxd,CN=<GUID>,OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware,DC=int do not match the thumbprint of the replaced SSL certificate.
Health service uses this value to build httpclient object for server certificate verification.
The thumbprint was mismatched because during vws startup, vws did not update these values. It detected that components specs already exist so it ignored and skip the update. You'll see these message in vws when it skips the update because component specs already exist.
2009-08-21 16:27:56,697 Thread-21 DEBUG 'com.vmware.vim.health.impl.HealthSpecPollerImpl'] Name already bound, ignoring error since component spec data must already be setup in ldap
Fix:
===
The bug is in Health service code. It needs to update component specs on start up.
The bug has been fixed in vc 4.0 u1.
Workaround:
====
We need to manually update value of vmw-vc-SSLThumbprint attribute under .visvc and .vpxd health component specs to match rui.crt's thumbprint in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL and the vmw-vc-SSLThumbprint attribute's under Dn: CN=VIMAPI,CN=<GUID>,OU=Instances,DC=virtualcenter,DC=vmware,DC=int.
Basically, value of vmw-vc-SSLThumbprint attribute need to be the same on the following places:
1) CN=VIMAPI,CN=<GUID>,OU=Instances,DC=virtualcenter,DC=vmware,DC=int
2) CN=VIMWEBSVC,CN=<GUID>,OU=Instances,DC=virtualcenter,DC=vmware,DC=int
3) CN=<GUID>.visvc,CN=<GUID>,OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware,DC=int
4) CN=<GUID>.vpxd,CN=<GUID>,OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware,DC=int
We need to use ldp.exe to update the value. ADSI Edit does not work here. Somehow it does not show the attribute under health component specs.
The customer can download ldp.exe from microsoft website
A) To connect to ldap server running on VC.
1. After you install the tool, open ldp.exe.
2. Go to "Connection" -> Connect. Enter hostname of vc server you want to connect to.
3. Go to "Connection" -> Bind. Enter authentication information. You can use admin account.
4. Now you already connected and binded to the ADAM server.
5. To see all contexts of the ADAM server, go to View->Tree View. Don't fill anyting in Base DN. Click OK.
B) To check vmw-vc-SSLThumbprint attribute values to see if it matches the VC's SSL certificate
1. Double click on DC=virtualcenter,DC=vmware,DC=int
Browse to
- CN=VIMAPI,CN=<GUID>,OU=Instances,DC=virtualcenter,DC=vmware,DC=int
- CN=VIMWEBSVC,CN=<GUID>,OU=Instances,DC=virtualcenter,DC=vmware,DC=int
- CN=<GUID>.visvc,CN=<GUID>,OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware,DC=int
- CN=<GUID>.vpxd,CN=<GUID>,OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware,DC=int
When you double click on each node, on right pane, you will see a list of attribute under this object. Look at vmw-vc-SSLThumbprint. Check their values.
I expect that only .visvc and .vpxd's do not match and vimapi and vimwebsvc are matching rui.crt's thumbprint in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL
C) To update the vmw-vc-SSLThumbprint of health component specs.
1) Go to Browse->Modify
2) Fill required values:
2.1)
Dn: CN=<GUID>.visvc,CN=<GUID>,OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware,DC=int
Note: Replace GUID with the one show in the part B query.
Attribute: vmw-vc-SSLThumbprint
Values: <thumb print value you copy from VIMAPI you get this value from part b>
Operation: Replace
3) Click Enter
4) Click Run - You can check whether or not the update commit successfully by looking at the right pane and click on the node itself.
5) Repeat #2 to #4 for .vpxd but replace CN value to point to .vpxd
-
>
Ok I dug a bit deeper today. Yes the error only happened after I installed VUM. The certificate is working just fine for vCenter, but not VUM. I didn't realize VUM has its own SSL certificates.
When I replaced the VUM certificates (rui.crt, rui.key, rui.pfx) in D:\Program Files (x86)\VMware\Infrastructure\Update Manager\SSL with the working ones in my vCenter SSL directory, I get an error when I launch VIC and connect to vCenter:
There was an error connecting to Vmware vCenter Update Manager - vctr.contoso.net:8084 vim.fault.invalidlogon
In the vpxd-35.log I see:
SSLStreamImpl::DoServerHandshake (75E6D08) SSL_accept failed. Dumping SSL error queue:
error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
Vmacore::Http::HttpSvcImpl::AcceptHttpConn accept failure - no read scheduled: ,SSL Exception: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknownclass Vmacore::Exception *
Vmacore::Http::HttpSvcImpl::AcceptHttpConn stream is NULL - no read scheduled
SSLStreamImpl::DoServerHandshake (75E6D08) SSL_accept failed. Dumping SSL error queue:
error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
Is updating the VUM certificates not as simple as replacing the three certificate files from my vCenter SSL directory? I was not able to find any guide for configuring VUM's SSL certificates.
Thanks for the workaround.
I will test this hopefully tomorrow and update you later.
Regards,
Harold
Not to dissapoint here... The information I have provided thus far on this thread is to get certificates replaced for vCenter only and not for VUM. I have a long standing SR open with VMware on the process to replace the VUM certificates and they have not been able to solve (or provide details) my issue. I have heard that it may be possible to perform a "repair" from add/remove programs of VUM after you place your certificates in the appropriate VUM certificates folder. Basically, the VUM repair will not replace your custom certs and instead will correct the VUM code to use the new thumbprints. I have not tried this myself so beware---I was told by VMware that the "repair" from add/remove is the only process that works (and I quickly told them I would NOT perform a repair on a working production envioronment).
Bummer about VUM! I tried to do a repair and didn't see such an option on Server 2008 for VUM.
I have tried your workaround to solve the vCenter Services health status, and it did the job!
That problem is solved.
And now we are facing the second issue...VUM SSL....
The story continues...
Thanks again for the workaround.
Regards,
Harold
Confirmed fixed in Update 1. Both in the release notes, and I used LDP to verify thumbprints and they match without any manual work.
I posted the full procedure at:
http://derek858.blogspot.com/2009/11/vcenter-server-40-ssl-certificate.html
I've also developed procedures to update the VUM SSL certificate with vCenter 4.0 Update 1. You can find the details at my blog:
http://derek858.blogspot.com/2009/11/vcenter-update-manager-40-ssl.html
Update: VMware support confirmed the workaround described in my blog is the official workaround until update 2 comes out.
Thanks to VMware and feedback on my previous blog post, there's now a more elegant and officially supported method to update your VUM SSL certificate. You can check it out here:
http://derek858.blogspot.com/2010/12/vcenter-4041-vum-ssl-certificate-how-to.html