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. Incoming 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. As I'll describe later on, in some cases, the SSL handshake can succeed if a subject alternate name (SAN) listed on the certificate matches the required name.
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 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 that can be gleaned from the TCP handshake and the beginning of the SSL handshake. This information is limited to the 5-tuple that defines the TCP connection, which includes the protocol (TCP), the source IP address and port, and the destination IP address and port. In particular, the only information that an ISA Server computer or a Web server published by ISA Server can use to select the certificate to present to the client is the destination 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 must trust the certification authority that issued the certificate. For a server certificate that was issued by a root certification authority, the client will trust the certificate only if the root certificate of the certification authority that issued it is installed in the Trusted Root Certification Authorities store on the client computer. For a certificate that was issued by an intermediate certification authority, the client will trust the certificate only if the certificates of all the subordinate certification authorities in the chain of trust are installed in the Intermediate Certification Authorities store on the client computer and the certificate of the root certification authority is installed in the Trusted Root Certification Authorities store.
Note. The ISA Server computer must also trust the certificate that it presents to the client computer. If the required certification authority certificates are not present in the applicable certificate stores on the ISA Server computer, the SSL handshake will fail with a trust error.
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 (or, in some cases, a subject alternate 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.
Note. If you install a commercial certificate on multiple computers, make sure that you have sufficient licenses. You wouldn’t want Web publishing to start failing because your certificate was revoked.
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.
ISA Server 2006 Service Pack 1 introduces support for certificates with multiple subject alternate name (SAN) entries that are presented by published Web servers to the ISA Server computer. With ISA Server 2006 SP1, your ISA Server computer can establish SSL connections with a published Web server that hosts multiple Web sites and has a single certificate with a SAN entry for each Web site. For example, you can have a separate Web publishing rule with a different internal name for each Web site on the To tab. These internal site names can all resolve to the same IP address of the published Web server, or you can use the optional Computer name or IP address field to specify this IP address or a computer name that resolves to the IP address. ISA Server will then use this IP address to establish a TCP connection with the published server to forward requests to any of the published Web sites. The SSL handshake can be completed successfully if any of the SAN entries on the certificate presented by the published server matches the internal site name specified in the corresponding Web publishing rule.
Note. The support for certificates with multiple SAN entries in ISA Server 2006 SP1 has nothing to do with the certificates specified in a Web listener.
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.”
Gabriel Koren
Forefront TMG (ISA Server) Team