Archive for the ‘SSL’ Category

Changing the IP of a vCenter Server 5.1 system – Part 1 – The easy way

April 13th, 2014 No comments

A couple of weeks back I had a post on changing the hostname of a vCenter server system. Today I am going to look how an IP change will go. The system is very small with a local database installed. VUM is also installed on the same machine. All web based services are working fine.


None of my certificates do actually include an IP address, forward and reverse DNS are setup correctly though and my domain controller is multi homed to keep the setup small.


The domain controller also has the “Routing and Remote Access” role installed and serves as the default router in the setup so I don’t need to do any changes to the connected host.


The last thing I checked was that this time we actually do have a hardware status on the virtual ESXi to compare if this is still the same afterwards.


Disclaimer: This is not a tested or officially approved procedure by VMware at any means, use at your own risks, don’t come to me complaining if everything breaks, DO A BACKUP! The proper way would be a reinstall of the binary packages against existing databases.

First step is actually stopping all services and changing the IP address of the vCenter server system. We are going from to This is followed by a reboot of the system. The first test we are going to do is a ping from the host which is successful (after turning off the blocking in the Windows Firewall). Even though the host does still have the old vCenter Server IP in the vpxa.cfg it won’t disconnect as we see later on.


The system boots up just fine like expected and Windows did accept the IP change without any further issues.

Capture6 Let’s check the services overview next to see if vCenter server was able to start successfully and we are actually looking pretty good there as well.


Logging into vCenter server the hardware status looks actually good as well but we can see the Update Manager tab is missing now.


So let’s see why the Update Manager plugin won’t connect anymore, which leads us to the vCenter Service Health status and gives us the clue that the addon actually registered with the IP address instead of the host name.


This is easily fixed though using the Update Manager Utility.


One service restart later we get the following picture which completes our little IP change procedure pretty successfully. And just to prove the point this time we have a look at the service status using the Web Client to demonstrate that it did not brake during the procedure as well.


This part was called “easy” because I did not introduce any dependencies on the IP in the certificates which I will do in a later post to see if the procedure is as smooth and easy as this one was.

Categories: SSL Tags:

Where is the keystore for domain controller certificates in Single Sign-On 5.1?

April 8th, 2014 No comments

A couple of weeks ago I got a request from one of our Technical Account Managers that I would have thought to be a rather quick question on how to look at the contents of a java key store.

I recommended Portecle (brilliant tool btw.) but was soon to learn that there was some follow up questions.

What the customer actually wanted to do is to have a peek at the key store of the domain controller certificates which were saved in SSO to remove PoC certificates and move to production.

So there were a couple of follow up questions involved:

1) Where is that key store actually saved on the file system?
2) Is there a direct relationship between the identity source and the SSL certificate?
3) How would we actually remove the certificates from the key store?

Turns out the answer did involve quite a bit of work.

First I tried to find the file on the system by simply starting Process Monitor (another rather awesome tool, go watch the “Case of the Unexplained” presentations of Mark Russinovich if you haven’t done so to see the tool in action) and setting several filters for default SSO directories and key store file extensions but turned out to be unsuccessful.

Only place left to look would therefore be the SSO database and as it turns out this is actually the place where these certificates are persisted after being uploaded via the Web Client or using the ssocli command line tool.

This leads us to question number 2, can we determine a direct relationship between the certificate and any identity source. Short answer is “no”. The longer answer leaves us looking at some SQL Server queries.

By simply browsing through all the tables of the SSO database one quickly jumps out as being called in an interesting way, namely “IMS_CERTIFICATES”.

Let’s take a look at the select statement output for that table.

NULL PRINCIPAL_CERT 608458820a00a8c063fe86669f076d35
NULL PRINCIPAL_CERT 7428b6120a00a8c02c3b39beb232ac4b
NULL PRINCIPAL_CERT 832b0ee20a00a8c0059824bccd1998c3
NULL PRINCIPAL_CERT c712638f0a00a8c030bc1236fa24da38

I have cut unimportant fields here that would contain additional data but not serve the purpose. I did add one single domain controller SSL certificate into the Web Client and we do have one entry with the purpose of “LDAP_TRUSTED_CERT” in our table. Interestingly enough we do not have a REF_ID entry in that row though. So it looks like we actually are not having any binding between a specific identity source and that certificate.

Trying to understand further if anything else was updated in the database I rolled back the backup I made before importing the cert and started again to get an exact timestamp. Afterwards I ran the following SQL query.

SELECT deqs.last_execution_time AS [Time], dest.TEXT AS [Query] FROM 
sys.dm_exec_query_stats AS deqs CROSS APPLY 
sys.dm_exec_sql_text(deqs.sql_handle) AS dest 
ORDER BY deqs.last_execution_time DESC

This gave the following output.

Time        Query
2014-04-08 12:39:47.240        (@P0 nvarchar(4000),@P1 int,@P2 nvarchar(4000),@P3 nvarchar(4000),@P4 nvarchar(4000),@P5 nvarchar(4000),@P6 nvarchar(4000),@P7 nvarchar(4000),@P8 datetime)INSERT INTO IMS_CERTIFICATES (ID, ROW_VERSION, NAME, DESCRIPTION, PURPOSE, DATA, REF_ID, LAST_UPDATED_BY, LAST_UPDATED_ON) VALUES ( @P0 , @P1 , @P2 , @P3 , @P4 , @P5 , @P6 , @P7 , @P8 )


So we can actually see that no other table was touched during the transaction and can confidently conclude that we do not have any identity source to certificate mapping within our SSO 5.1 instance.

As for the last question…

DisclaimerThis is not a tested or officially approved procedure by VMware at any means, use at your own risks, don’t come to me complaining if everything breaks, DO A BACKUP!

Well we do know the text that we need to look for within the purpose field of that table to get the proper rows, we then can filter by the date or try to unscramble the data encoding in which I will not go into any further for today. Deleting certificates is as easy as deleting the row but it is playing around with a backend database which could potentially break your most central vSphere component so it is not really recommended to do so.

Categories: SSL, SSO Tags:

Upgrading VC 4.x to 5.x while changing the hostname

March 22nd, 2014 No comments

Paul Meehan posted a question on twitter earlier this week.

While this was an upgrade from 4.x to 5.1 it would have been possible to simply go to 5.0 first with a new VM, use the migration tool and later change the IP address of that VM, but that would be boring, right?

Disclaimer: This is not a tested or officially approved procedure by VMware at any means, use at your own risks, don’t come to me complaining if everything breaks, DO A BACKUP!

So I quickly spun up a Windows Server 2008 R2 VM, installed vCenter Server 4.0 after quickly checking in the Solution Upgrade matrix that it is indeed supported to go directly from 4.0 U4 to 5.1U2.


So if we want to upgrade to 5.1 U2 now and change the host name there is a couple of issues using the VC default certificate.

1) Key length, the minimum requirement for vCenter 5.1 is 1024 bit with at least 2048 bit being the recommendation
2) The SAN field only has the old host name in there without an IP address, this certificate would not be valid for the new host system and could lead to many issues with the SSO integration

To move out of this situation you could blow away vCenter, create a certificate and prepopulate the install paths to reinstall against the existing database after a host name change, but I personally really dislike reinstalls, you only do them when you are out of options or an tight time constraints. Therefore the method I will follow here is a double certificate swap, rename of the system and then upgrade the system to vCenter 5.1U2.

As we are doing a double swap I did not care if the intermediate certificate that would be used for a couple of minutes was an CA signed or self signed certificate, I therefore simply created one using openssl (without Inventory Service this would mean on an external box as well).

I used the following openssl config:

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:, DNS:

[ req_distinguished_name ]
countryName = IE
stateOrProvinceName = Cork
localityName = Cork
0.organizationName =
organizationalUnitName = vCenterService
commonName =

This resulted in the following certificate.


I replaced the certificate following the official guidelines which is a walk in the park for vCenter Server 4.0. After that I renamed the system and performed a reboot to see if vCenter Server still was able to start with its new certificate which indeed was the case. The next step was to change the name in the vCenter Server settings.


A quick search through the registry for the old host name also did not yield any worrying results, so at this point in time I would consider the name change successful. DNS resolution was updated automatically due to my domain settings, depending on the situation this step would need to be done manually.

If you don’t care for the certificates to have additional information in them you could theoretically perform the upgrade to 5.1 U2 now and be done. For those out there actually having some sort of security guys chasing them with sticks if an old host name is still present in the SSL certificate we will go through the same document mentioned above once more and actually replace the certificates before upgrading to 5.1 U2 as it in fact is only a 2 step procedure in 4.0 but far more involved in 5.1.

To test the full impact I also added a host to this vCenter to see if hardware status, search and performance data was still working after the upgrade to 5.1.  As I did add the host after the name change in a real life scenario you might need to update the vpxa.cfg on the hosts to reflect the name change of your vCenter Server.

I noticed that a couple of things were broken on 4.0 since the name change, namely the Inventory Service and all web services relying on the Inventory Service. As we are blowing this instance away anyway during the upgrade process I decided to continue on, otherwise the best way to handle this situation probably would be the reinstall of the binaries to let the installer take care of all the tiny little details, I found at least one stale entry in the proxy.xml alone.

Log snippet from vws.log

[2014-03-22 10:00:22,442 Thread-43 ERROR ‘’] Error while trying to login to
at com.vmware.vim.common.ssl.AuthSSLProtocolSocketFactory.createSocket(
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(
at org.apache.commons.httpclient.HttpClient.executeMethod(
at org.apache.commons.httpclient.HttpClient.executeMethod(

So to recap we now have a vCenter 4.0 Update 4 on which we changed the name from to with a CA signed certificate issues to The Inventory Service and the Management Web Services seem to be broken after these changes and we will now have a look if the upgrade to vCenter Server 5.1U2 will fix the issue as the binaries and config files should be removed and readded by the installer.


I chose the simple install option as I did not see any additional benefit in going through each installer by myself since we are asked for the the FQDN of the system anyway and I was too lazy to type go through the wizard 3 times.


The upgrade to 5.1 took around as much time as all steps before combined … I then manually installed the Web Client and updated the Classic Client to have a closer look at the system status now. The first thing I always check is if we have a duplicate certificate in the lookupservice registration, easiest way to do that is by going into the vCenter Server SSL folder and look if a second certificate named sso is present, which is not the case, the installer successfully reused my already existing certificate without running into any issues.


The second step is to connect to the vCenter Server using the Classic Client and look if the vCenter Service Status, Hardware Status, Storage Views, Performance Charts and Search are working. This indicates that all tomcat based services are healthy and that the Inventory Service is working as expected. The last and final step is to connect with the Web Client and basically check if I can see an inventory with a user that does have vCenter permissions and if changes done in the Web Client are reflected in the Classic Client and vice versa. If these checks pass I generally deem the system healthy and so far no customer disagreed 🙂

In my installation this was working for the most part, but I would still get 2 alerts in the vCenter Service Status overview. The hardware status also would not display an error anymore but be completely empty.


Having a look again at the vCenter Server advanced settings quickly showed the issue related to the vCenter Service status. A quick look into the ADAM instance also confirmed the old entries in there.


Editing these settings a following a vCenter Server restart the situation changed.


The only thing left to do was getting the hardware status to work now. The cim-diag.log did not show any errors, so Host to VC communication does not seem to be the issue here. The CIM provider script on the host also did not show any issues, so this problem must lie between vCenter Server and the Inventory Service. I therefore registered vCenter Server with the Inventory Service. That did not help. I then decided to make a different test and added the host to a different vCenter Server to see if it got a hardware status there as well to rule anything wrong with the host itself as I know this vCenter is set up correctly and can display the hardware status of my physical lab hosts.

And sure I was chasing a ghost, the hardware status also did not work in the known good vCenter Server… guess that is one of the draw backs with old virtualized ESXi versions 🙂

Only step I would change after going through all of this would probably be to set the advanced settings before the upgrade to 5.1 as this might also repair the search etc. in 4.0 already.

Apart from every recommendation out there it seems that it is indeed possible to change the host name even though quite some work is needed. I started this procedure 4 hours ago, if I calculate the write up out the whole procedure probably took me around 2.5 – 3 hours.

Categories: SSL Tags:

Converting PKCS #12 files to be useful for the SSL Automation Tool

November 11th, 2013 No comments

Today I had a customer who had a rather unusual way (at least for me) to get his certificate from his CA.

They provided him with a PKCS #12 file instead of the usual PKCS #7 file and chain. And this would be the only way they could get the cert out of them.


So how would we get that format converted to the proper format used by the SSL Automation Tool?

OpenSSL actually does this with a one liner.

openssl pkcs12 -in rui.pfx -passin pass:testpassword -out chain.pem -nodes

This gives you one file containing the private key and PKCS #7 certificate chain. So all you need to do now is delete the additional attributes and cut and paste the key to a seperate file and you are good to go and replace your certificates with the SSL Automation Tool.


Categories: SSL Tags:

VCAP-CIA objective 5.1 – Manage vCloud Director SSL Certificates

August 1st, 2013 No comments

The blueprint states the following skills needed to cover this objective.

  • Create and process certificate requests
  • Replace default certificates

SSL certificates are an absolute requirement for vCloud Director to work. You will need 2 different certificates, one for the vCloud Director Web Interface and one for the Console Proxy. There are 2 options for SSL certificates, self-signed and CA signed. The process to create the certificate requests and generate the certificates is described in the vCloud Director Installation and Upgrade Guide on pages 17 – 20 in the English version. There is also the following kb article describing the process in detail.

Generating SSL certificates for VMware vCloud Director

To create untrusted self-signed certificates simply run the following 2 commands on the vCD cell.

keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey –keyalg RSA -alias http
keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -genkey –keyalg RSA -alias consoleproxy

This generates the certificates which are valid for 90 days by default (use the -validity parameter to set a different value).


You can list the contents of the keystore using the following command.

keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -list

You should expect to see both certificates in there.


To actually replace the certificates now you can follow the guidelines in the English version of the vCloud Director Administrator’s Guide on page 16. It is basically a 3 step process.

  1. Stop the vCD cell
  2. Run the configuration script again
  3. Provide the path to the new keystore file and passwords for the keystore and certificates


After a restart of the cell the new certificates should be loaded and accessible.


The process to create CA signed certificates is slightly different. Instead of creating the certificate itself we are going to use the key tool to create requests which have to be handed over to a CA which will provide back the actual certificate files. These will be imported to a keystore again like the self-signed certificates. The procedure to actually replace the certificates for the cell stays the same.

The requests can be creating by using the following 2 commands.

keytool -keystore certificates.ks -storetype JCEKS -storepass passwd –certreq -alias http -file http.csr
keytool -keystore certificates.ks -storetype JCEKS -storepass passwd -certreq –alias consoleproxy -file consoleproxy.csr

You will need an existing certificates.ks keystore with self-signed certificates for the consoleproxy and http interface in it for these commands to work.


Upload these files to your CA and request the certificates. You will need to get back the 2 requested certificates, the root certificate for the CA and any intermediate CA certs if they exist. These need to be imported into the keystore using the following commands.

keytool -storetype JCEKS -storepass passwd-keystore certificates.ks -import -alias root -file root.cer
(optional) keytool -storetype JCEKS -storepass passwd-keystore certificates.ks -import -alias intermediate -file intermediate.cer
keytool -storetype JCEKS -storepass passwd-keystore certificates.ks -import -alias http -file http.cer
keytool -storetype JCEKS -storepass passwd-keystore certificates.ks -import -alias consoleproxy -file consoleproxy.cer

When the complete chain is imported you should list the contents of the keystore to make sure everything is in there.

keytool -storetype JCEKS -storepass passwd -keystore certificates.ks -list


When everything is in place you can run the configure script as described above to actually replace the certificates. You should also import the root certificate into the trusted certificates store of the clients actually using vCloud Director to get rid of the security warnings.


Categories: Certification, SSL, VCAP Tags:

Setting up your own CA using openssl

June 30th, 2013 No comments

SSL certificates and the processes to actually create and implement them in a vSphere 5.1 environment are a fairly complex topic. In some environments the very specific requirements VMware puts on these certificates are not accepted by the in house CA. This post is going to review these requirements and will show how to create a CA for self signing certificate requests when using a corporate or public CA is not feasible using only the SSL automation tool without the need to setup an additional Microsoft CA.

This post is going to concentrate on the certificates used by the Windows version of vCenter 5.1 and all required components. The number of certificates to replace and services differ slightly on a vCenter Server appliance but the same process can be used to actually create these certificates.

Tools needed:

First of all let’s recap the requirements for the certificates (taken from

  • Have the subject alternative name field included in them
  • Have unique Subject Distinguished Name (DN) for the certificate. The SSL Certificate Automation tool uses OrganizationalUnitNames for the components to achieve this uniqueness.
  • Include digitalSignaturekeyEncipherment, and dataEncipherment components for Key Usage
  • Not mentioned in the kb but a logical consequence of the used fields the SSL certificates need to be x509.3

Extract the downloaded ZIP file to a folder which you will be using through this tutorial, I decided for C:\SSLAutomationTool1.0.1, open an elevated shell and navigate to the tools\openssl subfolder.


 Run the following command:

openssl req -newkey rsa:<keylength> -days <validity period> -x509 -nodes -out Root64.cer

For example:

openssl req -newkey rsa:4096 -days 3650 -x509 -nodes -out Root64.cer


Our root certificate to sign our requests is in place. Time to get the final configuration for the CA set up. Create the following in C:\SSLAutomationTool1.0.1\tools\openssl:

  • myca.conf
  • certindex
  • serialfile
  • a folder “tmp”


Next edit serialfile to contain “000a” (without the quotation marks). The file named certindex can remain empty and myca.conf will contain the openssl configuration for our CA:

[ ca ]
default_ca = myca

[ crl_ext ]
# issuerAltName=issuer:copy #this would copy the issuer name to altname authorityKeyIdentifier=keyid:always

[ myca ]
new_certs_dir = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\tmp
unique_subject = no
certificate = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\Root64.cer
database = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\certindex
private_key = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\privkey.pem
serial = C:\\SSLAutomationTool1.0.1\\tools\\openssl\\serialfile
default_days = 3650
default_md = sha1
policy = myca_policy
x509_extensions = myca_extensions

[ myca_policy ]
commonName = supplied
stateOrProvinceName = supplied
countryName = supplied
emailAddress = optional
organizationName = supplied
organizationalUnitName = supplied

[ myca_extensions ]
basicConstraints = CA:false
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
keyUsage = digitalSignature,keyEncipherment,dataEncipherment
extendedKeyUsage = serverAuth,clientAuth

Now our CA is completely set up and ready to sign. The next step is creating the certificate signing requests. To make life a little bit easier we can actually pre-populate some common information in the ssl-environment.bat located in C:\SSLAutomationTool1.0.1.

step4The creation of the signing requests is rather simple as can be seen in the following screenshot.

step5Before we actually sign the certificates we should double check that the requests actually do contain all the fields which are required. This can be achieved by running the following command.

openssl req -in <path to csr> -noout -text

For example:

 openssl req -in C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\rui.csr -noout -text


The signing is another simple command line.

openssl ca -batch -config myca.conf -notext -in <path to csr file> -out <destination path of crt file> -extensions v3_req -extfile <path to csr_openssl.cfg created by the automation tool>

For exmpale:

openssl ca -batch -config myca.conf -notext -in C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\rui.csr -out C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\rui.crt -extensions v3_req -extfile C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\csr_openssl.cfg

step7This should result in a certificate that fulfills all the requirements which can easily be verified by issuing the following command.

openssl x509 -in <path to crt> -noout -text

For example:

openssl x509 -in C:\SSLAutomationTool1.0.1\requests\vCenterServer-examplevc\rui.crt -noout -text


If your certificates do meet the requirements you are ready to follow the last part of KB 2044696 to actually get them into a format the tool can work with and replace them.

Generating certificates for use with the VMware SSL Certificate Automation Tool

A couple of things that you should double check before starting to replace the certificates for vCenter Server and all other components are:

  • Check C:\Programdata\VMware\VMware VirtualCenter\SSL, if you find sso.crt, sso.key and sso.pfx in that folder work through KB 2048202 (
  • Check C:\Programdata\VMware\VMware VirtualCenter\vpxd.cfg to contain a service ID and NOT(!) the string vCenterServer
  • Check for other known issues
  • Be sure to have a complete system backup including a backup of the vCenter database and SSO database
Categories: SSL Tags: