[isapros] Re: ISA and SAN Certs
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Thu, 30 Aug 2007 22:22:06 -0700
What question?
The blog was never intended to be a treatise on web-publishing using SAN
certs.
It had one purpose alone - that of providing authoritative description
of an ISA limitation and functional, tested methodologies for working
around this limitation.
The statement, "the Web listener will respond not only to the common
name on the certificate, but will also respond to any of the Subject
Alternative Names (SANs)" is incorrect, pure and simple. With the
exception of IE on Vista & Longhorn (and some Linux apps [see RFC 4366
for the gory details]), the client never supplies the "server name"
information during the SSL handshake (you know; when certificates are
exchanged). Even for those that do, Windows 2003 does not process this
part of the request and so the server (read: ISA) cannot respond in any
specific "name" context.
For the foreseeable future, the client-server SSL handshake works like
unto thusly (summarized for simplicity):
Client --> [SSL Client Hello] --> Server
Server --> [SSL Server Hello, Certificate] --> Client
..client validates the certificate, exchanges keys with server,
establish encryption and may perform other negotiation as well..
---- SSL session is now established ----
Client --> [GET /abs_path HTTP/1.x] --> Server
..this request includes a "host" header with FQDN of server name..
---- this is the place where the WPR makes the "public name" decision
----
Note that at no time have my hands left my arms...
Jim
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thomas W Shinder
Sent: Thursday, August 30, 2007 8:36 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
But that doesn't answer the question.
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jim Harrison
Sent: Thursday, August 30, 2007 10:13 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
ISA Web Listeners don't care about SAN certificates.
There is no specific support nor lack thereof.
The web listener response is limited to an SSL Server Hello message,
which includes the certificate associated with that IP listener. The
certificate is received by the client and it processes the certificate
without any assistance from ISA whatever.
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thomas W Shinder
Sent: Thursday, August 30, 2007 7:12 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
Hmmm. OK. So to use active terminology:
"ISA Web Listeners support SANs and therefore we are able to publish
multiple SSL sites with different FQDNs with a single IP address using a
single certificate since the Web listener will respond not only to the
common name on the certificate, but will also respond to any of the
subject names"
That is what you are saying in 2a.
Tom
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Jim Harrison
Sent: Thursday, August 30, 2007 8:34 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
" implies that ISA doesn't support SANs on the Web listener " - how do
you come to this contusion?
I state very clearly:
<quote>
There are two things that I wish to make very clear about this problem;
it:
1. can only appear in two ISA Server bridging scenarios (as described
in this ISABLOG entry);
a. HTTP Asymmetric
b. HTTPS Symmetric
2. does not affect
a. Certificates that are associated with ISA Server Web
Listeners.
b. User connections to ISA Server Web listeners
</quote>
how is that vague in any way?
Jim
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thomas W Shinder
Sent: Thursday, August 30, 2007 4:32 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
I'd think that Jim might need to update his SAN article. The article
implies that ISA doesn't support SANs on the Web listener, however I
have a guy who has the autodiscover FQDN as a second SAN on the
certificate bound to his Web listener and he's shown me strong evidence
that it actually works, even though it shouldn't.
I wish the Exchange or ISA UE teams could get it together to explain how
to get autodiscovery working correctly and more importantly, show us how
it works with and without DNS SRV records. It looks like once you have
DNS SRV records, its a no brainer.
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> MVP --
Microsoft Firewalls (ISA)
________________________________
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
Sent: Wednesday, August 29, 2007 2:38 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
Never mind :)
I found it:
http://support.microsoft.com/kb/940881
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7>
MVP -- Microsoft Firewalls (ISA)
________________________________
From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder
Sent: Wednesday, August 29, 2007 2:35 PM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
OK, that's an interesting sentence in a KB OL update
article. But there's no mention of this anywhere else on the ms.com
site.
In addition, how do we configure the SRV records?
Service?
Protocol?
Priority?
Weight?
Port number?
Host offering this service?
I try to read minds best as I can, but I'm flailing on
this one :))
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7
MVP -- Microsoft Firewalls (ISA)
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim
Harrison
> Sent: Wednesday, August 29, 2007 2:27 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
>
> DatzDeWun! O'curse it works in real life; I tested
it.
>
> http://support.microsoft.com/kb/939184
> OL 2K7 seeks a "autodiscovery" SRV record first, and
only if
> that fails,
> it'll seek the A record. This is based on the same
domain suffix as
> specified in the mail domain.
> If your OL client is behind a CERN proxy (and it knows
it), it can't
> specify that the proxy should look up a SRV record for
> autodiscover.sfx.
> The proxy assumes that any CERN request will be for a
"host"
> and makes a
> DNS query for an A record.
>
> OL 2K7 uses the SRV record to discover the host
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx]
> On Behalf Of Thomas W Shinder
> Sent: Wednesday, August 29, 2007 12:15 PM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
>
> BAM!!!!
>
> I think I get it. On the TO tab for the
autodiscover.msfirewall.org, I
> can still use owa.msfirewall.org since it resolves to
the same IP
> address as autodiscover.msfirewall.org on the internal
network -- and
> the path is going to /autodiscover, so that's cool.
It's all making
> sense on paper -- now to see if it works in real life
:)
>
> BTW -- why do I need a SRV record for OL
autodiscovery? I haven't seen
> any documentation on that requirement on the Exchange
side.
>
> Thanks!
> Tom
>
> Thomas W Shinder, M.D.
> Site: www.isaserver.org
> Blog: http://blogs.isaserver.org/shinder/
> Book: http://tinyurl.com/3xqb7
> MVP -- Microsoft Firewalls (ISA)
>
>
>
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of
Jim Harrison
> > Sent: Wednesday, August 29, 2007 2:09 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Yes; I'd forgotten about the OL client's "SAN
problem".
> > It amazed me how much noise the Exch folks make
about the same
> > limitation for ISA.. ..but I digress.
> >
> > "Web Publishing Rule that is publishing the
> > autodiscover.msfirewall.org/autodiscover path must
be
> > configured on the
> > TO tab to use autodiscover.msfirewall.org " - how do
you
> cone to that
> > contusion?
> > Why do you think you need to use "autodiscover" in
the ISA rule
> > published hostname? Use whatever works for ISA and
let the
> > client be as
> > stupid as you want.
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx]
> > On Behalf Of Thomas W Shinder
> > Sent: Wednesday, August 29, 2007 12:05 PM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Hi Jim,
> >
> > CIL...
> >
> > Thomas W Shinder, M.D.
> > Site: www.isaserver.org
> > Blog: http://blogs.isaserver.org/shinder/
> > Book: http://tinyurl.com/3xqb7
> > MVP -- Microsoft Firewalls (ISA)
> >
> >
> >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx
> > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of
Jim Harrison
> > > Sent: Wednesday, August 29, 2007 1:49 PM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: ISA and SAN Certs
> > >
> > > All good points, but really orthogonal to the
question of how ISA
> > > handles SAN certs. Actually, I wrote that because
some folks were
> > > whining about how ISA handled SAN certs in
general. In
> > fact, I tried
> > > not to delve into the variant forms of
self-inflicted ISA
> manglement
> > > pain that were filling other blogs.
> > >
> > > Q1 - Why do you need a second listener? Use your
DNS to point
> > > autodiscover to the same Exch listener. The
public name is a
> > > rule; not
> > > a listener arttribute.
> >
> > TOM: We need a second listener because we can't have
two
> certificates
> > with different common names listening on the same
listener using the
> > same IP address. OK, in ISA 2006 I *can* use
multiple
> > certificates using
> > the same listener, but each of the certificates must
be
> assigned to a
> > different IP address, so no big deal there -- so I
create two
> > different
> > Web Publishing Rules -- one for owa.msfirewall.org
and a second Web
> > Publishing Rule for autodiscover.msfirewall.org. So
far so
> > good and SANs
> > aren't even an issue.
> >
> > > Q2 - why does the external OL client give a rats
bahootie
> > > what's listed
> > > in the cert used at the CAS? It never sees it.
> >
> > TOM: That's true and I didn't mean to imply that it
did. The
> > concern is
> > that common name and the first SAN on the Web site
> > certificate bound to
> > the Client Access Server site is owa.msfirewall.org.
The
> second SAN is
> > autodiscover.msfirewall.org
> >
> >
> > > Q3 - why is the lack of the autodiscover.suffix
public
> name make the
> > > /autodiscover path "useless"? "Incomplete"
perhaps, but
> > > hardly useless.
> >
> > TOM: Because the OWA publishing rule is listening
for
> > owa.msfirewall.org, NOT autodiscover.msfirewall.org.
Since
> > there are two
> > certificates involved here, one with the common name
> > owa.msfirewall.org
> > and a second with autodiscover.msfirewall.org -- we
have to use two
> > different IP addresses, and owa.msfirewall.org is
NOT going
> to resolve
> > to the same IP address as
autodiscover.msfirewall.org. Thus,
> > adding the
> > /autodiscover path to the owa.msfirewall.org Web
Publishing
> Rule won't
> > work and is extraneous. The /autodiscover path only
applies to the
> > autodiscover.msfirewall.org Web Publishing Rule.
> >
> > >
> > > IOW, create your SRV and A records for
autodiscover.suffix, add
> > > "autodiscover.suffix" to the public names (ISA
2006 only) and
> > > make sure
> > > the cert used in the ISA web listener includes
> > > "autodiscover.suffix" in
> > > the SAN.
> >
> > Again, the issue isn't with the Web listeners, I
have no
> problem with
> > that. The issue is with the connection between the
ISA
> > Firewall and the
> > Client Access Server. The Web site certificate bound
to the Client
> > Access Server has a common name and a first SAN name
of
> > owa.msfirewall.org and a second SAN name of
> > autodiscover.msfirewall.org.
> >
> > Given that, the Web Publishing Rule that is
publishing the
> > autodiscover.msfirewall.org/autodiscover path must
be
> > configured on the
> > TO tab to use autodiscover.msfirewall.org --
HOWEVER, and
> this is THE
> > QUESTION -- with the ISA Firewall when establishing
the SSL channel
> > between itself and the Client Access Server, be able
to use
> the SECOND
> > SAN on the Client Access Server Web site certificate
to allow the
> > connection?
> >
> > Make sense?
> >
> >
> > >
> > > Jim
> > >
> > > -----Original Message-----
> > > From: isapros-bounce@xxxxxxxxxxxxx
> > > [mailto:isapros-bounce@xxxxxxxxxxxxx]
> > > On Behalf Of Thomas W Shinder
> > > Sent: Wednesday, August 29, 2007 11:33 AM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: ISA and SAN Certs
> > >
> > > This is a good step in understanding some of the
issues,
> > but I suspect
> > > the major problems people are running into relates
to
> publishing the
> > > autodisocvery site. You'll notice that when you
run the Exchange
> > > Publishing Wizard in ISA 2006 that is includes an
> > /autodiscover path,
> > > which is completely useless, since the client is
looking for
> > > autodiscover.domain.com/autodiscover and not the
Client
> > Access Server
> > > Public Name, which would be something like
owa.domain.com.
> > >
> > > OK, easy problem to solve, right? All we need to
do is
> > create a second
> > > Web listener on a second IP address and configure
it to listen for
> > > public name autodiscover.company.com. HOWEVER,
the Client Access
> > > Server's common/subject name and first SAN is
owa.company.com. The
> > > second SAN is autodiscover.company.com.
> > >
> > > So, if we put on the TO tab
autodiscover.company.com, will
> > ISA 2006 be
> > > able to "consume" the second SAN to support to the
Outlook 2007
> > > autodiscovery service?
> > >
> > > Thanks!
> > > Tom
> > >
> > > Thomas W Shinder, M.D.
> > > Site: www.isaserver.org
> > > Blog: http://blogs.isaserver.org/shinder/
> > > Book: http://tinyurl.com/3xqb7
> > > MVP -- Microsoft Firewalls (ISA)
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: isapros-bounce@xxxxxxxxxxxxx
> > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf
Of Jim Harrison
> > > > Sent: Wednesday, August 29, 2007 1:10 PM
> > > > To: isapros@xxxxxxxxxxxxx
> > > > Subject: [isapros] ISA and SAN Certs
> > > >
> > > >
> > > > Another isablog for your reading pleasure.
> > > >
> > > >
> > > >
http://blogs.technet.com/isablog/archive/2007/08/29/certificat
> > > > es-with-mu
> > > >
ltiple-san-entries-may-break-isa-server-web-publishing.aspx
> > > >
> > > > All mail to and from this domain is GFI-scanned.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > All mail to and from this domain is GFI-scanned.
> > >
> > >
> > >
> > >
> >
> >
> > All mail to and from this domain is GFI-scanned.
> >
> >
> >
> >
>
>
> All mail to and from this domain is GFI-scanned.
>
>
>
>
All mail to and from this domain is GFI-scanned.
All mail to and from this domain is GFI-scanned.
All mail to and from this domain is GFI-scanned.
Other related posts:
