Hi,
This topic has been discussed before e.g:
<QUOTE>
On 2008-08-07, at 1143, Kacper Wysocki wrote:
The problem is that the configuration file specifies only one
certificate file for dovecot, which means only one Common Name, which
means one cannot provide one server cert that will match mail.foo.com
AND mail.bar.com, and either ma... at foo.com or bo... at bar.com will get a
"Security Error: Domain Name Mismatch" in their mail client when
connecting through IMAPS.
</QUOTE>
I bring it up again because I've just been trying the release candidate
for Thunderbird 3. This has a config wizard which derives from ones
email address the mail server address etc. It doesn't handle SSL
virtual mail servers very well because of this problem.
I have encountered a web server called Cherokee
(http://www.cherokee-project.com) which has virtual server capability
that *demands* a different certificate for each virtual server. How
can that be I thought?
This is what Cherokee documentation says:
<QUOTE>
SSL Virtual Hosts
You might have been told elsewhere that named virtual hosts in SSL
cannot be supported without SNI (Server Name Indication) because a web
server cannot see the hostname header when the SSL request is being
processed. Technically this might have been correct in the past. The
first thing that the server has to do is to connect with the other end
by using SSL/TLS. The user entered host part of the URI must match the
Common Name (CN) provided by the certificate. Since virtual hosts are in
use, the CN of the first available certificate may or may not match the
one specified in the early stages of TLS negotiation.
Cherokee supports the clean and standard method of dealing with this
issue called Server Name Indication (SNI) that sends the name of the
virtual host during the TLS negotiation.
If SNI is supported by your SSL/TLS library, the SSL layer does not need
to be restarted. Since the host info can be put in the SSL handshake,
things will simply work as long as there is a web browser with SNI
support at the other side. Currently every modern web browser supports
this, and Cherokee has TLS SNI support for the OpenSSL backends.
Note that for SNI to work, client support is required. Web browsers
known to support it are Mozilla Firefox 2.0+, Opera 8.0+, Internet
Explorer 7 (Vista, not XP) or later and Google Chrome.
</QUOTE>
If Cherokee can do it why not dovecot? Is this something that is, or
could be, being considered? It does assume that TB3 and other mail
clients support SNI but whatever, I suspect that once TB3 is released
the subject will pop-up more frequently.
I'm curious to know the latest thinking.
Dick
On Sun, Dec 06, 2009 at 04:23:36PM +0000, Dick Middleton wrote:> I bring it up again because I've just been trying the release > candidate for Thunderbird 3. This has a config wizard which derives > from ones email address the mail server address etc. It doesn't > handle SSL virtual mail servers very well because of this problem.I'd consider that a bug in the wizard, wouldn't you?> I have encountered a web server called Cherokee > (http://www.cherokee-project.com) which has virtual server > capability that *demands* a different certificate for each virtual > server. How can that be I thought? > > This is what Cherokee documentation says:[snip]> Cherokee supports the clean and standard method of dealing with this > issue called Server Name Indication (SNI) that sends the name of the > virtual host during the TLS negotiation. > > If SNI is supported by your SSL/TLS library, the SSL layer does not > need to be restarted. Since the host info can be put in the SSL > handshake, things will simply work as long as there is a web browser > with SNI support at the other side. Currently every modern web > browser supports this, and Cherokee has TLS SNI support for the > OpenSSL backends. > > Note that for SNI to work, client support is required. Web browsers > known to support it are Mozilla Firefox 2.0+, Opera 8.0+, Internet > Explorer 7 (Vista, not XP) or later and Google Chrome. > </QUOTE> > > If Cherokee can do it why not dovecot? Is this something that is, > or could be, being considered? It does assume that TB3 and other > mail clients support SNI but whatever, I suspect that once TB3 is > released the subject will pop-up more frequently.It also assumes that the IMAP protocol has SNI support. IMAP != HTTP. I don't know, but my thought is "don't hold your breath." Consider TLS in IMAP and SMTP. The protocols were years ahead of the clients. Even now we see lots of issues with MUAs with inadequate (or NO) TLS support. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Dick Middleton wrote:> Hi, > > This topic has been discussed before e.g: > <snip /> > > Cherokee supports the clean and standard method of dealing with this > issue called Server Name Indication (SNI) that sends the name of the > virtual host during the TLS negotiation. > > <snip/> > > If Cherokee can do it why not dovecot? Is this something that is, or > could be, being considered? It does assume that TB3 and other mail > clients support SNI but whatever, I suspect that once TB3 is released > the subject will pop-up more frequently. > > I'm curious to know the latest thinking. > > Dick > >>From the "Dovecot SSL Limitations" thread last week:Timo Sirainen wrote:> On Nov 30, 2009, at 4:32 PM, AllenJB wrote: > >> Possibly off-topic from what the OP wants, but couldn't TLS Server Name >> Indication (SNI) be used to overcome the single server certificate >> limitation? > > With Dovecot v2.0 and living in theoretical land, sure. >
On Dec 6, 2009, at 11:23 AM, Dick Middleton wrote:> Note that for SNI to work, client support is required. Web browsers known to support it are Mozilla Firefox 2.0+, Opera 8.0+, Internet Explorer 7 (Vista, not XP) or later and Google Chrome. > </QUOTE> > > If Cherokee can do it why not dovecot?It's already implemented for Dovecot v2.0. You can do things like: local imap.foo.org { ssl_cert = </.../imap.foo.org.crt ssl_key = </.../imap.foo.org.key }