Cipher suites: Difference between revisions

No edit summary
No edit summary
(One intermediate revision by the same user not shown)
Line 1: Line 1:
{{BC|Certified}}
= Using Zimbra with strong TLS configuration =
__FORCETOC__
<div class="col-md-12 ibox-content">
= ZCS Certificates Tools =
{{KB|{{ZC}}|{{ZCS 10.0}}|{{ZCS 9.0}}|{{ZCS 8.8}}||}}


See also:
Transport Layer Security (TLS) encrypts data sent over the Internet to ensure that eavesdroppers and hackers are unable to see what you transmit which is particularly useful for private and sensitive information such as passwords, credit card numbers, and personal correspondence. (further reading: https://www.internetsociety.org/deploy360/tls/basics)


* [[https://wiki.zimbra.com/wiki/Cipher_suites Cipher suites]] strong TLS configuration
In this article you will learn how to configure Zimbra to use only strong encryption ciphers for TLS. Configuration settings on this page are routinely validated by our QA team.
* [[Certificate_Chain]] practical how to on creating the certificate chain file.
* [[Installing_a_LetsEncrypt_SSL_Certificate]] Let's Encrypt steps for Zimbra
* [[Multiple_SSL_Certificates,_Server_Name_Indication_(SNI)_for_HTTPS]] using SNI on Zimbra
* [[Secopstips]] Securing your Zimbra installation


= Generate ssl_ciphers for use with zimbraReverseProxySSLCiphers =


ZCS allows administrators to manage their [https://en.wikipedia.org/wiki/Public_key_certificate certificates] using either the Administration Console or the Command Line Interface (CLI). This article discusses the ZCS 8.x, 8.0.x, 7.0.x Administration Console, and the CLI tools for ZCS 8.x, 8.0.x, 7.0.x.
Since encryption is always evolving it is recommended to use Mozilla SSL Config generator that you can find at https://ssl-config.mozilla.org/ in addition we have to [https://help.deepsecurity.trendmicro.com/10_1/on-premise/Protection-Modules/Intrusion-Prevention/ref-disable-dh.html disable Diffie-Hellman].


== A note on CN and subjectAltName ==
Select <code>Intermediate</code> and <code>Nginx</code> (Zimbra proxy is based on Nginx) at the time of writing this article this will select nginx 1.17.7 and OpenSSL 1.1.1d. The tool also reports the oldest supported clients that work with this configuration: Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, and Safari 9.


By default ZCS requires valid certificates when communicating with hosts over TLS/SSL.  As such, certificates within an install should be valid (not expired and have hostnames matching the certificate).
From the generated config file copy the value from <code>ssl_ciphers</code>:


Per https://tools.ietf.org/html/rfc2818#section-3.1
<pre>ssl_ciphers !DH:!EDH:!ADH:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;</pre>
<blockquote>
= Configuring Zimbra Proxy Nginx =
If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.
</blockquote>


See also [https://tools.ietf.org/html/rfc2459#section-4.2.1.7 RFC2459 section-4.2.1.7] for details on Subject Alternative Name handling and usage.
Configure Zimbra to use the above ciphers, and enable TLSv1.2 and TLSv1.3 like this:


In short setting subjectAltName, it must include all host names to be trusted, not just "additional" ones beyond what is in CN (by default zmcertmgr will put `zmhostname` in the subjectAltName).
<pre>zmprov mcf zimbraReverseProxySSLProtocols TLSv1.2
zmprov mcf +zimbraReverseProxySSLProtocols TLSv1.3


= ZCS Administration Console =
zmprov -l mcf zimbraReverseProxySSLCiphers '!DH:!EDH:!ADH:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'


The ZCS Certificates tools are located in the Navigation pane, under '''Configure>Certificates'''
zmproxyctl restart</pre>
= Configuring Zimbra Mailbox =


[[File:SSL_Install_Web_001.png]] [[File:SSL_Install_Web_002.png]]
Also configure Zimbra mailbox to allow the use of TLSv1.3. Open in a text editor <code>/opt/zimbra/conf/localconfig.xml</code> find the line <code>mailboxd_java_options</code> and set <code>TLSv1.2,TLSv1.3</code> in <code>https.protocols</code> and <code>jdk.tls.client.protocols</code>. Example result:


== Viewing Certificates ==
<pre>&lt;key name=&quot;mailboxd_java_options&quot;&gt;
Using the Administration Console, you can view the details of certificates currently deployed. Details include the certificate subject, issuer, validation days, and subject alternative name.
  &lt;value&gt;-server -Dhttps.protocols=TLSv1.2,TLSv1.3 -Djdk.tls.client.protocols=TLSv1.2,TLSv1.3 -Djava.awt.headless=true -Dsun.net.inetaddr.ttl=${networkaddress_cache_ttl} -Dorg.apache.jasper.compiler.disablejsr199=true -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=1 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=15 -XX:G1MaxNewSizePercent=45 -XX:-OmitStackTraceInFastThrow -verbose:gc -Xlog:gc*=info,safepoint=info:file=/opt/zimbra/log/gc.log:time:filecount=20,filesize=10m -Djava.net.preferIPv4Stack=true&lt;/value&gt;
&lt;/key&gt;</pre>
Then restart mailbox, or reboot your server:


To view a certificate, select a service host name, either under '''Certificates''' in the Navigation pane or by selecting a Service host name in the Manage Certificates tab and clicking '''View Certificate'''.  A Certificates tab for the service host name you selected opens in the Content Pane.
<pre>zmmailboxdctl restart</pre>
== Configure additional HTTP headers ==


[[File:SSL_Install_Web_003.png]]
The following headers will:


Information about the certificate:
* Enable HTTP Strict Transport Security (HSTS)
* Disable search indexing of your server by Google et al.


[[File:SSL_Install_Web_004.png]]
<pre>zmprov mcf +zimbraResponseHeader &quot;Strict-Transport-Security: max-age=31536000; includeSubDomains&quot;
zmprov mcf +zimbraResponseHeader &quot;X-Content-Type-Options: nosniff&quot;
zmprov mcf +zimbraResponseHeader &quot;X-Robots-Tag: noindex&quot;
zmprov mcf +zimbraResponseHeader &quot;Referrer-Policy: no-referrer&quot;
zmprov mcf zimbraMailKeepOutWebCrawlers TRUE
zmmailboxdctl restart</pre>
= DH parameters =


You can refresh the currently displayed details by clicking '''Refresh''' at the top of the tab.
While we disable Diffie-Hellman for Zimbra Proxy and MTA, Diffie-Hellman may still be used by other Zimbra services. Use pre-defined DHE groups as recommended by [https://tools.ietf.org/html/rfc7919 IETF RFC 7919].


== Generate a valid CSR (Certificate Signing Request) for a Commercial SSL ==
Further reading:
Go to '''Home > Configure > Certificates''' and click in the settings icon, then click on '''Install Certificate'''
 
[[File:Zimbra-ssl-adminconsole-001.png|800px]]
 
Select the target server to generate the SSL files like the CSR and the private key:
 
[[File:Zimbra-ssl-adminconsole-002.png|800px]]
 
In the next step, select the option '''Generate the CSR for the commercial certificate authorizer'''
 
[[File:Zimbra-ssl-adminconsole-003.png|800px]]
 
In this window, you need to select the next settings:
* Select digest '''SHA256''' or above, not SHA1 as is not longer considered to be secure
* Key Length 2048 or above
* Common Name (CN) needs to be the FQDN that you want to use, if you are using a Single-Server is recommended that the FQDN and the hostname are the same.
* The checkbox about the Wildcard is if you want to use a Wildcard SSL certificate for your Zimbra, and for the rest of you other FQDN in your Company. If the hostname and the FQDN doesn't match, but are in the same domain, use this option and buy a Wildcard Certificate.
* In the Subject Alternative Name (SAN), you can select another names if you will use a Multi-SAN SSL certificate, this option is indicated if you want to have mail.customer1.com, mail.customer2.com, etc.
 
[[File:Zimbra-ssl-adminconsole-004.png|800px]]
 
You can download now the CSR file, ready to send to your SSL Certificate Provider, if you miss this step, you can find the csr file in the next path '''/opt/zimbra/ssl/zimbra/commercial/commercial.csr''':
 
[[File:Zimbra-ssl-adminconsole-005.png|800px]]
 
You can check if your CSR is valid and correct using for example [https://certlogik.com/decoder/ https://certlogik.com/decoder/]
 
== Installing Certificates ==
Clicking '''Install Certificate''' from either the Manage Certificates tab or a Certificates tab opens the Certificate Installation Wizard.  The Certificate Installation Wizard is a tool that will help you quickly create and deploy a certificate.
 
=== Generating & Installing a Self-Signed Certificate ===
Sometimes we want to regenerate the Self-Signed Certificate, we can do it in the Administration Console. We need to click in the '''Cog>Select Install Certificate''' and follow the steps:
 
The first step is select '''Install the self-signed certificate'''
 
[[File:SSL_Install_Web_005.png]]


Next, we need to mark the checkbox '''Replace the existing CSR'''
* https://weakdh.org/
* https://github.com/internetstandards/dhe_groups


[[File:SSL_Install_Web_006.png]]
<pre>wget https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem -O /etc/ffdhe4096.pem
su - zimbra
zmprov mcf zimbraSSLDHParam /etc/ffdhe4096.pem</pre>
Reboot the server.


We need to be sure of select the Key Length at 2048, and the rest of the fields, for now have a Bug Opened in 8.5 and also if you change this values will be the same default values - [https://bugzilla.zimbra.com/show_bug.cgi?id=95450].
= Configuring Zimbra MTA Postfix =


[[File:SSL_Install_Web_007.png]]
Postix traffic is not routed through Zimbra proxy. Below commands show how to configure Zimbra MTA to use only strong TLS ciphers. In 2021 not all mail servers on the Internet support encryption. For maximum compatibility it is still recommended to use <code>Opportunistic TLS</code>. So that you can receive email via unencrypted transmissions. However you can set zimbraMtaTlsSecurityLevel to encrypt to force the use of TLS. This ''will'' result in mail delivery issues.


We can select also the time that we want to have this SSL validated, remember that is Self-Signed, if we are not planning any future change, we can select more than a year. And then press '''Install'''.
To test the current state of the MTA run from the MTA:


[[File:SSL_Install_Web_008.png]]
<pre>nmap --script ssl-enum-ciphers -p 25 your-mta-server.example.com</pre>
The last line of output with Zimbra default config: least strength: F


The SSL Certificate Self-Signed are now installing in our Zimbra Collaboration Server.
<pre>openssl s_client -starttls smtp -showcerts -connect your-mta-server.example.com:25 -servername your-mta-server.example.com -tls1_1</pre>
Then the following configuration will remove weak ciphers and disable some Postfix options that are considered unsecure.


[[File:SSL_Install_Web_009.png]]
Find the current list of ciphers for Postfix via:


Once the installation has finish, the system request us a restart of the ZCS services.
https://ssl-config.mozilla.org/#server=postfix


[[File:SSL_Install_Web_010.png]]
Configure it in Zimbra using:


Trough console by user zimbra we need to execute the next command, and wait until all services are up again:
<pre>zmprov mcf zimbraMtaSmtpdTlsCiphers medium
<pre>zmcontrol restart</pre>
zmprov mcf zimbraMtaSmtpdTlsMandatoryCiphers  medium
zmprov mcf zimbraMtaSmtpdTlsProtocols '&gt;=TLSv1.2'
zmprov mcf zimbraMtaTlsSecurityLevel may
postconf -e fast_flush_domains=&quot;&quot;
postconf -e smtpd_etrn_restrictions=reject
postconf -e disable_vrfy_command=yes
postconf -e tls_medium_cipherlist='!DH:!EDH:!ADH:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'
postconf -e tls_preempt_cipherlist=no


If we will go again to our https://mail.domain.com we will have the known problem with SSL Certificate in our Web Browser:
zmprov gs `zmhostname` zimbraMtaTlsAuthOnly
zmprov ms `zmhostname` zimbraMtaTlsAuthOnly TRUE # if not already (this is default)
zmmtactl restart</pre>
'''''IT IS VERY IMPORTANT tls_medium_cipherlist IS SET, setting just medium or high in zimbraMtaSmtpdTlsCiphers/zimbraMtaSmtpdTlsMandatoryCiphers will not work!!'''''


[[File:SSL_Install_Web_011.png]]
Above config was tested with email from Gmail (uses tls), Ubuntu 20 Postfix (uses tls), from Zimbra itself (uses lmtp) and http://ismyemailworking.com/ (uses plain text) and this all works.
=== Generating Multiple CSRs using the Administration Console ===


Currently the Administration Console only supports having one Certificate Signing Request (CSR) and private key at a time. Generating a new CSR overrides the existing one and generates a new private key. To generate more than one CSR, move both the CSR and key from the directory it is generated in (e.g. /opt/zimbra/ssl/zimbra/commercial directory/) before generating another CSR.
Run again to verify your set-up:


== Maintaining Valid Certificates ==
<pre>nmap --script ssl-enum-ciphers -p 25 your-mta-server.example.com</pre>
It is important to keep your SSL certificates valid to ensure clients and environments work properly, as the ZCS system can become non-functional if certificates are allowed to expire. You can view deployed SSL certificates from the ZCS administrator console, including their validation days. It is suggested that certificates are checked periodically, so you know when they expire and to maintain their validity.
The last line of output with Zimbra new config: least strength: A


= ZCS Certificate CLI =
It seems TLS v1.3 is either not enabled or not tested via nmap, but you can verify that like so:


== zmcertmgr ==
<pre>openssl s_client -starttls smtp -showcerts -connect your-mta-server.example.com:25 -servername your-mta-server.example.com -tls1_3
This command allows you to manage certificates.


=== General Guidelines ===
openssl s_client -starttls smtp -showcerts -connect your-mta-server.example.com:25 -servername your-mta-server.example.com -tls1_1</pre>
Follow these guidelines when using this command.
Please note that you can best run nmap/openssl commands on your MTA server to avoid firewall and network blocking issues of port 25.
* For versions before 8.7, this tool must be run as root. '''In 8.7+, this tool is run as user zimbra.'''


==== Commercial Certificate Guidelines ====
= Configuring Zimbra LDAP OpenLDAP =
Follow these guidelines when using this command to generate a commercial certificate.
*The private key must exist in the '''/opt/zimbra/ssl/zimbra/commercial''' directory, and must be named '''commercial.key''' with its permission set to '''740''' before 8.7, and '''640''' in 8.7+.
*The server certificate and the chain certificate files must exist in a temp directory. (E.g. /tmp/certs/)
*The chain certificate files must be concatenated into one file called '''commercial_ca.crt'''


=== Syntax ===
Zimbra stores passwords in LDAP and is not proxied via Zimbra proxy. To find your current TLS protocols and ciphers you can run nmap, but you will need a recent version of nmap.
zmcertmgr [options]


=== Description ===
<pre>nmap --script ssl-enum-ciphers -p 389 your-ldap-server.example.com</pre>
{|style="width:100%" border="1" cellpadding="5" cellspacing="0"
Check and see if TLSv1.0 and TLSv1.1 are enabled (default) and what the least strength cipher is for TLSv1.2 and above (default: A).
! align="left" style="color:white;" bgcolor="#1785c2" |Name
! align="left" style="color:white;" bgcolor="#1785c2"|Description
|-
! colspan="2" align="left" style="color:white;" bgcolor="#f15a25" |General Options
|-
|style="background=white" |<nowiki>-help</nowiki>
|Displays usage options for '''zmcertmgr'''
|-
! colspan="2" align="left" style="color:white;" bgcolor="#f15a25" |Self-Signed Certificate Options
|-
! colspan="2" | <nowiki>createca [-new] [-keysize keysize] [-digest digest] [-subject subject]</nowiki>
|-
|
| Generates a Certificate Authority (CA).
|-
! colspan="2" | <nowiki>deployca [-localonly]</nowiki>
|-
|
| Deploys a Certificate Authority (CA).  The '''-localonly''' avoids updating any certificate related settings in LDAP.
|-
! colspan="2" | <nowiki>createcsr <self|comm> [-new] [-keysize keysize] [-digest digest] [-subject subject] [-subjectAltNames "host1,host2"]</nowiki>
|-
|
| Creates a certificate signing request (CSR) for either a self or commercially signed certificate authority.  By default the CSR
subjectAltNames contains the current zmhostname (8.7 only: unless the '''-noDefaultSubjectAltName''' argument is used).
|-
! colspan="2" | <nowiki>createcrt [-new] [-days validation days] [-keysize keysize] [-digest digest]  [-subject subject] [-subjectAltNames "host1,host2"]</nowiki>
|-
|
| Creates a self-signed certificate based on the CSR generated using '''createcsr'''.
|-
! colspan="2" | Where options are:
|-
| -new
| Force the generation of a new CA/Cert/CSR, overwriting existing data.
|-
| -keysize
| The RSA keysize in bits, for example "-keysize 4096".  Minimum keysize is 2048.  Default keysize is 2048. (as of 8.0.7 https://bugzilla.zimbra.com/show_bug.cgi?id=85023)
|-
| -subject
| The X.500 distinguished name (DN). The default was "/C=US/ST=N\/A/L=N\/A/O=Zimbra Collaboration Suite/OU=Zimbra Collaboration Suite/CN=${zimbra_server_hostname}" before 8.7, and in 8.7+ is "/OU=Zimbra Collaboration Suite/CN=${zimbra_server_hostname}" after.
|-
| &#8209;subjectAltNames
| Additional host names that may use the certificate other than the one listed in the subject.  The alternate names can be specified as comma separate values (or in 8.7+ the '''-subjectAltNames''' can be used multiple times).
|-
! colspan="2" align="left" style="color:white;" bgcolor="#f15a25" | Self-Signed (self) and Commercial (comm) Certificate Options
|-
! colspan="2" | <nowiki>deploycrt <<self>|<comm [certfile ca_chain_file]>> [-allservers] [-localonly] [[-deploy $services] ...]</nowiki>
|-
|
| Deploys a certificate. For commercial certificates the certificate file and the certificate authority (CA) chain may be specified. For deploycrt, the use of '''-allservers''' will cause zmcertmgr to iterate through all servers in the ZCS deployment (zmprov gas, minus the initiating zmcertmgr host).
|-
! colspan="2" | <nowiki>getcrt <self|comm> [-allservers]</nowiki>
|-
! colspan="2" | <nowiki>savecrt <self|comm> [-allservers]</nowiki>
|-
|
| Get (or Save) a certificate.  For '''getcrt''' and '''savecrt''', the use of '''-allservers''' causes the configuration keys to be get/set as a global (getConfig/modifyConfig) configuration settings (zimbraSSLCertificate and zimbraSSLPrivateKey) instead of as a per-server setting (getServer/modifyServer).
|-
! colspan="2" | <nowiki>viewcsr <self|comm> [csr_file]</nowiki>
|-
|
| Shows a certificate signing request (CSR). Optionally, the CSR file can be specified.
|-
! colspan="2" | <nowiki>viewstagedcrt <self|comm> [certfile]</nowiki>
|-
|
| Shows a staged certificate. A staged certificate is placed in a staging file, where all files that will be deployed with the certificate are kept. You can use the staging area to verify that you are ready to deploy a certificate.
|-
! colspan="2" | <nowiki>verifycrt <self|comm> [[[priv_key] [certfile]] [ca_chain_file]]</nowiki>
|-
|
| Combines '''verifycrtkey''' and '''verifycrtchain''' checks (see below).
|-
! colspan="2" | <nowiki>verifycrtkey <priv_key> <certfile></nowiki>
|-
|
| Compares certificate private key and certificate file modulus digests to ensure they match.
|-
! colspan="2" | <nowiki>verifycrtchain <ca_chain_file> <certfile></nowiki>
|-
|
| Verifies a certificate chain.
|-
! colspan="2" | <nowiki>viewdeployedcrt    [all|ldap|mailboxd|mta|proxy]</nowiki>
|-
|
| Shows a deployed certificate on the local server.
|-
! colspan="2" | <nowiki>checkcrtexpiration [all|ldap|mailboxd|mta|proxy] [-days days]</nowiki>
|-
|
| Check if certificate(s) expire within '''-days days'''
|}


=== Examples ===
To force the use of TLS &gt;= v1.2 with strong Ciphers run the following:
The following are examples of using the above options for different installation scenarios.


==== Single-Node Self-Signed Certificate ====
<pre>zmlocalconfig -e ldap_common_tlsprotocolmin=&quot;3.3&quot;
1. Begin by generating a new Certificate Authority (CA).
zmlocalconfig -e ldap_common_tlsciphersuite=&quot;HIGH&quot;</pre>
  /opt/zimbra/bin/zmcertmgr createca -new
In addition require TLS for LDAP (disable unencrypted LDAP) via:
2. Then generate a certificate signed by the CA that expires in 1825 days.
  /opt/zimbra/bin/zmcertmgr createcrt -new -days 1825
3. Next deploy the certificate.
  /opt/zimbra/bin/zmcertmgr deploycrt self
4. Next deploy the CA.
  /opt/zimbra/bin/zmcertmgr deployca
5. To finish, verify the certificate was deployed to all the services.
  /opt/zimbra/bin/zmcertmgr viewdeployedcrt


==== Multi-Node Self-Signed Certificate ====
<pre>zmlocalconfig -e ldap_starttls_supported=1
1. Begin by generating a new Certificate Authority (CA).
zmlocalconfig -e zimbra_require_interprocess_security=1
  /opt/zimbra/bin/zmcertmgr createca -new
zmlocalconfig -e ldap_starttls_required=true</pre>
  /opt/zimbra/bin/zmcertmgr deployca
For this change it is recommended to restart Zimbra using <code>zmcontrol restart</code>.
2. Then generate a certificate signed by the CA that expires in 365 days with either wild-card or subject altnames.
  /opt/zimbra/bin/zmcertmgr createcrt -new -subjectAltNames "*.example.com"
  /opt/zimbra/bin/zmcertmgr createcrt -new -subject "/C=US/ST=CA/O=Example/CN=*.example.com"
  /opt/zimbra/bin/zmcertmgr createcrt -new -subjectAltNames "host1.example.com,host2.example.come"
3. Next, deploy the certificate to all nodes in the deployment.
  /opt/zimbra/bin/zmcertmgr deploycrt self -allserver
4. To finish, verify the certificate was deployed.
  /opt/zimbra/bin/zmcertmgr viewdeployedcrt
'''''Note''': The option '''viewdeployedcrt''' only works for the local server.''


===== Alternate Method =====
= Configuring POP3 =
The "-allserver" command above doesn't always work as expected, depending on whether the ssh keys are current and working properly. One can also create the new CA first on an LDAP Master node, and then manually deploy the CA and create the self-signed certs on all the other nodes:


On an LDAP Master:
It is recommended you disable the use of POP3 via a host firewall, in case you want to use POP3 anyway, disable the unencrypted sending of username and password and force the use of encryption with the following command:
/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca
/opt/zimbra/bin/zmcertmgr createcrt -new -subject "/C=US/ST=CA/O=Example/CN=*.example.com"
OR
/opt/zimbra/bin/zmcertmgr createcrt -new -subjectAltNames "host1.example.com,host2.example.com"
OR
/opt/zimbra/bin/zmcertmgr createcrt -new -subjectAltNames "*.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self


On all other systems:
<pre>zmprov ms `zmhostname` zimbraPop3CleartextLoginEnabled FALSE</pre>
/opt/zimbra/bin/zmcertmgr deployca -localonly
Verify that TLS is required for POP3 via Zimbra Proxy, the setting should be <code>only</code> which is default.
/opt/zimbra/bin/zmcertmgr createcrt -new -subject "/C=US/ST=CA/O=Example/CN=*.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self


==== Single-Node Commercial Certificate ====
<pre>zmprov gs `zmhostname` zimbraReverseProxyPop3StartTlsMode
We need to take care and ask for the Certificate authority for the Root and Intermediate Keys, we will need it soon.
zimbraReverseProxyPop3StartTlsMode: only</pre>
With the above setting the Zimbra POP3 implementation requires the client to issue the STLS command. This command will switch from cleartext to encrypted communications.


We will use at least 2048-bit key, is the minimum for all Certificate Authorities:
If the STLS command is not issued, any command the client sends such as AUTH or USER to Zimbra will result in an error and the client will not try authentication. This means the password is not send without encryption. In addition email contents and attachments are also transmitted using encrypted communication.
1. Begin by generating a Certificate Signing Request (CSR).
<pre>/opt/zimbra/bin/zmcertmgr createcsr comm -new -subject "/C=US/ST=CA/L=Sunnyvale/O=Zimbra/OU=Zimbra Collaboration Suite/CN=host.example.com" -subjectAltNames host.example.com</pre>
2. Next, submit the CSR to the SSL provider and get a commercial certificate in PEM format. Save the new certificate to a temporary file (e.g. /tmp/commercial.crt).


3. Now, download and save the root Certificate Authority (CA) from your provider to a temporary file. (e.g. /tmp/ca.crt)
== False positives in OpenVAS and warnings in email clients such as Thunderbird ==


4. Download any intermediary CAs from your provider to a temporary file. (e.g. /tmp/ca_intermediary.crt)
Email clients and vulnerability scanner can send some commands in plain text to Zimbra, such as CAPA (to list capabilities) and Zimbra will respond to these without encryption. This will make vulnerability scanners such as OpenVAS believe POP3 is enabled for unencrypted connections. This is however not the case. The false positive will look like this:


5. Combine root and intermediary CAs into a temporary file.
<code>The remote host is running a POP3 daemon that allows cleartext logins over unencrypted connections.</code>
<pre>cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt</pre>
6. Verify your commercial certificate.
<pre>/opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key /tmp/commercial.crt /tmp/ca_chain.crt
**Verifying /tmp/commercial.crt against
/opt/zimbra/ssl/zimbra/commercial/commercial.key
Certificate (/tmp/commercial.crt) and private key
(/opt/zimbra/ssl/zimbra/commercial/commercial.key) match.
Valid Certificate: /tmp/commercial.crt: OK</pre>
7. Deploy your commercial certificate.
<pre>/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt
** Verifying /tmp/commercial.crt against
/opt/zimbra/ssl/zimbra/commercial/commercial.key
Certificate (/tmp/commercial.crt) and private key
(/opt/zimbra/ssl/zimbra/commercial/commercial.key) match.
Valid Certificate: /tmpt/commercial.crt: OK
**Copying commercial.crt to /opt/zimbra/ssl/zimbra/commercial/commercial.crt
**Appending CA chain /tmp/ca_chain.crt to
/opt/zimbra/ssl/zimbra/commercial/commercial.crt
**Saving server config key zimbraSSLCeretificate…done.
**Saving server config key zimbraSSLPrivateKey…done.
**Installing mta certificate and key…done.
**Installing slapd certificate and key…done.
**Installing proxy certificate and key…done.
**Creating pkcs12 file /opt/zimbra/ssl/zimbra/jetty.pkcs12…done.
**Creating keystore file /opt/zimbra/mailbox/etc/keystore…done.
**Installing CA to /opt/zimbra/conf/ca…done.</pre>
8. To finish, verify the certificate was deployed.
<pre>/opt/zimbra/bin/zmcertmgr viewdeployedcrt</pre>


==== Single-Node Wildcard Commercial Certificate ====
For the same reason you can add your Zimbra account with POP3 to Thunderbird (and other clients) and select <code>Connection security: none</code> this will trigger a warning, saying your credentials will be transmitted without encryption. In reality the communication between the client and Zimbra will halt because of errors before authentication unless TLS is used.
Using a Wildcard Certificate, you will need the next files, because you probably generated the CSR in other server:
* The .key file which you generated the CSR.
* The .crt file that you SSL provide to you.
* The CA Intermediate and the root files merged into one only file, called for example ca_chain.crt


1.- Backup your actual .key file located in '''/opt/zimbra/ssl/zimbra/commercial/commercial.key''':
This has been verified by using Wireshark.
mv /opt/zimbra/ssl/zimbra/commercial/commercial.key /opt/zimbra/ssl/zimbra/commercial/commercial.key.backup
2.- Move your actual .key file into the path '''/opt/zimbra/ssl/zimbra/commercial/''' with the name commercial.key:
mv /tmp/wildcard.key /opt/zimbra/ssl/zimbra/commercial/commercial.key
3.- Verify all the files before deploy the SSL certificate with the next command:
/opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key /tmp/wildcard.crt /tmp/ca_chain.crt
4.- Then as user '''root (or zimbra for 8.7+)'''  run the next command, please be sure to use the proper path instead /tmp:
/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/wildcard.crt /tmp/ca_chain.crt
5.- Restart your Zimbra Collaboration server as Zimbra user:
zmcontrol restart
6.- To finish, verify the certificate was deployed.
  /opt/zimbra/bin/zmcertmgr viewdeployedcrt


==== Multi-Node Commercial Certificate ====
= Configuring IMAP =
1. We'll start by assuming you have your Commercial Certificate. If you don't, please see above.


2. Store the certificate and CA Chain on one of your systems:
It is recommended you disable the use of IMAP via a host firewall, in case you want to use IMAP anyway, very that you have the following settings, that are the default and disable the unencrypted sending of username and password and force the use of encryption with the following command:
* Signed Certificate: /tmp/commercial.crt
* Certificate Key (Private): /tmp/commercial.key
* Root Certificate Authority (CA Root): /tmp/ca.crt
* Any Intermediate CA Certs: /tmp/ca_intermediary.crt


3. Combine root and intermediary CAs into a temporary file.
<pre>zmprov gs `zmhostname` zimbraImapCleartextLoginEnabled
  cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt
zmprov ms `zmhostname` zimbraImapCleartextLoginEnabled FALSE # if not already</pre>
Verify that TLS is required for IMAP via Zimbra Proxy, the setting should be <code>only</code> which is default.


4. [Optional Step] If you previously had an earlier Commercial Certificate on this platform, it may help - make this easier and more consistent - to remove the old ones:
<pre>zmprov gs `zmhostname` zimbraReverseProxyImapStartTlsMode
  mv /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.old
zimbraReverseProxyImapStartTlsMode: only</pre>
Then recreate the directories:
= Configuring Admin UI =
  mkdir /opt/zimbra/ssl/zimbra
  mkdir /opt/zimbra/ssl/zimbra/ca
  mkdir /opt/zimbra/ssl/zimbra/commercial
  mkdir /opt/zimbra/ssl/zimbra/server
  chmod 740 /opt/zimbra/ssl/zimbra    # chmod 750 for ZCS 8.7+
  chmod 740 /opt/zimbra/ssl/zimbra/*  # chmod 750 for ZCS 8.7+


4.5 If you go for step 4, copy the contents of /opt/zimbra/ssl/zimbra.old/ca/ directory to /opt/zimbra/ssl/zimbra/ca/
It is not recommended to expose the Admin UI to the Internet. Instead administrators should access Admin UI via a VPN. In any case you will need to make sure to proxy the Admin UI via Zimbra Proxy to make sure it uses the best TLS configuration. This means you should access Admin UI via the proxied port 9071, and deny access to port 7071 via a firewall. To enable this you should run as user Zimbra:
  cp -pr /opt/zimbra/ssl/zimbra.old/ca/* /opt/zimbra/ssl/zimbra/ca/
 
5. Copy the commercial.key to /opt/zimbra/ssl/zimbra/commercial
  cp /tmp/commercial.key /opt/zimbra/ssl/zimbra/commercial/
  chmod 640 /opt/zimbra/ssl/zimbra/commercial/commercial.key
5. Verify your commercial certificate. (as user '''root in 8.6- or zimbra in 8.7+'''):
  /opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key /tmp/commercial.crt /tmp/ca_chain.crt
6. Deploy your commercial certificate.
  /opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt
7. To finish, verify the certificate was deployed.
  /opt/zimbra/bin/zmcertmgr viewdeployedcrt
8. In case of any issues in the Java keystore, check that the Intermediate CA was added to the keystore:
 
  <8.7 # /opt/zimbra/java/bin/keytool -list -keystore \
    /opt/zimbra/java/jre/lib/security/cacerts -storepass changeit
OR
  8.7+ $ keytool -list -keystore \
    /opt/zimbra/common/lib/jvm/java/jre/lib/security/cacerts -storepass changeit
 
If necessary, import the CA into the keystore:
 
  <8.7 # /opt/zimbra/java/bin/keytool -import -alias root -keystore \
    /opt/zimbra/java/jre/lib/security/cacerts -storepass changeit -file /opt/zimbra/conf/ca/commercial_ca.pem
OR
  8.7+ $ keytool -import -alias root -keystore \
    /opt/zimbra/common/lib/jvm/java/jre/lib/security/cacerts -storepass changeit -file /opt/zimbra/conf/ca/commercial_ca.pem
 
9. Copy these files to each of your other nodes, and repeat steps 4-8 on each node:
* Signed Certificate: /tmp/commercial.crt
* Certificate Key (Private): /tmp/commercial.key
* Certificate Chain: /tmp/ca_chain.crt
 
Further reading:


* [[IPhone]] for information about iPhone SSL certificates.
<pre>/opt/zimbra/libexec/zmproxyconfig -e -w -C -H `zmhostname`
* [[SecureConfiguration]] for best practices when security a ZCS installation.
zmproxyctl restart</pre>
* [[TLS/STARTTLS_Localconfig_Values]] for information about security related localconfig settings.
= Validate your settings online using SSL Labs =


Go to https://www.ssllabs.com/ssltest/analyze.html and enter the the domain name of your Zimbra server. If you followed the steps in this article you should receive an A+ score and there should be no mention of weak ciphers in the report. This article was written in September 2021. In the report take a look at the client devices listed under <code>Handshake Simulation</code> these will give you an idea of the devices your users can use to connect to your Zimbra server. Also validate there are no weak ciphers listed under <code>Cipher Suites</code>.


{{Article Footer|ZCS 10.0, 9.0, 8.8 | 9/10/2008}}
= Further reading =


[[Category:Administration]]
* https://wiki.zimbra.com/wiki/SecureConfiguration
[[Category:Certificates]]
* https://wiki.zimbra.com/wiki/Postconf_keys
[[Category:Command Line Interface]]
[[Category:Troubleshooting Certificates]]
[[Category:Certified]]

Revision as of 08:17, 4 January 2023

Using Zimbra with strong TLS configuration

Transport Layer Security (TLS) encrypts data sent over the Internet to ensure that eavesdroppers and hackers are unable to see what you transmit which is particularly useful for private and sensitive information such as passwords, credit card numbers, and personal correspondence. (further reading: https://www.internetsociety.org/deploy360/tls/basics)

In this article you will learn how to configure Zimbra to use only strong encryption ciphers for TLS. Configuration settings on this page are routinely validated by our QA team.

Generate ssl_ciphers for use with zimbraReverseProxySSLCiphers

Since encryption is always evolving it is recommended to use Mozilla SSL Config generator that you can find at https://ssl-config.mozilla.org/ in addition we have to disable Diffie-Hellman.

Select Intermediate and Nginx (Zimbra proxy is based on Nginx) at the time of writing this article this will select nginx 1.17.7 and OpenSSL 1.1.1d. The tool also reports the oldest supported clients that work with this configuration: Firefox 27, Android 4.4.2, Chrome 31, Edge, IE 11 on Windows 7, Java 8u31, OpenSSL 1.0.1, Opera 20, and Safari 9.

From the generated config file copy the value from ssl_ciphers: 

ssl_ciphers !DH:!EDH:!ADH:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

Configuring Zimbra Proxy Nginx

Configure Zimbra to use the above ciphers, and enable TLSv1.2 and TLSv1.3 like this: 

zmprov mcf zimbraReverseProxySSLProtocols TLSv1.2
zmprov mcf +zimbraReverseProxySSLProtocols TLSv1.3

zmprov -l mcf zimbraReverseProxySSLCiphers '!DH:!EDH:!ADH:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'

zmproxyctl restart

Configuring Zimbra Mailbox

Also configure Zimbra mailbox to allow the use of TLSv1.3. Open in a text editor /opt/zimbra/conf/localconfig.xml find the line mailboxd_java_options and set TLSv1.2,TLSv1.3 in https.protocols and jdk.tls.client.protocols. Example result: 

<key name="mailboxd_java_options">
  <value>-server -Dhttps.protocols=TLSv1.2,TLSv1.3 -Djdk.tls.client.protocols=TLSv1.2,TLSv1.3 -Djava.awt.headless=true -Dsun.net.inetaddr.ttl=${networkaddress_cache_ttl} -Dorg.apache.jasper.compiler.disablejsr199=true -XX:+UseG1GC -XX:SoftRefLRUPolicyMSPerMB=1 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=15 -XX:G1MaxNewSizePercent=45 -XX:-OmitStackTraceInFastThrow -verbose:gc -Xlog:gc*=info,safepoint=info:file=/opt/zimbra/log/gc.log:time:filecount=20,filesize=10m -Djava.net.preferIPv4Stack=true</value>
</key>

Then restart mailbox, or reboot your server: 

zmmailboxdctl restart

Configure additional HTTP headers

The following headers will:

  • Enable HTTP Strict Transport Security (HSTS)
  • Disable search indexing of your server by Google et al.
zmprov mcf +zimbraResponseHeader "Strict-Transport-Security: max-age=31536000; includeSubDomains"
zmprov mcf +zimbraResponseHeader "X-Content-Type-Options: nosniff"
zmprov mcf +zimbraResponseHeader "X-Robots-Tag: noindex"
zmprov mcf +zimbraResponseHeader "Referrer-Policy: no-referrer"
zmprov mcf zimbraMailKeepOutWebCrawlers TRUE
zmmailboxdctl restart

DH parameters

While we disable Diffie-Hellman for Zimbra Proxy and MTA, Diffie-Hellman may still be used by other Zimbra services. Use pre-defined DHE groups as recommended by IETF RFC 7919.

Further reading: 

wget https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem -O /etc/ffdhe4096.pem
su - zimbra
zmprov mcf zimbraSSLDHParam /etc/ffdhe4096.pem

Reboot the server.

Configuring Zimbra MTA Postfix

Postix traffic is not routed through Zimbra proxy. Below commands show how to configure Zimbra MTA to use only strong TLS ciphers. In 2021 not all mail servers on the Internet support encryption. For maximum compatibility it is still recommended to use Opportunistic TLS. So that you can receive email via unencrypted transmissions. However you can set zimbraMtaTlsSecurityLevel to encrypt to force the use of TLS. This will result in mail delivery issues.

To test the current state of the MTA run from the MTA: 

nmap --script ssl-enum-ciphers -p 25 your-mta-server.example.com

The last line of output with Zimbra default config: least strength: F 

openssl s_client -starttls smtp -showcerts -connect your-mta-server.example.com:25 -servername your-mta-server.example.com -tls1_1

Then the following configuration will remove weak ciphers and disable some Postfix options that are considered unsecure.

Find the current list of ciphers for Postfix via:

https://ssl-config.mozilla.org/#server=postfix

Configure it in Zimbra using: 

zmprov mcf zimbraMtaSmtpdTlsCiphers medium
zmprov mcf zimbraMtaSmtpdTlsMandatoryCiphers  medium
zmprov mcf zimbraMtaSmtpdTlsProtocols '>=TLSv1.2'
zmprov mcf zimbraMtaTlsSecurityLevel may
postconf -e fast_flush_domains=""
postconf -e smtpd_etrn_restrictions=reject
postconf -e disable_vrfy_command=yes
postconf -e tls_medium_cipherlist='!DH:!EDH:!ADH:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384'
postconf -e tls_preempt_cipherlist=no

zmprov gs `zmhostname` zimbraMtaTlsAuthOnly
zmprov ms `zmhostname` zimbraMtaTlsAuthOnly TRUE # if not already (this is default)
zmmtactl restart

IT IS VERY IMPORTANT tls_medium_cipherlist IS SET, setting just medium or high in zimbraMtaSmtpdTlsCiphers/zimbraMtaSmtpdTlsMandatoryCiphers will not work!!

Above config was tested with email from Gmail (uses tls), Ubuntu 20 Postfix (uses tls), from Zimbra itself (uses lmtp) and http://ismyemailworking.com/ (uses plain text) and this all works.

Run again to verify your set-up: 

nmap --script ssl-enum-ciphers -p 25 your-mta-server.example.com

The last line of output with Zimbra new config: least strength: A

It seems TLS v1.3 is either not enabled or not tested via nmap, but you can verify that like so: 

openssl s_client -starttls smtp -showcerts -connect your-mta-server.example.com:25 -servername your-mta-server.example.com -tls1_3

openssl s_client -starttls smtp -showcerts -connect your-mta-server.example.com:25 -servername your-mta-server.example.com -tls1_1

Please note that you can best run nmap/openssl commands on your MTA server to avoid firewall and network blocking issues of port 25.

Configuring Zimbra LDAP OpenLDAP

Zimbra stores passwords in LDAP and is not proxied via Zimbra proxy. To find your current TLS protocols and ciphers you can run nmap, but you will need a recent version of nmap. 

nmap --script ssl-enum-ciphers -p 389 your-ldap-server.example.com

Check and see if TLSv1.0 and TLSv1.1 are enabled (default) and what the least strength cipher is for TLSv1.2 and above (default: A).

To force the use of TLS >= v1.2 with strong Ciphers run the following: 

zmlocalconfig -e ldap_common_tlsprotocolmin="3.3"
zmlocalconfig -e ldap_common_tlsciphersuite="HIGH"

In addition require TLS for LDAP (disable unencrypted LDAP) via: 

zmlocalconfig -e ldap_starttls_supported=1
zmlocalconfig -e zimbra_require_interprocess_security=1
zmlocalconfig -e ldap_starttls_required=true

For this change it is recommended to restart Zimbra using zmcontrol restart.

Configuring POP3

It is recommended you disable the use of POP3 via a host firewall, in case you want to use POP3 anyway, disable the unencrypted sending of username and password and force the use of encryption with the following command: 

zmprov ms `zmhostname` zimbraPop3CleartextLoginEnabled FALSE

Verify that TLS is required for POP3 via Zimbra Proxy, the setting should be only which is default. 

zmprov gs `zmhostname` zimbraReverseProxyPop3StartTlsMode
zimbraReverseProxyPop3StartTlsMode: only

With the above setting the Zimbra POP3 implementation requires the client to issue the STLS command. This command will switch from cleartext to encrypted communications.

If the STLS command is not issued, any command the client sends such as AUTH or USER to Zimbra will result in an error and the client will not try authentication. This means the password is not send without encryption. In addition email contents and attachments are also transmitted using encrypted communication.

False positives in OpenVAS and warnings in email clients such as Thunderbird

Email clients and vulnerability scanner can send some commands in plain text to Zimbra, such as CAPA (to list capabilities) and Zimbra will respond to these without encryption. This will make vulnerability scanners such as OpenVAS believe POP3 is enabled for unencrypted connections. This is however not the case. The false positive will look like this:

The remote host is running a POP3 daemon that allows cleartext logins over unencrypted connections.

For the same reason you can add your Zimbra account with POP3 to Thunderbird (and other clients) and select Connection security: none this will trigger a warning, saying your credentials will be transmitted without encryption. In reality the communication between the client and Zimbra will halt because of errors before authentication unless TLS is used.

This has been verified by using Wireshark.

Configuring IMAP

It is recommended you disable the use of IMAP via a host firewall, in case you want to use IMAP anyway, very that you have the following settings, that are the default and disable the unencrypted sending of username and password and force the use of encryption with the following command: 

zmprov gs `zmhostname` zimbraImapCleartextLoginEnabled
zmprov ms `zmhostname` zimbraImapCleartextLoginEnabled FALSE # if not already

Verify that TLS is required for IMAP via Zimbra Proxy, the setting should be only which is default. 

zmprov gs `zmhostname` zimbraReverseProxyImapStartTlsMode
zimbraReverseProxyImapStartTlsMode: only

Configuring Admin UI

It is not recommended to expose the Admin UI to the Internet. Instead administrators should access Admin UI via a VPN. In any case you will need to make sure to proxy the Admin UI via Zimbra Proxy to make sure it uses the best TLS configuration. This means you should access Admin UI via the proxied port 9071, and deny access to port 7071 via a firewall. To enable this you should run as user Zimbra: 

/opt/zimbra/libexec/zmproxyconfig -e -w -C -H `zmhostname`
zmproxyctl restart

Validate your settings online using SSL Labs

Go to https://www.ssllabs.com/ssltest/analyze.html and enter the the domain name of your Zimbra server. If you followed the steps in this article you should receive an A+ score and there should be no mention of weak ciphers in the report. This article was written in September 2021. In the report take a look at the client devices listed under Handshake Simulation these will give you an idea of the devices your users can use to connect to your Zimbra server. Also validate there are no weak ciphers listed under Cipher Suites.

Further reading

Retrieved from "http://wiki.zimbra.com/index.php?title=Cipher_suites&oldid=69416"
Jump to: navigation, search