Dovecot TLS Certificate Generation

This page assumes familiarity with the terminology defined on the main Mail Server Page.

Many system administrators have expressed to me that they are going to stick with RSA and wait with transitioning Dovecot to ECDSA certificates until Ed25519 support has become ubiquitous in e-mail clients. Especially with the Android 7.0 bug (mentioned later), that is an understandable position.

If that is your position, then ignore this page and just use the Postfix TLS Certificate Generation scripts. The certificates generated there will be RSA and will work just fine with Dovecot.

That being said, I recommend ECDSA for Dovecot.

Differences from Apache Key / Cert Generation

The shell scripts on the page are virtually identical to the shell scripts on the Apache TLS Certificate Generation page with the following three differences:

EC Curve

Android 7.0 has a very serious bug.

Basically, it only included support for a single curve — prime256v1 (aka secp256r1 and P-256). This did not impact browsers on Android 7.0 as browsers bundle their own TLS libraries, but it did impact virtually every other application including mail clients.

The bug was fixed in Android 7.1.1 but Android has a fundamentally broken update system. Unless your Android device is actually made by Google, you do not get updates from Google but from your device manufacturer. Not all device manufacturers have made the update to 7.1.1 available.

There are still Android devices out there (including my Samsung and my father’s Motorola) that do not have the bug fix update available to them and thus have mail clients which only support either RSA certs or ECDSA certs with prime256v1 but not the other standard curves.

How one of the richest companies in the world could have that drastic of a quality assurance failure just boggles the mind, but they did. Remember that next time you are tempted to give Google your geek worship. They simply do not deserve it — not with a broken design for updates and a very bad bug they should have caught in QA that now results in functional limitations for everyone.

This is what happens without proper diversity in the market. When so much of the market is owned by a few companies, they become sloppy because mistakes like this do not cost them market share, so consumers suffer. Google needs to be split up.

It is my opinion that the best course of action is to continue to use prime256v1 until Android 7.0 devices are very rare, and by that time, hopefully ed25519 will be ubiquitous enough we can switch to that.

For a corporate mail server, you can edit the scripts I provide to instead use secp521r1 and simply require employees with phones that have Android 7.0 to buy a new phone. I hate advocating electronic waste when phones still function, Google really should be fined for Android’s broken update infrastructure contributing to the electronic waste problem.

Conspiracy Theory

It is my opinion that prime256v1 is safe. That being said, I believe it is my responsibility to explain why there is cause for concern. If you trust my opinion you can skip ahead.

The NIST Suite B curves, including prime256v1, have constant parameters that lack transparency with respect to why those constants were chosen. Many Android applications, including chat applications, use ECDSA for key exchange. Many of them now use prime256v1 rather than secp384r1 or secp521r1 (Also Suite B curves but stronger) because using those latter two curves would break compatibility with Android 7.0 devices.

Could the Android 7.0 bug be part of a deal between Google and the U.S. Government? The U.S. Government may have agreed not to prosecute Google for anti-trust violation, something virtually every country except the United States has done, in exchange for Android influencing cryptography towards what the NSA may already have methods to break.

I always found the Android update distribution network to be suspect, how could a company that employs the best geeks in the world have such a broken update system that keeps so many phones from receiving critical updates? Maybe collusion with governments is precisely why.

This is a conspiracy theory, but unfortunately it is very possible. We know Google has colluded with the Chinese government reducing privacy there, they certainly are not above this kind of thing.

Do not underestimate the kind of collusion that can happen between a government like the United States that has been caught spying on its own citizens and a company that literally made its billions by violating the privacy of the masses.

In the case of an IMAPS server, all messages are stored without encryption on the server anyway (unless separately encrypted with PGP or S/MIME) so if the NSA wanted them, they probably could get them without needing a MITM on the key exchange. This conspiracy theory is a concern however with every other application on Android that uses ECDSA with prime256v1. Even with IMAPS there is concern, authentication information (login name and password) would also be vulnerable if a MITM with prime256v1 does exist.

I have to concede that it is perfectly possible no attack exists. Everything is circumstantial.

It is possible that the update distribution process in Android is broken because Google simply has no market motivation to fix it. The update process is not broken for the high end Nexus line made by Google, the update distribution is only broken for the third party makers which usually are less expensive phones and tablets. Their only competition are Apple iOS devices which are expensive and high end.

It is possible that despite having access to the best engineers in the world, a flaw that excludes all RFC specified EC curves except for the weakest one is by accident even though it has been industry standard to run test suites on cryptography libraries since before Android existed specifically to catch this kind of mistake. Perhaps their lack of market competition allows them to be sloppy with testing too.

Without knowing what the potential weakness is, if one even exists, it is hard to jump to conclusions. Prominent politicians have repeatedly called for backdoors, they would likely implement backdoors if they could, but that does not mean they actually can or have.

It is my opinion that what we are seeing is not a backdoor. Rather, the symptoms of degradation of service quality that happens when a monopoly does not have the necessary market competition needed to compel them to quality.

I have this opinion because I have seen no evidence that suggest an attack against prime256v1 in the context of ECDSA signatures has ever taken place.

Still though, it is perfectly understandable why many system administrators prefer to continue using RSA for key exchange on IMAPS / Submission servers until Ed25519 is well supported everywhere.

OCSP Stapling

Dovecot does not yet support OCSP stapling. Support is planned but does not exist yet.

As such, the scripts for Dovecot will not produce certificates that require OCSP stapling.

When Dovecot does have OCSP stapling, I will likely wait several months before updating these scripts just to make sure there are not any issues with the stapling implementation.

Also, Postfix so far has not announced plans to support OCSP stapling. This could be an issue since it is common to use the same certificate Dovecot uses with the Postfix submission service.

Certificate with Chain of Trust

The script for Let’s Encrypt will produce an additional file that contains the certificate combined with the Certificate Authority Bundle. Dovecot configuration frequently uses a single file for both rather than separate files.

Private Key / CSR / Certificate Generation Scripts

For usage instructions, please refer to the Apache TLS Certificate Generation page.

Note that the script names and the files they generate contain IMAPS in them. If you are using POP3 they still work, though I do not personally see a reason to continue supporting POP3.

To generate a Let’s Encrypt certificate:

To generate a CSR for use with a commercial certificate authority:

Remember that both of those scripts, you need to edit them for a few local details (such as admin e-mail address) before you run them.

Let’s Encrypt Notes

Sample session with the Let’s Encrypt script:

[root@librelamp ~]# systemctl stop httpd.service
[root@librelamp ~]# sh
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator standalone, Installer None
Starting new HTTPS connection (1):

[ redacted output ]

TLSA from PubKey:
3 1 1 647F2908F640C8DF29C8D346349A215299125AD33BA8AD5CEA703512D347FEAD

Private Key:    /etc/pki/tls/eff_private/
x.509 Cert:     /etc/pki/tls/eff_certs/
CA Bundle:      /etc/pki/tls/eff_certs/
Cert Plus CAB:  /etc/pki/tls/eff_certs/
DANE TLSA Data: /etc/pki/tls/tlsa/

New Private Key Generated.
Be sure to update your DNS TLSA record(s) if you use DANE
[root@librelamp ~]# systemctl start httpd.service

You only need to stop the httpd service if one is running on the server. Also, make sure your firewall does not block port 80 or 443.

Except when a new key is generated (first time you run it in a calendar year), only the certificate setting (ssl_cert parameter) needs to be updated in the Dovecot /etc/dovecot/conf.d/10-ssl.conf file, the private key (ssl_key parameter) will remain the same.

CSR Script Notes

This script is for generating a CSR that is then manually submitted to a commercial Certificate Authority to obtain a certificate that is valid for one or two years rather than ninety days.

Even though Let’s Encrypt certificates are financially free, if you have the budget honestly I recommend just paying for a two-year Comodo certificate from Namecheap so that frequent renewal is not needed. The cheap PositiveSSL product is probably what you want, unless you need the certificate to be valid for more than one hostname, in which case you want the PositiveSSL Multi-Domain product. The more expensive products (EssentialSSL and InstantSSL) are just marketing, they do not add any actual security. The most expensive option, EV certificates, are meaningless for IMAPS.

I still recommend generating a fresh private key once a year. The reason for a two-year certificate, your certificate does not expire if you are a little later than one year in generating a new one. At $16.00 for the single domain option, that is less than $2.00 a month.

Make January the month you renew. New year, new private key and new certificate. If you first buy a certificate late in the year (and it is a two year certificate) go ahead and skip the first January and wait until the next January to start the January renewal pattern.

While it is not 100% mandatory, it is recommended that you use a single file to contain the certificate and the bundle provided by Certificate Authority. The certificate for your server needs to be first in the file, the intermediary certificates (the Certificate Authority Bundle) come second. To combine them into a single file:

[root@host ~]# cat certificate-file.crt ca-bundle-file.crt >
[root@host ~]# mv /etc/pki/tls/certs/

The resulting file /etc/pki/tls/certs/ is what you will use with the Dovecot ssl_cert directive.

Dovecot Configuration

Edit the file /etc/doveconf/conf.d/10-ssl.conf and change the following directives:

ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem

The ssl_cert directive should reflect your combined ‘Cert Plus CAB’ file.

The ssl_key directive should point to your private key.

ssl_cert = </etc/pki/tls/eff_certs/
ssl_key = </etc/pki/tls/eff_private/

Optional Postfix Configuration

At this time, Postfix MX servers do still need to support RSA key exchange because some MTA clients still do not support ECDSA key exchange.

It still may be desirable to allow ECDSA key exchange for e-mail clients connecting to a submission server.

If you wish to do so, edit you /etc/postfix/ file and find the section that looks like following:

smtps     inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes

Add the following two lines:

  -o smtpd_tls_cert_file=/etc/pki/tls/eff_certs/
  -o smtpd_tls_key_file=/etc/pki/tls/eff_private/

Notice there are no spaces in the parameter definition, not even around the =. In the file spaces are a field delimiter. After the edit it will look something like this:

smtps     inet  n       -       n       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_tls_cert_file=/etc/pki/tls/eff_certs/
  -o smtpd_tls_key_file=/etc/pki/tls/eff_private/

Note the above is for submission on Port 465, as is now recommended. If you still run submission on Port 587 where STARTTLS is required to initiate TLS, the section to edit will start with:

submission inet n       -       n       -       -       smtpd

What the above edit does, it overrides the smtpd_tls_cert_file and smtpd_tls_key_file parameters as defined in /etc/postfix/ but only in the context of SMTPS / Submission.

SMTP MTA clients connecting to Port 25 will still get the RSA certificate, but MUA clients connecting to Port 465 (or 587 if you still use it) will get the ECDSA certificate.

Reload the Postfix daemon after making the change:

[root@host ~]# postfix reload

As this certificate is not used in the context of Port 25, if you use DANE for SMTP you do not need to worry about the TLSA record. You can optionally add a TLSA record for Port 465 (or 587) but to the best of my knowledge, no e-mail clients yet will make use of it, so there is not much of a point in doing so.