View source for ZCO Connection Security

{{BC|Certified}}
__FORCETOC__
<div class="col-md-12 ibox-content">
= ZCO Connection Security =
{{KB|{{ZC}}|{{ZCS 8.6}}||||}}

ZCO v8.0.7 introduced significant improvements to the way connection security is managed to address [https://bugzilla.zimbra.com/show_bug.cgi?id=83030 BUG 83030]. This article gives a overview of the new behavior.

=Overview of ZCO Connections=

ZCO establishes several connections to the ZCS server:
*to send/receive email
*to synchronize folders
*to synchronize the GAL
*to detect changes made an the server
*to synchronize signatures
*to synchronize whitelists/blacklists
*to synchronize preferences
*to perform autoupgrade


It connects to the server specified in '''Server Name''' on the Server Configuration tab of the profile properties:

[[File:ZCOProfileServerConfig.PNG]]


As seen above, ZCO also provides a '''Use Secure Connection''' checkbox. The notes that follow describe the behavior of this checkbox and discuss the ways ZCS, and potentially the Windows account hosting ZCO, must be configured in order to support it.


By default, the checkbox is unticked because support for secure connections requires additional configuration on ZCS. This causes information to be sent over the connections using HTTP. Unfortunately, HTTP data is sent ''in-the-clear'', making it susceptible to eavesdropping by unauthorized intruders. This allows them to harvest sensitive and valuable information such as passwords and email contents. HTTP connections are also vulnerable to an attack known as a ''man-in-the-middle'' (MitM) attack. In a MitM attack, an intruder can substitute the server ZCO 'thinks' it is communicating with, with a server of their own, again giving them an opportunity to steal information.


To prevent these forms of eavesdropping, ZCO also supports communication over HTTPS. '''HTTPS is enabled by ticking the "Use Secure Connection" checkbox'''.

=What is HTTPS?=

HTTPS uses public/private key-pair cryptography to secure the connection. Keys are essentially mathematically related numbers used at each end of the connection to encrypt/decrypt information. The private key is kept private on the server; the public key is given to clients that wish to connect securely. 

Public keys are carried to the client in entities called ''Certificates'' when the HTTPS connection is initially established. ZCO examines the certificate and decides whether to trust it. In order to trust it, it has to be sure that it originated on the server in question, and that it has not been tampered with in transit. 

*If it cannot trust it, it displays a warning to the user that the connection cannot be secured.
*If it can trust it, the public key contained within is subsequently used to encrypt/decrypt the traffic to/from the server.


How does ZCO decide whether to trust the certificate? Certificates are in turn ''signed'' by another certificate known as a '''Root CA Certificate''' (or more strictly the key contained within that certificate). The signing process attests that the public key within the certificate is authentic and has not been tampered with.

The Root CA Certificate is placed in the '''Trusted Root Certification Authorities''' node of the '''Windows Certificate Store''', and during verification, ZCO ensures that the certificate tallies with that.

=Enabling Connection Security in ZCS and ZCO=

For all of this to work, a number of things need to be in place:
*ZCS must be configured with an appropriate certificate
*ZCS must be configured to accept HTTPS connections
*The Windows client hosting ZCO must know about the root CA certificate

==Configuring the Certificate ZCS Uses for HTTPS Connections==

Broadly, there are two types of certificate:
*'''Commercial''': These can be purchased from a 3rd party vendor known as a ''Certificate Authority''. The vendor attests that the certificate belongs to the server in question.
*'''Self-signed''': These can be generated, at no cost, on ZCS. The administrator who creates the certificate attests that the certificate belongs to the server in question.

It is generally recommended that Commercial Certificates are used in production environments, and that Self-signed are only used for trialing.

See [[Administration_Console_and_CLI_Certificate_Tools]] for information on configuring both types of certificate.

One advantage of using a Commercial certificate is that the root CA certificate will typically already be installed on the Windows client. If a self-signed certificate is used, then the root CA certificate must be deployed manually on all Windows clients which involves potentially significant additional configuration effort.

==Deploying the Root CA Certificate to ZCO Client (only required for Self-signed Certificates)==

=== Single Client===
First, obtain the root CA certificate from the server. The certificate is in the form or PEM file, which cannot be installed on the Windows system so it is necessary to convert the certificate file.

1. Log on to your server as root and go to the directory '''/opt/zimbra/ssl/zimbra/ca'''

2. Run the command:

 openssl x509 -in ca.pem -out cacert.der -outform DER

This will generate a file called '''cacert.der''' in the same directory. Copy this file and store it on the Windows system on which you want to import the certificate.

On the Windows client, do Start->Run->CertMgr.msc to access the Windows Certificate Store:

[[File:DCBZCOWinCertMgr.PNG]]


Right-click the '''Certificates''' folder under Trusted Root Certificate Authorities and choose All Tasks->Import. Follow the Wizard instructions to import '''cacert.der'''. Ensure that the certificate is placed in the Certificates folder under Trusted Root Certification Authorities.

===Multiple ZCO Clients===

When there are several hundred Windows clients, it might be preferable to use Group Policy to deploy the root CA certificate. See [http://technet.microsoft.com/en-us/library/cc770315(v=ws.10).aspx Deploy Certificates by Using Group Policy]

==Enabling Support for HTTPS Connections on ZCS==

The next step is to configure ZCS to accept HTTPS connections. The CLI '''[[CLI zmtlsctl to set Web Server Mode|zmtlsctl]]''' configures the types of connections ZCS supports. From 8.0.7, zmtlsctl defaults to HTTPS, but you can check the current setting as follows:

 zmprov -l gs <server> |grep -i zimbramailmode

To set it to HTTPS, proceed as follows:

 zmtlsctl HTTPS
 zmcontrol stop

Wait for everything to stop, then do

 zmcontrol start

==Configuring a ZCO Profile to use HTTPS==

Once all of the above steps are complete, the '''Use Secure Connection''' checkbox can be ticked. When Outlook is then started, ZCO will connect securely to the server. If there are any problems, ZCO will display the Certificate Trust Dialog described below.

=Important Notes Concerning Profiles Created by pre-8.0.7 ZCO=
Profiles created with pre-8.0.7 ZCO ('prior ZCO') will continue to work with ZCO v8.0.7, but please note the following:
*Prior ZCO supported a feature called Allow Invalid Certificates. This was a checkbox on the ZCO Advanced Dialog (see below) that suppressed warnings about certificates that could not be trusted. This has been removed in 8.0.7. If the checkbox was ticked, this is ignored by 8.0.7. '''This means that users who previously did not encounter the Certificate Trust dialog will now see it unless the configuration steps detailed above are implemented in full.'''
*Prior ZCO's Certificate Trust dialog allowed a user to select the period of time an untrusted certificate should be permitted for. One of the options was "Always". This has now been removed. Also, ''any'' trust interval configured in a legacy profile is ignored during first startup of a new 8.0.7 install.

=ZCO Connection Security UI=

This section describes the new ZCO User Interface that is related to connection security.

==The Certificate Trust Dialog==


The Certificate Trust Dialog appears whenever ZCO encounters a problem with the certificate while establishing a secure connection. This can happen for any one of the connections ZCO establishes but you are perhaps most likely to see it when starting Outlook.

Note that when the client and server and are correctly configured in accordance with the above instructions, users should never see this dialog, unless an intruder has instigated a MitM attack (or perhaps because of rare events such as certificate expiry).


Here is an example of a Certificate Trust Dialog that would appear as a result of incorrect configuration:

[[File:DCB_ZCO_CertTrustDlg1.PNG]]

The text at the top of this dialog explains which connection was being established when the problem occurred.


Clicking '''View Certificate''' displays the certificate returned by the server. The three tabs of this can be used to glean further information on why the certificate failed to verify.

[[File:DCBZCOViewCert1.PNG]]   [[File:DCBZCOViewCert2.PNG]]   [[File:DCBZCOViewCert3.PNG]]

In this example '''The issuer of this certificate could not be found''' shows that the issue is caused by using a self-signed certificate where the root CA certificate has not being installed on the client.


A user could in this case opt to trust the certificate manually by clicking '''Connect Despite the Risks'''. This allows them to specify for how long they wish to trust the certificate. Note that this is not recommended and once again should not happen in a correctly configured environment:

[[File:DCBZCOCertConnectDespite.PNG]]


The drop-list allows the user to specify how long this certificate should be trusted for, and clicking '''Authorize Connections''' allows the connection to go ahead. Note also that any subsequent connections that return this certificate will also be implicitly trusted.

Other reasons why the trust dialog might appear:
*The certificate has expired
*The certificate does not match the server
*The wrong root CA certificate has been installed
*The connection is being subjected to a MitM attack

==The Connection Settings Tab==

The '''Connection Status''' box on the Connection Settings tab of the profile properties dialog shows the status of the current connection:

[[File:DCBZCOConnTabConnStat.PNG]]

On a properly secured connection, this will simply say "SECURE".


The '''View Certificate''' button allows the current certificate to be viewed.]

The '''Stop Trusting''' button allows any existing trust to be terminated. Clicking this causes Outlook to Work Offline.

=Changes from ZCO v8.6.0=

==UI Changes==

===Advanced Settings Dialog===

Allow Invalid Certificates removed for reasons described described above:

[[File:DCBZCOCertsAdvanceOldNew.PNG]]

===Certificate Trust Dialog===

Improved as described above

===Connection Settings Tab===

Improved as described above


==Functional Changes==

ZCO now more rigorously enforces connection security, and is more informative when problems arise. When the user manually trusts a certificate, that certificate's fingerprint is recorded. Should a subsequent connection see a different certificate, ZCO warns the user, and the user can always click '''View Certificate''' to examine the offending certificate:

[[File:DCBZCOCertDifferent.PNG]]