Home > CA SSL Certificates, Security, VMware > The Trouble with CA SSL Certificates and vCenter 5

The Trouble with CA SSL Certificates and vCenter 5

This article is a follow up to the one I posted previously regarding The Trouble with CA SSL Certificates and ESXi 5. This article will focus on successfully changing the default VMware SSL certificates on vCenter 5 and vCenter Update Manager hosts with CA signed certificates using a Microsoft CA (it will also work with public and OpenSSL CAs, but I have not tested it yet). One of the things that makes it hard for people to get this right is that like with ESXi 5 there is no one document or source of truth that explains in sufficient detail what the requirements and supported configurations are or how to implement CA signed SSL certificates in vCenter Server.  I’m hoping that the information in this article will help and encourage more people to change out the default certs (to improve security), and make the process far more reliable and easier to achieve with vCenter 5. Although not covered here, vCenter Heartbeat is becoming more critical as a component in VMware Infrastructures to provide high availability to vCenter. There is currently no supported way to change the SSL certificates that vCenter Heartbeat uses. There is an unsupported method that I will test and if successful will post once I’ve configured vCenter Heartbeat in my environment.

VMware vCenter CA SSL Certificate Resources

As with my previous article I had to run through a bunch of different resources, some of them the same, some of them different. There are some differences in the way you need to generate certificates between vCenter (and VUM) and the ESXi hosts. The below resources are in no particular order or importance. The all contained important information, which I have distilled into a successful process for this article.

If you want a way to fully manage the certificate lifecycle and replace certs automatically then you’ll want to check out vCert Manager – Changing VMware SSL Certs Made Easy. This will completely automate the SSL certificate process in vSphere environments. 

vi_vcenter_certificates.pdf

vSphere 5 Security Guide

Replacing vCenter Server 4.1 Certificates

Generating Domain Root CA signed certificates for vCenter Server

VMware KB 1023011 – Replacing SSL certificates for VMware vCenter Update Manager by using the Update Manager Utility

VMware KB 2007824 – After upgrading to vCenter Server 5.0, the vCenter Service Stats and Hardware Status tab cannot be accessed

VMware KB 2009857 – Certificate warning is reported even after replacing vCenter Server 5.0 default SSL certificates with custom SSL certificates

Creating a Certificate with Multiple Hostnames

vSphere 5 Certificates – Replacing the Default vCenter 5 Server Certificate

vSphere 5 Certificates – Replacing the Default Update Manager Server Certificate

Import an OpenSSL CSR into a Windows CA

Replace SSL Certificates: Replace vCenter SSL Certificates

Replacing vCenter 4.1 SSL Certificate with Active Directory Issued One

Replacing vCenter SSL Certificate with Certificate Issued by Microsoft Certificate Authority

Special thanks to the author of WoodITWork.com, Julian Wood for the excellent articles that he posted that were a great help in putting this together.

Now for the Trouble

With a bit of trial and error you could easily enough replace the vCenter Server certificate with a CA signed certificate with a similar process that I showed you for ESXi. However this won’t do you any good as all of your web services will fail. There is a high likelihood that even if you followed the information in VMware KB 2007824 for vCenter 5 that you would be in no better position. The reason for this is that you would likely not have the correct options in either your CA certificate template, or in your OpenSSL configuration file. There are some slight changes in both of these places that will most likely trip you up. It’s not until you read vSphere 5 Certificates – Replacing the Default vCenter 5 Server Certificate and vSphere 5 Certificates – Replacing the Default Update Manager Server Certificate and then VMware KB 1023011 that you might pick up on the necessary fields that you need to concern yourself with. If you don’t take good care you will find yourself without functioning web services, which is were a lot of the vCenter goodies are. Updating Update Manager is actually on the whole a lot easier than vCenter, provided you have the correct options in your CA Template and also your OpenSSL configuration file. As in my previous article I have invested considerable effort to bring you a solution, that I hope will save you a lot of time and frustration. Also note that just updating the SSL Certificate in the vCenter SSL folder is not good enough. You will also need to replace the SSL Certificate files in the Inventory Service SSL directory and also the SSL directory of any other installed components, such as vSphere Web Client.

Now for the Fix

To ensure that the certificates in vCenter Server actually work and function correctly with the Web Services you actually need to add some additional fields into your CA template and your Certificate Signing Request via the OpenSSL configuration file. The information you need is actually contained in VMware KB 1023011. But honestly this isn’t the first place you’re going to look when trying to change out vCenter Server Certificates as it relates to Update Manager. Why this critical information is not present in the security guide I’m not sure. To save you having to read it all the key bits of configuration for OpenSSL are as follows:

Section [ req ]

encrypt_key = no

Section [ x509 ] in the KB and [ v3_req ] in my example configuration

keyUsage = digitalSignature,keyEncipherment
extendedKeyUsage = serverAuth,clientAuth

I found that the default VMware generated certificate had an additional keyUsage parameter, so in my example I have added nonRepudiation and  dataEncipherment, so my config line is as follows:

keyUsage = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment

You must also include a Subject Alternative Name, which should be the FQDN of the vCenter Server. You can optionally include multiple DNS names in the Subject Alternative Name section, as I have done in my example, to include also the short name of the server. This will ensure that no certificate warning box will be presented if a truly valid server name is used to access it. If you have ever configured certificates for SRM you will know that it uses Subject Alternative Name and Common Name (CN) differently. In the SRM case The Common Name is normally set to “SRM” and must be the same on both sides. The Subject Alternative Name is then set to the FQDN of the SRM Server. This is quite a different use compared to vCenter.

Because we are specifying a Subject Alternative Name for the vCenter Server you must ensure that your CA certificate template includes this option. This options may not be available in all Microsoft CA versions (I have tested 2003 and 2008 successfully).

Although the KB is a good source of information it is still quite easy to get confused by the way it is written. It also doesn’t have all the details, but it’s good that it has more details than many of the other sources of information. For example if you tried issuing the command that includes the -x509 statement you would not have good results if you are sending the request to a CA, as it needs to be base64 encoded.

There is one piece of very important information in the KB that is quite easy to gloss over and it is this:

openssl pkcs12 -in ./mycert.p12 –info #To see the information in pfx file

In my example I actually just ran the command directly against rui.pfx instead of having an additional step. But this step is critical to test the pfx file and ensure it’s integrity and that it can be deciphered using the correct password. If this part of the process fails you know your pfx file is no good and you should not proceed to replace the certificates on the vCenter or Update Manager Servers.

The key pieces of information you need from KB 2007824 are steps 10 through 12, which I have included in my step by step process below.

Step by Step vCenter Server SSL Certificate Replacement using Windows and a Microsoft CA

You will notice that I have repeated some of the steps below from my previous article on ESXi SSL Certificate replacement. This is intentional so that you have all the necessary steps in one place and don’t have to switch back and forth between multiple articles (like I had to do).

You could execute a similar process to the one I’m about to describe using an OpenSSL or Public CA and using the Unix/Linux version of OpenSSL, however this is how I did it successfully in my lab and with my customer. As mentioned in the vSphere 5 Security Guide VMware uses X.509 v3 SSL certificates (base-64 encoded) for encrypting traffic between various components. If you CA has been set to support only SHA512 hash that is fine, it will work, although the VMware documentation doesn’t mention it. The three key files for an vCenter Server are rui.crt, rui.key and rui.pfx.

In order to generate the certificates you’ll need to get a copy of OpenSSL x86 v0.98r or higher, and have access to a Microsoft CA (2003 or higher). The certificates will use a clone of a standard web server request template with Subject Alternative Name added, for my lab I modified the default Web Server Certificate Template to accept up to 15 years for certificates. On the system where you will generate the certificate signing request rui.csr) you will need to ensure you have Microsoft Visual C++ 2008 Redistributable Package (x86) before installing OpenSSL. For the purposes of this process you will use the Microsoft CA Web Pages to submit the certificate request and download the resulting base-64 encoded certificate. You can use the certreq command if you wish also (not covered here). Before applying the certificates to your environment you should ensure that your clients and vCenter server trust your CA, if it’s an AD integrated CA this should be automated, else you may have to pre-trust the Root or Intermediary CA  by loading the CA public cert into your clients and vCenter server (not covered in this process).

Don’t forget to test access to all the management tools you use in your environment once the vCenter Certificate is updated. You will likely need to update their connections to vCenter as they will still hold the old SSL thumbprint.

Prerequsites:

Microsoft CA (2003 or above, with Web Server Template with Subject Alternative Name included and configured to your liking)
The CA Template must have the “Allow Key Exchange Only With Key Encryption” option selected in its key usage policy
Microsoft Visual C++ 2008 Redistributable Package (x86) on the system where you will generate the certificate signing request (CSR)
OpenSSL 0.98r or above on the system you will use to generate the CSR
vCenter 5.0

Things to watch out for:

Do not change the password in the OpenSSL configuration from ‘testpassword’, it must remain testpassword.
As stated above you must download the certificate in PEM (Privacy Enhanced Mail) base-64 encoded format.

Process Step by Step:

  1. Before you start this process you should log into vCenter Server and check that all the services linked with Web Services are working, such as Hardware Status Tab, vCenter Service Status, and also Profile Driven Storage. These are the areas that are very likely to get broken if the process is not followed correctly.
  2. After having installed Microsoft Visual C++ 2008 Redistributable Package (x86) and Open SSL 0.98r or later on a management system (vCenter or other system, not the CA) open a command prompt (As Administrator if on Windows 2008) and change to the OpenSSL\bin folder. Use the same command prompt opened As Administrator for all the OpenSSL actions in this list.
  3. Edit the openssl.cfg file and ensure it looks similar to the one included at the bottom of this article but with your organization specific information, save the configuration.
  4. Execute the following command – openssl req -new -nodes -out rui.csr -keyout rui.key -config openssl.cfg. Note: there will be no prompts as all the information is contained within the configuration file. This is a bit different than when generating the CSR for the ESXi hosts, but that is because there are more of them, and you may not want to have to generate entire config files for each host. For ESXi hosts it is much easier to just hit enter a few times and then specify a common name (fqdn) and then more on. However for vCenter and Update Manager it is better to have everything in the config file, especially as you will likely be specifying multiple Subject Alternative Names (SAN’s – not to be confused with storage area networks).
  5. Copy or submit rui.csr to your CA, submit an advanced certificate reqeust, using the Web Server template that you modified, and download the base-64 encoded certificate to the system with OpenSSL that was used to generate the CSR (Screenshots of this available here: How to use CA certificate to replace VMware certificate on ESX(i) 4 and vCenter or here: vSphere 5 Certificates – Replacing the Default vCenter 5 Server Certificate.)
  6. Execute the following command – openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx. This will create a rui.pfx file which we will now verify. Note: I have had trouble specifying the -name rui with double quotes so I have removed them. When you verify the pfx file ensure the friendly name just says rui without any other characters. Note: Do not change the password from “testpassword”.
  7. Execute the following command – openssl pkcs12 -in rui.pfx -info. When prompted enter the password testpassword. You should see an base64 encoded string or characters displayed on the screen and information about the file. Note you will be asked to enter the password twice when it is displaying the private key. Ensure the certificate is visible and that the friendly name is rui without any other special characters.
  8. Create a folder on the system used to generate the CSR to back up the existing VMware default certificates that are on the vCenter Server, a separate directory will be needed for vCenter Server, Inventory Service, and any other services (such as vSphere Web Client) running on the vCenter Server.
  9. Copy the existing rui.crt, rui.key and rui.pfx files from the vCenter and Inventory Service SSL folders to the backup folders you just created. You should also back these files, and the new certificate files up to a safe location. The location by default for vCenter this is C:\ProgramData\VMware\VMware VirtualCenter\SSL and for the Inventory Service SSL certificate is C:\Program Files\VMware\Infrastructure\Inventory Service\ssl.
  10. Copy the new rui.crt, rui.key, and rui.pfx files that were generated to the target host in the vCenter Server and Inventory Service SSL locations.
  11. You will use the vCenter Server Managed Object Browser to load the new SSL Certificates into memory. Ensure that you have not yet disabled the MoB as part of your hardening before you have successfully changed the certificates. To access the MoB browse to the following location from the vCenter Server – https://localhost/mob/?moid=vpxd-securitymanager&vmodl=1, when prompted enter a vCenter Administrator username and password.
  12. The Managed Object Type for the vpx.SecurityManager will load, Click on reloadSslCertificate
  13. Click on Invoke Method
  14. The new SSL certificates will be loaded into memory and you will see the following if successful – Method Invocation Result: void.
  15. If you do not already have an RDP or Console session open on your vCenter Server please open one now. Log in as an administrator and open a command prompt As Administrator.
  16. Change directory to C:\Program Files\VMware\Infrastructure\VirtualCenter Server\
  17. Execute the following command and when prompted enter the database password – vpxd -p. This will update the encrypted form of the db password after the new certificate, which will allow all the web services to access it. NOTE: You should enter the existing database password, not a new password at this point.
  18. Stop and then restart the VMware VirtualCenter Server, which will in turn restart vCenter Management Web Services, Inventory, and Profile Driven Storage Services. You may have to reconnect all your hosts if you are doing vCenter SSL certs before the host certs. In my environment I did the hosts first and did not have to reconnect them when changing the vCenter SSL certs as a result.
  19. After the initial restart you may notice that after 5 minutes or so the Profile Driven Storage Service has stopped (I did). At that point you should restart it again and it should remain running.
  20. Log into vCenter Server and verify that all Host Status Tab’s are working, the vCenter Service Status is functioning and all services are running correctly, and that Profile Driven Storage configuration is accessible and working.

Now that you’ve updated the vCenter Server and also the Inventory Service Certificates you may need to also update your vSphere Web Client Certificate if it is also on your vCenter Server. The location for the vSphere Web Client SSL Certificate is C:\Program Files\VMware\Infrastructure\vSphere Web Client\DMServer\config\ssl by default. Once you have updated the vSphere Web Client SSL Certificate and restarted the services you will then need to browse to the vSphere Web Client Admin App and re-register vCenter Server to ensure that it is registered with the correct thumbprint. Browse to https://localhost:9443/admin-app.

Up to step 10 the process is almost exactly the same for Update Manager. For Update Manager however you need to copy the new certificate files into <Update Manager Installation Directory>\SSL, after taking a backup of course. The default locations are as follows:

  • The default path in 64-bit Windows is C:\Program Files (x86)\VMware\Infrastructure\Update Manager\SSL
  • The default path in 32-bit Windows is C:\Program Files\VMware\Infrastructure\Update Manager\SSL

Once the new certificate files are copied into the correct location you need to do the following on the Update Manager Server:

  1. If you do not already have an RDP or console session open on the Update Manager Server do that now and log in as an administrator.
  2. Stop the Update Manager Services
  3. Change directory to the Update Manager Installation Directory, by default as per above minus the SSL part.
  4. Double click on VMwareUpdateManagerUtility.exe to execute the file.
  5. Log in by using the administrator credentials and the IP address or host name of vCenter Server system.
  6. In the Options pane of the Update Manager Utility, click SSL Certificate.
  7. In the Configurations pane, select Followed and verified the steps and click Apply.
  8. Once the operation completes start the VMware vCenter Update Manager service.

Please let me know if you have any trouble with the above process, and also if it works for you, your comments and feedback are appreciated.

Example OpenSSL Configuration file (openssl.cfg) without most of the normal comments and white space that is included:

# vCenter OpenSSL example configuration file start.
HOME            = .
RANDFILE        = $ENV::HOME/.rnd
oid_section        = new_oids

[ new_oids ]

[ ca ]
default_ca        = CA_default        # The default ca section

[ CA_default ]

dir                = ./demoCA        # Where everything is kept
certs                = $dir/certs        # Where the issued certs are kept
crl_dir            = $dir/crl        # Where the issued crl are kept
database            = $dir/index.txt    # database index file.
new_certs_dir        = $dir/newcerts        # default place for new certs.
certificate            = $dir/cacert.pem     # The CA certificate
serial            = $dir/serial         # The current serial number
crlnumber            = $dir/crlnumber    # the current crl number  must be commented out to leave a V1 CRL
crl                = $dir/crl.pem         # The current CRL
private_key        = $dir/private/cakey.pem# The private key
RANDFILE        = $dir/private/.rand    # private random number file
x509_extensions    = usr_cert        # The extentions to add to the cert
name_opt         = ca_default        # Subject Name options
cert_opt             = ca_default        # Certificate field options
default_days        = 5475            # how long to certify for
default_crl_days    = 30            # how long before next CRL
default_md        = sha512        # which md to use.
preserve            = no            # keep passed DN ordering
policy            = policy_match

[ policy_match ]
countryName            = match
stateOrProvinceName    = match
organizationName        = match
organizationalUnitName    = optional
commonName            = supplied
emailAddress            = optional

[ policy_anything ]
countryName            = optional
stateOrProvinceName    = optional
localityName            = optional
organizationName        = optional
organizationalUnitName    = optional
commonName            = supplied
emailAddress            = optional

[ req ]
default_bits            = 2048
default_keyfile             = privkey.pem
distinguished_name        = req_distinguished_name
attributes                = req_attributes
x509_extensions        = v3_ca    # The extentions to add to the self signed cert
input_password         = testpassword
output_password         = testpassword
encrypt_key             = no
prompt                = no
string_mask             = nombstr
req_extensions         = v3_req     # The extensions to add to a certificate request

[ req_distinguished_name ] # change these settings for your environment
countryName                = NZ
stateOrProvinceName        = Auckland
localityName                = Auckland
0.organizationName            = IT Solutions 2000 Ltd
organizationalUnitName        = IT
commonName                = vc.homedns.org
emailAddress                = admin@yourdomain.com

[ req_attributes ]

[ usr_cert ]

basicConstraints        =CA:FALSE
nsComment            = “OpenSSL Generated Certificate”
subjectKeyIdentifier        =hash
authorityKeyIdentifier    =keyid,issuer

[ v3_req ]
basicConstraints         = CA:FALSE
keyUsage                 = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage         = serverAuth, clientAuth
subjectAltName         = DNS:vc.homedns.org, DNS:vc41.homedns.org, DNS:vc41 #examples only

[ v3_ca ]
subjectKeyIdentifier        =hash
authorityKeyIdentifier    =keyid:always,issuer:always
basicConstraints         = CA:true

[ crl_ext ]
authorityKeyIdentifier    =keyid:always,issuer:always

[ proxy_cert_ext ]
basicConstraints        =CA:FALSE
nsComment            = “OpenSSL Generated Certificate”
subjectKeyIdentifier        =hash
authorityKeyIdentifier    =keyid,issuer:always
proxyCertInfo            =critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo

# vCenter OpenSSL example configuration file end.

# vCenter Update Manager OpenSSL example configuration file Start.

HOME            = .
RANDFILE        = $ENV::HOME/.rnd
oid_section        = new_oids

[ new_oids ]

[ ca ]
default_ca        = CA_default        # The default ca section

[ CA_default ]

dir                = ./demoCA        # Where everything is kept
certs                = $dir/certs        # Where the issued certs are kept
crl_dir            = $dir/crl        # Where the issued crl are kept
database            = $dir/index.txt    # database index file.
new_certs_dir        = $dir/newcerts        # default place for new certs.
certificate            = $dir/cacert.pem     # The CA certificate
serial            = $dir/serial         # The current serial number
crlnumber            = $dir/crlnumber    # the current crl number must be commented out to leave a V1 CRL
crl                = $dir/crl.pem         # The current CRL
private_key        = $dir/private/cakey.pem# The private key
RANDFILE        = $dir/private/.rand    # private random number file
x509_extensions    = usr_cert        # The extentions to add to the cert
name_opt         = ca_default        # Subject Name options
cert_opt             = ca_default        # Certificate field options
default_days        = 5475            # how long to certify for
default_crl_days    = 30            # how long before next CRL
default_md        = sha512        # which md to use.
preserve            = no            # keep passed DN ordering
policy            = policy_match

[ policy_match ]
countryName            = match
stateOrProvinceName    = match
organizationName        = match
organizationalUnitName    = optional
commonName            = supplied
emailAddress            = optional

[ policy_anything ]
countryName            = optional
stateOrProvinceName    = optional
localityName            = optional
organizationName        = optional
organizationalUnitName    = optional
commonName            = supplied
emailAddress            = optional

[ req ]
default_bits        = 2048
default_keyfile         = privkey.pem
distinguished_name    = req_distinguished_name
attributes            = req_attributes
x509_extensions    = v3_ca    # The extentions to add to the self signed cert
input_password     = testpassword
output_password     = testpassword
encrypt_key         = no
prompt             = no
string_mask         = nombstr

req_extensions = v3_req     # The extensions to add to a certificate request

[ req_distinguished_name ] # change these settings for your environment
countryName            = NZ
stateOrProvinceName    = Auckland
localityName            = Auckland
0.organizationName        = IT Solutions 2000 Ltd
organizationalUnitName    = IT
commonName            = updmgr.homedns.org
emailAddress            = admin@corp.it-solutions.homedns.org

[ req_attributes ]

[ usr_cert ]
basicConstraints        =CA:FALSE
nsComment            = “OpenSSL Generated Certificate”
subjectKeyIdentifier        =hash
authorityKeyIdentifier    =keyid,issuer

[ v3_req ]
basicConstraints         = CA:FALSE
keyUsage             = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage         = serverAuth, clientAuth
subjectAltName        = DNS:updmgr.homedns.org, DNS:updmgr # examples only

[ v3_ca ]
subjectKeyIdentifier        =hash
authorityKeyIdentifier    =keyid:always,issuer:always
basicConstraints         = CA:true

[ crl_ext ]
authorityKeyIdentifier    =keyid:always,issuer:always

[ proxy_cert_ext ]
basicConstraints        =CA:FALSE
nsComment            = “OpenSSL Generated Certificate”
subjectKeyIdentifier        =hash
authorityKeyIdentifier    =keyid,issuer:always
proxyCertInfo            =critical,language:id-ppl-anyLanguage,pathlen:3,policy:foo

# vCenter Update Manager OpenSSL example configuration file End.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Advertisements
  1. Whysyn
    February 16, 2012 at 3:49 am

    Any thoughts on getting the name used by Update Manager to update? I installed a commercial cert using a lot of information on your site (THANK YOU!). Now I get an error that the certificate name mismatches when installing the Update Manager plugin.

    • February 16, 2012 at 8:40 am

      Hi Whysyn, Which host is your Update Manager installed on? The cert used for Update Manager needs to have the correct FQDN, else it will report a mismatch. It’s also possible that update manager is registered with vCenter using a short name or IP, what did you enter when you installed it? In the case of short name it may be possible to use the Subject Alternative Name in the CSR to get the cert working. But this is a bit inconvenient if you have public CA certificates given the costs.

      • Whysyn
        February 16, 2012 at 8:58 am

        Update Manager is installed on the vCenter server.

        Update manager is registered with the internal hostname… during installation they present a dialog that only allows choosing an IP address, short name, or full hostname – they don’t permit entering an arbitrary hostname, which is what I need since my internal hostname (vc.dbsvi.local) is different from my public domain name.

        The cert has the proper, publicly accessible hostname. My question is how to change VUM’s registered hostname.

      • February 16, 2012 at 9:47 am

        There is no easy answer there. You will likely have to change your certificate to the internal hostname / FQDN, not the external / public one. Is your vCenter actually publicly available?

      • Whysyn
        February 16, 2012 at 9:49 am

        Yes it is, we are a hosting provider. Was just hoping for an easy answer before getting on with VMWare support. Thanks again.

      • February 16, 2012 at 9:52 am

        Ah, well in that case there may be another answer. Register the vCenter in the name of the external DNS and then make sure that the internal server can access vCenter using the external DNS name. Then access to vCenter is via external DNS name even for internal. You can use split horizon DNS to present different IP based on internal/external source.

  2. Behruz
    February 20, 2012 at 9:27 pm

    Hey Michael,

    which version of OpenSLL you are using? i have version OpenSSL 1.0.0g 64bit for Windows and original config file is much bigger than you have posted even after removing # dash sections. can i replace my cfg file with one you have posted here?

  3. Behruz
    February 20, 2012 at 9:47 pm

    i have missed the part where you talks about openssl version. i will try to use your openssl config file on windows and will let you know results

    thank you

  4. Behruz
    February 20, 2012 at 11:21 pm

    i have followed your instruction and everything is working like charm excpet VMware vSphere Profile-Driven Storage Service whihc still fails after resart with “The VMware vSphere Profile-Driven Storage Service service terminated with service-specific error Incorrect function..” error. any suggestions?

    • February 22, 2012 at 12:51 pm

      Hi Behruz, That is a common errror, as is the vCenter Service Status and the Host Status tabs not working if the certificates have been generated incorrectly or applied incorrectly. I’ve attempted to contact you offline regarding this and when we have worked out what has gone wrong we can post an update. Do you have a backup of all your certs?

  5. Behruz
    February 21, 2012 at 9:13 am

    15 hours I’m stuck in front of my pc with this problem about certificates for vSphere vCenter 5 and I’m wrong in my previous post, it’s not working as I expected.

    1. The VMware vSphere Profile-Driven Storage Service doesn’t want to start
    2. vCenter Service Status shows Cannot access the health service
    3. Web Client still gives the same certificate warning but IE show that certificate is ok

    I followed yours and Julian Woods’s instruction 5 times, no luck. VMware vSphere Profile-Driven Storage stops after 30 or so and health status shows error.

    I have removed Web Client thinking it uses port which suppose to be used by SPS, SMS- not helped. I have generated few more certs and it also doesn’t help. After digging in tomcat logs I have added localhost to the new certificate in SAN field thinking it will help because tomcat uses localhost in it’s extension config file

    C:\Program Files\VMware\Infrastructure\VirtualCenter Server\extensions\ sms and sps

    Then I have tried ports change and changed http: to https or added 80 or 81, no luck all this doesn’t help. At the moment I’m installing original ssl certificates everything coming back and running from first try. Digging bring me to the KB from kb.vmware.com/kb/2007824 what i’m doing wrong with certificates?

    • April 4, 2012 at 4:33 pm

      Hi Behruz, it appears that your certificates do not contain all the mandatory attributes (based on the review of the supplied certs). Either the CA Certificate Template or the OpenSSL File is incorrect. Let me know how you get on when you do get time to retry the process.

  6. Dredd
    February 29, 2012 at 10:50 pm

    To minimise the impact of changing VC certs, you can re-use the existing RSA key when creating the new certificate. This can be done with something like “openssl req … -key rui.key …”.where the existing rui.key file is used to create the CSR.

    The advantage of doing this with the VC is that you will not have to reconnect the ESX hosts manually after replacing the VC cert, if the key is the same on the old and new certs. Nor do you need to re-encrypt any database passwords or passwords in customzation specs.

    • March 1, 2012 at 8:48 am

      Thanks Dredd, good tip. You also don’t need to reconnect the hosts if the hosts are changed to CA SSL certs prior to vCenter. Then it doesn’t matter if you change the vCenter key or not you will not have to reconnect the hosts. I think most customers that are changing out the certs want to start a fresh though so will most likely be changing their keys. Most of the customers I deal with don’t accept the default keys as they view them as too weak.

  7. Paul
    March 28, 2012 at 7:46 pm

    Great post 🙂

    I can get all this to work fine, bar the fact I’m using a commercial CA and can’t seem to get the certs to chain properly, is this expected behaviour?

    • March 28, 2012 at 8:36 pm

      Normally the full chain will be in the certificate. You may want to check with your CA if the full chain is not included. Make sure the vCenter trusts the CA by installing the Root CA Cert if necessary.

  8. Chris
    April 14, 2012 at 2:30 am

    How can I ensure that my certificate is correct? I followed your instructions but the web services won’t start..

    • April 14, 2012 at 1:56 pm

      Hi Chris, The easy way to verify your cert is by double clicking on the .crt file and looking through all the attributes. Compare the attributes listed in the cert with those that I have documented as required. The most likely reason why the web services won’t start is that either the cert is not correct (would also normally cause vCenter not to start), or the database password hasn’t been reset correctly using vpxd -p. When you issue the vpxd -p command you need to use the same database password as it was before. You should not specify testpassword here, unless your database password also just happens to be test password.

  9. April 26, 2012 at 7:32 am

    If you have ever configured certificates for SRM you will know that it uses Subject Alternative Name, but in the SRM case it is normally set to “SRM” and must be the same on both side <— Nah it should be the FQDN name the CN should be the same at both sides

    • April 26, 2012 at 12:02 pm

      Good Spotting Johan. I have updated the wording of the article, where I had got it around the wrong way with regard to SRM.

  10. May 4, 2012 at 1:53 am

    Using a GoDaddy Wild Card Cert I recieve the following error when attempting to click the “Invoke Method” button:

    Method Invocation Result: vpx.fault.SecurityConfigFault
    dynamicType: String Unset
    dynamicProperty: vmodl.DynamicProperty[] Unset
    faultCause: vmodl.MethodFault Unset
    faultMessage: vmodl.LocalizableMessage[] Unset

    I have removed the rui.* files from both locations and replaced them with the .crt / .pfx / .key files I received from GoDaddy.

    Any insight? Thanks for the great guide

    • May 4, 2012 at 1:58 pm

      Hi Bill, It’s most likely some required attributes are missing or one or more of the files is corrupted. Have you verified the .pfx file? Have you checked all the attributes of the crt file?

      • May 5, 2012 at 3:29 am

        Which are the “Required Attributes” ? and I have used this cert and .pfx file previously on other (non esxi / vcenter) servers without issue.

      • May 6, 2012 at 9:01 pm

        All of the required attributes are covered in the article. So verify that all the required attributes are present in the certificate files and that the pfx file is correct with the correct alias. It will not work without the correct alias of rui.

  11. Paul Howard
    May 14, 2012 at 1:51 am

    I had another stab of this today, no joy i just cant get it to chain rapidssl certs or digicert for that matter, vCentre just wont play ball, anyone had any success with a comercial CA?

  12. Nicholas
    May 18, 2012 at 2:47 am

    Hi Paul Just saw your post, I’m having issues getting a commercial CA to work on vCenter 5. Please see my post here and get in contact with me. http://communities.vmware.com/message/2041504.

    I have an open SR with VMware, MAN! they have no idea what they are doing. We need more people to open up an SR so they can fix the issue. So just reiterate when you replace the default SSL on VC with a commercially sign SSL vCenter will not load the certificate chain even if you have installed the intermediate CA into the trusted store. Another thing to try, when you compile the PFX file using openssl use the -certfile switch to import the Intermediate CA certificates provided by your CA “openssl pkcs12 -export -in rui.crt -inkey rui.key -certfile CACert.crt -name rui -passout pass:testpassword -out rui.pfx” now that PFX will have the chain. However vCenter still does not load the chain, BUT if you browse to https://vcFQDN:8443 this will load the tomcat page and the SSL works perfectly, I suggest to use and online ssl checker to make sure.

    • May 18, 2012 at 9:51 am

      Hi Nicholas, Thanks for your comment and additional information and comment. I agree SR’s need to be raised for this and a proper fix provided. But vCenter not loading the chain isn’t an issue per se for vCenter (I’m not saying it’s not an issue, just vCenter should still work). Tomcat and IE/Windows will check/load the chain however. If your CA isn’t in the Microsoft root list you will need to load the CA certs into the system also.

  13. Nicholas
    May 21, 2012 at 2:58 pm

    I agree, its not a show stopper and vCenter still functions correctly. I actually have actually made some progress with VMware Support, the engineer assigned to me case has been much more responsive and has acknowledged that there is an issue with vCenter 5 loading the commercially signed CA chains.

    Have a look at this documentation, http://www.vmware.com/files/pdf/techpaper//vsp_41_vcserver_certificates.pdf

    I know its for vCenter 4.1 but the same principle still applys, in particular note these:

    Page 2 – “Certificates signed by a commercial certificate authority, such as Entrust or Verisign, are pre‐trusted on the
    Windows operating system.”

    Page 6 – “VMware recommends that you replace default certificates with those signed by a commercial certificate
    authority.”

  14. James
    May 23, 2012 at 2:09 pm

    I’m having the exact same problem with vCenter 5 U1. We Installed a GoDaddy Web server SSL, I also updated the ROOT CAs on the server and vCenter does not load the chain, I also tried Nicholas suggestion with the :8443, that did not work either at first, but then I recreated the pfx file with the certificate chain and browsing to the vCenter :8443 works perfectly with the entire chain. Definitely a problem with vCenter I have had this working in prior versions.

    • May 23, 2012 at 2:21 pm

      I don’t think it’s a vCenter only problem as even without vCenter in the picture the chain is not visible on a standard windows system. For Thawte I’ve verified it’s definitely in the trusted list of CA’s in Windows by default, at least their high trust version is. I’ve not had a chance to verify why the chain is not visible in the base CRT file when the PFX isn’t being used. Tomcat is using the PFX, so the main difference is that it has access to both the cert and also the keys. For cases where the environment is not exposed to the internet then an internal enterprise CA is normally the best and easiest option. For systems exposed to the internet, such as vCD / vC in public cloud, then a commercial public CA is normally the best option (doesn’t help you guys). I’ll see if I can make contact with VMware Support and determine why the public CA’s are causing these symptoms. I know with GoDaddy their certs do not contain the required attributes, so that could be part of the problem. You would have to pick the correct template for the request and make sure your request contained the required attributes.

  15. Nicholas
    May 23, 2012 at 5:14 pm

    @vcdxnz0 Thanks for your comments, I believe somehow we will get to the bottom of this. Just so we know what I have tried, here is a list:

    1. Created CSR as per VMware vCenter 5 Documentation, Signed by Thawte using SSL123 certificate (domain validation only SSL) installed certificate as per VMware documentation.

    2. Created the CSR using methods above and methods explained in other blogs, where modifying the openssl.cfg, then every other steps described in VMware documentation.

    3. Also tried and SSL signed by Thawte, using Web Server Certificate, which validates company and other attributes.

    4. When updating the SSL in the vCenter directory, The Tomcat Web UI at port 8443 uses that certificate and requires the Intermediate CA’s to be loaded into the PFX file to complete the chain. I was able to have the Tomcat Web UI load the certificate with the fully trusted chain, when I import the Intermediate CAs into the PFX using the -certfile switch on OpenSSL.

    5. VMware have also tested this in lab and was also not able to load the chanter on vCenter.

    If anyone out there believes they have successfully replaced the SSL with a commercially sign certificate on a public accessible vCenter server, can you please test it using https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=SO9555 or https://ssl-tools.verisign.com This will ensure that in fact that it is fully public trusted by the browser not just pre-trusted manually?

    • May 29, 2012 at 10:57 pm

      Hi Nicholas, Just wanted to let you know that I’m working with Thawte and VMware on this problem and we will get too the bottom of it and publish the resolution.

  16. conraddel
    May 29, 2012 at 10:48 pm

    There seems to be a bit of a devil in the detail here:
    We are busy implementing a PCI compliant environment for our customer. They have a Windows 2003 Std Edition CA in the environment, we have duplicated the Web Server Template. But when doing step 5, we are unable to select the duplicated customised web server template……

    So we went ahead and issued it with the standard web server template, but now the generated SSL certificate is missing some detail when we compare it with the VMware default one:

    Key usage:
    VMware default = Digital Signature, Key Encipherment, Data Encipherment (b0)
    Generated one = Digital Signature, Key Encipherment (a0)

    Enhanced Key usage
    VMware default = Server Authentication (1.3.6.1.5.5.7.3.1) Client Authentication (1.3.6.1.5.5.7.3.2)
    Generated one = Server Authentication (1.3.6.1.5.5.7.3.1)

    Any idea how to get around this problem ?

    • May 29, 2012 at 10:55 pm

      If you go into the Certificate Authority Manager do you see the template listed under certificate templates? You will need to go into the certtmpl mmc snap-in to be able to manage the templates and configure the necessary attributes on the certificate templates. You also need to make sure that your CSR’s contain all the necessary attributes that you need.

  17. conraddel
    May 30, 2012 at 12:26 am

    Hi there
    Thank you for your reply. We used the openssl.cfg config file as you supplied, and just modifed the:

    [ req_distinguished_name ] and subjectAltName

    sections as appropriate

    Yes when we launch certtmpl.mmc we do see our modfied template, however when we launch https://localhost/certsrv and we select request a certificate, advanced certificate request etc. we do not see the modified template in the “certificate template” dropdown.

  18. Doron Offir
    June 11, 2012 at 9:47 pm

    Thank you so much, for me it helped beautifully, I wasted two days trying to convince the VC 5 and its services to work with the VC 4 certificate, the VC was working, but no the services, and this article helped to pinpoint the problem, many thanks!

  19. Ross
    June 12, 2012 at 2:50 am

    Great article and I got there in the end. What wasn’t spelt out was how to create the necessasry duplicate template so I’ll list the key steps that I used on a Windows 2008 R2 Certificate Authority server:

    On the CA server launch Administrative Tools | Certificate Authority
    R-click certificate templates and choose Manage
    R-click Web Server and choose Duplicate Template
    Choose Windows Server 2003 Enterprise (this seemed to be important as by choosing the 2008 option I couldn’t get the new template appearing in the drop down list for certificate templates using the web based certificate request process.
    Change the Template Display Name to whatever e.g. vCenter Template
    Set the Validity Period to whatever you require e.g. 5 years
    On the Request Handling tab check the box for: Allow private key to be exported
    On the Subject Name tab ensure that “Supply in the request” is selected
    On the Extensions tab edit Application Policies and add Client Authentication to the existing Server Authentication
    Edit the Key Usage extension so that the Digital Signature box is checked, the Signature is proof of origin is checked, Allow key exchange only with key encryption is selected and Allow encryption of user data is checked.
    Close the managing templates window
    R-click Certificate Templates and choose New | Certificate Template to Issue and select the newly created template.
    Restart the Active Directory Certificate Services service.

    • June 12, 2012 at 9:04 am

      Hi Ross, Thanks for going to the trouble to add in the information regarding creating the necessary template. That is greatly appreciated.

  20. June 16, 2012 at 6:56 am

    Step 5 can be done from the command prompt rather than going through the certificate services website… Something like:

    certreq -submit -attrib “CertificateTemplate:VMwareCert” rui.csr

    which will return something like:
    RequestId: 123

    and then
    certreq -retrieve 123

  21. Eugene
    June 21, 2012 at 8:00 am

    In step 17 you say “You should enter the existing database password, not a new password at this point.” What about if you are using SQL 2008 Express for your DB?

    • July 22, 2012 at 12:56 pm

      Hi Eugene, SQL Express is not recommended for production environments, so I’m not really as familiar with replace certs in an environment using an Express DB. I would think that it would normally be the password of your windows user account or service account for vCenter. Unless you’re using Local System. If you’re using local system the whole username and password doesn’t really come into play. Maybe this should be the topic for another blog post, and also something I have to consider for a new project that I’m working on. Thanks for your comment.

  22. DavidS
    July 13, 2012 at 3:40 pm

    A great article I find After doing all this from the VMWare KBs (Not actually too bad, the v5 KBs are much better).

    One thing that I still need to figure out though is for the vCenter Web UI. Every user/pc that connects has to save/ignore the untrusted thumbprint for the vCenter server.

    The thumbprint and CN are correct. I am thinking I need to configure the webui’s trusted CA store to include the CA I am using to sign my certs. Does anyone have some tips on this?

  23. James Livingston
    July 18, 2012 at 5:23 am

    I found some information about using keytool to import the root certificate into the java trust keystore. But it applied to vCenter Orchestrator. However I used C:\Program Files\VMWare\Infrastructure\jre\bin\keytool.exe -import –alias root –keystore C:\ProgramData\VMWare\Virtual Center\SSL\sms.truststore –trustcacerts c:\temp\hpcass_ns.crt followed by the cert store password. It worked I was able to get all the vSphere services running and the pesky register.bat finally worked for the Inventory.

    • July 18, 2012 at 7:54 am

      Great news James. Thanks for posting a comment back here. This is very valuable information for everyone.

  24. K. Zachary Abbott
    September 8, 2012 at 12:47 pm

    I am having the same issue as Bill Scrhrier had:

    When I go to invoke method I get:

    Method Invocation Result: vpx.fault.SecurityConfigFault
    dynamicType: String Unset
    dynamicProperty: vmodl.DynamicProperty[] Unset
    faultCause: vmodl.MethodFault Unset
    faultMessage: vmodl.LocalizableMessage[] Unset

    The only change I have made to your template for the OpenSSL.cfg is to change the subjectAltName as follows (recommnded here: http://lanestechblog.blogspot.com/2009/04/creating-ssl-certificates-with-multiple.html)

    subjectAltName = @alt_names
    [alt_names]
    DNS.1 = vdi-vc1.mydomain.com
    DNS.2 = vdi-vc1.mydomain.com
    DNS.3 = vdi-vc1

    rui file ls named rui.pfx

    Apache works just fine – not sure what vCenter isn’t liking. Would be grateful for any assistance you might be able to offer – happy to take it “offline.”

    • K. Zachary Abbott
      September 8, 2012 at 12:58 pm

      Quick update on my situation – just had my security folks issue me an in-house certificate using the same rui.csr, and viola, no problems….Only major difference – no intermediate CA, but then I can’t see that being the issue. Maybe the format of the rui.crt that is issued? will try to compare the two and see if there’s anything helpful….

    • K. Zachary Abbott
      September 11, 2012 at 10:50 am

      And…Issue Resolved! If anyone else has this issue:

      1) make sure you do *not* change the password in the openssl.cfg file. I found in one of the VMware KBs that this password *has* to be “testpassword”

      2) if you use a commercial CA, make sure you download the cert in x509/PEM format

      Those were the last two changes I made, and everything is working great now.

      Michael – I’m not sure I said before, but thank you for putting this all together!

      • September 11, 2012 at 4:52 pm

        Thanks for your comment. I’ve added some additional emphasis in my article to highlight these two critical factors. I’m in the process of developing a solution that will automate the process of changing SSL Certs in vSphere components. I will be blogging about this and where people can sign up for the early adopter program.

  25. stine
    September 13, 2012 at 12:27 am

    Thanks for your instructions and also for your (and others) efforts getting VMware to implement and document this better.\

    Regarding the ‘testpassword’ password, is the reason not to change it because its hardcoded in one or more of the applications or that you simply have to locate every .XML file and udpate them all?

    Unfortunatly, I’ll probably re-image my vcenter server and install vcenter from scratch since I originally couldn’t bring myself to use testpassword…

    • September 13, 2012 at 12:34 am

      There are a number of XML files to change it in and testpassword is the only officially supported password. You should maintain a supported config.

      To secure your certs from compromise you need to ensure the vCenter OS is secured, and the folders are locked down to only the vCenter service account. No matter what you change it to it will still be in clear text. This is why the OS and file system security is so important.

  26. Henrik
    September 21, 2012 at 2:06 am

    Am i the only one seeing the config example is duplicated/repeated?

    • September 22, 2012 at 4:48 pm

      Hi Henrik, one of the config examples if for vCenter and the other config example if for Update Manager. Some of the config is similar and some of it is different.

  27. September 23, 2012 at 5:25 pm

    What key usage values are required for vSphere 5.1? I looked at a variety of the 5.1 VMware self-signed SSL certs and none of them have nonrepudiation, but some do have Data Encipherment.

    • September 23, 2012 at 5:49 pm

      Hi Derek, The required attributes are covered in the product documentation. There is a new replacing certs document – Replacing SSL Certificates in vCenter 5.1 and ESXi 5.1.

      • September 24, 2012 at 2:10 am

        Mike that document is very inadequate and poorly written. I’ve been using that document and nowhere does it use the word “dataEncipherment”, yet looking at some of the VMware self-signed certs for 5.1 that key usage is clearly there.

        The default MS web server certificate template does NOT have “client authentication” enhanced key usage, yet the guide shows that extendedkeyusage attribute yet. Looking at the self-signed VMware certs I didn’t see any with enhanced key usage for client authentication, only server.

        There seems to be inconsistencies between the self-signed VMware cert key properties and the vSphere 5.1 certificate guide. Not to mention the guide suggest using the MS web server template, which doesn’t support client authentication usage.

        I’ll create a custom template in the MS CA for the extended attributes that I see in the self-signed certs, but aren’t at all mentioned in the VMware guide to see if that helps resolve some major cert problems with 5.1.

      • September 24, 2012 at 6:52 am

        Hi Derek,

        I agree there are some gaps. My plan is to use the same templates and key usage attributes as I did in 5.0. The template is based off the web server template but isn’t exactly the web server template as you would have needed to modify it to include the required attributes. Feel free to submit feedback directly to VMware – docfeedback at VMware dot com also. I haven’t looked at the default self-signed certs yet, so your feedback is valuable on that. Also if you think Windows is hard you should try the VCVA. I’m working with some guys on that right now and it is incredibly difficult and not at all well documented.

  1. February 10, 2012 at 10:42 am
  2. February 10, 2012 at 11:35 pm
  3. February 19, 2012 at 1:11 pm
  4. February 24, 2012 at 6:53 am
  5. March 6, 2012 at 9:21 pm

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: