This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.

Dovecot SSL configuration

The most important SSL settings are (in conf.d/10-ssl.conf):

ssl = yes
# Preferred permissions: root:root 0444
ssl_cert = </etc/ssl/certs/dovecot.pem
# Preferred permissions: root:root 0400
ssl_key = </etc/ssl/private/dovecot.pem

The certificate file can be world-readable, since it doesn't contain anything sensitive (in fact it's sent to each connecting SSL client). The key file's permissions should be restricted to only root (and possibly ssl-certs group or similar if your OS uses such). Dovecot opens both of these files while still running as root, so you don't need to give Dovecot any special permissions to read them (in fact: do not give dovecot user any permissions to the key file).

It's possible to keep the certificate and the key both in the same file:

# Preferred permissions: root:root 0400
ssl_cert = </etc/ssl/dovecot.pem
ssl_key = </etc/ssl/dovecot.pem

It's also possible to use different certificates for IMAP and POP3. However its important to note that "ssl = yes" must be set globally if you require SSL for any protocol (or dovecot will not listen on the SSL ports), which in turn requires that a certificate and key are specified globally even if you intent to specify certificates per protocol. The per protocol certificate settings override the global setting.:

protocol imap {
  ssl_cert = </etc/ssl/certs/imap.pem
  ssl_key = </etc/ssl/private/imap.pem
protocol pop3 {
  ssl_cert = </etc/ssl/certs/pop3.pem
  ssl_key = </etc/ssl/private/pop3.pem

There are a couple of different ways to specify when SSL/TLS is required:

Note that plaintext authentication is always allowed (and SSL not required) for connections from localhost, as they're assumed to be secure anyway. This applies to all connections where the local and the remote IP addresses are equal. Also IP ranges specified by login_trusted_networks setting are assumed to be secure.

Multiple SSL certificates

Different certificates per IP and protocol

If you have multiple IPs available, this method is guaranteed to work with all clients.

local { # instead of IP you can also use hostname, which will be resolved
  protocol imap {
    ssl_cert = </etc/ssl/dovecot/
    ssl_key  = </etc/ssl/dovecot/

  protocol pop3 {
    ssl_cert = </etc/ssl/dovecot/
    ssl_key  = </etc/ssl/dovecot/

local {
  protocol imap {
    ssl_cert = </etc/ssl/dovecot/
    ssl_key  = </etc/ssl/dovecot/

  protocol pop3 {
    ssl_cert = </etc/ssl/dovecot/
    ssl_key  = </etc/ssl/dovecot/

Note that you will still need a top-level "default" ssl_key and ssl_cert as well, or you will receive errors.

# doveconf -n
doveconf: Error: ssl enabled, but ssl_cert not set

With client TLS SNI (Server Name Indication) support

It is important to note that having multiple SSL certificates per IP will not be compatible with all clients, especially mobile ones. It is a TLS SNI limitation. See SSL/SNIClientSupport for list of clients known to (not) support SNI.

local_name {
  ssl_cert = </etc/ssl/certs/
  ssl_key = </etc/ssl/private/
local_name {
  ssl_cert = </etc/ssl/certs/
  ssl_key = </etc/ssl/private/
# ..etc..

Password protected key files

SSL key files may be password protected. There are two ways to provide Dovecot with the password:

  1. Starting Dovecot with dovecot -p asks the password. It's not stored anywhere, so this method prevents Dovecot from starting automatically at startup.

  2. ssl_key_password setting. Note that dovecot.conf is by default world-readable, so you probably shouldn't place it there directly. Instead you could store it in a different file, such as /etc/dovecot-private.conf containing:

     ssl_key_password = secret

    and then use !include_try /etc/dovecot-private.conf in the main dovecot.conf.

Chained SSL certificates

Put all the certificates in the ssl_cert file. For example when using a certificate signed by TDC the correct order is:

  1. Dovecot's public certificate
  2. TDC SSL Server CA
  3. TDC Internet Root CA
  4. Globalsign Partners CA

SSL security settings

When Dovecot starts up for the first time, it generates new 512bit and 1024bit Diffie Hellman parameters and saves them into <prefix>/var/lib/dovecot/ssl-parameters.dat. After the initial creation they're by default regenerated every week. With newer computers the generation shouldn't take more than a few seconds, but with older computers it can take as long as half an hour. The extra security gained by the regeneration is quite small, so with slower computers, for Dovecot versions prior to v2.2, you might want to disable it:

ssl_parameters_regenerate = 0

From version 2.2, you can specify the wanted DH parameters length using:

ssl_dh_parameters_length = 2048

By default Dovecot's allowed ciphers list contains:

ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

Disallowing more won't really gain any security for those using better ciphers, but it does prevent people from accidentally using insecure ciphers. See for a list of the ciphers.

SSL verbosity

verbose_ssl = yes

This will make Dovecot log all the problems it sees with SSL connections. Some errors might be caused by dropped connections, so it could be quite noisy.

Client certificate verification/authentication

If you want to require clients to present a valid SSL certificate, you'll need these settings:

ssl_ca = </etc/ssl/ca.pem
ssl_verify_client_cert = yes

auth_ssl_require_client_cert = yes
#auth_ssl_username_from_cert = yes

The CA file should contain the certificate(s) followed by the matching CRL(s). Note that the CRLs are required to exist. For a multi-level CA place the certificates in this order:

  1. Issuing CA cert
  2. Issuing CA CRL
  3. Intermediate CA cert
  4. Intermediate CA CRL
  5. Root CA cert
  6. Root CA CRL

The certificates and the CRLs have to be in PEM format. To convert a DER format CRL (e.g. into PEM format, use:

openssl crl -in class3-revoke.crl -inform DER -outform PEM > class3-revoke.pem

With the above settings if a client connects which doesn't present a certificate signed by one of the CAs in the ssl_ca file, Dovecot won't let the user log in. This could present a problem if you're using Dovecot to provide SASL authentication for an MTA (such as Postfix) which is not capable of supplying client certificates for SASL authentication. If you need Dovecot to provide SASL authentication to an MTA without requiring client certificates and simultaneously provide IMAP service to clients while requiring client certificates, you can put auth_ssl_require_client_cert = yes inside of a protocol block as shown below to make an exemption for SMTP SASL clients (such as Postfix).

protocol !smtp {
  auth_ssl_require_client_cert = yes

You may also force the username to be taken from the certificate by setting auth_ssl_username_from_cert = yes.

You may also want to disable the password checking completely. Doing this currently circumvents Dovecot's security model so it's not recommended to use it, but it is possible by making the passdb allow logins using any password (typically requiring "nopassword" extra field to be returned).


Try out your new setup:

openssl s_client -connect

You should see something like this:

depth=2 /O=Root CA/OU= Cert Signing Authority/
verify error:num=19:self signed certificate in certificate chain
verify return:0
Certificate chain
 0 s:/
   i:/O=CAcert Inc./OU= Class 3 Root
 1 s:/O=CAcert Inc./OU= Class 3 Root
   i:/O=Root CA/OU= Cert Signing Authority/
 2 s:/O=Root CA/OU= Cert Signing Authority/
   i:/O=Root CA/OU= Cert Signing Authority/
Server certificate
issuer=/O=CAcert Inc./OU= Class 3 Root
No client certificate CA names sent
SSL handshake has read 5497 bytes and written 293 bytes
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: zlib compression
Expansion: zlib compression
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 114A22BE4625B33F6893124ACF640AE0628B48B5039E90B3B9A20ADF7FA691F3
    Master-Key: B8A55EC91A060575CFB29503FBF7160C2DC8BCBFE02D20A7F704882F72D8D00272D8D002CE5CCC4B94A492F43ED8F
    Key-Arg   : None
    TLS session ticket:
    0000 - 86 c7 46 63 a5 b6 48 74-16 d8 e0 a7 e2 64 e8 89   ..Fc..Ht.....d..
    0010 - 97 90 59 4b 57 f3 e2 b3-e2 d2 88 90 a8 aa b4 44   ..YKW..........D
    0020 - ea 24 08 5e b4 14 7f e1-2a 1a 1c 40 ca 85 e7 41   .$.^....*..@...A
    0030 - 9d 0d a8 4c f7 e3 db 1e-ef da 53 9c fe 43 cc 62   ...L......S..C.b
    0040 - 79 b6 ad ea 9d cf ca b2-37 41 b7 0f ea 7d 59 e8   y.......7A...}Y.
    0050 - 10 01 a0 eb dc c2 63 66-56 54 6a e8 3a 4b 93 49   ......cfVTj.:K.I
    0060 - 77 da e4 4b 21 e8 30 7e-bf 10 91 3a 2c f9 59 80   w..K!.0~...:,.Y.
    0070 - 01 1f 36 0b 92 85 67 55-c8 86 1d 44 b1 6f 0d ae   ..6...gU...D.o..
    0080 - 15 36 b6 49 3a ef 94 9a-ef 6d 27 f0 80 20 43 09   .6.I:....m'.. C.
    0090 - be 70 c5 30 15 3b 93 c6-c1 4c e9 7f 5c 34 98 dd   .p.0.;...L..\4..

    Compression: 1 (zlib compression)
    Start Time: 1292857721
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
+OK Dovecot ready.

Testing CA

The above test procedure returns:

    Verify return code: 19 (self signed certificate in certificate chain)

which is expected result since test command omits option to verify CA root certificate. The following commands will enable CA root certificate validation.

Testing CA On Debian

On Debian derived distributions try:

openssl s_client -CApath /etc/ssl/certs -connect

Testing CA On RHEL

On Red Hat Enterprise Linux derived distributions try:

openssl s_client -CAfile /etc/pki/tls/cert.pem -connect

Testing CA Success

    Verify return code: 0 (ok)

SSL/DovecotConfiguration (last edited 2015-10-30 02:18:10 by ConradPino)