Dear community,
Since about 2 weeks I am experiencing a certificate revocation check error in our Horizon View 6.2 environment. The strange thing is that within about 12 hours both (replicating) connection servers and the vCenter server / Composer server (on the same machine) are considered to have invalid certificates, though, in fact, they have valid ones (CA certificates). We do not use security servers.
The view administrator console shows the following for the connection servers:
Server's certificate is not trusted.
Server's certificate cannot be checked.
For the vCenter it says (as I manually validated the certificate):
No problem detected.
Certificate is untrusted but the thumbprint for the certificate is accepted.
With logging set to "full" the connection server logs show the following for the vCenter server:
TRACE (17B0-0E98) <VCHealthUpdate> [NativeKeyVault] validateCertificateChain response: { Result=FAIL, EndEntityReasons=cantCheckRevoked, ChainReasons=invalid, SelfSigned=false, EndErrorCode=16777280, EndInfoCode=258, ChainErrorCode=16777280, ChainInfoCode=256, PolicyErrorCode=-2146885613 }
As far as I can see there are no similar entries for the connection server certificates in the log.
At the moment I am running the environment with manually validated Composer and vCenter certificates and invalid (red) connection server certificates (as View clients and browsers do not consider them to be invalid).
I already checked that I am able to make everything "green" again via setting the registry key "CertificateRevocationCheckType" to 2 (as described here Configuring Certificate Revocation Checking on Server Certificates). This leads me to the conclusion that one of the intermediate certificates cannot be validated. As well, I got the information that one "version" of an intermediary certificate (of an intermediary ca) has been revoked. It seems to be no coincidence - as the point of time fits as well, but this particular version seems not be in use in my connection servers.
However, even with full logging activated, I cannot get the information which (intermediary) certificate cannot be validated and why. I would have expected to see something like "checking OCSP" or "checking CRL" but I cannot find it in the logs. Though, I noticed that one of the intermediary certificates was missing the OCSP URL (though the "Authority Information Access" field existed). Of course I updated the certificate with a version containing the OCSP URL but it did not change anything.
Additionally I manually checked all the certificates in the chain with openssl (for OCSP) and the CRL lists as well, but everything seems to be OK (all URLs are reachable and no used certificate has been revoked). In fact, as well, I do not interpret the error as "that the connection server does consider a certificate as invalid because it has been revoked", but "that it cannot check if it has been revoked". The servers do not need a proxy and there is none configured, as well (I checked proxy settings system context, too).
For the moment the problem is not critical, as the "red" status of the connection servers does not have an effect on our customers and as well I could turn off the certificate revocation checking (or switch it to only check the server certificate (2)). But of course I would like to really fix the problem.
Is there anyone who can give me a hint about what to check, e.g. how to find out which certificate cannot be checked and why? Has anyone had the same or a similar problem? VMware support works on the problem as well, but they seem to do not know the problem, neither.
I appreciate any thoughts and replies! Thanks!
Best regards,
Fabian
Dear community,
Meanwhile I was able to fix the error described in the beginning of this thread. Skip to the end to see what probably might help you...
So what probably will help in similar cases:
My question to the VMware technicians/developers: Is it supported to use certificates which only include the server aliases. If not why did it work before and where is it documented? Where is certificate information cached so that simply replacing the certificate only was some and not a complete success (see above). For your information - when I initally paired the replicas I had to install the CA certificate (including only the alias) after the first replication - now, with the certificates (including server name and alias) I could install the certificate before replicating (=installing the connection server).
Hi,
I thought I'd jump on this thread to keep it alive as I too have a 6.2 environment that just 'went red' with the same CRL issue, yet each of the connection servers is able to download the .crl file they need.
The support KB method of disabling the CRL checking just doesnt sit right with me - I want to know what & why it happens - the KB also doesn't mention anything about Horizon 6.2.
i'm about to put a job in with vmware on this and i'll update anything i find.
I'd be interested to see what you come up with... - we disabled CRL
Hi,
have you any feedback about that issue? I'm in the same situation and disable CRL checking doesn't fix it.
Hi Alethay,
Depending on the problem, CRL checking should fix it - though it only is a workaround and not a real fix. However I really fixed it, see below.
Best regards,
Fabian
Dear community,
Meanwhile I was able to fix the error described in the beginning of this thread. Skip to the end to see what probably might help you...
So what probably will help in similar cases:
My question to the VMware technicians/developers: Is it supported to use certificates which only include the server aliases. If not why did it work before and where is it documented? Where is certificate information cached so that simply replacing the certificate only was some and not a complete success (see above). For your information - when I initally paired the replicas I had to install the CA certificate (including only the alias) after the first replication - now, with the certificates (including server name and alias) I could install the certificate before replicating (=installing the connection server).