[isapros] Re: ISA and SAN Certs
- From: "Jim Harrison" <Jim@xxxxxxxxxxxx>
- To: <isapros@xxxxxxxxxxxxx>
- Date: Fri, 31 Aug 2007 07:11:51 -0700
Datzdewun!
Multiple certificates per IP listener is now an RFC-supported process.
Given that this RFC only hit the wires last year, it'll be some time
before you see much in the way of server-side implementations for these
extensions. The client-side code is "cheap" compared to the server-side
code for this mechanism (not to mention the rest of those extensions).
-----Original Message-----
From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thomas W Shinder
Sent: Friday, August 31, 2007 7:08 AM
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA and SAN Certs
Hi Jim,
Looks like I'm there -- the birthing of understanding is painful but
glad you'all stuck with me as I worked through it :)
RFC 4366 3.1 sounds like adding the ability to the client to add a
server_name in the client hello which would allow the server to *select
a certificate* that matches the server_name if such a certificate is
available, correct?
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: Friday, August 31, 2007 8:50 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
>
> SAN certs allow the admin to use a single cert for multiple server
> "contexts"; nothing else. If you operate your own PKI structure, this
> functionality is a real boon. Based on f/b I received during the
> pre-posting blog review, purchased SAN certs can actually
> cost far more
> than individual certs for the same name list.
>
> " all ISA does with the Web listener is impersonate the Web site and
> present its certificate information to the client "
> 99.444% there - ISA (SChannel, really) presents the
> certificate itself;
> not "information gleaned from the certificate"
>
> Jason is correct; in the "reading material" which precedes the
> discussion, I also list the LCS/OCS items that espouse the use of SAN
> certs. It's getting to be "the next big thing!!"
>
> If you're interested in another can of gasoline for the SSL
> fire, have a
> read in RFC 4366.
> www.ietf.org/rfc/rfc4366.txt; specifically "3.1. Server Name
> Indication". IE on Vista & Longhorn support this, but so
> far, extremely
> few servers do (my research is admittedly thin here). Current server
> versions of Windows (including LH) do not.
>
> Jim
>
> -----Original Message-----
> From: isapros-bounce@xxxxxxxxxxxxx
> [mailto:isapros-bounce@xxxxxxxxxxxxx]
> On Behalf Of Thomas W Shinder
> Sent: Friday, August 31, 2007 6:37 AM
> To: isapros@xxxxxxxxxxxxx
> Subject: [isapros] Re: ISA and SAN Certs
>
> Hi Jason,
>
> I think what bugged me was that I wasn't thinking about how the SSL
> handshake works when interpreting this issue and for some reason I was
> assigning ISA resposibility for something that it's not even
> responsible
> for. For some reason I thought that "ISA didn't support SANs" when all
> ISA does with the Web listener is impersonate the Web site and present
> its certificate information to the client -- and then it's up to the
> client to "consume" the SANs and if the client is unable to
> do so, then
> the SANs get ignored.
>
> And if I understand things correctly now, the phenomenum that Jim was
> trying to explain in his blog entry was how ISA behaves *as an SSL
> client* to the published SSL server. Again, it's a client issue, not a
> server issue since all the server does it present it's server
> certificate to the SSL client.
>
> I think I'm getting closer to the brass ring :)
>
> 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 Jason Jones
> > Sent: Friday, August 31, 2007 8:25 AM
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > Tom,
> >
> > I think the issue is more widespread than Exchange, if you look at
> > things like LCS/OCS as an example they too are starting to
> really need
> > the use of SANs. The issue seems to be that applications are
> > connecting
> > to a single web service using SSL, but using different
> FQDNs. The only
> > way to solve this is to use SAN certs or wildcard certs,
> > because the SSL
> > handshake will always do an FQDN vs. common name check.
> >
> > Maybe Exchange is the first "big app" to bring this into
> > public focus. I
> > remember a similar pain when we looked at LCS last year, but
> > that is no
> > a distant painful memory :-)
> >
> > Personally, in my experience it is often just easier to use
> wildcards
> > than SAN certs, especially since ISA2k6 now supports this
> properly and
> > Windows Mobile 6 too. Not always the best solution security
> > wise due to
> > a single private key, but at least solves the FQDN vs common
> > name checks
> > if this is what bugs you. The main downside is cost :-(
> >
> > Cheers
> >
> > JJ
> >
> > -----Original Message-----
> > From: isapros-bounce@xxxxxxxxxxxxx
> > [mailto:isapros-bounce@xxxxxxxxxxxxx]
> > On Behalf Of Thomas W Shinder
> > Sent: 31 August 2007 14:15
> > To: isapros@xxxxxxxxxxxxx
> > Subject: [isapros] Re: ISA and SAN Certs
> >
> > OK, let's get to the actual issue.
> >
> > What is the purpose of a SAN?
> >
> > Why in the h*ll did the Exchange team open this can of worms
> > if they're
> > not used for anything other than to create confusion?
> >
> > 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: Friday, August 31, 2007 12:22 AM
> > > To: isapros@xxxxxxxxxxxxx
> > > Subject: [isapros] Re: ISA and SAN Certs
> > >
> > > 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.
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
> All mail to and from this domain is GFI-scanned.
>
>
>
>
All mail to and from this domain is GFI-scanned.
Other related posts:
