Installing a LetsEncrypt SSL Certificate

Revision as of 13:59, 12 July 2016 by Jorge de la Cruz (talk | contribs) (Build the proper Intermediate CA plus Root CA)

Installing a Let's Encrypt SSL Certificate

   KB 22434        Last updated on 2016-07-12  

(one vote)


Step by Step Wiki/KB article to install a Let's Encrypt Commercial Certificate. Disclaimer The Let’s Encrypt Client is BETA SOFTWARE. It contains plenty of bugs and rough edges, and it should be tested thoroughly in staging environments before use on production systems. For more information regarding the status of the project, please see Be sure to check out the Frequently Asked Questions (FAQ).


Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. It could be an option to protect Zimbra Servers with a valid SSL certificate; however, please be aware that is a Beta for now. Some stuff could not work or have issues, so use it at your own risk.

Installing Let's Encrypt on a Zimbra Server

Let's Encrypt must be installed on one Linux machine to obtain the proper SSL Certificate, CA Intermediate, and Private Key. It is not required that it be on the same Zimbra Server, but it could save time and help to obtain the renewals, etc.

  • First Step is to stop the jetty or nginx service at Zimbra level
zmproxyctl stop
zmmailboxdctl stop
  • Second step is to Install git on the Server (apt-get install git/yum install git), and then do a git clone of the project on the folder we want
    • Note: On RedHat/CentOS 6 you will need to enable the EPEL repository before install.
git clone
cd letsencrypt
  • Let's now run Let's Encrypt in auto mode and use the certonly option, because for now the project can't automatically install the cert on Zimbra servers.
root@zimbra86:~/tmp/letsencrypt# ./letsencrypt-auto certonly
    • (This step only happens the first time. This process will not occur when renewing the SSL Certificate if using the same machine.) The process will download all of the OS dependencies that Let's Encrypt needs, and after a few minutes:
Creating virtual environment...
Updating letsencrypt and virtual environment dependencies...../root/.local/share/letsencrypt/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see
./root/.local/share/letsencrypt/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see
      • The process will ask for an Email Address in case of emergency contact or to recover the lost key.


      • The process will ask if we agree with the ToS.


        • In case we run a renewal, or a request for a new FQDN, the process will just take a few seconds.
Updating letsencrypt and virtual environment dependencies.......
Running with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly
      • Let's Encrypt will prompt for the domain to protect, in this lab case (


  • The process will take a few seconds to validate and then will end:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/ Your cert
   will expire on 2016-03-04. To obtain a new version of the
   certificate in the future, simply run Let's Encrypt again.
 - If like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:
   Donating to EFF:          

Where are the SSL Certificate Files?

You can find all your files under /etc/letsencrypt/live/$domain, where $domain is the fqdn you used during the process:

root@zimbra86:/etc/letsencrypt/live/ ls -al
total 8
drwxr-xr-x 2 root root 4096 Dec  5 16:46 .
drwx------ 3 root root 4096 Dec  5 16:46 ..
lrwxrwxrwx 1 root root   42 Dec  5 16:46 cert.pem -> ../../archive/
lrwxrwxrwx 1 root root   43 Dec  5 16:46 chain.pem -> ../../archive/
lrwxrwxrwx 1 root root   47 Dec  5 16:46 fullchain.pem -> ../../archive/
lrwxrwxrwx 1 root root   45 Dec  5 16:46 privkey.pem -> ../../archive/

cert.pem is the certificate

chain.pem is the chain

fullchain.pem is the concatenation of cert.pem + chain.pem

privkey.pem is the private key

Please keep in mind that the private key is only for you.

Build the proper Intermediate CA plus Root CA

Let's Encrypt is almost perfect, but during the files the process built, they just add the chain.pem file without the root CA. You must to use the IdenTrust root Certificate and merge it after the chain.pem

Your chain.pem should look like:


To sum up: chain.pem has to be concatened with the root CA. First the chain and the end of the file the root CA. The order is important.

Verify your commercial certificate.

Move to the Let's Encrypt folder with all files /etc/letsencrypt/live/$domain and then launch the next command as root:

root@zimbra86:/etc/letsencrypt/live/ /opt/zimbra/bin/zmcertmgr verifycrt comm privkey.pem cert.pem chain.pem 
** Verifying cert.pem against privkey.pem
Certificate (cert.pem) and private key (privkey.pem) match.
Valid Certificate: cert.pem: OK

Deploy the new Let's Encrypt SSL certificate

Backup Zimbra SSL directory

Before deploying a good practice is to make a backup.

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.$(date "+%Y%m%d")

Copy the private key under Zimbra SSL path

Before deploying the SSL Certificate, you need to move the privkey.pem under the Zimbra SSL commercial path, like this:

cp /etc/letsencrypt/live/ /opt/zimbra/ssl/zimbra/commercial/commercial.key

Final SSL deployment

Then deploy the certificate as follows:

root@zimbra86:/etc/letsencrypt/live/ /opt/zimbra/bin/zmcertmgr deploycrt comm cert.pem chain.pem 
** Verifying cert.pem against /opt/zimbra/ssl/zimbra/commercial/commercial.key
Certificate (cert.pem) and private key (/opt/zimbra/ssl/zimbra/commercial/commercial.key) match.
Valid Certificate: cert.pem: OK
** Copying cert.pem to /opt/zimbra/ssl/zimbra/commercial/commercial.crt
** Appending ca chain chain.pem to /opt/zimbra/ssl/zimbra/commercial/commercial.crt
** Importing certificate /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt to CACERTS as zcs-user-commercial_ca...done.
** NOTE: mailboxd must be restarted in order to use the imported certificate.
** Saving server config key zimbraSSLCertificate...failed.
** Saving server config key zimbraSSLPrivateKey...failed.
** 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/mailboxd/etc/keystore...done.
** Installing CA to /opt/zimbra/conf/ca...done.

Then you need to restart the services, which will restart the nginx or jetty you stopped before:

zmcontrol restart

Test the new SSL Certificate

The last step is to go to your Web Browser and open the URL of your Zimbra server where you installed the Let's Encrypt SSL Certificate:


You can expand the Certificate Information to see the new SSL Certificate your server is using:


Test the new SSL Certificate with OpenSSL

You can use openssl cli tools to check and test the new SSL certificate:

echo QUIT | openssl s_client -connect $domain:443 | openssl x509 -noout -text | less

where $domain is the fqdn you used during the process

Building Multi-SAN SSL Certificate and complex scenarios

You can do almost everything you need, like Subject Alt Names, different domains, etc. But to see more about this, visit the web of the official project.

Here is an example using two FQDN:

./letsencrypt-auto certonly --standalone -d fqdn1 -d fqdn2

Verifying SSL certificate is not expired

SSL certificates issued by let's encrypt are valid for 90 days during the BETA phase. You need to check the expiration of your SSL certificate. We can suggest using monitoring tools like Nagios. With nagios plugins there's a command which can check the expiration:

/usr/lib/nagios/plugins/check_http --sni -H '<FQDN>' -C 30,14

A warning will be issued 30 days before the expiration, a critical will be issued 14 days before the expiration.

Here is a nagios config file excerpt:

define command{
       command_name    check_https_vhost
       command_line    /usr/lib/nagios/plugins/check_http --sni -H '$ARG1$' -C 30,14
define service{
       use generic-service
       host_name <FQDN>
       service_description SSL <FQDN>
       check_command check_https_vhost!<FQDN>

Additional Content

Verified Against: Zimbra Collaboration 8.6, 8.5 Date Created: 12/05/2015
Article ID: Date Modified: 2016-07-12

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 »

Wiki/KB reviewed by Jorge SME2 Copyeditor Last edit by Jorge de la Cruz
Jump to: navigation, search