Another Look at Web Publishing. Part II: Host Headers with SSL and Certificates

In Part I, I mentioned that separate TCP connections are established for conveying a Web request from a client to an ISA Server computer and for forwarding the request from the ISA Server computer to the published server. In this part, I’ll focus on some issues that need special attention when one or both of these connections must become an SSL connection for encrypted communication.

SSL Connections and SSL Bridging

Whenever ISA Server terminates or initiates an SSL connection on a segment between a client and a published Web server, we say that it performs SSL bridging. The following SSL bridging scenarios are possible:

· HTTPS-to-HTTPS bridging—A request arriving at the ISA Server computer on an SSL connection is forwarded to the published server over an SSL connection. In this scenario, both the client and ISA Server send encrypted requests.

· HTTPS-to-HTTP bridging—A request arriving at the ISA Server computer on an SSL connection is forwarded over an ordinary TCP connection. In this scenario, the client sends an encrypted request, and ISA Server sends an unencrypted request.

· HTTP-to-HTTPS bridging—An HTTP request arriving at the ISA Server computer is forwarded over an SSL connection. In this scenario, only ISA Server sends an encrypted request.

The client indicates that an SSL connection is required in the first segment by specifying the HTTPS protocol in the URL requested, and the properties of the Web publishing rule that applies to the client’s encrypted request (if there is a Web publishing rule with a Web listener that listens on the IP address and port to which the request is sent) determine whether an SSL connection is required between the ISA Server computer and the published server. Web requests that require an SSL connection are typically sent to port 443.

Whenever an SSL connection is required, the server, that is the ISA Server computer in the first segment and the published Web server in the second segment, must present a server certificate to prove its identity to the client during the SSL handshake. On the segment between the original client and the ISA Server computer, the SSL handshake can be completed successfully only if the common name on the certificate matches the host name in the URL requested. On the segment between the ISA Server computer and the published server, the SSL handshake can be completed successfully only if the common name on the certificate presented by the published server matches the name that is expected by ISA Server, which acts as the client here. In some cases, the SSL handshake can succeed if a subject alternate name on the certificate matches the required name, but this possibility is beyond the scope of this discussion.

In addition, for each SSL connection you can optionally require the client to present a certificate to prove its identity to the server, but this option is also beyond the scope of this discussion.

It is important to bear in mind here that the SSL handshake takes place after the TCP connection is established, but before the HTTP request message is sent. The HTTP request is sent as an encrypted message only after the SSL connection is established. In other words, the server must respond with the certificate before it receives the Host header in the HTTP GET request. The server has only the information received during the TCP handshake and the beginning of the SSL handshake. In particular, the server knows the IP address and port used to establish the TCP connection. If we confine this discussion to requests sent to port 443, the server must return the same certificate for all requests that arrive on the same IP address, even if they are destined for different Web sites.

From the Client to the ISA Server Computer

Let’s examine how this name matching can be achieved. When a client requests an SSL connection with an ISA Server computer, the ISA Server computer must present a certificate with a common name that matches the host name in the URL requested. The request can reach the ISA Server computer only if the host name in the URL requested is resolved to an IP address of the ISA Server computer, for example, by querying DNS. On the ISA Server computer, you can configure a Web listener to listen for requests from a specific network on a specific IP address and specify a certificate with a common name that matches the host name which resolves to this IP address. The appropriate certificate must be installed in the Personal store for the local computer on the ISA Server computer, and the client will trust this certificate only if the root certificate of the Certification Authority (CA) that issued the certificate is installed in the Trusted Root Certification Authorities store on the client computer.

In ISA Server 2006, you can publish multiple Web sites or applications on different IP addresses using the same Web listener. In this case, you can specify a different server certificate for each Web site. This is done by mapping a different server certificate to each IP address on which the Web listener listens. ISA Server will present the server certificate that is mapped to the IP address on which each request arrives. In ISA Server 2004, you can specify only one SSL server certificate in a Web listener.

If you are publishing multiple Web sites that have public names with the same DNS suffix, you can use a single IP address and a single Web listener to publish multiple sites by using a wildcard certificate. For example, if you want to publish Web sites with the resolvable public host names mail.contoso.com, news.contoso.com, and blogs.contoso.com, you can acquire a wildcard certificate for *.contoso.com and install it on the ISA Server computer. Clients sending requests for any of the host names just listed will accept a certificate with the common name *.contoso.com as a valid certificate.

From the ISA Server Computer to the Published Server

Now let’s move on to the SSL connection between the ISA Server computer and the internal server that hosts the published Web site, which must be listening on the port for forwarding Web requests that is specified in the applicable Web publishing rule (this port is typically 443). In this case, you need to configure your Web publishing rule to accept the common name on the certificate that will be presented by the published server. For a single published server, this means that the name of the published server (ISA Server 2004) or the internal site name (ISA Server 2006) specified on the To tab of the Web publishing rule must match the common name on the certificate that will be presented by the published server. In ISA Server 2004, this name must be resolvable to the IP address of the published server because ISA Server 2004 uses this IP address to establish the TCP connection with the published server. In ISA Server 2006, if your ISA Server computer cannot resolve the internal site name to the IP address of the published server, you can select Computer name or IP address, and then type the required IP address or a name that can be resolved by the ISA Server computer.

Thus, ISA Server 2006 offers you a simple way to use the same certificate on the published server and your ISA Server computer. You can do this by requesting the certificate from a commercial CA on the internal Web server, installing it on the internal Web server, exporting it along with its private key, and then importing it to your ISA Server computer. In this case, the common name on the certificate will be identical to the host name that the original client provides in the URL. This can also be done on ISA Server 2004, but the procedure, which is publicly available, is a bit more complicated.

For example, if you are publishing https://www.fabrikam.com/orders and you want to protect the private information that external clients submit from disclosure to unauthorized folks on the Internet and within your organization, you can create a Web site named www.fabrikam.com on an internal server, request a certificate with the common name www.fabrikam.com from the server, install the certificate on the server, and export it to your ISA Server 2006 computer. Then, in This rule applies to this published site (the internal site name), type www.fabrikam.com, and in Computer name or IP address, type the IP address of the published server. The domain name of the published server is not used by ISA Server in this case.

If the Web site is hosted on an ISA Server 2006 Web farm, certificates with the same common name must be installed on all the farm members, and the internal site name specified on the Web Farm tab must match the common name on the certificates. To install these certificates, you can request a certificate with the same common name from each farm member. Alternatively, you can obtain and install a certificate on one farm member, and then you can export the certificate along with its private key and import it to the other farm members. In all of these cases, of course, the ISA Server computer must trust the CA that issued the certificate.

Note. If you request a server certificate on a published server and you intend to export it to a farm member or to the ISA Server computer, the certificate must have an exportable private key. When you import a certificate to a server, in the Certificate Import Wizard opened from the Certificates snap-in, you select Mark this key as exportable on the Password page.

ISA Server 2004 only supports wildcard certificates on the ISA Server computer. ISA Server 2006 also supports the use of wildcard certificates on the published Web server for publishing multiple Web sites using a single certificate. When using HTTPS to HTTPS bridging, you cannot use a wildcard certificate on an ISA Server 2004 computer to authenticate the internal Web server. Instead, on the internal Web server, install a different certificate that matches the name of the internal Web server, as specified on the To tab in the Web publishing rule.

After the SSL handshake is completed successfully and the SSL connection is established, the HTTP GET request can be forwarded to the published Web server. As in the case of forwarding an HTTP GET request without SSL that I described in Part I, if the Forward the original host header instead of the actual one option is selected, the Host header that is included in the request will contain the host name specified in the original URL requested by the client. If this option is not selected, the Host header will contain the name or network address of the published server (ISA Server 2004) or the internal site name (ISA Server 2006) that is specified in the properties of the applicable Web publishing rule.

There is one issue that should be mentioned here. In the case of HTTPS-to-HTTP bridging with the Forward the original host header instead of the actual one option selected, ISA Server 2006 adds the port number 443 to the Host header if a port number was not included in the original URL. If the Web application that is running on the Web server does not expect the Host header to include the port number, the Web application may generate an error. For information about how to resolve this issue, see the Microsoft Knowledge Base article 925287 “ISA Server 2006 includes the Host header together with the port number of the Web server after you publish a Web site.”

Pesach Shelnitz
Forefront TMG (ISA Server) Team

Published Thursday, June 19, 2008 10:28 AM by isablog

Forefront TMG (ISA Server) Product Team Blog : Another Look at Web Publishing. Part II: Host Headers with SSL and Certificates