[isapros] Re: ISA and SAN Certs

  • From: "Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>
  • To: <isapros@xxxxxxxxxxxxx>
  • Date: Fri, 31 Aug 2007 07:10:40 -0700

Yes, you can.  But only after you turn off the "Jim only sees what he
wants" application level filter :-p

t

> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison
> Sent: Friday, August 31, 2007 7:01 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
> 
> Can so; neener-neener-boo-boo; thpthpthpthp
> 
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-
> bounce@xxxxxxxxxxxxx]
> On Behalf Of Thor (Hammer of God)
> Sent: Friday, August 31, 2007 6:44 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
> 
> That's why he can't communicate ;)
> 
> t
> 
> > -----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: