I’m configuring bunch of UD Pockets and I’m having an issue with the Horizon Client in IGEL OS trusting my internal CA certs. I uploaded all of the root and intermediate certs to the UMS and transferred them to the UD Pocket. If I log in with a terminal session I can see them all in /etc/ssl/certs and in the /wfs/ca-certs directories. So far this is what I have tried;
• Exported all the certs from the certificate store on the Windows server running UMS as Base 64 .cer files
• I uploaded them to UMS as both common and ssl certificate types
• Changed the certificate file names to match the “Issued To” field in the certificate (Some had spaces in the names, so I replaced the spaces with underscores)
• Made sure the session name in the Horizon Client matched the Horizon server certificate name
However whenever I click on the Horizon Server within the Horizon client session, I am still getting an error “Untrusted Connection. Failed to connect to the Connection Server. The server provided an invalid certificate.” when the SSL setting is set to “Warn before connecting to untrusted servers. If I change the SSL setting to “Do not verify identity certificates” it connects fine, but the connection states it is not secure (expected).
If I connect from a local system running Windows and the Horizon Client with SSL set as “Warn before connecting to untrusted servers” , it works fine, so I know the certs are fine.
Can you please check the local date and time of the thin client?
Time is to the minute.
Just in case, you could also check the chain consistency by using Openssl, just in case!
Verifying certificate chains
Verify root certificate against site
openssl s_client -connect <test.ca:443|test.ca:443> -CApath /etc/ssl/certs
openssl s_client -connect <test.ca:443|test.ca:443> -CAfile /path/to/cafile.pem
Combine the intermediate and root with cat in combined.pem, test all certs together for chain.
openssl verify -verbose -purpose sslserver -CAfile combined.pem wildcard.test.ca.pem <– chain is OK
Example wildcard.test.ca.pem is a wildcard cert provided by Entrust
You can also do:
openssl verify -verbose -purpose sslserver -CAfile root.pem -untrusted intermediate.pem wildcard.test.ca.pem
openssl verify -CAfile RootCert.pem -untrusted Intermediate.pem UserCert.pem
Getting the certificate from the server
openssl s_client -showcerts -connect host.host:9999 </dev/null
I tried openssl s_client -connect <test.ca:443> -CApath /etc/ssl/certs and connected to the site successfully.
Which Igel OS Version are you using?
How did you uploaded the Certs to UMS? As Common Purpose Certificate, if no, could you? Then reset the device to factory defaults and retry.
I did both Common and SSL. I read an Igel doc that said for Horizon use SSL cert type
Is a reset to factory defaults necessary? When I changed the classification I did remove them from the profile and re-add them
Common purpose covers all SSL Stores so you should be good with that route. Well, it might. I already had a few situations where it got messed up after too much tests.
OK. I will change them all to Common and FD the device.
Chain is OK
Same error after changing all certs to Common and FD the device and re-applying the profile
Is there anything under Firmware Customizations that should be enabled for this to work correctly? I used the Securing IGEL OS Endpoints pdf to lock these devices down removing most of the Features except for the Horizon features and smart card support.
How is your chain looking like:
What happens when editing the Cert files with Notepad? Are they starting with Begin Certificate?
No, but you might try to remove the Profile for the Features Lockdown just to sort that out.
I’m actually doing that right now
Well, it wasnt the features
All the cert files are legible in notepad and have a BEGIN and END line
openssl verify the roots and intermediates after I cat-ted them in a chain file
Do you have a client running an older firmware version which you can test on, e.g. 11.02.150?
Nothing earlier than 11.03.500.01 anymore
I just wanted to update anyone who comes across this thread with the same problem.
Working with IGEL Pre-Sales Engineers today, we got this working.
By actually _removing_ certificates for my Connection Servers, and external UAG sites from my IGEL devices cert store, I can now connect successfully to my Horizon environment with the Horizon Client and the SSL setting set to “Warn before connecting to untrusted servers.”
Prior to making this change, I would always get a “Untrusted Connection. Failed to connect to the Connection Server. The server provided an invalid certificate” error with this setting selected.
The IGEL certificate store now only contains my root and intermediate certificates and nothing else.
Thanks Ka-ton and Cameron for the assistance!
Continue reading and comment on the thread ‘Issue with the VMware Horizon Client in IGEL OS trusting my internal CA certs’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.
Submit a question, or Join Today!
Popular Message Threads
- Receiving error: “Citrix Receiver cannot create a secure connection in this browser” when launching a secure connection from Firefox on IGEL OS
- How to Install IGEL OS via a Bootable USB Drive
- Where to delete the certificates that cause ‘invalid certificate’ when trying to import an IGEL into UMS?
- How to change the default IGEL UMS admin password?
- IGEL UD3 (LX50) randomly get this error with Citrix: The X Request 130.1 caused error :”10: BadAccess ( attempt to access private resource denied) any ideas?
- IGEL UMS Universal Update Error: “could not resolve host name”
- Citrix connection via Netscaler Error: “AM_ERROR_AUTH_NETWORK_ERROR” on IGEL OS