Cipher suites: Difference between revisions

No edit summary
No edit summary
Line 1: Line 1:
{{BC|Certified}}
__FORCETOC__
__FORCETOC__
<div class="col-md-12 ibox-content">
<div class="col-md-12 ibox-content">
= Cipher suites =
= ZCS Certificates Tools =
{{KB||{{ZCS 9.0}}|{{ZCS 8.8}}|}}
{{KB|{{ZC}}|{{ZCS 10.0}}|{{ZCS 9.0}}|{{ZCS 8.8}}||}}
{{WIP}}


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)
See also:


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.
* [[https://wiki.zimbra.com/wiki/Cipher_suites Cipher suites]] strong TLS configuration
* [[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 =


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].
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.


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.
== A note on CN and subjectAltName ==


From the generated config file copy the value from <code>ssl_ciphers</code>:
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).


<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>
Per https://tools.ietf.org/html/rfc2818#section-3.1
= Configuring Zimbra Proxy Nginx =
<blockquote>
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>


Configure Zimbra to use the above ciphers, and enable TLSv1.2 and TLSv1.3 like this:
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.


<pre>zmprov mcf zimbraReverseProxySSLProtocols TLSv1.2
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).
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'
= ZCS Administration Console =


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


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:
[[File:SSL_Install_Web_001.png]] [[File:SSL_Install_Web_002.png]]


<pre>&lt;key name=&quot;mailboxd_java_options&quot;&gt;
== Viewing Certificates ==
  &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;
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;/key&gt;</pre>
Then restart mailbox, or reboot your server:


<pre>zmmailboxdctl restart</pre>
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.
== Configure additional HTTP headers ==


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


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


<pre>zmprov mcf +zimbraResponseHeader &quot;Strict-Transport-Security: max-age=31536000; includeSubDomains&quot;
[[File:SSL_Install_Web_004.png]]
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 =


Use pre-defined DHE groups as recommended by [https://tools.ietf.org/html/rfc7919 IETF RFC 7919].
You can refresh the currently displayed details by clicking '''Refresh''' at the top of the tab.


Further reading:
== Generate a valid CSR (Certificate Signing Request) for a Commercial SSL ==
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'''
 
[[File:SSL_Install_Web_006.png]]
 
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].
 
[[File:SSL_Install_Web_007.png]]
 
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'''.
 
[[File:SSL_Install_Web_008.png]]


* https://weakdh.org/
The SSL Certificate Self-Signed are now installing in our Zimbra Collaboration Server.
* https://github.com/internetstandards/dhe_groups


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


= Configuring Zimbra MTA Postfix =
Once the installation has finish, the system request us a restart of the ZCS services.


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.
[[File:SSL_Install_Web_010.png]]


To test the current state of the MTA run from the MTA:
Trough console by user zimbra we need to execute the next command, and wait until all services are up again:
<pre>zmcontrol restart</pre>


<pre>nmap --script ssl-enum-ciphers -p 25 your-mta-server.example.com</pre>
If we will go again to our https://mail.domain.com we will have the known problem with SSL Certificate in our Web Browser:
The last line of output with Zimbra default config: least strength: F


<pre>openssl s_client -starttls smtp -showcerts -connect your-mta-server.example.com:25 -servername your-mta-server.example.com -tls1_1</pre>
[[File:SSL_Install_Web_011.png]]
Then the following configuration will remove weak ciphers and disable some Postfix options that are considered unsecure.
=== Generating Multiple CSRs using the Administration Console ===


Find the current list of ciphers for Postfix via:
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.


https://ssl-config.mozilla.org/#server=postfix
== Maintaining Valid Certificates ==
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.


Configure it in Zimbra using:
= ZCS Certificate CLI =


<pre>zmprov mcf zimbraMtaSmtpdTlsCiphers medium
== zmcertmgr ==
zmprov mcf zimbraMtaSmtpdTlsMandatoryCiphers  medium
This command allows you to manage certificates.
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=&quot;!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&quot;
postconf -e tls_preempt_cipherlist=no


zmprov gs `zmhostname` zimbraMtaTlsAuthOnly
=== General Guidelines ===
zmprov ms `zmhostname` zimbraMtaTlsAuthOnly TRUE # if not already (this is default)
Follow these guidelines when using this command.
zmmtactl restart</pre>
* For versions before 8.7, this tool must be run as root.  '''In 8.7+, this tool is run as user zimbra.'''
'''''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.
==== Commercial Certificate Guidelines ====
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'''


Run again to verify your set-up:
=== Syntax ===
zmcertmgr [options]


<pre>nmap --script ssl-enum-ciphers -p 25 your-mta-server.example.com</pre>
=== Description ===
The last line of output with Zimbra new config: least strength: A
{|style="width:100%" border="1" cellpadding="5" cellspacing="0"
! 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'''
|}


It seems TLS v1.3 is either not enabled or not tested via nmap, but you can verify that like so:
=== Examples ===
The following are examples of using the above options for different installation scenarios.


<pre>openssl s_client -starttls smtp -showcerts -connect your-mta-server.example.com:25 -servername your-mta-server.example.com -tls1_3
==== Single-Node Self-Signed Certificate ====
1. Begin by generating a new Certificate Authority (CA).
  /opt/zimbra/bin/zmcertmgr createca -new
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


openssl s_client -starttls smtp -showcerts -connect your-mta-server.example.com:25 -servername your-mta-server.example.com -tls1_1</pre>
==== Multi-Node Self-Signed Certificate ====
Please note that you can best run nmap/openssl commands on your MTA server to avoid firewall and network blocking issues of port 25.
1. Begin by generating a new Certificate Authority (CA).
  /opt/zimbra/bin/zmcertmgr createca -new
  /opt/zimbra/bin/zmcertmgr deployca
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.''


= Configuring Zimbra LDAP OpenLDAP =
===== Alternate Method =====
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:


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.
On an LDAP Master:
/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


<pre>nmap --script ssl-enum-ciphers -p 389 your-ldap-server.example.com</pre>
On all other systems:
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).
/opt/zimbra/bin/zmcertmgr deployca -localonly
/opt/zimbra/bin/zmcertmgr createcrt -new -subject "/C=US/ST=CA/O=Example/CN=*.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt self


To force the use of TLS &gt;= v1.2 with strong Ciphers run the following:
==== Single-Node Commercial Certificate ====
We need to take care and ask for the Certificate authority for the Root and Intermediate Keys, we will need it soon.


<pre>zmlocalconfig -e ldap_common_tlsprotocolmin=&quot;3.3&quot;
We will use at least 2048-bit key, is the minimum for all Certificate Authorities:
zmlocalconfig -e ldap_common_tlsciphersuite=&quot;HIGH&quot;</pre>
1. Begin by generating a Certificate Signing Request (CSR).
In addition require TLS for LDAP (disable unencrypted LDAP) via:
<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).


<pre>zmlocalconfig -e ldap_starttls_supported=1
3. Now, download and save the root Certificate Authority (CA) from your provider to a temporary file. (e.g. /tmp/ca.crt)
zmlocalconfig -e zimbra_require_interprocess_security=1
zmlocalconfig -e ldap_starttls_required=true</pre>
For this change it is recommended to restart Zimbra using <code>zmcontrol restart</code>.


= Configuring POP3 =
4. Download any intermediary CAs from your provider to a temporary file. (e.g. /tmp/ca_intermediary.crt)


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:
5. Combine root and intermediary CAs into a temporary file.
<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>


<pre>zmprov ms `zmhostname` zimbraPop3CleartextLoginEnabled FALSE</pre>
==== Single-Node Wildcard Commercial Certificate ====
Verify that TLS is required for POP3 via Zimbra Proxy, the setting should be <code>only</code> which is default.
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


<pre>zmprov gs `zmhostname` zimbraReverseProxyPop3StartTlsMode
1.- Backup your actual .key file located in '''/opt/zimbra/ssl/zimbra/commercial/commercial.key''':
zimbraReverseProxyPop3StartTlsMode: only</pre>
mv /opt/zimbra/ssl/zimbra/commercial/commercial.key /opt/zimbra/ssl/zimbra/commercial/commercial.key.backup
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.
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


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.
==== Multi-Node Commercial Certificate ====
1. We'll start by assuming you have your Commercial Certificate. If you don't, please see above.


== False positives in OpenVAS and warnings in email clients such as Thunderbird ==
2. Store the certificate and CA Chain on one of your systems:
* 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


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:
3. Combine root and intermediary CAs into a temporary file.
  cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt


<code>The remote host is running a POP3 daemon that allows cleartext logins over unencrypted connections.</code>
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:
  mv /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.old
Then recreate the directories:
  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+


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.
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/
  cp -pr /opt/zimbra/ssl/zimbra.old/ca/* /opt/zimbra/ssl/zimbra/ca/


This has been verified by using Wireshark.
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:


= Configuring IMAP =
  <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


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:
If necessary, import the CA into the keystore:


<pre>zmprov gs `zmhostname` zimbraImapCleartextLoginEnabled
  <8.7 # /opt/zimbra/java/bin/keytool -import -alias root -keystore \
zmprov ms `zmhostname` zimbraImapCleartextLoginEnabled FALSE # if not already</pre>
    /opt/zimbra/java/jre/lib/security/cacerts -storepass changeit -file /opt/zimbra/conf/ca/commercial_ca.pem
Verify that TLS is required for IMAP via Zimbra Proxy, the setting should be <code>only</code> which is default.
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


<pre>zmprov gs `zmhostname` zimbraReverseProxyImapStartTlsMode
9. Copy these files to each of your other nodes, and repeat steps 4-8 on each node:
zimbraReverseProxyImapStartTlsMode: only</pre>
* Signed Certificate: /tmp/commercial.crt
= Configuring Admin UI =
* Certificate Key (Private): /tmp/commercial.key
* Certificate Chain: /tmp/ca_chain.crt


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:
Further reading:


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


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>.


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


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

Revision as of 09:36, 21 December 2022

ZCS Certificates Tools

   KB 2661        Last updated on 2022-12-21  




0.00
(0 votes)

See also:


ZCS allows administrators to manage their 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.

A note on CN and subjectAltName

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).

Per https://tools.ietf.org/html/rfc2818#section-3.1

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.

See also RFC2459 section-4.2.1.7 for details on Subject Alternative Name handling and usage.

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).

ZCS Administration Console

The ZCS Certificates tools are located in the Navigation pane, under Configure>Certificates

SSL Install Web 001.png SSL Install Web 002.png

Viewing Certificates

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.

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.

SSL Install Web 003.png

Information about the certificate:

SSL Install Web 004.png

You can refresh the currently displayed details by clicking Refresh at the top of the tab.

Generate a valid CSR (Certificate Signing Request) for a Commercial SSL

Go to Home > Configure > Certificates and click in the settings icon, then click on Install Certificate

Zimbra-ssl-adminconsole-001.png

Select the target server to generate the SSL files like the CSR and the private key:

Zimbra-ssl-adminconsole-002.png

In the next step, select the option Generate the CSR for the commercial certificate authorizer

Zimbra-ssl-adminconsole-003.png

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.

Zimbra-ssl-adminconsole-004.png

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:

Zimbra-ssl-adminconsole-005.png

You can check if your CSR is valid and correct using for example 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

SSL Install Web 005.png

Next, we need to mark the checkbox Replace the existing CSR

SSL Install Web 006.png

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 - [1].

SSL Install Web 007.png

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.

SSL Install Web 008.png

The SSL Certificate Self-Signed are now installing in our Zimbra Collaboration Server.

SSL Install Web 009.png

Once the installation has finish, the system request us a restart of the ZCS services.

SSL Install Web 010.png

Trough console by user zimbra we need to execute the next command, and wait until all services are up again:

zmcontrol restart

If we will go again to our https://mail.domain.com we will have the known problem with SSL Certificate in our Web Browser:

SSL Install Web 011.png

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.

Maintaining Valid Certificates

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.

ZCS Certificate CLI

zmcertmgr

This command allows you to manage certificates.

General Guidelines

Follow these guidelines when using this command.

  • 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

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

zmcertmgr [options]

Description

Name Description
General Options
-help Displays usage options for zmcertmgr
Self-Signed Certificate Options
createca [-new] [-keysize keysize] [-digest digest] [-subject subject]
Generates a Certificate Authority (CA).
deployca [-localonly]
Deploys a Certificate Authority (CA). The -localonly avoids updating any certificate related settings in LDAP.
createcsr <self|comm> [-new] [-keysize keysize] [-digest digest] [-subject subject] [-subjectAltNames "host1,host2"]
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).

createcrt [-new] [-days validation days] [-keysize keysize] [-digest digest] [-subject subject] [-subjectAltNames "host1,host2"]
Creates a self-signed certificate based on the CSR generated using createcsr.
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.
‑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).
Self-Signed (self) and Commercial (comm) Certificate Options
deploycrt <<self>|<comm [certfile ca_chain_file]>> [-allservers] [-localonly] [[-deploy $services] ...]
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).
getcrt <self|comm> [-allservers]
savecrt <self|comm> [-allservers]
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).
viewcsr <self|comm> [csr_file]
Shows a certificate signing request (CSR). Optionally, the CSR file can be specified.
viewstagedcrt <self|comm> [certfile]
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.
verifycrt <self|comm> [[[priv_key] [certfile]] [ca_chain_file]]
Combines verifycrtkey and verifycrtchain checks (see below).
verifycrtkey <priv_key> <certfile>
Compares certificate private key and certificate file modulus digests to ensure they match.
verifycrtchain <ca_chain_file> <certfile>
Verifies a certificate chain.
viewdeployedcrt [all|ldap|mailboxd|mta|proxy]
Shows a deployed certificate on the local server.
checkcrtexpiration [all|ldap|mailboxd|mta|proxy] [-days days]
Check if certificate(s) expire within -days days

Examples

The following are examples of using the above options for different installation scenarios.

Single-Node Self-Signed Certificate

1. Begin by generating a new Certificate Authority (CA).

 /opt/zimbra/bin/zmcertmgr createca -new

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

1. Begin by generating a new Certificate Authority (CA).

 /opt/zimbra/bin/zmcertmgr createca -new
 /opt/zimbra/bin/zmcertmgr deployca

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

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:

/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:

/opt/zimbra/bin/zmcertmgr deployca -localonly
/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

We need to take care and ask for the Certificate authority for the Root and Intermediate Keys, we will need it soon.

We will use at least 2048-bit key, is the minimum for all Certificate Authorities: 1. Begin by generating a Certificate Signing Request (CSR).

/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

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)

4. Download any intermediary CAs from your provider to a temporary file. (e.g. /tmp/ca_intermediary.crt)

5. Combine root and intermediary CAs into a temporary file.

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

6. Verify your commercial certificate.

/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

7. Deploy your commercial certificate.

/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.

8. To finish, verify the certificate was deployed.

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Single-Node Wildcard Commercial Certificate

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:

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

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:

  • 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.

 cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

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:

 mv /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.old

Then recreate the directories:

 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/

 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:


Verified Against: ZCS 10.0, 9.0, 8.8 Date Created: 9/10/2008
Article ID: https://wiki.zimbra.com/index.php?title=Cipher_suites Date Modified: 2022-12-21



Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »

Jump to: navigation, search