Sendmail TLS with multiple virtual domains
ubralod
Say we have 2 domains: abc.foo, xyz.foo. We have one smtp server which
is running sendmail and acts as MX server for both domains. We have
mail.abc.foo and mail.xyz.foo hosts in appropriate dns zone files, both
resolve to the same ip - ip of our smtp server. When we connect to
either of them, we connect to our smtp server. Now we want to provide
TLS for both domains. Is it possible with sendmail? We would like to
purchase 2 certificates for these domains and somehow tell sendmail to
send correct certificate to a client according to the server name to
which this client is connected.
Thanks in advance,
George
Big Negrow
You can 10 pref any host you want as an MX in DNS.
Example:
Host: abc.foo
abc.foo IN MX 10 your.server.com
That way no matter what mail would come to abc.foo, the TLS session
would always be established with your.server.com.
ubralod
The main problem is that we can't do it. abc.foo belongs to our
customer who insists to put mail.abc.foo in his mail client instead of
your.server.com.
Thanks for your reply anyway.
Big Negrow
be responsible for a single certificate to represent it's hostname.
We have wide-scale usage of TLS at my office, but what you ask has
never been brought up before. It's interesting to say the least, since
I too run TLS on a Sendmail box with virtual host assignments at my
residence as well.
Per Hedeland
Negrow" <big.n...@gmail.com> writes:
>Unless there is something within Sendmail I am unaware of, it can only
>be responsible for a single certificate to represent it's hostname.
It's impossible for any MTA to have multiple certificates without using
multiple IP addresses - the server has no way of knowing which host name
the client looked up to make the connection, so can't know which
certificate to present. I guess this could be considered a bug in the
SMTP STARTTLS spec - since the parties *do* communicate before the
establishment of the TLS session, there would have been an opportunity
for the client to inform the server about the host name (e.g. as an
argument to the STARTTLS command). But I assume that if this was
considered at all, it was deemed pointless - as you wrote in your
previous message, it shouldn't matter which host name is used for SMTP.
In the particular case of sendmail, it can't work even when using
multiple IP addresses with one server process (via DAEMON_OPTIONS()),
since you can only specify a single server certificate anyway (via
confSERVER_CERT) - this could in principle be changed, but I don't think
that is likely to happen... So, the only possibility is to have separate
server processes, each with their own config and IP address - they could
still run on the same host of course, and probably share the queue
directory and most everything else too.
>We have wide-scale usage of TLS at my office, but what you ask has
>never been brought up before. It's interesting to say the least, since
>I too run TLS on a Sendmail box with virtual host assignments at my
>residence as well.
Well, it seems SMTP clients (other than MUAs at least) will normally
ignore a failure to verify the server certificate - even if the host
name is correct, it is probably rare that the client has the CA cert
needed for the verification.
--Per Hedeland
p...@hedeland.org
Kari Hurtta
> On Wed, 17 May 2006, Per Hedeland wrote:
> > In article <1147897705....@y43g2000cwc.googlegroups.com> "Big
> > Negrow" <big.n...@gmail.com> writes:
> > >Unless there is something within Sendmail I am unaware of, it can only
> > >be responsible for a single certificate to represent it's hostname.
> >
> > It's impossible for any MTA to have multiple certificates without using
> > multiple IP addresses - the server has no way of knowing which host name
> > the client looked up to make the connection, so can't know which
> > certificate to present. I guess this could be considered a bug in the
> > SMTP STARTTLS spec - since the parties *do* communicate before the
> > establishment of the TLS session, there would have been an opportunity
> > for the client to inform the server about the host name (e.g. as an
> > argument to the STARTTLS command). But I assume that if this was
> > considered at all, it was deemed pointless - as you wrote in your
> > previous message, it shouldn't matter which host name is used for SMTP.
>
> That's a bug? The same thing happens with web servers and HTTPS. One cannot
> virtual host without having a separate IP address for each SSL-ed inbound
> connection of the same port type. However, the best parallel would be if the
> TCP connection came in via SMTPS, not SMTP - for I agree that connecting via
> SMTP then issuing a STARTTLS command with the identity of the destination
> virtual server (if it were allowed) COULD have avoided this issue.
https is _not_ same thing
smtp + starttls on smtp word
correspond
http + Upgrade: TLS on WWW -word
( See http://www.ietf.org/rfc/rfc2817.txt )
That later either do not require every virtual host to be
own ip address although TLS is used.
( On Upgrade: TLS you can send Host: -header on clear text
part before TLS is started. )
/ Kari Hurtta
Per Hedeland
>> Negrow" <big.n...@gmail.com> writes:
>> >Unless there is something within Sendmail I am unaware of, it can only
>> >be responsible for a single certificate to represent it's hostname.
>>
>> It's impossible for any MTA to have multiple certificates without using
>> multiple IP addresses - the server has no way of knowing which host name
>> the client looked up to make the connection, so can't know which
>> certificate to present. I guess this could be considered a bug in the
>> SMTP STARTTLS spec - since the parties *do* communicate before the
>> establishment of the TLS session, there would have been an opportunity
>> for the client to inform the server about the host name (e.g. as an
>> argument to the STARTTLS command). But I assume that if this was
>> considered at all, it was deemed pointless - as you wrote in your
>> previous message, it shouldn't matter which host name is used for SMTP.
>
>virtual host without having a separate IP address for each SSL-ed inbound
>connection of the same port type.
Yes, I actually thought of bringing up the (non-)parallell with HTTPS
here, but decided that it would be too off-topic/long-winded.:-) In
HTTPS (and other "SSL-wrapped" versions of protocols) the problem is
unavoidable, since the SSL handshake happens before the parties have the
opportunity to exchanage any application-level data (notably the HTTP
Host: header that allows for virtual hosting on a single IP address with
plain HTTP).
In fact this practice of doing SSL-wrapped versions of traditional
protocols on a different port is "officially" deprecated these days, in
favor of STARTTLS and the like. There is even STARTTLS-equivalent
functionality specified for HTTP, see RFC 2817 (deployment is another
thing though...).
> However, the best parallel would be if the
>TCP connection came in via SMTPS, not SMTP - for I agree that connecting via
>SMTP then issuing a STARTTLS command with the identity of the destination
>virtual server (if it were allowed) COULD have avoided this issue.
Exactly - SMTPS relates to STARTTLS in SMTP as HTTPS relates to
"Upgrade: TLS/1.0" in HTTP - just that for historical reasons, the
opposite choice has become the "standard standard" in the two cases. And
while RFC 2817 specifically mentions the possibility of virtual hosting
on a single IP address by using the Upgrade mechanism specified, this
issue is ignored (intentionally or not) in the SMTP STARTTLS RFC (now
3207, which doesn't differ in this respect from the original 2487).
--Per Hedeland
p...@hedeland.org
Big Negrow
> Well, it seems SMTP clients (other than MUAs at least) will normally
> ignore a failure to verify the server certificate - even if the host
> name is correct, it is probably rare that the client has the CA cert
> needed for the verification.
Well, not exactly. I've used Thunderbird, Outlook and Cone. Each throw
a warning when the connection is made over TLS/SSL to a server that
presents a certificate with a non-matching hostname or when the
certificate is signed by an unknown CA. Now granted, the connection
does not fail, but the user IS presented with a warning.
The only way around this is for people to just buck up and pay GoDaddy
$17 a year for a Certificate that has TLS client/server extensions. The
signing CA itself is not recognized, but the intermediate signer is.
Per Hedeland
>Per Hedeland wrote:
>> Well, it seems SMTP clients (other than MUAs at least) will normally
>> ignore a failure to verify the server certificate - even if the host
>> name is correct, it is probably rare that the client has the CA cert
>> needed for the verification.
>
>Well, not exactly. I've used Thunderbird, Outlook and Cone. Each throw
>a warning when the connection is made over TLS/SSL to a server that
>presents a certificate with a non-matching hostname or when the
>certificate is signed by an unknown CA. Now granted, the connection
>does not fail, but the user IS presented with a warning.
I *did* say "other than MUAs", and should probably have left off the "at
least" - I would expect all SSL/TLS-capable MUAs to present such a
warning, just like all browsers do (I hope:-). But since the original
question was about virtual domains and Mxen, I think it was mostly an
issue with MTA-MTA connections.
>The only way around this is for people to just buck up and pay GoDaddy
>$17 a year for a Certificate that has TLS client/server extensions. The
>signing CA itself is not recognized, but the intermediate signer is.
Well, for the case of MUAs connecting to a SMTP server within the same
organization, being your own CA should be a feasible alternative.
--Per Hedeland
p...@hedeland.org