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.