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.

Use a non-SSL connection to the published server

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)

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