User manual

Table Of Contents
n
Is the certicate signed by an unknown or untrusted certicate authority (CA)? Self-signed certicates
are one type of untrusted CA.
To pass this check, the certicate's chain of trust must be rooted in the device's local certicate store.
N For information about distributing a self-signed root certicate to all Windows client systems in a
domain, see "Add the Root Certicate to Trusted Root Certication Authorities" in the View Installation
document.
When you use Horizon Client to log in to a desktop, if your administrator has allowed it, you can click
 SSL to set the certicate checking mode. You have three choices:
n
Never connect to untrusted servers. If any of the certicate checks fails, the client cannot connect to the
server. An error message lists the checks that failed.
n
Warn before connecting to untrusted servers. If a certicate check fails because the server uses a self-
signed certicate, you can click Continue to ignore the warning. For self-signed certicates, the
certicate name is not required to match the server name you entered in Horizon Client.
You can also receive a warning if the certicate has expired.
n
Do not verify server identity . This seing means that no certicate checking occurs.
If the certicate checking mode is set to Warn, you can still connect to a Connection Server instance that uses
a self-signed certicate.
If an administrator later installs a security certicate from a trusted certicate authority, so that all certicate
checks pass when you connect, this trusted connection is remembered for that specic server. In the future,
if that server ever presents a self-signed certicate again, the connection fails. After a particular server
presents a fully veriable certicate, it must always do so.
I If you previously congured your company's client systems to use a specic cipher via GPO,
such as by conguring SSL Cipher Suite Order group policy seings, you must now use a Horizon Client
group policy security seing included in the ADM and ADMX template les. See “Security Seings for
Client GPOs,” on page 47. You can alternatively use the SSLCipherList registry seing on the client. See
“Using the Windows Registry to Congure Horizon Client,” on page 64.
Configuring Advanced TLS/SSL Options
You can select the security protocols and cryptographic algorithms that are used to encrypt communications
between Horizon Client and Horizon servers or between Horizon Client and the agent in the remote
desktop.
These security options are also used to encrypt the USB channel.
With the default seing, cipher suites use 128- or 256-bit AES, remove anonymous DH algorithms, and then
sort the current cipher list in order of encryption algorithm key length.
By default, TLS v1.0, TLS v1.1, and TLS v1.2 are enabled. SSL v2.0 and v3.0 are not supported.
N If TLS v1.0 and RC4 are disabled, USB redirection does not work when users are connected to
Windows XP desktops. Be aware of the security risk if you choose to make this feature work by enabling
TLS v1.0 and RC4.
If you congure a security protocol for Horizon Client that is not enabled on the server to which the client
connects, a TLS/SSL error occurs and the connection fails.
I At least one of the protocols that you enable in Horizon Client must also be enabled on the
remote desktop. Otherwise, USB devices cannot be redirected to the remote desktop.
Chapter 3 Configuring Horizon Client for End Users
VMware, Inc. 43