VMware Cloud Community
chjones
Enthusiast
Enthusiast
Jump to solution

Unable to register vSphere Web Client after SSL Certifcate Replacement

Hi all,

I have been following Derek Seaman's Blogs on replacing all certificates in vSphere 5.1 and have since turned to the VMware KB Articles. I have replaced the certificates for SSO, Inventory Service and vCenter Server with no problems (other than having to use OpenSSL-Win64 for the vCenter Certificate as I just couldnt get the x86 version's certificate to work, makes no sense, but I'll take the small win).

When following the vmware guide to replace the web service certificate, http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&e..., I get to step 12, Register the VMware vSphere Web Client back to vCenter Single Sign On, and receive the following error:

##########################

D:\Program Files\VMware\Infrastructure\vSphereWebClient\SsoRegTool>regTool.cmd registerService --cert "C:\ProgramData\VMware\vSphere Web Client\ssl" --ls-url https://(Server URL):7444/lookupservice/sdk --username admin@system-domain --password (password) --dir "D:\Program Files\VMware\Infrastructure\vSphereWebClient\SsoRegTool\sso_conf" --ip "*.*" --serviceId-file "D:\Program Files\VMware\Infrastructure\vSphereWebClient\serviceId"

No properties files found
Intializing registration provider...
Getting SSL certificates for https://vsphere.au.ray.com:7444/lookupservice/sdk
Getting SSL certificates for https://vsphere.au.ray.com:7444/sso-adminserver/sdk
Unhandled exception tries to escape: null
Return code is: OperationFailed
100

##########################

VMware Tech Support suggested I uninstall all components, delete all databases and try again. I have done this and have the exact same result.

Has anyone seen this or been able to resolve it?

Chris

0 Kudos
1 Solution

Accepted Solutions
chjones
Enthusiast
Enthusiast
Jump to solution

So I managed to resolve this issue. Not sure this applies to everyone, but my issue was caused by registering using one of the Subject Alternate Names in the SSL Certificate for SSO rather than the common name of the certificate.

For example, the server name is server1.company.com. That was the common name of the certificate. But one of the SAN's of the certificate was "vSphere.company.com".  If I used that alternate name in any of the component registrations they would fail. I found I must use the common name. Even though the alternate names work for accessing via your web browser, there are no certificate warnings, if registering components using those names it would fail.

It seems crazy that you can't use any of the SANs ... so why allow us to have them?

I initially tried to replace the SSO Certificate where the common name was vsphere.company.com rather than the hostname of the server, and that installed. However, trying to install the Web Client would fail. When you get to the step where you have to accept the SSO Certificate, the installation would fail because the common name of the certificate did not match the hostname of the SSO server. This just seems crazy to me ... why the hostname of the server running SSO should even come into it when all calls are via HTTPS is just absurd!

I validated this with VMware Tech Support and they verified my findings.

View solution in original post

0 Kudos
4 Replies
johndball
Contributor
Contributor
Jump to solution

I've got the same problem. Working well up until now. Any luck in resolving it?

Update: I retyped the command and it worked. I copied/pasted my original and retyped commands into a notepad doc. They are exactly the same. Maybe I was running the command too soon after I restarted the service?

More tech ramblings: http://www.johndball.com
0 Kudos
aakalan
Enthusiast
Enthusiast
Jump to solution

return code 100 says; wrong input. your have wrong command.

0 Kudos
chjones
Enthusiast
Enthusiast
Jump to solution

So I managed to resolve this issue. Not sure this applies to everyone, but my issue was caused by registering using one of the Subject Alternate Names in the SSL Certificate for SSO rather than the common name of the certificate.

For example, the server name is server1.company.com. That was the common name of the certificate. But one of the SAN's of the certificate was "vSphere.company.com".  If I used that alternate name in any of the component registrations they would fail. I found I must use the common name. Even though the alternate names work for accessing via your web browser, there are no certificate warnings, if registering components using those names it would fail.

It seems crazy that you can't use any of the SANs ... so why allow us to have them?

I initially tried to replace the SSO Certificate where the common name was vsphere.company.com rather than the hostname of the server, and that installed. However, trying to install the Web Client would fail. When you get to the step where you have to accept the SSO Certificate, the installation would fail because the common name of the certificate did not match the hostname of the SSO server. This just seems crazy to me ... why the hostname of the server running SSO should even come into it when all calls are via HTTPS is just absurd!

I validated this with VMware Tech Support and they verified my findings.

0 Kudos
Andy_Zelpin
Contributor
Contributor
Jump to solution

Just replace the -ip otion from "*.*" to "solution.ini"

0 Kudos