It is the day that I decided to put to the Internet our laboratory installation of Horizon Workspace. I equipped a wildcard certificate issued by Rapid SSL (GeoTrust), created the appropriate chain file and proceeded to action. Of course, in the case of Horizon Workspace nothing is simple when it comes to changing the FQDN and upload new SSL certificates for gateway-va. At the outset, collided with a “Certificate does not chain up to the root.”
We look to the log of configurator-va:/opt/vmware/horizon/configuratorinstance/logs/configurator.log
To verify the certificate is used verifyCert.hzn script, and after reviewing it turns out that the OpenSSL command is used:
openssl verify-purpose sslserver-CApath / dev / null-CAfile ho.pl ho.pl (ho.pl file is uploaded to my chain temp directory).
We extend the command of the verbose mode and check the result:
It turns out that the chain is bad constructed, instead of Rapid SSL CA, I put Geotrust SSL CA. Just fixing the chain and check again:
We get the message “error 2 at 1 depth lookup: unable to get issuer certificate” which translates to “Error validating custom certificate”. It turns out that there is no further certificate, but how is that possible? The chain is exactly the path:
After a moment’s thought, check GeoTrust Global CA certificate and it turns out that this is also a certified intermediary! Chain is as follows:
I add a certificate from GeoTrust (Equifax Secure CA) to certificate chain and check again:
It works! So the correct chain for a certificate issued in Rapid SLL are:
3. RapidSSL CA
2. GeoTrust Global CA
The first time I met up with a situation where Windows gives an incomplete path to the certificate, apparently GeoTrust Global CA is Microsoft’s very high level of confidence.
I recall that the correct certificate chain file structure is as follows:
Thumbprint Server Certificate
Thumbprint Intermediate(2) CA Server
Thumbprint Intermediate(1) CA Server
Thumbprint Root CA Server
Was this information is helpful? Tell me, please leave a comment!