Saturday, November 21, 2009

vCenter Server 4.0 SSL Certificate Generation - Fixed

In the release notes of vCenter 4.0 Update 1 it mentions that the SSL thumbprint problem is solved. The bug in 4.0 caused various thumbprint entries buried deep in the ADAM LDAP database to not be updated when the certificates were replaced. That caused all kind of issues. Today I verified that vCenter 4.0 Update 1 solves the thumbprint problem.

Here's the procedure I used to generate and install the vCenter certificates. Note that this doesn't take care of the VUM SSL certificates. I'm still researching how to properly update those. Like my previous blog on updating ESXi SSL certificates, you need to install Open SSL. See this post, and follow the first three steps before proceeding.

  1. Execute: c:\openssl\bin\openssl req -new -nodes -out rui.csr
  2. At this point OpenSSL will prompt you for various parameters. Enter any information you wish, but make sure the Common Name is the FQDN of your vCenter server (.e.g. Q100VCTR01.contoso.net). Do not set a password.
  3. Use NotePad and copy the contents of rui.csr to the clipboard.
  4. Navigate to your Microsoft CA and select the option called something like "Submit a certificate request by using a base-64-encoded CMC...."
  5. On the Saved Request screen paste the contents of the clipboard, and change the certificate template to Web Server.
  6. Submit the request, then download the Base-64 encoded certificate (not the certificate chain). I saved the file as rui.cer into the c:\OpenSSL\Certs diretory.
  7. Rename privkey.pem rui.key
  8. Rename rui.cer (from step 6) to rui.crt
  9. Note in the following command you must use testpassword, not your own password. C:\openssl\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx
  10. In Explorer cut and paste the appropriate path into the address bar:

Server 2008/R2:

C:\Users\All Users\Application Data\vmware\VMware VirtualCenter\SSL

Server 2003/R2:

C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL

11. Highlight all files, right click, and Send to a Compressed Folder named backup keys.zip.

12. Stop the VMware Virtual Center Server service.

13. From the C:\Openssl\certs directory copy rui.key, rui.crt and rui.pfx to the SSL directory shown above and overwrite all existing files.

14. Restart the VMware VirtualCenter Server and Vmware VirtualCenter Management WebServices services. Verify they start.

15. Browse to the HTTPS FQDN of the vCenter Server and verify the new certificate is being used.

You should update the vCenter SSL certificate PRIOR to creating any customization specifications. If you update the certificate afterwards, you will need to re-do your customization specifications since they rely on encryption parameters that get changed when you update the SSL certificate.

22 comments:

  1. Hi Derek,

    I was wondering whether or not you did not have to run 'vpxd -p' to reset the database password to make this work.

    I'm currently working on an automated build of vCenter 4.0. update 1 and cannot get it to work without executing this step between 13 and 14.

    I look forward to hearing from you.


    Erwin Zoer

    ReplyDelete
  2. Erwin,

    During my testing I never had to execute that command. But I'm glad you mentioned that in case others run into the same problem.

    ReplyDelete
  3. Hi there,

    On step 8 when you need to rename that file, is that the file that i saved to the certs directory? When i run the next command it says it cant find this file. Any help would be great.
    Thanks

    ReplyDelete
  4. Anonymous,

    Yes step 6 you download the certificate from your CA and use a file name of rui.cer. Step 8 renames this same file to rui.crt.

    ReplyDelete
  5. Has anywhere here gotten vCenter 4.0 update 1 to successfully failover seamlessly using a Windows 2008 64-bit Failover 2-node cluster?
    Basically, I am seeing during a simulated or actual failover that vCenter 4.0 loses the connection to all the ESX hosts, and they must be manually reconnected (they show up with a red disconnected symbol).
    I am not sure if this is related to SSL certs or not.
    I am going to open a case and also post this to the Vmware forums.

    ReplyDelete
  6. Hi Derek,

    Just had another question. The vmware documentation on this is a little fuzzy, but it seems according to their docs that to update the vCenter certs requires that all VMs be shutdown? I beleive this just to be my confusion. Do you have to reconnect the hosts as well to update their passwords?

    ReplyDelete
  7. Mark,

    I haven't done the SSL cert fix on a production network (yet), so I can't guarantee my answer. But I think you can leave your VMs running while you update the certificate. I also believe you don't need to reconnect the hosts. But first try it out in a lab environment to verify.

    ReplyDelete
  8. To answer Mark's questions, since I just did this on a production vCenter server:
    1. VMs can remain powered on
    2. Hosts will become disconnected but can be reconnected by right-clicking, selecting "Connect" and entering the proper credentials in the wizard that pops up.

    ReplyDelete
  9. The correct path for SSL certificates on 2008 R2 is:
    C:\ProgramData\VMware\VMware VirtualCenter\SSL.

    ReplyDelete
  10. Thanks for the information, & Erwen thanks for the password recovery command - this has been very helpful!

    ReplyDelete
  11. Hi,

    In my case vpxd -p was obligatory. Not doing this you have a vCenter Server service not able to start.

    When connecting ESX hosts back to the vCenter after certicates change I needed to put the root credentials.

    Regards,
    oczkov

    ReplyDelete
  12. Erwin, How did you know what password to make it? We are using SQL Express and do not know what username or PW is being used to connect at this point.

    ReplyDelete
  13. This guide has been very helpful. Thank you.

    It would appear to me that you do not have to reset the password with "vpxd -p" if you are using VCenter with SQL Express. In our test environment with SQL Express we did not have to reset the password. In fact we are not sure how since there is no System DSN to even see what account VCenter is using.

    ReplyDelete
  14. I had to use the "vpxd -p" in our live environment using SQL Express.

    ReplyDelete
  15. Has anyone else run into getting prompted to choose a digital certificate when using IE to browse to the web interface (https://vcservername.domainname.com)?

    I get a promt saying “the website you want to view requests identification. Please choose a certificate.”

    I have one cert there, I can choose it or simply hit cancel and it let’s me in and the certificate I used per the procedure above shows as fine. Not sure why it’s asking for a client cert?

    Thanks,
    Bob

    ReplyDelete
  16. I am not sure what step I am missing, but I ahve gone so far as to cut and paste the commands and when I start the Virtual Cneter services I receice an error

    The VMware VirtualCenter Server service terminated with service-specific error 2 (0x2).

    Any thoughts?

    Thanks

    ReplyDelete
  17. I had to go to R:\Program Files (x86)\VMware\Infrastructure\VirtualCenter Server and run VPXD -p to encrypt the connection password to the database

    ReplyDelete
  18. After successfully applying the certificate, everything works fine except the report tab. I get the following:

    Report application initialization is not completed successfully. Retry in 60 seconds.

    ReplyDelete
  19. I actually had to revert to a backup of the vCenter server after I ran 'vpxd -p' following the certificate update. While the vCenter services started, I could not [re]connect to any of the servers. I kept getting the following error:

    "Call "Datacenter.QueryConnectionInfo" for object "[VM Server]" on vCenter Server "[vCenter server]" failed.

    Perhaps there is a built-in password SQL Express uses, and when changed, vCenter could no longer connect to it? What password do you use when resetting it with 'vpxd -p'?

    Anyway, once I reverted to the pre- 'vpxd -p' state of the vCenter server, the certificate upgrade went smoothly without issuing 'vpxd -p'. Services started fine, and the VM Servers reconnected easily (I only had to re-enter their login passwords).

    ReplyDelete
  20. I'd like to amplify on step 9, which states that in the “openssl pkcs12? command, you must use “pass:testpassword”. Otherwise Tomcat fails with the symptom that Performance Overview charts won’t display in the vSphere client. If you use a different password, you can edit C:\Program Files\VMware\Infrastructure\tomcat\conf\server.xml, changing “keystorPass=testpassword” to the password you actually used. Sometimes you really wonder “What were they thinking in VMware land?” Here’s another article on this issue from IBM: “unable to enable plug-ins in vCenter 4.0? at http://www-01.ibm.com/support/docview.wss?uid=isg3T1011813. Cheers, Jeff.

    ReplyDelete
  21. I'm running vCenter Server 4.1.0 and followed these steps using OpenSSL 1.0.0d. The services started fine but the Performance and Storage View tabs weren't working. "vpxd -p" did not resolve the issue. I called VMware and the tech said that OpenSSL 1.0.x would not work with Tomcat. I installed OpenSSL 0.9.8r and recreated the certs. Everything worked after that.

    ReplyDelete
  22. Just recently ran through this scenario and was looking at multiple write-ups about how to do this. I did the vpxd -p and it screwed up my connections to all of my vCenter hosts. After playing with it for hours I came to a very simple realization: vpxd -p must be run ONLY on environments that are using SQL authentication to the database.

    If you are using Windows/AD authentication to the database then running this command will cause it to try and use the password you enter every time it connects, which obviously breaks things.

    You can check your connection type by going to HKLM\SOFTWARE\VMware, Inc.\VMware VirtualCenter\DB. Look at REG_SZ "2". If it has a username there then you are using SQL auth and need to run the command. If it is blank then DO NOT run it. The encrypted password is stored in REG_SZ "3", so if you screw up and run it on an AD auth system then just clear this string.

    ReplyDelete