“SAN” in this context refers to the certificate attribute “Subject Alternative Name”. Among other uses, this attribute allows the site administrator to save money and administrative overhead by building a single certificate that lists all the sites that require a server authentication certificate. There are several articles that deal with the “how”, “why” and “when” for multiple-SAN certificates:
Exchange Team Blog More on Exchange 2007 and certificates - with real world scenario
Microsoft Knowledge Base article Unified Communications Certificate Partners for Exchange 2007
TechNet article Advanced Certificate Enrollment and Management
TechNet article Troubleshooting SSL Certificates in ISA Server Publishing (not specifically SAN-related, but worth including in this discussion)
TechNet article How to Configure SSL Certificates to Use Multiple Client Access Server Host Names
TechNet article Microsoft Office Communicator Web Access Technical Reference Guide for Communications Server 2007
ISA Server 2004 cannot process certificate SAN attributes at all. The Subject of the certificate installed at the published server must match the published hostname used in the Web Publishing rule. ISA Server 2006 is able to use either the Subject or the first SAN entry. What this means for the ISA Server admin is that if ISA Server is expecting the certificate to read “host.domain.tld” and that name is not either:
1. The certificate “Subject” (AKA “common name”)
2. The first entry in the SAN list (ISA Server 2006 only)
..ISA Server will produce the response discussed in Microsoft Knowledge Base article Clients may receive an "Error Code 500 Internal Server Error" error message when they try to visit a Web site that you publish by using ISA Server 2006 or ISA Server 2004. Whether or not the user actually experiences this exact error depends on the application in use (Outlook, OWA, EAS, etc) and how that application handles this error case. The key point is that you will find 0x80090322 in the ISA Server Web Proxy log HTTP Status Code field for those requests that meet with this error.
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
To understand how ISA Server connects to the published server and determines the “correct” name of the certificate received from it, we have to first examine how Web Publishing rules are processed. The area we’re most interested in is the rule “published hostname” definition. For single-server web publishing, this is found in the rule To tab; for Web Farm publishing, this is the Web Farm tab. The key information for certificate validation is provided by the ISA Server administrator in a textbox labeled:
ISA Server 2004 (All Web Publishing) Specify the name or the network address of the server to publish:
ISA Server 2006 Single-server rule: This rule applies to this published site:
Web Farm rule: Internal site name:
When ISA Server decides to allow traffic through a single-server web publishing rule, ISA Server will:
1. Attempt to resolve the published hostname to an IP address. If you have specified the published hostname as an IP address, this step is bypassed.
2. When ISA Server receives the Server Authentication certificate from the published server, it compares the published hostname to the certificate Subject or the first entry in the SAN list. If ISA Server cannot find a match, it will produce the “target principle name” error.
For ISA Server 2004, you should seriously consider upgrading to ISA Server 2006 + SP1 or Forefront TMGFor ISA Server 2006, you have two options:1. Install ISA Server 2006 SP1 (at least)2. If you don't want to install SP1 (can't imagine why...), there are four functional options available to the ISA Server administrator.
Ok; I know, I know. This is a functional method only if your web service can accept unencrypted traffic and your security policies allow it. It’s the simplest option, but obviously not the best. Another critical point to this option is that if your ISA Server Web Listener accepts both HTTP and SSL connections, and the Web Publishing rule includes both HTTP and SSL selections in the Bridging tab, the client connection type determines the published connection type. In other words, if the client connects using SSL, ISA Server will connect to the published host using SSL.
Rebuild your certificates without SAN entries and make sure the published hostname matches your certificate Subject. If you’ve purchased your certificates from someone else, your first reaction might be “You payin’ for it, buddy?!?”, in which case, I’d respond, “read on, McDuff…” I get that not everyone has their own PKI structure (for any of several perfectly valid reasons), although I’d strongly recommend that you seriously consider building one; it’s well worth the time & effort.
If for whatever reason, you cannot change the rule’s published hostname value, you can build a certificate that includes all possible site names. For instance, if you created a multi-SAN certificate that included
You might consider creating a wildcard certificate that uses only *.domain.tld as the Subject. If you can’t or don’t want to use wildcard certificates, read on (I prefer the next option anyway).
Notes for ISA Server 2004:
1. Because ISA Server 2004 is unable to read the certificate SAN attribute, you must use the certificate Subject in the web publishing rule published hostname field.
2. If the certificate Subject cannot be resolved to the published server’s IP address, you will have to add the selected name to your ISA server’s hosts file (located at %windir%\system32\drivers\etc\hosts). If you do this, I strongly advise you to place a shortcut to the hosts file in %AllUsersProfile%\Desktop so that it’s clear to anyone that logs onto your ISA Server that the hosts file has been modified. Otherwise, you and your minions may find yourselves going painfully bald while you try to solve self-inflicted name resolution “weirdness” later.
1. Change the Web publishing rule published hostname value (in red below) so that it matches either the Subject or (for ISA Server 2006 only) the first SAN entry.
2. (ISA Server 2006 only) Enter the IP address of the published server in the Computer name or IP address field (in orange below). This will allow ISA Server to connect to the published server without having to resolve the published hostname to an IP address. This also avoids having to mangle the hosts file.
3. Depending on the website being published, you may have to uncheck Forward the original host header instead of the actual one (in green below)
ISA Server 2004 Web Publishing Rule
ISA Server 2006 Web publishing Rule
NOTE: this option requires that you use the same certificate at each published server in the Web Farm.
1. Edit the relevant Web publishing rule published hostname so that it matches the first SAN entry (in red below). This will allow ISA Server to match the published hostname with the certificate SAN
2. Uncheck Forward the original host header instead of the actual one (in green below)
3. Enter the IP address of each farm member in the Web Farm Servers list (in orange below). This will allow ISA Server to connect to each farm member without having to resolve the member name or FQDN to an IP address.
Happy Exchange Publishing!
Program Manager, ISA SE
PingBack from http://blogs.msexchange.org/walther/2007/08/29/certificates-with-multiple-san-entries-may-break-isa-server-web-publishing/
great information about SAN certificates on ISA. Do you know when the solution from the ISA team will be available?
regards Marc Grote
We're examining our options. We can't discuss an ETA until we're satisified with the scope of the problem and the solution options we have.
I'll comment here when we reach a decision.
Pokud jste se někdy snažili o publikaci služeb Exchange Server 2007 skrze ISA Server 2006, dost pravděpodobně
If you want your other SAN names to work, just keep your TO: tab to be either the CN or 1st SAN name as the article suggests, and just change the Public Name tab to be the name of another SAN name and it'll work just fine.
An example is included in my blog entry below where I explain how to get this to work with both Exchange web services as well as autodiscover using a SAN cert. So for those wanting to get Autodiscover, Web Services, EAS, OA, OWA, etc. using a SAN cert all published on ISA 2006, check out the following article:
Actually, what you do at the web listener itself has no bearing on how ISA acts as a "certificate consumer". Based on recent threads in the isapros list and some other offline comments, this seems to be a common point of confusion.
While it's true that OL operates similarly to ISA regarding SAN enteirs, this only means that you make "autodiscover" the Subject or first SAN entry in the cert associated with the web listener.
This is interesting in that seems to contrast with what Steven Hope has found in his investigations of how ISA acts as a "consumer" of server certificates of a published Web site. Over at:
"To top all this, ISA 2006 has a bug regarding Common Names (CNs) and Subject Alternative Names (SANs). When ISA Server bridges a SSL Connection to a web server with a certificate containing SANs, it ignores the CN and only does a name match with the FIRST SAN entry! To work around this make sure the FIRST SAN listed is the same as the CN which in this scenario is MAIL.VIRCOM.CO.UK"
So, if I read it correctly, you say that ISA will use *either* the common/subject name or the first SAN. Steven says that the common/subject name is ignored and only the first SAN is used.
That's interesting. My testing (yes, I really did test this <g>) was quite different; ISA 2006 recognized the Subject name just fine. Could be there's someting in his environment that caused his observaations..?
In the test I did I only saw ISA using the CN only if there was no SAN present. If multiple SAN were present it would only use the SAN and not the CN.
Hi Jim and Tom
ISA 2006 behaved in the following way during my testing:
If there was a cert on the exchange server 2007 that had NO SAN entry then the CN was used - as expected. However, if there was a cert on the exchange server that had at least one SAN entry then ISA ONLY looked at the first SAN entry and ignored the CN completely. In conclusion it seemed that ISA 2006 would ONLY look at the CN if there were NO SAN entries at all.
My recommendation is thus to always make the first SAN entry the same as the CN so ISA behaves the way you would expect it to, i.e. appears to use the CN even though its actually using the first SAN. It would be nice if ISA would FIRST look at the CN and if a match isn’t found, SECOND run through the list of SAN’s, but that isn’t the case.
How would this configuration be enhanced to support an environment where on the front-end server there are two URLs and certificates, one for OWA and one for Exchange ActiveSync. There were some significant challenges when coming up with an ISA SSL configuration that could support a web farm of two FE servers hosting OWA, that certificate has a SAN and adding to that configuration support for EAS, leveraging that same web farm but using a different certificate and URL.
You'd have to create separate rules for each VRoot that operates under a different certificate.
ISA redirects based on the published hostname, and if these differ between VRoots (whether they're separate servers or simply separate IIS listeners), then you need sepoarate rules.
Jim ! where was this wonderful guide when i needed it :)??
I had a terrible time to figure this out on ISA 2004 , now that i noticed both this article & the update to autodiscovery service i'll might just re-do this all over again...properly this time.
What a nightmare. Is it too much to expect the “recommended” firewall for Exchange 2007 to “just work” correctly the first time? Did anyone bother piloting this before Exchange 2007 shipped?
There's a temporal disconnect you're overlooking.
ISA 2006 shipped before Exchange 2007.
SAN certificates didn't become part of the Exchange recommended deployment until after Exch 2007 shipped.
It's rather difficult for any product team to test "future scenarios", but we're working on it.