Posts Tagged ‘SSL’

Single Sign-On Warning 25000

November 12th, 2013

Up to this point, I’ve deployed several net new instances of vCenter Server 5.5 and of course its essential components including Single Sign-On, Inventory Service, next generation Web Client, and the legacy vSphere Client.  Most of these deployments leveraged the vCenter appliance.  Using the appliance is a very easy to deploy vCenter because all of the essential components are pre-installed in the appliance and only need to be configured.

One area I hadn’t tackled much yet are upgrades of existing Windows-based vCenter environments to vSphere 5.5.  Having recently completed an inline upgrade of vCloud Director 5.1.2 to 5.5, it was now time to upgrade said vCloud’s underlying vSphere 5.1 (Update 1a I believe) virtual infrastructure.   Prior to starting the upgrade, I took the necessary precautions of getting a point in time snapshot of the vCenter Server, the vCloud Director Cells, and the Microsoft SQL Server databases for each (three total: SSO, vCenter, and vCD).  I accomplished this using array based snapshots – in this case Dell Compellent Storage Center Replays.

I launched autorun from the vCenter 5.5 installation media.  I opted for the custom installation and started with the Single Sign-On (SSO) upgrade from 5.1 to 5.5.  During the installation, I was met with

Warning 25000.  Please verify that the SSL certificate for your vCenter Single Sign-On 5.1 SSL is not expired.  If it did expire, please replace it with a valid certificate before upgrading to vCenter Single Sign-On 5.5.

Snagit Capture

In this particular environment, self-signed certificates from VMware were in use.  I know that this environment was deployed new less than two years ago and a verification of the SSL certificates in use proved that none were expired.  But because SSO and vCenter are such integral components to vCloud Director, I didn’t want to proceed without further vetting this out.


Upgrade from vSphere 5.1 to vSphere 5.5 rolls back after importing Lookup Service data (2060511) – This KB article describes a situation in which Warning 25000 results when a registry value on the existing Windows-based SSO 5.1 server does not match a field on the SSL certificate.  The resolution involves simply changing the registry value to match that which is on the SSL certificate.  I won’t repeat the details because you can read the KB article yourself.  Furthermore it didn’t resolve the problem in this case because the field on my SSL certificate and the registry key were an identical match.

Upgrading to VMware vCenter Single Sign-On 5.5 displays the error: Warning 25000 (2061478) – This KB article describes a problem for which there is no resolution. However, there is a workaround and that involves changing service_id and files.  More detail is available in the KB article and again the symptoms in the log files weren’t a close match.

The Trouble With SSL Certificates and Upgrading to VMware SSO 5.5 – Then I took a look at Michael Webster’s blog article on precisely the same error message.  Michael briefly discusses the two SSL certificate deployment models and then digs into VMware KB 2060511 mentioned above.  While the information in Michael’s blog article reassured me I was not alone in my journey, KB 2060511 didn’t solve my problem either.  But sometimes the value of blog articles is not only in the original author’s content, but also in the follow up comments from the readers.  Such was the case here.  A number of Michael’s readers responded by saying they were essentially in the same boat I’m in – it sounds like KB 2060511, but in the end this article doesn’t have the solution because there was nothing wrong with their SSO registry values.  The readers found no choice but to push onward beyond Warning 25000 with fingers crossed.  As it turned out in my as well as with some others, Warning 25000 was benign in nature and the installation completed successfully with no rollback.

In summary, this blog post does not represent global authority to ignore Warning 25000.  Rather it is meant to highlight one particular scenario where Warning 25000 may present itself and the actions that were taken to work through the problem.  I can’t stress enough the importance of the SSO component of vCenter going forward.  If any conclusion can be drawn here, it is that a backup of the infrastructure components should be secured before committing to the upgrade steps.  In this case, snapshots are the quickest and easiest method to provide data protection and recovery.  Although vSphere snapshots would work in some deployment architectures, recovering an environment when the environment being upgraded is managing the snapshots could be a challenge.  That is why I chose an out of band array based snapshot in this instance.

I would also like to point out in closing that vSphere 5.5 is still relatively new and VMware appears to still be chasing down all possible causes, resolutions, and workarounds to Warning 25000.  New information as well as VMware KB articles may develop subsequent to this writing so it may be worth continuing your own Google searching beyond this point.

Have a great week!

SSL integration with VirtualCenter

November 4th, 2008


Are you tired of seeing the Security Warning splash screen when launching the Virtual Infrastructure Client to connect to VirtualCenter?  Do you feel a sense of guilt clicking the Ignore button or checking the “Do not display any security warnings for…” box?  Are you flirting with real world dangers or risking termination for fostering a less secure virtual infrastructure?  Would you like to correct the situation the right way by integrating SSL certificates and securing VIC/VirtualCenter communication at the same time?  Here are the step by step instructions (originally created by VMTN forum member astrolab and refined by myself).

In this exercise, I’ll be using a Microsoft Active Directory integrated enterprise certificate authority (CA) to generate a certificate for the VirtualCenter host which resides in the same AD domain.  We’ll begin with the assumption that the enterprise CA has already been built as well as the VirtualCenter Management Server (VCMS).  We will also assume that the enterprise CA is listed as a Trusted Root Certification Authority on the client that will be connecting to the VCMS via the VIC.  To validate this in Internet Explorer, choose Tools|Internet Options|Content|Certificates|TRCA tab

  1. Download and install Win32 OpenSSL Light onto the VCMS
  2. Back up the existing RUI.CRT, RUI.KEY, and RUI.PFX files located in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\
  3. Generate an RSA private key and a certificate-signing request (the openssl binary comes from the installation of Win32 OpenSSL Light in step 1 above)
    1. From a command prompt, change to the C:\openssl\bin\ directory and issue the command openssl genrsa 1024 > rui.key
    2. From a command prompt, change to the C:\openssl\bin\ directory and issue the command openssl req -new -key rui.key > rui.csr
      1. Provide the appropriate information.  Your Name/Common Name is the FQDN of your VCMS (ie.
  4. Request a certificate from the Microsoft enterprise CA
    1. In an IE browser, browse to http://enterprise_ca_domain_controller/certsrv/
    2. Click Request a certificate
    3. Click advanced certificate request
    4. Click 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
    5. Open the rui.csr file with MS wordpad and copy the entire contents (including the BEGIN and END lines) into the “Saved Requst” field of the certificate request in the web browser.  Alternatively, you can click the “Browse to insert” link to simply attach the rui.csr file
    6. Change the Certificate Template to Web Server
    7. Click the Submit button
    8. On the next screen, choose “Base 64 encoded” and click the “Download certificate” link
    9. When prompted, save the certificate to C:\openssl\bin\  with the file name rui.crt
  5. Create a .pfx (personal individual exchange) file for rui.crt on the VCMS
    1. From a command prompt, change to the C:\openssl\bin\ directory and issue the command openssl pkcs12 -export -in rui.crt -inkey rui.key -name -out rui.pfx
  6. Move rui.cft, rui.key, and rui.pfx from C:\openssl\bin\ to C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\
  7. Disconnect all ESX hosts from the VCMS (you can safely leave the guest VMs running or whatever state they are in).  This step needs to be done because after the VCMS loads the new certificates, it will not be possible to gracefully shut down the VMs from the VIC, though it could still be done through RDP or COS.  It’s best to perform this step to avoid future headaches.
  8. Stop the VMware VirtualCenter Server service
  9. From a command prompt, change to the C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ directory and issue the following command to re-encrypt the VCMS database password):  vpxd -p (when prompted, type the password used for the VCMS database)
  10. Start the VMware VirtualCenter Server service
  11. Reconnect all ESX hosts
  12. The steps are complete, but there is one important note going forward that deals with the inherent behavior of certificates and our certificate request outlined above:  Use the Virtual Infrastructure Client to connect to the VirtualCenter Management Server using the FQDN (ie.  You can connect to the short NetBIOS name of the VCMS but at that point your connection won’t be covered by your certificate and you’ll once again receive the Security Warning dialogue box shown at the beginning of this article.