--On August 22, 2005 12:02:49 PM -0700 Harald Tveit Alvestrand
On reviewing T. Schorr's suggestion, I read this paragraph a few times:
The decision of whether or not to believe the authenticity of the
other party in a TLS negotiation is a local matter. However, some
general rules for the decisions are:
- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.
Now... I have a server that is an MX host for half-a-dozen domains, and
has about 3 A records pointing to it (why is a long history).
How does my server know which certificate to present to the client, so
that the above general rule is satisfied?
(For the MX case, the answer might be "content of the MX record" rather
than "domain that contains the MX record" - doesn't help for the A case,
and is not obvious from the text)
Am I missing something obvious?
No - this is a 'known' problem. Its an issue for IMAP and other types of
services too, where people want to run virtual domains off a single server.
<draft-ietf-tls-rfc3546bis-01.txt> (Section 3.1) attempts to address this
by extending TLS to allow the client to specify the server name it is using
during the TLS handshake, thus allowing the server to pick the appropriate
certificate for that name.