Exim + SNI, did anyone get it to work?

Z

zmippie

Verified User
Joined
Apr 19, 2015
Messages
161
After zEitEr's suggestion to use a multi-domain TLS certificate for all domains on my server (adding new ones, when needed), I came to the conclusion that in the long run this would become cumbersome. So I've reverted back to using seperate certificates for each domain (multi-domain certficiates allright, but with just subdomains).

To make this work on one IP address, I have to rely on SNI (Server Name Identification). I managed to set up Dovecot, Pure-FTPD and the webserver (NGINX) working fine, but I'm currently stuck on Exim.

Per the Exim docs, I seem to understand that the ${tls_in_sni} variable should be expanded to whatever server name got fed into the connection. I realize the risk of the server name being passed is a doctored string (like "../../../root/whatever/"), so sanitazion is in order. But that's not my problem right now.

I've set /etc/exim.conf up like the docs say:

tls_certificate = /path/to/exim/certs/${tls_in_sni}.pem
tls_privatekey = /path/to/exim/keys/${tls_in_sni}.key

The Exim docs say:

"If the string tls_in_sni appears in the main section’s tls_certificate option (prior to expansion) then the following options will be re-expanded during TLS session handshake, to permit alternative values to be chosen: tls_certificate, tls_privatekey etc...", found here
​

I know this works only with newer versions of openSSL and Exim, but that's been taken care of. The problem is that the server name is just never expanded.

When I start exim in debug mode, logging the connection details and making a connection which contains a server name, I can confirm that the tls_in_sni variable is just completely empty:

Code: 
9964 tls_certificate file /path/to/exim/certs/.pem
9964 TLS error on connection from <my ip> (openssl.client.net) [22.222.22.22] (SSL_CTX_use_certificate_chain_file file=/path/to/exim/certs/.pem): error:02001002:system library:fopen:No such file or directory

My test from my client command line is:

Code: 
openssl s_client -tls1 -starttls smtp -connect mail.mydomain.com:587 -servername mail.mydomain.com

I tried the (apparantly deprecated) ${tls_sni} variable name too, it didn't matter.

So what am I missing here? Did anyone get this to work reliably? If so, what did you do to sanitize the passed server name string?

Many thanks.
 
smtalk said:
Please check http://forum.directadmin.com/showthread.php?t=50059&p=263954#post263954 :)
Click to expand...

Okay, that's a great example, and it's working perfectly now. I probably should have searched the forum better, but that thread wanders off quite a bit from where it started, so it wouldn't have been so easy. But anyway, many thanks! I still don't quite understand why my (test) version didn't work:

Code: 
tls_certificate = /path/to/exim/certs/${tls_sni}.pem
tls_privatekey = /path/to/exim/keys/${tls_sni}.key

I'm using these exact same file locations in a modified version of your example code.
But maybe it's because the entire path needs to be evaluated for the tls_sni string to get expanded? Still confused.

I'd like to post another question regarding the e-mail services config files, for Dovecot in this case:

I have:
/etc/dovecot.conf​
but I also have a folder:
/etc/dovecot/​
Within that folder, there's another "dovecot.conf" and a bunch of includes (ssl, protocols etc.).
Now the /etc/dovecot.conf seems like a leftover from a previous version (although it says 2.0 in the header), but when I rename it, dovecot won't start. But when I comment everything out in that file, dovecot starts fine. So apparantly, it's required, but not used? How can I find out which config dovecot uses? Thanks a lot.
 
SeLLeRoNe said:
/etc/dovecot.conf is requred, and itself is a symlink to /etc/dovecot/dovecot.conf.
Click to expand...

Thanks for clearing that up. Unfortunately, in my case, it doesn't hold true. The file at /etc/dovecot.conf is definitely not a symlink. I wonder how it can function, because it contains a bunch of relative includes that don't take the /dovecot subdirectory into account.
But as I said, renaming it causes Dovecot to fail. Commenting everything out makes no difference: Dovecot starts and runs without problems.

Still confused...
 
So try to rename it to a temp file (ex. dovecot.conf.old) and create the symlink with ln -s /etc/dovecot/dovecot.conf /etc/dovecot.conf

So you will use the actual CB confs (maybe also a /usr/local/directadmin/custombuild/build dovecot_conf should work aswell)

Regards
 
SeLLeRoNe said:
So try to rename it to a temp file (ex. dovecot.conf.old) and create the symlink with ln -s /etc/dovecot/dovecot.conf /etc/dovecot.conf
Click to expand...

Yes, I could do that. But where is determined which conf file is being used? If I issue this from the command line:

Code: 
doveconf -n

It gives me back:

Code: 
# 2.2.16: /etc/dovecot/dovecot.conf

So it's using the one in the dovecot directory, but the one at /etc is still required. Why?
 
Maybe the init command ask for that :) Not sure honestly :) But for sure the symlink would help you to unify the file :)

Regards
 
SeLLeRoNe said:
Maybe the init command ask for that :) Not sure honestly :) But for sure the symlink would help you to unify the file :)Regards
Click to expand...

I found it, I think: it's a (redundant?) check in the dovecot boot script at (CentOS 6.2):

Code: 
/etc/rc.d/init.d/dovecot

Which is an exact copy of the one I found in the custombuild folder (named "dovecot.boot"), so I assume that this is created by custombuild. In any case, this check seems inappropriate:

Code: 
[ -r /etc/dovecot.conf ] || exit 1

Because that's not the dovecot.conf that dovecot (2.2.16) seems to load for its configuration.

Should I log this somewhere?
 
Since smtalk have already replyed to this topic, i presum he will get notified about this and he will put a fix on this (if applicable) :)

Regards
 
Hello,

zmippie; said:
came to the conclusion that in the long run this would become cumbersome.
Click to expand...

Yes, it might be cumbersome if you host clients on such a server. For personal use it might be the best options, if to consider you have a free multi-domain SSL cert.

zmippie said:
I found it, I think: it's a (redundant?) check in the dovecot boot script at (CentOS 6.2):
Click to expand...

The custombuild 1.x does not write dovecot's configs to /etc/dovecot/, it still uses /etc/dovecot.conf.
So I guess that's the reason you see it init script.

That's only what I've found out :)
 
zEitEr said:
Hello,
The custombuild 1.x does not write dovecot's configs to /etc/dovecot/, it still uses /etc/dovecot.conf.
Click to expand...

Yes, but I've updated to custombuild 2, so it shouldn't require /etc/dovecot.conf to be present in that case. The file is completely ignored by Dovecot, but required by the custombuild-generated dovecot boot script.

The less clutter, the better :)
 
I just posted my thoughts on why it's there. Let John and Martynas to fix if it's a bug ;)
 
Thanks for the report.
The -r /etc/dovecot.conf check really had no business being there :)
That's from dovecot 1.x, and we have been creating a symbolic link /etc/dovecot.cof -> /etc/dovecot/dovecot.conf.
Plus -r is usually used for non-root accounts, and we run as root.
Check has been obliterated on all dovecot.boot* scripts on files1.

Thanks,
John
 
DirectAdmin Support said:
Thanks for the report.
The -r /etc/dovecot.conf check really had no business being there :)
Click to expand...

Thanks for the confirmation John. And thanks for letting me make a (albeit small) contribution to DA's quality :)

PS. Those random questions that are required for posting on this forum, will they go away when my reputation increases? For non-English speakers, it's not always obvious what the right answer is.
 
I would like to confirm your user but apparently my permissions are not enough to do so, John would probably do that (or maybe smtalk or Zeiter aswell)

Regards
 
Yes, they go away after X amount of time and after X posts.
I'll just manually verify your account now, to save you the trouble ;)
John
 
You must log in or register to reply here.
Back
Top