[6468] in Release_7.7_team
Re: Problem with username.mail.mit.edu for Exchange
daemon@ATHENA.MIT.EDU (Alex Dehnert)
Mon Oct 12 17:26:55 2009
Message-ID: <4AD39F0B.4070604@mit.edu>
Date: Mon, 12 Oct 2009 17:26:35 -0400
From: Alex Dehnert <adehnert@MIT.EDU>
MIME-Version: 1.0
To: Evan Broder <broder@mit.edu>
CC: "release-team@mit.edu" <release-team@mit.edu>
In-Reply-To: <4AD37917.2040800@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 5
X-Spam-Level: ***** (5)
X-Spam-Flag: NO
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 3280:
>> 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
>
