Dovecot SNI config management


Following the Enabling SNI for Dovecot on Symbiosis Guide and some discussion (mostly Enabling SNI for Exim on Symbiosis)…

Exim looks after itself (yay!) but dovecot requires manual intervention when sites come and go. So, in preparation for easier management I’ve gone with include files:


# enable sni config on a site-by-site basis
# Alternatively, see (Nov 2018)

!include_try /srv/*/config/dovecot-sni.conf

That way we only have to sudo make the main dovecot.conf once (but changes in the include files will require a service restart).

So, test domain has this…


# include file: /srv/
# enable sni for this site (requires /etc/dovecot/symbiosis.d/10-main/50-x-sni-include)

local_name { 
    ssl_cert = </srv/
    ssl_key  = </srv/ 
local_name { 
    ssl_cert = </srv/ 
    ssl_key  = </srv/ 

Testing it works:

openssl s_client -connect localhost:imap -starttls imap -servername

…picks up the site-6 certificate but complains about an incomplete chain:
Verify return code: 21 (unable to verify the first certificate)

Changing the ssl-cert value from ssl.crt to ssl.combined makes the error go away.

So the immediate questions:

  • Does the error matter?
  • Is it safe to use ssl.bundle which contains the private key? I see people doing it on the Internet :wink: (e.g.) but I’ve also read this…

SSL / Dovecot Configuration

The certificate file can be world-readable, since it doesn’t contain anything sensitive (in fact it’s sent to each connecting SSL client).

… so, is it worth creating an ssl.full-chain file (ssl.combined without key)?

Back to the automation goal: a script to create & manage the config/dovecot-sni.conf files is required. It’ll run manually and via ssl-hooks (when 1+ certificate is updated) and probably at other scheduled times. Although that’s fairly easy under say, bash, it strikes me that Symbiosis already does this in a number of areas – via .erb template, hashes to avoid overwriting manual updates, etc. I’ve no experience in ruby but a couple of the files look fairly easy to adapt. Luckily, I’m not daft enough to say that out loud…

Anyway, answers, any & all input welcome.


Dear All,

The following is an extract from Bytemark’s Enabling SNI for Dovecot guide:

Please note: if you remove a certificate for a domain, you MUST remove the configuration from Dovecot, or Dovecot won’t start.

The Exim and Dovecot SNI docs are immature / incomplete because they lack any domain management details. Domains come and go so it would be handy to understand how to cleanly migrate/ remove a domain and the certifiacte config / setup without Dovecot issues. The panacea of course would be automation of the whole process.

Of course the other alternative to avoiding cert errors would be to set a particular domain for mail collection as documented here:

The setup is a bit more user friendly and has a documented rollback guide plus it allows free movement of domains without Dovecot complaining.

There are advantages and disadvantages with each current approach so I guess anyone trying to conduct a bit of email hosting is caught between a rock and a hard place at this point in time.

Rgds Pete


SNI is the way to go here for a few reasons:

  • telling (organic) clients to connect to [mail.] not is a feel-good factor. Surprisingly significant in some cases
  • domains are autonomous and more easily moved across servers
  • it’ll make any future server replacement easier
  • subjectively, at least, there’s a better chain of trust

In the short to medium term the only downside is the unknown level of mail client support in my client base. Initial tests have shown no problem and workarounds would be relatively pain free (e.g. omit [site]/config/sni-dovecot.conf and use the machine hostname for setup [as-now]).

Imo, dovecot config automation is easily achievable but I’d like to sort some of the details (above) before going live. Ideally, sni would be adopted in core symbiosis but I suspect we’ll have to find our own way via Guides and bespokery for at least a good while.


This looks like a really nice solution, that might make it quite easy for us to build into Symbiosis. I’d definitely take the private key out of the chain, though. I’m going to think about changing our docs based on these tips!

That’s true. But unsupported just means they won’t ask for a specific domain certificate. In that event, they’ll be served the default certificate: so you need to think about which domain that’s going to be. I suspect that all major currently developed mail clients will be using SSL libraries that support SNI, but it might be worth documenting the fallback domain.


Good point. For exim I’ve been pointing at /srv/$primary_hostname/ssl/current/ssl.combined as the fallback instead of the suggested /etc/ssl/ssl.combined and I’m doing similar for dovecot in /etc/dovecot/symbiosis.d/10-main/50-ssl-cert-key-files. This works well because over the years I’ve been using the machine name at the first sign of trouble – and a lot of mail clients seem to have complained about self-signed (I assume that was their beef). Now, with sni, exceptions are easy to deal with and I can migrate configs from the machine hostname to the appropriate domain at leisure.


As it’s looking like there’s a bit more development afoot I’m a bit reluctant to use the SNI solution on a production server.