Creating and Configuring SSL Web Publishing Rules - Dr. Tom Shinderamp;#039;s Configuring ISA Server 1002004 [Electronic resources] نسخه متنی

Creating and Configuring SSL Web Publishing Rules

You can publish secure Web servers using SSL Web Publishing Rules. Publishing Secure Web servers requires a bit more work up front because you need to obtain a Web site certificate for the published Web site, bind that certificate to the Web site on the published Web server and then bind a Web site certificate to the ISA firewall so that it can impersonate the Web server. This allows the ISA firewall to provide very high security for SSL Web sites published via Web Publishing Rules.

In this section we'll discuss the following:

SSL Bridging

Importing Web site certificates into the ISA Firewall's machine certificate store

Requesting a Web site certificate for the ISA Firewall to present to SSL Web sites

Creating an SSL Web Publishing Rules

SSL Bridging

SSL Bridging is a ISA firewall feature that allows the ISA firewall to perform stateful application layer inspection on SSL connections made to Web published Web servers on an ISA firewall Protected Network. This unique feature allows the ISA firewall to provide a level of stateful application layer inspection that no other firewall in its class can perform today.

SSL bridging prevents intruders from hiding exploits within an encrypted SSL tunnel. Conventional stateful filtering firewalls (such as most 'hardware' firewalls on the market today) cannot perform stateful application layer inspection on SSL connections moving through them. These hardware stateful filtering firewalls see that an incoming SSL connection, check the firewall's Access Control List, and if there is an ACL instructing the stateful packet filter based firewall to forward the connection to a server on the corporate network, then the connection is forwarded to the published server without any inspection for potential application layer exploits.

The ISA firewall supports two methods of SSL bridging:

SSL to SSL bridging

SSL to HTTP bridging

SSL to SSL bridging provides a secure SSL connection from end to end. SSL to HTTP bridging ensures a secure connection between the Web client and the ISA firewall and then allows a clear text connection between the ISA firewall and the published Web server.

In order to appreciate how the ISA firewall works with SSL in protecting your Web server, let's look at the life cycle of a communication between the Web client on the Internet and the Web site on the ISA firewall protected network:

The OWA client on the Internet sends a request to the ISA firewall's external interface.

An SSL session is negotiated between the Web client on the Internet and the ISA firewall's external interface

After the SSL session is established, the Web client sends the username and password to the ISA firewall. The SSL tunnel that has already been established between the Web client and ISA firewall and protects these credentials.

The request is decrypted before the request is forwarded by the ISA firewall to the published Web server. The decrypted packets received from the Web client are examined by the ISA firewall and subjected stateful application layer inspection via the ISA firewall's HTTP security filter and any other application layer inspection filters you've installed on the ISA firewall. If the ISA firewall finds a problem with the request, it is dropped.

If the request is acceptable, the ISA Server firewall re-encrypts the communication and sends it over a second SSL connection established between the ISA firewall and the published Web site on the ISA firewall Protected Network.

The published Web server decrypts the packet and replies to the ISA firewall. The Web server encrypts its response and before sends it to the ISA firewall.

The ISA firewall decrypts the response received from the published Web server. It evaluates the response in the same way it did in step 4. If something is wrong with the response, the ISA firewall drops it. If the response passes stateful application layer inspection, the ISA firewall re-encrypts the communication and forwards the response to the Web client on the Internet via the SSL session the Internet Web client already established with the ISA firewall.

SSL 'Tunneling' versus SSL 'Bridging'

The ISA firewall actually participates in two different SSL sessions when SSL-to-SSL bridging is used:

An SSL session between the Web client and the external interface of the ISA firewall

A second SSL session between an internal interface of the ISA firewall and the published Web server

The typical stateful packet-filter firewall only performs forwards connections for published SSL sites. This is sometimes referred to as 'SSL tunneling.' The conventional stateful filtering firewall accepts SSL communications on its external interface and forwards them to the published SSL server. Application-layer information in the communication is completely hidden inside the SSL tunnel because the packet filter-based firewall has no mechanism to decrypt, inspect, and re-encrypt the data stream. Because traditional stateful filtering firewalls are unable to make allow and deny decisions based on knowledge of the contents of the encrypted tunnel, it passes viruses, worms, buffer overflows and other exploits from the Web client to the published Web site.

What About SSL-to-HTTP Bridging?

The ISA firewall can also perform SSL-to-HTTP bridging. In the SSL-to-HTTP bridging scenario, the connection between the Web client and the external interface of the ISA firewall is protected in the SSL tunnel. The connection between the ISA firewall's internal interface and the published Web server on the corporate network is sent 'in the clear' and not encrypted. This helps performance because avoids the processor overhead incurred for the second SSL link.

However, you have to consider the implications of SSL-to-HTTP bridging. Steve Riley (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/columns/security/askus/auaswho.asp), a Program Manager on the ISA Server team at Microsoft, has mentioned that the external user connecting to the published Web site using SSL has an implicit agreement and expectation that the entire transaction is protected. We agree with this assessment. The external Web client enters into what can arguably be considered a 'social contract' with the published Web server, and part of that contract is that communications are protected from 'end to end.'

SSL-to-SSL bridging protects the data with SSL and the ISA Server firewall services from end to end. SSL-to-HTTP bridging protects the data from the OWA client and while it's on the ISA Server firewall, but it is not safe once it's forwarded from the ISA Server firewall and the OWA site on the internal network.

Enterprise and Standalone Certificate Authorities

The topic of Certificate Authorities (CAs) and PKI (Public Key Infrastructure) is usually enough to drive many administrators away from even considering SSL. There are a number of reasons for this:

The available documentation on certificate authorities and PKI, in general, is difficult to understand.

The subject has the potential to be extremely complex.

You need to learn an entirely new vocabulary to understand the CAs and PKI. Often the documentation on these subjects doesn't define the new words, or they use equally arcane terms to define the arcane term for which you're trying to get the definition.

There doesn't seem to be any support for the network and firewall administrator who just wants to get a CA setup and running so that he can use certificates for SSL and L2TP/IPSec authentication and encryption.

We not going to do an entire course on PKI and the Microsoft CA, but we do want to help you understand some of the decisions you need to make when deciding what type of Certificate Authority to install and use.

The Microsoft Certificate Server can be installed in one of four roles:

Enterprise Root CA

Enterprise Subordinate CA

Standalone Root CA

Standalone Subordinate CA

Enterprise Root and Enterprise Subordinate CAs can only be installed on Active Directory member servers. If you want to install a CA on a non-domain member, then install a Standalone Root or Standalone Subordinate CA. If you install a single Certificate Server, you'll install it as an Enterprise Root or Standalone Root. Subordinate CAs are used in organizations managing multiple CAs.

You can use the Certificates MMC standalone snap-in to obtain machine or user certificates - the snap-in is only available to domain member computers.

You can configure Group Policy to automatically issue machine and user certificates via autoenrollment - this feature is only available to domain member computers.

You can use the Web enrollment site to obtain certificates via a Web interface.

The Certificates MMC standalone snap-in or autoenrollment can't be used to obtain certificates from Standalone CAs. The only way to obtain a certificate from a standalone CA is to request one from the standalone CA's Web enrollment site. You must fill out a form and then submit the request. The certificate is not immediately issued, because the only thing the CA knows about the requestor is what's put in the form. Someone needs to 'eyeball' the request and then manually approve the request. The requestor then needs to use the browser to return to the Web enrollment site and download the certificate.

The enterprise CA is less hassle because it has information about the requestor. Since the request is for a computer or user in the domain, someone has already qualified the domain user or computer and deemed that member worthy of a certificate. The enterprise CA assumes you have administrative control over all domain member users and computers and can evaluate the validity of the certificate requests against the information available to it in the Active Directory.

For these reasons, we recommend you use enterprise CAs. We will assume that you're using an enterprise CA for the remainder of this discussion.

For more information on Certificate Authorities and PKI, check out Microsoft's PKI page at www.microsoft.com/windowsserver2003/technologies/pki/default.mspx

SSL-to-SSL Bridging and Web Site Certificate Configuration

One of the most common reasons that ISA firewall admins give up on SSL, and SSL-to-SSL bridging is the problems they may experience in getting the SSL connections to work correctly. The most common reason for this is a configuration error that involves the relationship between the certificate configuration and the Web Publishing Rule used to publish the Web site.

Figure 8.29 and the list to follow provides details of the SSL-to-SSL bridged connection to a public Outlook Web Access Web site.

Figure 8.29: SSL-to-SSL bridging

The Web client sends the request https://www.internal.net/exchange/ to the external interface of the ISA Server firewall publishing the OWA 2003 Web site

The ISA firewall checks its Web Publishing Rules to see if there is a Web Publishing Rule containing a Destination Set with the FQDN www.internal.net and the path /exchange. If there is a Web Publishing Rule matching this FQDN and path, the connection will be handled based on the forwarding instructions included in the Web Publishing Rule. However, before the ISA firewall can evaluate the URL, the SSL session must be established. The common name on the certificate the ISA firewall uses to impersonate the OWA Web site must be the same as the FQDN used by the Web client to connect to the site. In this example, the common name on the certificate the ISA firewall uses to impersonate the OWA Web site must be www.internal.net so that it matches the FQDN the external OWA client uses in its request.

The ISA firewall decrypts the packets, examines them, and then attempts to create a new SSL connection between itself and the internal OWA Web site. Just like when the external OWA client connects to the external interface of the ISA Server firewall, the ISA Server firewall's Web Proxy service acts as a client to the OWA 2003 Web site on the internal network. The request the Web Proxy service sends to the OWA 2003 site on the internal network must match the common name on the certificate on the OWA Web site. That is why we must configure the request to be forwarded to www.internal.net when we configure the Web Publishing Rule. I'll remind you of this important fact when we discuss the configuration of the Web Publishing Rule.

The packets are forwarded to the Web site after the SSL session is established between the ISA firewall and the Web server on the internal network.

Things break when the common name on the server certificate doesn't match the name used by the client request. There are two places where things can break in the SSL-to-SSL bridging scenario:

If the common name on the certificate used by the ISA Server firewall to impersonate the Web site doesn't match the name (FQDN) used by the Web client on the Internet.

If the common name on the certificate on the Web site doesn't match the name (FQDN) used by the ISA firewall service to forward the request; the name in the ISA firewall's request to the published Web server is determined by the entry on the To tab in the Web Publishing Rule.

Keep these facts in mind as we work through our SSL-to-SSL bridging Web Publishing Rule later.

Importing Web Site Certificates into The ISA Firewall's Machine Certificate Store

The ISA firewall must be able to impersonate the published Web server so that it identifies itself to the remote Web client as the published Web server. The mechanism behind this impersonation is a common name on the Web site certificate. We must install the Web site certificate on the ISA firewall to accomplish this task.

The first step is to export the Web site certificate from the secure Web server's Web site. The IIS console has an easy-to-use Certificate Wizard where you can export the Web site certificate. When you export the Web site certificate, make sure that you include the private key. One of the most common reasons for failure in secure Web Publishing Rules is that the Web site certificate was not exported with its private key.

The Web site certificate is then imported into the ISA firewall's machine certificate store. Once the Web site certificate is imported into the ISA firewall's machine certificate store, it will be available to bind to a Web listener. You'll know that the certificate wasn't properly imported if you're unable to bind the certificate to a Web listener.

Perform the following steps to import the Web site certificate into the ISA firewall's machine certificate store:

Copy the Web site certificate to the ISA firewall machine.

Click Start, and then click the Run command. In the Run dialog box, enter mmc in the Open text box, and click OK.

In the console, click File, and then click Add/Remove Snap-in.

In the Add/Remove Snap-in dialog box, click Add.

In the Add Standalone Snap-in dialog box, click Certificates in the list of Available Standalone Snap-ins, and click Add.

On the Certificates Snap-in page, select the Computer account option and click Next.

On the Select Computer page, select Local computer (the computer this console is running on) and click Finish.

Click Close in the Add Standalone Snap-in dialog box.

Click OK in the Add/Remove Snap-in dialog box.

Expand the Certificates (Local Computer) node in the left pane of the console.

Expand the Personal node in the left pane of the console.

Right-click the Certificates node, point to All Tasks and click Import.

Click Next on the Welcome to the Certificate Import Wizard page.

On the File to Import page, use the Browse button to find the certificate you copied to the ISA firewall. Click Next after the certificate appears in the File name text box.

Enter the password you assigned to the Web site certificate in the Password text box on the Password page. Do not mark the certificate as exportable. Click Next.

Accept the default setting, Place all certificates in the following store on the Certificate Store page. Click Next.

Click Finish on the Completing the Certificate Import Wizard page.

Click OK on the Certificate Import Wizard dialog box.

The Web site certificate and the CA certificate appear in the right pane of the console. The CA certificate has the same name as the entry in the Issued by column.

Right-click the CA certificate and click Cut.

Expand the Trusted Root Certification Authorities node in the left pane of the console.

Right-click the Certificates node and click Paste. If the Paste command does not appear, repeat step 20, and then try again.

Return to the Personal\Certificates node in the left pane of the console and double-click the Web site certificate.

In the Certificate dialog box, click the Certification Path tab. The CA certificate should not have a red 'x' on it. If there is a red 'x' on the CA certificate, that indicates that the CA certificate was not successfully imported into the Trusted Root Certification Authorities node.

Close the Certificate dialog box.

Close the mmc console. Do not save the console.

Now that the Web site certificate is imported into the machine's certificate store, it'll be available to bind to the Web listener used in the SSL Web Publishing Rule.

Requesting a User Certificate for the ISA Firewall to Present to SSL Web Sites

The ISA firewall can be configured to present a user certificate to Web sites that require user certificates before connecting to the site. These user certificates are also referred to as client certificates. The published Web site can be configured to require that the client certificate be presented before a connection is allowed. Client certificates can be mapped to user accounts. This allows for user certificate authentication. However, you can require user certificates and then provide log on credentials via alternate authentication methods.

You can request a user certificate for the ISA Firewall's Firewall Service and then configure the Web Publishing Rule to present this certificate when Web sites request a client certificate. The first step is to request a certificate for the ISA firewall's Firewall Service account.

In the following example we will use the certificates MMC to import a certificate for the ISA Firewall's Firewall service account. We cannot use the Certificates MMC to request a certificate for the account, but we can import a user certificate using the Web enrollment site.

In order to request a certificate for the ISA firewall from the Web enrollment site, we must first create a user account for the ISA firewall. Create a user account name isafirewall in the Active Directory prior to performing the following procedures.

Perform the following steps to request a certificate for the Firewall service account:

At the ISA firewall machine, open the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name, and click the Firewall Policy node.

Click the Tasks tab in the Task pane. On the Tasks tab, click the Show System Policy Rules link.

In the list of System Policy Rules, right-click Rule 2 Allow all HTTP traffic from ISA Server to all networks (for CRL downloads), and click Edit System Policy.

On the General tab of the System Policy Rule for CRL Download, check the Enable checkbox. Click OK.

Click Apply to save the changes and update the firewall policy.

Click OK in the Apply New Configuration dialog box.

Open Internet Explorer on the ISA firewall and enter the URLhttp://<certificateserver>/certsrv, where certificateserver is the name or IP address of the enterprise CA on the corporate network.

In the Connect to dialog box, enter the credentials of the isafirewall account and click OK.

Click Add in the Internet Explorer dialog box, creating the blocking of the site.

Click Add in the Trusted site dialog box. Click Close.

On the Welcome page, click the Request a certificate link.

On the Request a Certificate page, click the User Certificate link.

On the User Certificate - Identifying Information page, click Submit.

Click Yes in the Potential Scripting Violation dialog box.

Click Yes in the dialog box informing you that you're sending information to the Web server.

On the Install this certificate page, click the Install this certificate link.

Click Yes in the Potential Scripting Violation dialog box.

Click the Tools menu in the browser, and click Internet Options.

In the Internet Options dialog box, click the Content tab.

On the Content tab, click Certificates.

In the Certificates dialog box, click isafirewall and click Export.

Click Next on the Welcome to the Certificate Export Wizard page.

On the Export Private Key page, select Yes, export the private key, and click Next.

On the Export File Format page, remove the checkmark from the Enable strong protection checkbox. Place a checkmark in the Include all certificates in the certification path if possible checkbox. Click Next.

On the Password page, enter a password and confirm the password for the certificate file. Click Next.

On the File to Export page, enter a path in the File name text box. In this example, we'll enter the file name c:\isafirewallcert. Click Next.

Click Finish on the Completing the Certificate Export Wizard page.

Click OK in the Certificate Export Wizard dialog box.

Click Close in the Certificates dialog box.

Click OK in the Internet Options dialog box.

Now we'll import the certificate into the Firewall service account:

Click Start and then click Run. In the Run dialog box, enter mmc in the Open text box, and click OK.

In the console, click File, and then click Add/Remove Snap-in.

In the Add/Remove Snap-in dialog box, click Add.

In the Add Standalone Snap-in dialog box, click Certificates in the list of Available Standalone Snap-ins, and click Add.

On the Certificates snap-in page, select the Services account option, and click Next.

On the Select Computer page, select Local Computer (the computer this console is running on), and click Next.

On the Select a service account to manage on the local computer page, select Microsoft Firewall from the Service account list, and click Finish.

Click Close in the Add Standalone Snap-in dialog box.

Click OK in the Add/Remove Snap-in dialog box.

In the console, expand the Certificates - Service node and right-click fwsrv\Personal. Point to All Tasks and click on Import.

On the Welcome to the Certificate Import Wizard page, click Next.

On the File to Import page, click Browse to find the location of the user certificate file you exported from the browser. Click Next.

Enter the password you assigned the certificate in the Password text box. Do not put a checkmark in the Mark this key as exportable checkbox. You might also want to delete the certificate from the Web browser on the ISA firewall so that this certificate cannot be stolen by individuals who obtain physical access to the ISA firewall. Click Next.

On the Certificate Store page, use the default setting Place all certificates in the following store, and click Next.

Click Finish on the Completing the Certificate Import Wizard page.

Click OK in the Certificate Import Wizard dialog box.

The certificate is now associated with the Firewall service account. You might want to disable the System Policy Rule we created earlier so that you don't inadvertently use the browser on the ISA firewall. Remember, you should avoid using the browser, and all other client applications, on the firewall.

Creating an SSL Web Publishing Rule

Now that our certificates are in place, we can create the SSL secure Web Publishing Rule. In the Microsoft Internet Security and Acceleration Server 2004 management console, expand the server name, and click the Firewall Policy node. On the Firewall Policy node, click the Tasks tab in the Task pane. In the Task pane, click Publish a Secure Web Server.

On the Welcome to the SSL Web Publishing Rule Wizard page, enter a name for the rule in the SSL Web publishing rule name text box. In this example, we'll name the rule Secure Web Server, and click Next.

The Publishing Mode Page

On the Publishing Mode page (Figure 8.30), you have two options:

SSL Bridging

SSL Tunneling

Figure 8.30: The Publishing Mode Page

The SSL Bridging option is the more secure option. SSL bridging provides a secure end-to-end encrypted SSL connection while at the same time allowing the ISA firewall to perform both stateful filtering (like any conventional 'hardware' firewall) and stateful application-layer inspection. This is the preferred option and the option we will use in this example.

The SSL Tunneling option is the less secure option. SSL tunneling bypasses the ISA firewall's stateful application-layer inspection functionality and reduces the overall level of security for the publishing rule that is provided by a conventional stateful filtering 'hardware' firewall. Do not use the SSL Tunneling feature unless you encounter an unusual situation where you publish applications that are not compliant with HTTP 1.1 Web Proxies.

Select SSL Bridging, and click Next.

The Select Rule Action page

The Select Rule action page, as shown in Figure 8.31, has two options: Allow or Deny. Allow allows connections to the published server, and Deny denies connections to the published server. The default option is Allow. You can use Deny publishing rules to fine-tune existing Web Publishing Rules.

Figure 8.31: The Select Rule Action Page

Select Allow, and click Next.

The Bridging Mode Page

On the Bridging Mode page you have three options (also shown in Figure 8.32):

Secure connection to clients

Secure connection to Web server

Secure connection to clients and Web server

Figure 8.32: The Bridging Mode Page

Each 'secure connection' is in the context of the connection from the ISA firewall.

The Secure connection to clients option sets the connection up as SSL-to-HTTP bridging. This option secures the connection between the Web client and the ISA firewall, but allows the connection to travel in unsecured free text between the ISA firewall and the published Web server. We highly recommend against this practice, unless you use an alternate method of securing the connection between the ISA firewall and the published Web server (such as IPSec or a dedicated link between the ISA firewall and the Web server where the cable itself would need to be compromised in the fashion of a 'vampire tap' such as cutting the cable and wiring each side of the twisted pairs to a listening device acting as a 'man in the middle,' or by picking up the signal using a Time Domain Reflectometer).

We do realize that there is always a trade-off between security and performance and the implicit contract you have with users who assume their connection is secure from end to end. If you believe that you have a strong, defensible reason for not using an end-to-end connection, then SSL-to-HTTP bridging is possible with the ISA firewall. Depending on the Web application you publish, you may need to use the ISA firewall's Link Translator feature to get things working properly. We'll talk more about the Link Translator in Chapter 10.

The Secure connection to Web server option allows you to perform HTTP-to-SSL bridging. The connection between the Web client is sent over HTTP, and the connection between the ISA firewall and the Web server is sent via SSL. This is a somewhat unusual scenario, where the client is on a more trusted network than the networks in the path between the ISA firewall and the published server. An example of this type of scenario is where a branch office has an ISA firewall connecting it to the main office using a dedicated WAN link. You can publish the main office Web server at the branch office ISA firewall and secure the connection over the WAN link to the main office and finally to the destination Web server.

Secure connection to clients and Web server (as shown in Figure 8.32) is the most secure and preferred option. This enables SSL-to-SSL bridging where the connection between the Web client and the ISA firewall is secured by SSL, and the connection between the ISA firewall and the published Web server is also secured by SSL. The ISA firewall is able to perform stateful application-layer inspection on the contents of the SSL connection when you use SSL bridging, while at the same time providing an end-to-end encrypted connection.

In this example, we will select Secure connection to clients and Web server, and click Next.

The Define Website to Publish Page

On the Define Website to Publish page, you have the following options:

Computer name or IP address

Forward the original host header instead of the actual one (specified above)

Path

Site

The Computer name or IP address text box includes the IP address or name for the published Web server. This is a critical entry for SSL publishing because the name in this text box must match the common name on the Web site certificate on the Web server. If the name you enter in the Computer name or IP address text box doesn't match the common name on the Web site certificate, the connection attempt will fail, and the user will see a 500 Internal Server error.

For example, if the common name on the Web site certificate bound to the published Web site is owa.msfirewall.org, then you must enter owa.msfirewall.org in the Computer name or IP address text box. If you enter the IP address or NetBIOS name of the server, the connection will fail because the name doesn't match the common name on the Web site certificate.

Forward the original host header instead of the actual one (specified above) works the same way as it does when you publish non-SSL sites. However, you must be careful with this option because if the remote user uses a FQDN that is different than the common name on the Web site certificate, the connection attempt will fail.

For example, if the remote user enters http://www.msfirewall.org to access the published Web site through the ISA firewall, then the ISA firewall will use www.msfirewall.org instead of owa.msfirewall.org when it proxies the connection to the published Web site, and the connection will fail with a 500 error. For this reason, we recommend that you use the same name from end to end for your Web Publishing Rules. However, this isn't required because if you do not enable the Forward the original host header instead of the actual one (specified above) option, and you use the same name from end to end, then the name the external user uses to access the Web site is the same as the common name on the Web site certificate.

The key to success is that the name in the Computer name or IP address text box matches the common name on the Web site certificate on the published Web site, and the ISA firewall resolves the name in the Computer name or IP address text box to the internal address, not the public address used by the Web listener, for that site. In this example, the name owa.msfirewall.org must resolve to the internal or non-public address. That is to say, the actual address bound to the Web site on the corporate networks.

The Path text box is used in the same way it's used for non-SSL connections. See the section in this chapter on publishing non-secure Web sites for details of this option.

The Site box lists the URL of the site that will be published on the Internal network.

The Define Website-to-Publish Rule Wizard is illustrated in Figure 8.33.

Figure 8.33: The Define Website to Publish Page

Click Next on the Define Website to Publish page.

The Public Name Details Page

On the Public Name Details (Figure 8.34) page, you define what names users can use to access the published Web site via this Web Publishing Rule. The Public Name Details page includes the following options:

Accept requests for

Public name

Path

Site

Figure 8.34: The Public Name Details Page

The Accept requests for drop-down list allows you to choose either This domain name (type below) or Any domain name. As we mentioned in our earlier discussion on non-SSL publishing, the Any domain name option is a low security option and should be avoided, if at all possible. This option allows the Web Publishing Rule to accept incoming requests using any IP address or FQDN that can reach the IP address that the Web listener for the Web Publishing Rule uses. The preferred option is This domain name (type below). This option limits the name remote users can use when accessing the Web site published by this Web Publishing Rule.

You enter the name the remote user uses to access the published Web site in the Public name text box. This is a critical option. You must enter the name that the remote user uses to access the Web site, and the name must match the common name on the Web site certificate bound to the Web listener used by this rule.

We recommend that you export the Web site certificate bound to the published Web site and import that certificate into the ISA firewall's machine certificate store. When you do this, you can bind the original Web site certificate to the Web listener used by this Web Publishing Rule. You would then use the same name from end to end.

For example, if the Web site certificate used on the published Web site has the common name owa.msfirewall.org, and you export that Web site certificate and bind it to the Web listener used by this Web Publishing Rule, you should use the same name, owa.msfirewall.org, in the Public name text box. Remote users must be able to resolve this name to the address on the ISA firewall that the Web listener used by this rule accepts incoming secure connections.

The Path text box allows you to set what paths are accessible on the published Web site. For more details on how to use the Path option, review our discussion of this subject in the non-SSL Web publishing section of this chapter.

See an example of The Public Name Details page in Figure 8.34.

Click Next on the Public Name Details page.

The Select Web Listener Page

Select the Web listener you want to use for this Web Publishing Rule on the Select Web Listener page (Figure 8.35). If you have already created an SSL Web listener on this ISA firewall, you can select it from the Web listener list. If you do not have an SSL Web listener, you can create one by clicking New.

Figure 8.35: The Select Web Listener Page

In this example, we will create a new SSL Web listener for this Web Publishing Rule. Click the New button as shown in Figure 8.35.

On the Welcome to the New Web Listener Wizard page, enter a name for the Web listener in the Web listener name text box. In this example, we'll name the Web listener SSL Listener. Click Next.

On the IP Address page, select the Network you want the listener to listen on. In this example, we want the listener to listen for incoming requests to the published Web site on the External interface. Check the box next to the Network where you want the listener to listen for requests. However, we do not want the Web listener to listen on all IP addresses assigned to the External Network interface(s), so we'll click Address as shown in Figure 8.36.

Figure 8.36: The IP Addresses Page

In the External Network Listener IP Selection dialog box, select Specified IP addresses on the ISA Server computer in the selected network. Select the address on the ISA firewall that resolves to the common name on the Web site certificate bound to the Web listener. In this case, the IP address that resolves to the name owa.msfirewall.org is 192.168.1.70. Select the IP address in the Available IP Addresses list, and click Add to move it to the Selected IP Addresses list. Click OK. The External Network Listener IP Selection page is shown in Figure 8.37.

Figure 8.37: The External Network Listener IP Selection Page

Click Next on the IP Address Selection page.

On the Port Specification page, set what TCP port(s) the Web listener will listen on. We recommend that you always create separate listeners for HTTP and SSL, since this provides you more flexibility in creating listeners and Web Publishing Rules. Since we are creating an SSL listener in this example, remove the checkmark from the Enable HTTP checkbox to prevent this Web listener from accepting incoming HTTP connections. Check the Enable SSL checkbox. The default listening port for the SSL listener is 443. You can change this port if you like, but users will need to manually enter the alternate port if you do.

The SSL listener needs a Web site certificate bound to it so that it can impersonate the published Web site. Click the Select button to select the certificate, as shown in Figure 8.38.

Figure 8.38: The Port Specification Page

You'll see a list of Web site certificates in the Select Certificate dialog box. In our current example, we see two certificates: a machine certificate assigned to the ISA firewall that it uses for user certificate authentication with Web sites that require user certificates, and the Web site certificate for the Web site we're publishing. Select the Web site certificate (in this example, the Web site certificate is owa.msfirewall.org), and click OK. The Select Certification dialog box is illustrated in Figure 8.39.

Figure 8.39: The Select Certificate Dialog Box

The certificate appears in the Certificate box on the Port Specification page as shown in Figure 8.40. Click Next.

Figure 8.40: The Certificate Appears on the Port Specification Page

Click Finish on the Completing the New Web Listener Wizard page. The details of the SSL listener now appear on the Select Web Listener page (Figure 8.41). Click Next.

Figure 8.41: The Select Web Listener Page

The User Sets Page

Configure the users you want to access the Web site on the User Sets page. The configuration options on the User Sets page are the same for both SSL and non-SSL publishing. Check out the discussion of the User Sets page in the non-SSL Web Publishing section of this chapter.

Click Finish on the Completing the New Web Publishing Rule Wizard page. Click Apply to save the changes and update the firewall policy. Click OK in the Apply New Configuration dialog box.

The SSL Web Publishing Rule Properties Dialog Box

The SSL Web Publishing Rule Properties dialog box is identical to that found in the non-SSL Web Publishing Rule Properties dialog box. Review the section on the Web Publishing Rule Properties dialog box in the non-SSL Web Publishing Rule section of this chapter.