Did you check whether the Linked VC is responding when pinged using DNS name which is shown in the Linked VC list ?
If you are using vCops 5.0 Enterprise try the following (I had similar issues):
1. Make sure you setup DNS properly in your in IP Pool.
2. If you are not using DNS in your IP pool simply use the New Registration button instead of the drop down box from Find Linked VCs. This could also be related to DNS issues in your IP Pool.
This way your vcenter registers with IP address rather then FQDN.
I have verified DNS resolution and that I can ping the remote hosts from the vCOPS VMs. The license has been applied, and data is being collected from our primary vCenter server correctly. VCOPS is correctly detecting the linked VCs, but it is not able to connect to either of them either by connecting as a linked mode VC or by entering a new registration. The connection does not work via hostname or IP address, indicating that the problem is not with name resolution.
When you attempt to use the "Find Linked vCenters", it assumes that the existing credentials are valid for each and every vCenter that is linked. If the credentials (or service account) is not valid for registration (Admin role), then it will probably fail.
Registering the Linked system directly is a good step to take, as was doing the ping/dig from the VMs directly.
There are a couple logs in the UI VM, under /var/log/vmware/ which may help (admin.log primarily) which should log the registration process but also the ciq.log which can show some of the more detailed errors as the capacity feature attempts to connect to vCenter.
Have you attempted different sets of credentials when attempting to connect to the seconday vCenters? Also, how were these additional vCenters created? (as a clone from the first vCenter, or a fresh installation from scratch). I have seen, once and a while, that the vCenter UUID is the same in two different installations which can cause registration failures.
If the above doesn't help, I'd suggest getting a ticket going with Support.
Out of the gigantic stack trace in admin.log, I get the following error, which I think indicates the root cause:
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.Validator
Exception: PKIX path validation failed: java.security.cert.CertPathValidatorExce
ption: timestamp check failed
And further down:
Caused by: java.security.cert.CertificateExpiredException: NotAfter: Tue Aug 09
16:29:10 PDT 2011
So, it looks like we have expired SSL certs. I'll start researching how to refresh or extend the SSL certs in vCenter, I guess.
Did you find a solution for this issue?
I'm having a similar issue. I want to connect 2 vCenter servers to a vCOPS 5 appliance but one fails with the same error as you. The other vcenter is connected without problems. These 2 vCenter server aren't configured in linked mode. They have both the same default VMware certificate wich are both expired. So I'm not sure why it would fail because of the certificate on one server and not the other.
Basically, you have to refresh the SSL certs in VMware. I used openssl as outlined in http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1009092.
That vCOPS does not throw a reasonable error and that the first suggestion by vCOPS itself and tech support is "redeploy the vApp" are tremendously annoying, because this cannot be an uncommon scenario for people who have upgraded from vCenter 2.5 or before.
Replacing the certificates with valid (not expired) once did indeed solve the issue.