Certificates with Multiple SAN Entries May Break ISA Server Web Publishing
What is a “SAN”?
“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
OK; so why is this interesting for ISA Server?
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
How is this happening?
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 2006Single-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.
Great; so NOW what do I do?
For ISA Server 2004, you should seriously consider upgrading to ISA Server 2006 + SP1 or Forefront TMG
For 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.
Use a single-subject certificate
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.
Use a wildcard certificate at the published server
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
Host1.subdomain1.domain.tld
Host2.subdomain1.domain.tld
Host1.subdomain2.domain.tld
Host2.subdomain2.domain.tld
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).
Use the Subject or first SAN name in the published hostname field
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.
Single-server publishing
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 |
|
|
Web Farm publishing (ISA Server 2006 only)
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!
Jim Harrison
Program Manager, ISA SE
Comments
Anonymous
January 01, 2003
Article très complet sur l'utilisation des certificats SAN avec ISA, http://blogs.technet.com/isablog/archive/2007/08/29/certificates-with-multiple-san-entries-may-break-isa-server-web-publishing.aspxAnonymous
January 01, 2003
Pokud jste se někdy snažili o publikaci služeb Exchange Server 2007 skrze ISA Server 2006, dost pravděpodobněAnonymous
January 01, 2003
IMPORTANT: This post is being kept for archival purposes, but please reference http://technet.microsoft.com/en-us/library/cc707697(TechNet.10).aspxAnonymous
January 01, 2003
ISA Server 2006 Service Pack 1 Features Introduction Microsoft ® Internet Security and Acceleration (ISA)Anonymous
January 01, 2003
Any update on this? When is ISA going to be patched so it can use all the SAN entries on a SAN cert?Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Elan, 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.Anonymous
January 01, 2003
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.Anonymous
January 01, 2003
Marc, 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.Anonymous
January 01, 2003
Open Interoperability Lab http://www.microsoft.com/presspass/press/2007/sep07/09-11MSNovellLabsPR.mspxAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The reality (sad or not) is that SAN certificates were not in common use by ISA administrators until just before this blog was motivated (days; not years). Had they been as commonly deployed in ISA web publishing scenarios as you seem to believe, you can certainly bet that ISA customers would have made plenty of noise before now (they haven't). Because the problem and resolution are much more complex than they appear, we're planning on shipping the fix with ISA 2006 SP1 to ensure proper regression testing. The schedule for this SP will be released ASAP.Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
Adam and I are working on a slightly different scenario for publishing SCCM through ISA. It's not specifically related to SAN certificates. JimAnonymous
August 29, 2007
Hi Jim, great information about SAN certificates on ISA. Do you know when the solution from the ISA team will be available? regards Marc GroteAnonymous
August 30, 2007
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: http://www.shudnow.net/2007/07/15/publishing-exchange-2007-autodisover-in-isa-2006/Anonymous
September 04, 2007
Hi Tom, 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..?Anonymous
September 09, 2007
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.Anonymous
September 19, 2007
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. Regards, Steven HopeAnonymous
October 10, 2007
The comment has been removedAnonymous
October 15, 2007
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.Anonymous
October 16, 2007
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. Thanks !Anonymous
November 13, 2007
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?Anonymous
November 14, 2007
The temporal disconnect is funny, but the sad reality is that the ISA team has had almost a year to release a hotfix or service pack that addresses this problem. And if we include the beta/RC period then you've had well over a year. How much time do you think is reasonable?