Re: [Dovecot] virtual domains and SSL certificates
On 12/6/2009, Timo Sirainen (t...@iki.fi) wrote:
> 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.
>>
>>
>> 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 =ssl_key = }
Now the question is, does Thunderbird 3 support it yet? If not, is there
a bug opened? I'll go find out...
Re: [Dovecot] virtual domains and SSL certificates
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.
>
>
> 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 =
Re: [Dovecot] virtual domains and SSL certificates
On 12/06/09 18:24, /dev/rob0 wrote: On Sun, Dec 06, 2009 at 04:23:36PM +, 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? Yes, but hard to resolve as they seem to be getting server from either email address or MX neither of which reliably lead to imap server. Trouble is it works for google and other popular providers. And it is quite an infectious idea. It also assumes that the IMAP protocol has SNI support. IMAP != HTTP. I thought SNI was done in TLS/SSL (before HTTP/IMAP was started). I don't know, but my thought is "don't hold your breath." That's OK, tomorrow will do :-) Dick
Re: [Dovecot] virtual domains and SSL certificates
Dick Middleton wrote: > Hi, > > This topic has been discussed before e.g: > > > 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 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. >
Re: [Dovecot] virtual domains and SSL certificates
On Sun, Dec 06, 2009 at 04:23:36PM +, 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. > > > 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
Re: [Dovecot] virtual domains and SSL certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2008-08-07, at 1206, Eduardo M KALINOWSKI wrote: Which leads us to the request: could it be that in a future version one could select a different certificate for each IP that Dovecot listens to? i have a client who is doing this now- they own two domain names, and they insisted that the users of each domain not have to ever enter the "other" domain name at all, even for something like an IMAP or SMTP server name... so they have two IPs on the server, and each domain has its own IP address. among other things, they're running dovecot under daemontools, using sslserver to answer the socket and handle the SSL negotiations, and they have a different certificate for each service. http://qmail.jms1.net/dovecot.shtml is a page i wrote about running dovecot under daemontools. http://qmail.jms1.net/scripts/service-dovecot-xxx-run is the daemontools "run" script for a dovecot IMAP or POP3 service. it needs to be customized with the details for your service(s); i tried to put enough comments within the script that you shouldn't have any problem understanding how it works and what goes where. - | John M. Simpson -- KG4ZOW -- Programmer At Large | | http://www.jms1.net/ <[EMAIL PROTECTED]> | - | Hope for America -- http://www.ronpaul2008.com/ | - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFImybYj42MmpAUrRoRAgnlAKCJqF3zHtMB+cqGNifNwGOYY1VSKACfUDOz uTdCQkNnbNvsVKKqoJ8l3aQ= =JjOY -END PGP SIGNATURE-
Re: [Dovecot] virtual domains and SSL certificates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] will get a "Security Error: Domain Name Mismatch" in their mail client when connecting through IMAPS. How can I avoid this domain name mismatch error? if you're using normal SSL (usually on port 993) each IP:PORT combination on the server can only have one SSL certificate. this is because the SSL negotiations happen before the internal protocol (in this case, IMAP) ever starts. the SSL protocol does not provide any way for the client to tell the server which hostname they're trying to connect to- the only thing the server knows is what IP and port the client connected to. if you're using STARTTLS, the connection starts as normal, but instead of sending login credentials, the client sends a "STARTTLS" command of some kind, the server says OK, and then starts SSL negotiations within the existing socket. in that kind of scenario it's theoretically possible for the client to tell the server which hostname it wants (so the server can select the appropriate certificate) however i don't think the IMAP protocol has that capability. this is the same kind of issue people run into with other SSL- encrypted services, such as SMTP-SSL or HTTPS. the problem is that when the SSL protocol was designed, they didn't think about a server having a need for multiple certificates, and there are too many existing SSL implementations in use right now to think realistically about changing the protocol at such a basic level. it might be possible to construct a special certificate with multiple CN= fields, or with multiple "alternate name" fields (i forget the X. 509 key for this field) however these are non-standard, and there's no guarantee that all clients will honour, or even understand, such certificates. what i do on my own server is just tell all of my clients that they must use the name "secure.jms1.net" as their IMAP-SSL and SMTP-SSL server names. it doesn't affect the appearance of their outgoing mail at all (other than the "Received" headers, which would happen anyway.) - | John M. Simpson -- KG4ZOW -- Programmer At Large | | http://www.jms1.net/ <[EMAIL PROTECTED]> | - | Hope for America -- http://www.ronpaul2008.com/ | - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFImyNej42MmpAUrRoRAnAuAJ0VnIwa6jpkwODwlfcGJL6dK/c9AQCdF9lq bQSR7ebRO4WBkV8HSpgMeC0= =Gue5 -END PGP SIGNATURE-
Re: [Dovecot] virtual domains and SSL certificates
On 8/7/2008, Eduardo M KALINOWSKI ([EMAIL PROTECTED]) wrote: Which leads us to the request: could it be that in a future version one could select a different certificate for each IP that Dovecot listens to? If I am not mistaken, this is already on the radar for 2.0... -- Best regards, Charles
Re: [Dovecot] virtual domains and SSL certificates
Kacper Wysocki escreveu: Hi all, I have dovecot 1.1.0 setup to access vpopmail accounts for several virtual domains. Dovecot IMAP is accessed through several virtual domains as well, ie mail.foo.com an d mail.bar.com 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 [EMAIL PROTECTED] or [EMAIL PROTECTED] will get a "Security Error: Domain Name Mismatch" in their mail client when connecting through IMAPS. How can I avoid this domain name mismatch error? a) Use a single host name for all domains. b) If you really want different hostnames for all domains, you'll need one IP address for each domain. Dovecot can at this moment listen on several addresses, but it only uses one SSL certificate for all of them, which means you would need several dovecot instantes running. Which leads us to the request: could it be that in a future version one could select a different certificate for each IP that Dovecot listens to?
