[6469] in Release_7.7_team
Re: Problem with username.mail.mit.edu for Exchange
daemon@ATHENA.MIT.EDU (Mitchell E Berger)
Tue Oct 13 06:33:37 2009
Message-Id: <200910131033.n9DAXPoH014433@byte-me.mit.edu>
To: Alex Dehnert <adehnert@MIT.EDU>
cc: Evan Broder <broder@MIT.EDU>,
"release-team@mit.edu" <release-team@MIT.EDU>
In-Reply-To: Your message of "Mon, 12 Oct 2009 17:26:35 EDT."
<4AD39F0B.4070604@mit.edu>
Date: Tue, 13 Oct 2009 06:33:25 -0400
From: Mitchell E Berger <mitchb@MIT.EDU>
X-Spam-Flag: NO
X-Spam-Score: 0.00
In fact, having done a lot of reading about issues related to
servers that have multiple names and virtual hosting over SSL
for scripts.mit.edu work, I can confirm that of the various
different methods used to handle certs for different server
names, SubjectAltName is about the most widely supported.
Pretty much all browsers cope with it (whereas a handful of
them don't cope with SNI, which is what scripts uses).
For the non-scripts folks, if you want some more background
on the mess that is certificates and multiple server names,
take a look at <http://wiki.cacert.org/VhostTaskForce>. The
English isn't great, but it does a decent job of covering the
options, and there's a chart about halfway down that shows how
the various browsers handle them. It doesn't cover mail clients,
but it's not surprising that Thunderbird behaves as Firefox does,
and if Alpine is also pleased with it, then it seems like a
good candidate.
Mitch
> You can probably use SubjectAltName on the certificate in question to
> work around the problem, at least on some clients.
>
> I tested this with a mail server and CA that I control, and confirmed
> that Alpine and Thunderbird will successfully connect to
> alex.imap.dehnert.arctic.org, when presented with a certificate for
> common name mail.dehnert.arctic.org with SubjectAltNames including
> *.imap.dehnert.arctic.org (and, of course, mail.dehnert.arctic.org). (I
> didn't test Mutt because I don't use it, and I couldn't immediately see
> how to point it at a different server.)
>
> I suspect that as long as the common name in the certificate gets left
> alone, other mail clients will be no worse off than they are now, and it
> looks like some, at least, mail clients will nicely handle the
> SubjectAltNames.
>
> This probably isn't as well-supported as changing the IP address, but it
> probably is easier to do.
>
> Anders points out:
> > FWIW, the behavior of wildcard subjectAltNames is left unspecified by RFC 3
> 280:
> >> Finally, the semantics of subject alternative names that include
> >> wildcard characters (e.g., as a placeholder for a set of names) are
> >> not addressed by this specification. Applications with specific
> >> requirements MAY use such names, but they must define the semantics.
> >>
>
> ~~Alex
>
> [ geofft and broder asked me to send an email about this. I'm not on
> release-team@mit.edu, so if there is a reply that you want me to see,
> make sure to keep me on the CC list. ]
>
> Evan Broder wrote:
> > I noticed today that username.mail.mit.edu doesn't work for Exchange
> > users, because mail clients are expecting an SSL certificate that
> > matches username.mail.mit.edu, and imap.exchange is serving up a
> > *.exchange.mit.edu cert.
> >
> > None of Thunderbird, alpine, or mutt are as fascist about certificate
> > validation as Firefox - they all provide a single click/keypress to get
> > through the error, but it's still kind of unfortunate.
> >
> > We could potentially work around this in all of our clients by testing
> > if the user is on Exchange and doing things differently.
> >
> > We could also declare that we don't support anything but OWA on Athena.
> >
> > But I think the best solution would be for user.mail.mit.edu to point to
> > a different IP address than imap.exchange.mit.edu, and have that
> > separate daemon present a *.mail.mit.edu certificate. This has the
> > advantage of not being an Athena-specific solution, since any Exchange
> > user using user.mail is affected by this. On the other hand, it is not a
> > simple solution.
> >
> > Anybody have thoughts on which we should go for?
> >
> > In other news, I think we need a /much/ more formal policy on testing
> > mail changes, given how regularly we've screwed it up.
> >
> > - Evan
> >
>
