vCenter 5.1 U1 Installation: Part 3 (Install vCenter SSO SSL Certificate)

Welcome to Part 3 of the 15 part vCenter 5.1 installation series, installing vCenter SSO SSL Certificates. IMPORTANT: Now that VMware has released the vCenter Certificate Automation Tool, I suggest you skip installing trusted SSL certificates during the install process and use the tool to do them post install. It’s less error prone, and then you will know it is done correctly. The tool has a lot of known issues, so some of you may need to execute the steps manually. If you want to use this new VMware tool then skip this post and proceed directly to Part 4.

If for some reason you can’t or don’t wish to use the new VMware tool, you can follow this post to update the SSO SSL certificate. It’s tedious and somewhat painful, so I’d really recommend you consider using the tool. You can find the official VMware KB article which covers these steps here.

Before we get started, listed below are the other related articles in this series:

Part 1 (SSO Service)
Part 2 (Create vCenter SSL Certificates)
Part 4 (Install Inventory Service)
Part 5 (Install Inventory Service SSL Certificate)
Part 6 (Create vCenter and VUM Databases)
Part 7 (Install vCenter Server)
Part 8 (Install Web Client)
Part 9 (Optional SSO Configuration)
Part 10 (Create VUM DSN)
Part 11 (Install VUM)
Part 12 (VUM SSL Configuration)
Part 13 (VUM Configuration)
Part 14 (Web Client and Log Browser SSL)
Part 15 (ESXi Host SSL Certificate)

Manual SSO Certificate Replacement

During the execution of Part 2, a number of certificate files were generated. For a short refresher, here’s what we have so far:

chain.pem – Required for VMware automated certificate manager
root-trust.jks – Java keystore with root certificates
rui.crt – Minted PKCS#7 x.509 certificate from your trusted CA
rui.csr – Base-64 encoded certificate signing request (CSR)
rui.key – Private RSA 2048-bit key
rui.pfx – Password protected PKCS #12 certificate file, private key, and root CA certs
SSO.cfg – OpenSSL certificate request configuration file for the SSO service
server-identity.jks– Java keystore with root certificates

4-16-2013 8-47-50 PM

The directions for replacing the vCenter SSO SSL certificates assumes the SSO service is installed in the default directory. This process is a bit tedious and error prone, so I would strongly encourage your take a snapshot of your vCenter VM AND SQL database prior to starting these steps so you can easily revert back to a known clean state should you botch the replacement process.

vCenter SSO SSL Certificate Replacement Procedures

1. A directory is required to store all of the vcenter SSO certificate files. The directory can be anywhere, but the vCenter service accounts needs full access. Do not use a directory path with spaces. I would suggest using:

c:\ProgramData\VMware\SingleSignOn\SSL

If you used my pre-staging script, it already has created this directory and copied the required files. If you didn’t use my pre-staging script, from the D:\certs\SSO directory copy: rui.crt, rui.key, rui.pfx, root-trust.jks, and server-identity.jks into this directory. From the D:\certs directory copy root64.cer into the same SSL directory.

Your directory should now look like the following screenshot:

2. To reconfigure the vCenter SSO SSL certificates we first must list the service records for the Group Check, SSO and Security Token Services. Open an elevated command prompt and type the following commands.

SET JAVA_HOME=C:\Program Files\VMware\Infrastructure\jre

cd /d C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli

ssolscli.cmd listServices https://Server.FQDN:7444/lookupservice/sdk

At this point you should see a lot of output on the screen and three “Service” sections with a bunch of details. Be sure to use the FQDN of the server, or the command may fail.

3. Use Notepad to create three separate text files, one for each of the services (STS, group check, SSO). I created three text files (sts.properties, gc.properties, admin.properties) in D:\Certs. The content of each file is shown below. Of course change your uri hostname to that of your SSO server, and the ssl variable to the proper path of the root certificate.

The “protocol” field is extremely critical and NOT the same for all three services. Using “wsTrust” for all three result in a smoking hole and a dead SSO server.

sts.properties


[service]
friendlyName=STS for Single Sign On
version=1.0
ownerId=
type=urn:sso:sts
description=The Security Token Service of the Single Sign On server.

[endpoint0]
uri=https://SSOServer.Domain:7444/ims/STSService
ssl=c:\ProgramData\VMware\SingleSignOn\SSL\Root64.cer
protocol=wsTrust

gc.properties


[service]
 friendlyName=The group check interface of the SSO server
 version=1.0
 ownerId=
 type=urn:sso:groupcheck
 description=The group check interface of the SSO server

[endpoint0]
 uri=https://SSOServer.Domain:7444/sso-adminserver/sdk
 ssl=c:\ProgramData\VMware\SingleSignOn\SSL\Root64.cer
 protocol=vmomi

admin.properties


[service]
 friendlyName=The administrative interface of the SSO server
 version=1.0
 ownerId=
 type=urn:sso:admin
 description=The administrative interface of the SSO server

[endpoint0]
 uri=https://SSOServer.Domain:7444/sso-adminserver/sdk
 ssl=c:\ProgramData\VMware\SingleSignOn\SSL\Root64.cer
 protocol=vmomi

3. Create three more text files (sts_id, gc_id, admin_id) in the D:\Certs directory. This time we need to put the unique serviceID shown in step 2 (which will NOT be the same for your install, so don’t blindly use my IDs below). Do not enter any additional information to the contents of the file.

4. As a check point in our configuration process, you should now have the following files in your Certs directory. I would also strongly suggest taking another snapshot of your SSO VM at this point, in case the certificate replacement process goes south and you need to recover to a known state. Certificate information is also stored in the SSO SQL database, so I would urge that you use SQL Studio to do a SSO database backup as well.

5. Stop the vCenter Single Sign On service via the Windows Server Manger.

6. Navigate to: C:\Program Files\VMware\Infrastructure\SSOServer\security and backup the root-trust.jks and server-identity.jks files. Replace these files with your versions (from D:\Certs\SSO).

7. Open an elevated command prompt and type the following commands. When prompted for the master password, enter the SSO password you entered during the SSO installation process.


SET JAVA_HOME=C:\Program Files\VMware\Infrastructure\jre

cd /d C:\Program Files\VMware\Infrastructure\SSOServer\utils

ssocli configure-riat -a configure-ssl --keystore-file C:\ProgramData\VMware\SingleSignOn\SSL\root-trust.jks --keystore-password testpassword

8. Re-start the vCenter Single Sign On service and wait a couple of minutes.

9. Open a web browser and open:

https://SSOserver.FQDN:7444/sso-adminserver/sdk

View the vCenter SSO SSL certificate and validate that it’s your trusted certificate, not the VMware self-signed certificate.

10. To bind the trusted SSL certificate to each of the three services issue the commands below in the same command prompt Window as above. Note that “updateService” is CASE SENSITIVE.

cd /d C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli

ssolscli.cmd updateService -d https://SSOServer.Domain:7444/lookupservice/sdk -u admin@System-Domain -p YourPassword -si D:\certs\sts_id -ip D:\certs\sts.properties

If the command is successful you will see the following. Repeat the process for the remaining two services.

ssolscli.cmd updateService -d https://SSOServer.Domain:7444/lookupservice/sdk -u admin@System-Domain -p YourPassword -si D:\certs\gc_id -ip D:\certs\gc.properties

ssolscli.cmd updateService -d https://SSOServer.Domain:7444/lookupservice/sdk -u admin@System-Domain -p YourPassword -si D:\certs\admin_id -ip D:\certs\admin.properties

11. If you are lucky at this point you have successful return codes for all three commands. However, you may not be out of the woods. Restart the vCenter Single Sign on service and wait a couple of minutes. Re-run step two to list all three services and verify everything is successful.

If you get errors such as “Return Code is: OperationFailed”, then Houston, we have a problem. If you see “unable to connect to server” errors while trying to list the services, wait a few minutes and try again.
Update Trusted Certificate Store

Note: You must pay close attention to the version of OpenSSL you are using, or you could end up with the wrong hashes. OpenSSL 1.x has a different default hashing algorithm than the 0.9.8 tree. I show both command lines below, which in my experience, produce the same hashes. I’ve tried 0.9.8y, 1.0.1c and 1.0.1e all with the same hashing results, assuming you use the proper switches. For compatibility with the vCenter Certificate Automation tool you should only use OpenSSL 0.9.8.

1. In Windows Explorer navigate to C:\ProgramData\VMware and see if you have a SSL directory. If not, create one (all CAPS).

2. Copy your Root64.cer file into C:\ProgramData\VMware\SSL and rename it ca_certificates.crt. If you have intermediary CAs, the ca_certificates.crt file should have all CA certificates appended to it. This should already be the case if you followed Part 2 of my guide, under the Download Root Certificates section. Double check the ca_certificates file ends in “crt” NOT “cer”.

3. Compute the hash of your Root64.cer file if you have a single CA hierarchy. If you have intermediary CAs, compute the hash of your Root64-1.cer (root CA) in this step. To do this with OpenSSL 1.0.0 and later use the following command:

c:\OpenSSL-Win32\bin\openssl x509 -subject_hash_old -noout -in D:\certs\Root64.cer

If you are using an OpenSSL version prior to 1.0.0, such as 0.9.8 use this command:

c:\OpenSSL-Win32\bin\openssl x509 -subject_hash -noout -in D:\certs\Root64.cer

4. If you have a single CA (no intermediary) copy your Root64.cer file into the SSL directory and rename it using the hash value from the previous step, and change the file extension to 0 (zero). For example, I would copy D:\certs\root64.cer to the SSL folder in step 2, and rename it to 97527d09.0.

If you have intermediary CAs, then copy the Root64-1.cer (your root cert only) file into the SSL folder and rename it using the same methodology. You also need to compute the hash for any intermediary CAs (e.g. Root64-2.cer) and copy those files into the SSL directory and rename them.

In short, each hash file should have only the contents of a single CA certificate. They cannot be appended like they are in the ca_certificates.crt file. Do not create a hash file for your concatenated Root64.cer file, when you have intermediary CAs.

Next up is part 4, Installing the vCenter Inventory Service.

Print Friendly, PDF & Email

Related Posts

Subscribe
Notify of
68 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
September 18, 2012 9:27 am

Derek,
completed part 7 go back to 2 this is the error message i got! can you tell me why?

C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli>ssolscli.cmd listServices https://3vmssosac.cuiab.local:7444/lookupservice/sdk
Intializing registration provider…

Getting SSL certificates for https://3vmssosac.cuiab.local:7444/lookupservice/sdk

com.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate assertion not verified and thumbprint not matched
com.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate assertion not verified and thumbprint not matched
Return code is: OperationFailed
100

Anonymous
October 3, 2012 8:35 am
Reply to  long_lanh

If your SSO server is NOT the same as your vCenter Server. I.e. all services are NOT running on the same box, you will need to go back to step 2 and fix the OpenSSL CSR requests to reference the correct FQDNs for each of the servers that the services run on. In my case, SSO is on VM02, while vCenter, Inventory, and WebClient server were all on VM01.
I had accidentally NOT fixed the CSR request to reference VM02 for the SSO certificate, and the certificate was cut for VM01, which caused this error.
Check that.

October 13, 2012 12:11 pm
Reply to  long_lanh

Same issue, running the command in step 2 from the SSO with same results:
Server certificate assertion not verified and thumbprint not matched

Anonymous
November 13, 2012 9:09 am
Reply to  long_lanh

taken from vmware kb
Note: Be sure to use the Fully Qualified Domain Name (FQDN) for the Lookup Service URL or the command will fail.

i used my FQDN and it worked 🙂

February 8, 2013 1:40 pm
Reply to  long_lanh

I figured this out. Turns out I had installed the SSO server with a different FQDN because I originally wanted to use our public wildcard cert. SSO was registered as ssoserver.company.com. The way I fixed it was to open the RSA database and change ALL occurrences of ssserver.company.com to the FQDN used in the certs that I generated from our MS CA server. Here are the tables with records I had to modify: IMS_CONFIG_VALUEIMS_INSTANCE_NODEIMS_SCHEDULE_JOBIMS_STS_CONFIGLS_SERVICE_ENDPOINT I should note that I did NOT restart the SSO service after making the updates, I was afraid the service would fail to startup and the… Read more »

Anonymous
September 18, 2012 1:41 pm

I had step 10 come back as OperationFailed after connection time outs. Checked and saw the tomcat process using a good amount of cpu. I waited for it to calm down, and reran the command and it worked that time.

September 18, 2012 7:55 pm

Hi Derek,

According to the Vmware guide I read that hash files need to be the actual rui.crt files renamed not a blank text file.

Terafirm: Yes you are right! Too late and a bit too frustrated….updated the instructions.

September 18, 2012 8:40 pm

Yep I understand this has been a full 6 days for me to get it all working.

first time round was actually the problem with host password encryption keys not being 2048 bit worked with Vmware on that one that was the first 2 days. SSL the rest and the documentation was not writen well at all and missing allot of things as I am sure you know.

KB if anyone needs it (vCenter service stays on starting) http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2035623

Charlie
September 20, 2012 9:16 am

Hi Derek,

Regarding Steps 13-14 of Part 3. The Replacing Default vCenter 5.1 and ESXi
Certificates Guide (pg. 17) mentions a different process for this step. Do you happen to know which step is correct, or can you provide information where you found your section?

Charlie,

Page 17 of the VMware certificate guide shows how to update the trust store, which are the procedures I outlined above.

Charlie, make sure that you are running the command in an elevated prompt. I haven’t see any other reports of access denied errors.

Charlie
September 21, 2012 6:39 am

I did. I ran it as domain admin, local admin and even admin@System-Domain all with the the same Access Denied error message.

Chris
September 24, 2012 3:57 am
Reply to  Charlie

I have tried twice and get: Return code is: OperationFailed100 each time I try and list the services. This happens after Step 9 for me. I am able to still list after Step 7. I have checked my .properties files and sts protocol is wsTrust and both gc and admin are vmomi. I noticed ownerID is blank in your examples, is that correct? Also when I try to navigate to sso-adminserver/sdk to see that it is using my cert I get an error: “ServerFaultCodeUnexpected EOF in prolog at [row,col {unknown-source}]: [1,0]”. It was however, using my new cert and I… Read more »

Simon
September 26, 2012 2:44 am
Reply to  Charlie

Hi Derek and thank you very much for this article.I think the whole process is way too complicated and should be made easier by VMware. I’ve done everything like in this article, but after trying to log onto the vsphere web-client I am running into the issue that right after entering my credentials the following message is being displayed: “Failed to connect to VMware Lookup Service https://server.domain.com:7444/lookupservice/sdk – SSL certificate verification failed.”. I have checked the URL in the browser and it is showing the correct certificate information (the one I signed myself). Have you got any idea what I… Read more »

September 26, 2012 11:11 am
Reply to  Charlie

I personally haven’t see any SSL problems with the Lookup service. Far different story for the inventory service. Did you use the certificate pre-population method with the Inventory service? Did your SSO SSL replacement seem to go OK (you can list the services after the cert replacement)?

Simon
September 26, 2012 11:42 am
Reply to  Charlie

Yep, everything went fine. I can list the Services, however there are more than 3 since I installed all components before replacing all the certificates. Is it necessary to build a unique certificate for every service or is one enough if all components are installed on the same machine?

September 26, 2012 12:44 pm
Reply to  Charlie

Simon, empirical evidence suggests that every service needs a unique certificate (except log browser), even if installed on one machine. I have an open support ticket with VMware to confirm/deny.

Anonymous
September 26, 2012 7:34 pm

Hi Derek,I’m having problem with step 9 with binding the trusted certs to the 3 services. Even though I’m able to hit the URL using browser (with cert warnings), I keep getting this below error message. Any idea?Error communicating to the remote server https://:7444/ims/STSService?wsdlReturn code is: ServiceNotResponding2Thanks,Cheikh

Ken
April 23, 2013 2:24 pm
Reply to  Anonymous

Cheikh,

Did you ever find a resolution to this problem? I am encountering the same thing, with multiple re-installs of SSO.

Cheikh, I’ve only seen that issue when I rebooted the vCenter server or restarted the VMware services and I didn’t give them time to fully restart. I waited a couple of minutes then all was well. Probably not the case with you….so don’t have any answers to offer.

Anonymous
November 20, 2012 11:20 am

Derek: First, THANK you for your posts. Unfortunately, I am receiving the exact same error as Cheikh. No issues until step 9. Since this was originally posted over a month ago, is there a solution to this issue?
Many thanks,
Helen

Anonymous
January 15, 2013 9:18 am

Same here, installed 5.1 successfully before but now completely stuck at this point (different system).

Started over clean again but nothing helps.

Any clues on what might be the problem?

Anonymous
September 28, 2012 8:48 am

Quick one, should “https://ServerFQDN:7444/sso-adminserver/sdk” actually load a page or is an XML error correct? Have just tried this on a fresh install as well. Both give:

Unexpected EOF in prolog at [row,col {unknown-source}]: [1,0]

Cheers!

Jimbo

Reply to  Anonymous

Jimbo, accessing those URLs from a browser does produce an error with the service since it is expecting input data that we are not providing. Browsing to the URL confirms a couple of things 1) You can validate which SSL cert it is using and 2) Confirm the service responds, even if it is with an error about EOF.

Anonymous
September 28, 2012 7:02 pm
Reply to  Anonymous

Thanks Derek, it was a red herring. My overall issue is that the third party certs don’t use the conf files details for OU. Instead ( as per the post below ) you get the domain control validated OU ( which makes some sense as that’s the level of validation that the SSL is.

So i can get as far as installing vCenter, then the SSL being the same error pops up despite SSL’s having different thumbprints/serials etc.

Jimbo

Reply to  Anonymous

Jimbo, yes according to research by Terafirma what VMware stores in the SQL database as the primary key for the certificate is the OU value, not the hash, thumbprint, etc. So the issue you are running into is not unexpected given the experiences of others.

Anonymous
September 28, 2012 9:44 am

When using third party certs, it seems the subject field contains the OU as “domain control validated” rather than say “inventoryservice” as per your screenshot, is that likely to be an issue?

Jim

Reply to  Anonymous

Jim, my understanding (not yet confirmed by VMware) is that the only requirement is the OU field be unique to each cert but the text string is not important. If all of your certs have that same text string for the OU field, then you may run into issue. I’m still waiting on VMware to explicitly state what the certificate requirements are, including the OU field.

September 28, 2012 2:09 pm

This is unbelievable. I thought the evolution of software things were suppose to get more efficient. I needed to change my SSO install to support a multisite install. Originally I went with a single install option and could not figure out how to switch the original SSO install over to support a multisite install. So I uninstalled SSO and reinstalled SSO. I’ve been in the tank ever since with the error at the top of your outstanding post. I can’t believe VMware has made it this difficult.

September 29, 2012 4:16 pm

I’m trying to get this working on a vCenter appliance, behind a load-balancer. Anyone know what the default ‘master’ password is? I’ve tried the default root password, but that’s not it. Which is doubly annoying, because this VMware KB indicates that the master password is the root password. http://kb.vmware.com/kb/2034608.

Mark
September 30, 2012 11:34 am

Hi Derek,

I successfully got all the way through to step 9, but the updateService command kept failing with “Return code is: InvalidInput. Put simply, it was ignoring the -si and -ip fields.

I finally figured out it was because the password had a quote (“) at the end and was cutting everything off.

I reset the password using the rsautil reset-admin-password tool and then re-ran it – success!

Anonymous
October 3, 2012 7:21 am

I’ve created a batch file which can do this. Check out the below URL…

http://communities.vmware.com/docs/DOC-20575

October 3, 2012 8:44 am

Everything went smoothly for me, but I’m getting the “ServerFaultCodeUnexpected EOF in prolog at [row,col {unknown-source}]: [1,0]” error when browsing to the sso-adminserver/sdk URL. I was even able to install the inventory service without any errors, even with this issue… but now I’m getting the same error when browsing to the lookupservice/sdk URL as well. Has anyone else run into this? I should mention that I started out with a fully functional vCenter 5.1 install using a separate SQL 2008 R2 backend. I uninstalled everything other than SSO and started with Step 2 (having followed your SSO guide to get… Read more »

Anonymous
October 7, 2012 7:55 am

ok Derek,
after blow the db and revert the snapshot install good and reboot the sso i got the error:
Unable to connect to server
Unable to connect to server
Return code is: OperationFailed
100
but when i access the web http://server:7444 it working fine without asking the ssl thing what going on here? please advice thanks

Reply to  Anonymous

Anonymous, it sounds like to me that possibly your properties file was incorrect, so the services are dead. To automate the SSL process, a reader provided this link to a script that worked great for me:

http://communities.vmware.com/docs/DOC-20575

Anonymous
October 7, 2012 8:01 am

Derek,
thanks for the update! after re-read your post create the folder add cert in that folder and no more error. but one thing is event run step 2 it give the error the on the web page it still work!….Thanks for your hard work.

October 29, 2012 3:44 pm

I’m currently getting

Cannot authenticate user
Return code is: InvalidCredentials
3

whenever I try to invoke updateService. The configure-ssl command executes without a problem and the new SSL certificates are indeed being used (verified via browser). I’ve obviously double checked the password as its the same one that has to be used to run configure-ssl.

Any ideas?

October 30, 2012 8:43 am

Derek:

I cannot emphasize how much I appreciate you making this resource available.

As in FYI, an error seems to have crept into the latest revision of this page. When you switched the storage location of your SSL certificate files to “c:\programdata\VMware\singleSignOn\SSL”, the trailing “rui.crt” was removed from the “ssl=” path in your sample “.properties” files. Running ssoslci to re-register the SSO components without naming a cert will result in an “Access Denied” error in step 9.

November 9, 2012 9:54 am

The 5.1 upgrade documents and KBs are light. Problem: The process to import vCenter SSO multisite replication data fails. I have 3 SSO servers in multisite mode. I made a change to 1, exported the data, and tried to import the data on the other 2 servers. Unfortunately, the import process failed on both. This is what I got: C:\Program Files\VMware\Infrastructure\SSOServer\sso-replication-cli>call repl_tool.cmd import -fssoexport.db -uadmin@System-Domain –p**********Start executing full data importBugPress any key to continue . . . The word “bug” showed up, but I verified that the SSO service is running. I have a support case open with VMware, but… Read more »

Anonymous
November 19, 2012 2:34 pm
Reply to  Todd

Todd,

Our SSO DB import fails too. I have a VMware case open. They say it’s a known bug. I do get feedback every day or so, but no workaround or fix yet.

Anonymous
November 12, 2012 7:10 pm

Hi Derek, I encounter this error.

Unexpected status code: 404
Unexpected status code: 404
Return code is: OperationFailed
100

November 21, 2012 3:18 am

Hi Derek,When I try to bind the trusted SSL certificate to each of the three services in step 8 I get some java errors Intializing registration provider…Getting SSL certificates for https://ssoserver.domain:7444/lookupservice/sdkGetting SSL certificates for https://ssoserver.domain:7444/sso-adminserver/sdk com.vmware.vim.binding.vmodl.fault.InvalidArgument:invalidProperty = No enum const class com.vmware.vim.lookup.EndpointProtocol.wsTrusinherited from com.vmware.vim.binding.vmodl.fault.InvalidArgument at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at com.vmware.vim.vmomi.core.types.impl.ComplexTypeImpl.newInstance(ComplexTypeImpl.java:171) at com.vmware.vim.vmomi.core.types.impl.DefaultDataObjectFactory.newDataObject(DefaultDataObjectFactory.java:26) at com.vmware.vim.vmomi.core.soap.impl.unmarshaller.ComplexStackContext.(ComplexStackContext.java:33) at com.vmware.vim.vmomi.core.soap.impl.unmarshaller.UnmarshallerImpl$UnmarshallSoapFaultContext.parse(UnmarshallerImpl.java:135) at com.vmware.vim.vmomi.core.soap.impl.unmarshaller.UnmarshallerImpl$UnmarshallSoapFaultContext.unmarshall(UnmarshallerImpl.java:98) at com.vmware.vim.vmomi.core.soap.impl.unmarshaller.UnmarshallerImpl.unmarshalSoapFault(UnmarshallerImpl.java:84) at com.vmware.vim.vmomi.client.common.impl.SoapFaultStackContext.setValue(SoapFaultStackContext.java:37) at com.vmware.vim.vmomi.client.common.impl.ResponseUnmarshaller.unmarshal(ResponseUnmarshaller.java:97) at com.vmware.vim.vmomi.client.common.impl.ResponseImpl.unmarshalResponse(ResponseImpl.java:245) at com.vmware.vim.vmomi.client.common.impl.ResponseImpl.setResponse(ResponseImpl.java:203) at com.vmware.vim.vmomi.client.http.impl.HttpExchange.run(HttpExchange.java:126) at com.vmware.vim.vmomi.client.http.impl.HttpProtocolBindingImpl.send(HttpProtocolBindingImpl.java:98) at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl$CallExecutor.sendCall(MethodInvocationHandlerImpl.java:526) at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl$CallExecutor.executeCall(MethodInvocationHandlerImpl.java:507) at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.completeCall(MethodInvocationHandlerImpl.java:295) at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.invokeOperation(MethodInvocationHandlerImpl.java:265) at com.vmware.vim.vmomi.client.common.impl.MethodInvocationHandlerImpl.invoke(MethodInvocationHandlerImpl.java:169) at $Proxy23.updateService(Unknown Source) at com.vmware.vim.install.cli.commands.UpdateServiceCommand.execute(UpdateServiceCommand.java:48) at com.vmware.vim.install.cli.RegTool.execute(RegTool.java:171) at com.vmware.vim.install.cli.RegTool.process(RegTool.java:131)… Read more »

November 23, 2012 11:39 am

Hi,Derek. In step 1, “ssolscli.cmd listServices” shows the URL of the STS service as:url=https://vCenter.domain.com:7444/ims/STSService?wsdl,protocol=wsTrust In step 2, it is configured as:uri=https://SSOServer.Domain:7444/ims/STSServiceprotocol=wsTrustin other words, without the “?wsdl” at the end of the uri. Carrying out all of the instructions and rerunning “ssolscli.cmd listServices” shows the URL of the STS service as:url=https://vCenter.countryday.net:7444/ims/STSService,protocol=wsTrustagain missing “?wsdl” at the end, and as expected from the properties file. My sense is that the uri in step 2 should be corrected unless you are aware of a specific reason why the uri should be changed from the original. http://kb.vmware.com/kb/2035011 has the same inconsistency. What is your opinion?… Read more »

Anonymous
December 2, 2012 2:10 pm

Hi Derek. Thx for this create article.
By my last step 8 to update each Service i got the Error

com.vmware.vim.vmomi.core.exception.MarshallException: LookupService required property version not set
Return code is: VmomiError
18

Solution: i checked the sts.properties file – in my case it was a missing “[” in “[service]” in the first line.

Hope that it helps someone.

Reinhard

December 17, 2012 2:18 pm

Hi, I took over a cumbersome installation of an existing 5.1.0 .The vSphere Web Client was not installed. I upgraded SSO (didn’t ask for a password, upgraded vCenter, Inventory etc. All works fine, until now I’m trying to install the web vsphere client and of course it ask me a password. Default user should be the one admin@Default-Domain. Every known password in the company fails to autheniticate. I ran the ssolsclie listServices https://ipadress:7444/lookupservices/sdk and got 4 services without any problemEvery rsautil I try it asks me of course for a master password, which I don’t have.Any idea how to get… Read more »

December 17, 2012 2:27 pm

Hi everybody. I got into an install from somebody else, and want to clean up his mess. Base install 5.1.0 with all features installed, except the web-client. I upgraded everything “by the book” with fine results, until I got to the web-client install which asks me for the master password. According to ancient logfiles, the user should be admin@Default-Domain. Got successfull logs in installing/upgrading SSO, Inventory, vCenter and the client, until I reach the install of the web-client.Every rsautil I try to use, give me a request for the master password, which I don’t have. Any idea how to get… Read more »

Anonymous
January 21, 2013 11:52 am

Solved! Made a stupid error by using the DNS server instead of the SSO server FQDN at DNS in the .cfg files!

Wasim Shaikh
February 5, 2013 3:55 am

Hi Derek, Your articles were really helpful. Thanks for putting it together. I am trying to figure out how to configure HA (19 Attempts till now)I am using Stingray Traffic manager.Also referring KB2033588. In Lab 1st I Installed Node1(SSO-A), replaced ssolscli.jar, installed Node2(SSO-B) as secondary node. made changes to server.xml on both Nodes. I did configure StingrayTM (virtual appliance) Virtual Server with a SSL.Set VirtualServer to decrypt the traffic, then apply rules to Map traffic appropriately according to KB2033588. The services got updated. Issue: After updating services on SSO-B SSOlscli listServices in giving error when trying to communicate on https://ssoha.vhomelab.com:7444/sso-adminserverfrom… Read more »

Anonymous
February 14, 2013 7:28 am

I got
Unable to connect to server
Unable to connect to server
Return code is: OperationFailed
100

Previous posts said there is something wrong with the .properties files. I looked through them. They looked ok, but I found one space ” ” at the end of the ssl= line. I removed the space, saved the files and updated the services again. Success!

Nile
February 17, 2013 1:40 pm

Hi All,thanks Derek for your blog. Installation worked well until Step 10, where I get C:\Program Files\VMware\Infrastructure\SSOServer\ssolscli>ssolscli.cmd updateService -d https://Server1.Domain.local:7444/lookupservice/sdk -u admin@System-Domain -p Password.01 -si C:\certs\sts_id -ip C:\certs\sts.propertiesIntializing registration provider…Getting SSL certificates for https://Server1.Domain.local:7444/lookupservice/sdkcom.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate assertion not verified and thumbprint not matchedReturn code is: SslHandshakeFailed1 Also the VMWare Client and Web Client cannot connect to the Server any more. Also with an SSL Error. In my Install.log file from SSO first line is:2013-02-10 21:58:01,331 – Server1.Domain.Local,,,,WARNING: Reverse DNS lookup of IP Address ‘169.254.66.110’ failed. The server SSL certificate will contain this IP address in the Subject Alternative Name extension… Read more »

Nile
February 18, 2013 11:42 am
Reply to  Nile

Hello Derek,
thanks for your fast reply. I am not sure, if the IP Address really is my problem. I found something else: when I run the keytool.exe to list the Content of my root-trust.jks keystore I get the following Java IOExeptions on the objects of the RUI Certificate:

#5: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false
Unparseable AuthorityInfoAccess extension due to
java.io.IOException: invalid URI name:ldap:///CN=VESDomain-VES-ADCERTAUTH-CA,CN=
AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=VESDomain,DC=Local?cA
Certificate?base?objectClass=certificationAuthority

And also:

#6: ObjectId: 2.5.29.31 Criticality=false
Unparseable CRLDistributionPoints extension due to
java.io.IOException: invalid URI name:ldap:///CN=VESDomain-VES-ADCERTAUTH-CA,CN=
VES-ADCertAuth,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=VES
Domain,DC=Local?certificateRevocationList?base?objectClass=cRLDistributionPoint

Could this be the reason for my Problems? I run Windows Server 2012 Domain and AD CA.

Thanks Nile

Nile
February 18, 2013 2:49 pm
Reply to  Nile

Hello Derek,
I found a typo in the FQDN-Server Name in my initial cfg-Files. Therefore everything was wrong. Now it is working.
Thanks again for your Support, and for your work on this great blog.
Greetings
Nile

Reply to  Nile

@Nile: Wish you luck with the install!

Anonymous
March 27, 2013 8:44 am

I noticed that I am unable to https://FQDN:7444/sso-adminserver/sdk but I can https://localhost:7444/sso-adminserver/sdk. Even when I roll back my snapshot to start again it only works with localhost. I should also mention I have a seperate SSO and vCenter servers. Is this going to be a problem when I actually get the right Cert (another problem I had which is why I rolled back).

dick
June 23, 2013 3:52 pm

the vmware software setups are suck horseshit nowadays … what a pain … bring back microsoft!! and dump sso sts n certs omg!!

Saket Gaikwa
January 28, 2014 6:27 am

My vCenter server restarted and I am unable to connect it now, getting error as 'Cannot connect to vCenter Single Sign On server – https://vcenter.xyz.com:7444/ims/STSService?wsdl….

September 8, 2017 12:28 am

Surprising. I would hazard to guess that given the reputation of the 5.1 vcenter appliance, the difficulty of managing, the difficulty of managing 4.1 certificates, the most common deployment model is this exact scenario [default certs on a 5.1 Windows vCenter Server]. Makes me wonder what the QA matrix looks like and how its executed.