SSL on Virtual Center and single Hosts

[astrolab]

I regenerated the SSL Certs for an instance of VirtualCenter using MS Enterprise CA. Now all clients from where VC client is launched trrust VC, everybody's happy. The question for the forum is: if I regenerate the certificate on every single ESX host, using the same Microsoft CA, the host is not happy, gets disconnected and when trying to reconnect I receive the error: bad username or password. Has anybody implemented a comprehensive certificate strategy where both VC and the single hosts use certificates issued by the same CA?

I tried to put together a step-by-step process on regenerating the VirtualCenter certificate. It applies to an environment with a Microsoft CA, but it can be adapted to any root CA. Please let me know of any errors.

1. Install openSSL on the VC Server.

2. Generate an RSA private key and a certificate-signing request

BACK UP THE EXISTING RUI.CRT, RUI.KEY and RUI.PFX TO A SECURE LOCATION.

They are located in c:\docs and settings\all users\app data\vmware VMware VirtualCenter\SSL

From the VC Server, navigate at the command prompt to the openSSL\bin directory

Issue the following commands:

openssl genrsa 1024 > rui.key

openssl req -new -key rui.key > rui.csr

Fill in the appropriate information.

3. Request a Certificate

Go to your CA webpage.

Click on Request a Certificate

Open the file that you saved above with notepad and copy all of the the contents including the "---BEGIN CERTIFICATE REQUEST-" and "-END CERTIFICATE REQUEST---" lines

Click on Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

Be sure that the Certificate Template is set to Web Server. There is no need to enter anything into the Additional Attributes field.

You will receive an email with certificate information in it that you can delete.

Paste the notepad contents of the certificate request file from above into the Saved Request field and click on the Submit button.

Select Base 64 Encoded and click Download Certificate and save the certificate to C:\...\openSSL\bin

4. Create a .pfx (personal individual exchange) file for rui.crt

At the Command Prompt on the VC server navigate to C:\...\openSSL\bin and issue:

openssl pkcs12 -export -in rui.crt -inkey rui.key -name VirtualCenterServerFQDN -out rui.pfx

5. Move rui.key, rui.crt and rui.pfx to

c:\docs and settings\all users\app data\vmware VMware VirtualCenter\SSL

6. Power off all VMs on the hosts in the VC. This needs to be done because after the VC loads the new certs it

will not be possible to gracefully shutdown the VMs from the VC Client, though it can still be done through RDP or Service Console.

8. Restart the VC server. From CMD, navigate to

C:\Program files\VMware\ Infrastructure\ VirtualCenter Server and issue:

Vpxd -p (it re-encrypts the DB password). When prompted. type the pw used for the VC database.

9. Restart all ESX hosts.

10. Reconnect all ESX hosts, and power on the VMs.

11. IMPORTANT: connect to the VC Infrastructure by using the Virtual Center FQDN.

[astrolab]

I guess not many people have attempted this yet...

[CamSchwartz]

Astro,

I'm attempting to do the same with my lab environment, by replacing all the ESX and the VirtualCenter default certificates with my own created from our Microsoft Cert. Services CA. (I used the process outlined in the VMware Technical Note "VMware Infrastructure 3 - Replacing VirtualCenter Server Certificates" but it is basically the same thing here except for some of the syntax). Note that I am running VC 2.5.0u1 Build 84767 and ESX 3.5.0u1 Build 82663.

I am like you and was lucky with VC and did not have a problem. I was able to generate the CSRs using openssl then create the new certs from the MS CA web interface (https://<cert_server>/certsrv) and everything worked great. Granted I had previously ignored certificate errors from the FQDN for the VC server which I installed the new cert on, but if I bring up that VC host's webpage over SSL/HTTPS, it does reflect the new cert. (Side question: can you reset the list of "ignored" hosts in the VC client? Would this happen on uninstall/reinstall?)

My problem was with replacing the certs for the ESX hosts; I used the exact same method (with exception of .pfx generation) for generating keys & CSRs, cut/pasted the requests into the browser, moved the cert to the /etc/vmware/ssl directory, checked the perms ('644' for rui.crt, '600' for rui.key) and rebooted. When the host came back up, it showed as unreachable in the client. I then disconnected the host in VC, and tried to reconnect. But instead of getting your error, I kept getting the error "Failed to install the VirtualCenter Agent service." Looking at other threads, I tried all sorts of things to get the thing to connect such as restarting the "mgmt-vmware" and "vmware-vpxa" services, manually removing/installing the vpxa package, half a dozen reboots including the VC host, etc. I finally checked the /etc/vmware/vpx/vpxa.log file and at the bottom I find the error:

http://.. 'App' ... error Failed: unrecognized file format: /etc/vmware/ssl/rui.crt

I then switched the cert and key files back the originals, restarted the services again, tried to connect again in VC and it worked first time. Just to make sure nothing happened during the copy process, I thought I should double-check the validity of the files. I used openssl ("openssl verify -CAfile MyCA.crt rui.key") to verify the key and it came back "OK."

So, it leaves me with a couple of glaring questions:

1. If I used the exact same process for VC as I am for the ESX hosts, why aren't they working?

2. If openssl can verify the certificate, what is the problem?

3. What am I doing wrong?

Hopefully we can get some more attention to this thread.

[bergeral]

I have the same behavior as CamSchwartz. In addition I get this error 'sec_error_unknown_issue' opening http://fqdn in firefox3. For ie the certificate is ok.

Did everybody have an idea?

[handers101]

FYI

I managed to replace the certs on my VC and the hosts, then everything was running ok untill i needed to deploy from a template and the encryption configuration file for the sysprep stage did not work and i had to undo all my work.

[bergeral]

The reason for this is a different format. Just fix the format with openssl.

mv rui.crt error_rui.crt

openssl x509 -text -in error_rui.crt > rui.crt

service mgmt-vmware restart

[scerazy]

This works: http://communities.vmware.com/thread/153794?tstart=0

Seb

[CamSchwartz]

bergeral: You are AWESOME! This worked perfect and now everything is connecting happily. Thanks for your help.

Can you explain why this is needed though? I understand that it was in the wrong format; I guess my question is what format were they originally in and what was required?

[admin]

Side question: can you reset the list of "ignored" hosts in the VC client? Would this happen on uninstall/reinstall.

These sites are stored in the registry: HKEY_CURRENT_USER\Software\VMware\Virtual Infrastructure Client\Preferences\UI\SSLIgnore

The easiest way to find them is to open regedit and search for "SSLIgnore".

Delete the registry entries to undo the "ignore".

[Joelius]

Hi When i run the command to create the rui.csr file (openssl req -new -key rui.key > rui.csr) i get the following error

" Unable to Load config info

Unable to find 'distinguished_name' in config problems making Certificate Request

4384"error"0E06D06A:configuration file routines:NCONF_get_string:no conf or environment variable:conf_lib.c:325: "

Can you please advice

[admin]

> Hi When i run the command to create the rui.csr file (openssl req -new -key rui.key > rui.csr) i get the following error

> " Unable to Load config info

> Unable to find 'distinguished_name' in config problems making Certificate Request

It sounds like you haven't set up the openssl.cnf config file correctly.

You could try passing the DN in the command line, using "-subj" something like this:

$ openssl req -new -nodes -md5 -key rui.key -subj '/C=US/ST=NY/L=Somewhere/organizationName=MyOrg/OU=MyDept/CN=fqdn.of.my.host' -days 3600 -out rui.csr

[dstambaugh]

I had the same error after I replaced my SSL cert with a new cert from our internal MS CA. I resolved it with this KB article, and you may find more info in this thread too.