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.