Enabling SNI for Exim on Symbiosis


#1

I’ve implemented the steps on this guide:

https://docs.bytemark.co.uk/article/enabling-sni-for-exim-on-symbiosis/

I thought this was going to allow me to use each individual domain name as the host name for incoming/outgoing, but I’m getting “The certificate for this server is invalid.” messages on my email client (Mac Mail).

Mail still works using the machine name.

Is this not the purpose of implementing this change, or does it simply remove the ‘certificate/server mismatch’ errors that some people are getting?

I’ve managed not to get those errors for a long time now (and I’m sure I wasn’t simply ignoring them) although someone using mail on their iPhone still gets multiple errors. Will this change cause those to be resolved, even using the machine name as the I/O mail server?


Dovecot SNI config management
#2

Having to use the FQDN or a common fixed domain to avoid mail server certificate issues was workable but sub-optimal.

I was surprised to find that Bytemark had published the SNI workaround guides a couple of weeks ago; I don’t think many folk have even tried the guides judging by the lack of banter on these forums.

For me this is a ‘game changer’ because I need to migrate a domain and a bunch of email accounts from an out-dated server as seamlessly as possible.

So, I created a new SymStretch VM and successfully implemented the SNI guides. I have a couple of test domains sending and receiving mail using their own unique mail settings without cert issues and so yes the guides appear to work fine. Noteworthy, a domain will need to have correctly installed ssl certificates prior to implementing the SNI guide.

I found the guides a bit vague to begin but they do work.


#3

I presume I’m doing something wrong then, as it won’t currently work for me.

I have valid LetsEncrypt SSL certs on all domains in question. I’ve only tested one though.


#4

Some quick thoughts. I’m wondering if it’s dovecot not exim (clients tend to Send [exim] & Receive [dovecot] at the same time so watch the error messages carefully. Also, it’s maybe a bit odd that you’ve only mentioned the exim guide).

Sticking with exim though… what does the “verifying it works” test output? it should be something like:

my-brilliant-site1.com: subject=CN = my-brilliant-site1.com
my-brilliant-site2.com: subject=CN = my-brilliant-site2.com
my-brilliant-site3.com: subject=CN = my-brilliant-site3.com

Mail clients can be sticky-fussy; a full reboot might help in some cases. (I’ve seen cases where Outlook and Microsoft Mail require the Account to be nuked).


EDIT 15-02-19: Corrected disgraceful apostrophe error and reported myself to the Apostrophe Protection Society. :slight_smile:


#5

Hi,

You might be onto something there — I didn’t implement the dovecot upgrade. I’d assumed it was all exim given some of the headers I’d seen on my received mails. I may as well implement the dovecot anyway.

Yes I do get the correct domains being listed in the output.

I’ll set up a fresh email account on one of the domains and see if that helps.


#6

Hi,

Setting up dovecot did it (longwinded though it was). Thanks for the heads up.


#7

Great. Noteworthy the dovecot guide has to be implemented each time a new domain is added to the server.


#8

Yes, and entries deleted if a domain is removed.


#9

Good point. Although I’m sure removal’s a synch nevertheless the guide could do with some guidance on domain removal.


#10

The guide is a bit sketchy.

For example it first said you had to create the domain names in /etc/dovecot/symbiosis.d/10-main/ - but I think what it was saying is that was one thing the following script was going to do (which it did)

So I first ended up with duplicate entries, which I had to delete from the created file.

I also had to modify the script with appropriate ‘sudo’ commands, as I’ve removed the root SSH login and use admin instead (I’m pretty sure this is based on Bytemark advice, anyway, so invoking sudo should be part of that script).

At least it seems to work now. My iPhone complained about one account to begin with but then sorted itself out. Just have to configure my wife’s domains and then I think we’re sorted.


#11

The thing that bothers me is the Subdomain implementation strategy. I just don’t get it.

cd /srv/
ln -s $domain mx.$domain/
ln -s $domain mail.$domain/

It’s messy (extraneous dns creating invalid http locations, etc…) and, afaics, it’s still going to create certificate name mismatches. E.g. when the dovecot config points at the main site certificate …

local_name mail.$domain { 
    ssl_cert = < /srv/${domain}/config/ssl/current/ssl.crt 
    ssl_key = < /srv/${domain}/config/ssl/current/ssl.key 
}

… which only supports {$domain} and www.{$domain} names, why do site dns for ‘mx’ and ‘mail’? I hope I’m missing something big here.

Meanwhile, ssl-hooks/!include_try /etc/dovecot/symbiosis-sites/*.conf automation looks compelling and wouldn’t it be great if symbiosis supported wildcard letsencrypt certs?


#12

I’ve taken the easy option and just don’t have any mail going to subdomains :slight_smile:

I didn’t really get what those symbolic links were for either. Is it for people who want to have mx.* or mail.* as a specific mail server?

I only use subdomains for websites and so I’m really not fussed if sub.example.com has email as example.com already has it. And I don’t really care if the mailserver is the same as the main domain name either.


#13

I think they’re used during the tls negotiation (sni).


#14

I know there’s reference to mx. and mail. in the config/dns text files but I’ve never really taken much notice of it.


#15

That’s part of the base magic in symbiosis. :slight_smile:


#16

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


#17

I think this is what a lot of people were trying to avoid. Apart from ease of typing, I don’t see an advantage to using an arbitrary domain name over the machine name. It just makes logical sense (even to a non-tech, I’d presume) to be able to say that the mail server name is the same as the domain name.

Yes, the dovecot stuff is a pain. Mileage varies as to how much. Fortunately for me, domains don’t come and go that often. At least adding a new domain (more common for me) won’t break the system (it just won’t work properly), whereas removing I need to remember to edit dovecot config. I am sure everyone’s email breaking will be enough of a jolt :wink:


#18

Forgive the talking to myself and I hope I’m not pulling the thread around too much.

The bit I was missing appears in Adding an SSL Certificate.

ln -s /srv/example.com /srv/mail.example.com

Symbiosis will then make the website visible on that domain, attempt to handle DNS, and alias everything across, and the next time it retrieves a certificate, it will attempt to get one with all the linked domains as alternate names.

It’s making sense now. I don’t think it’s working here (maybe due to impatience or ssl-only everywhere) but at least I can see the plan now.


#19

I implemented the changes in accordance with the guides and ssl certs are being seamlessly served to my sub-domains. The guides need updating to include some automation so that domains can be removed without Dovecot complaining. I guess we’ll have to wait for Bytemark to work their magic.