Comprehensive Overview of Web and Server Publishing Rules in TMG 2010 (Part 6)

If you would like to read the other parts in this article series please go to:


If you had a chance to read parts 1 through 5 of this series, you have probably figured out by now that while web publishing might seem as easy as using a the Web Publishing Wizard and creating a Web Publishing Rule, when you go under the hood, things get a bit more complicated. Not that it has to be difficult, but if your Web Publishing Rules are going to do everything that you want them to do, then you are going to need to know all the finer details of web publishing and how to access the controls that enable you to create rules that will accomplish your specific purposes.

We’ll pick up this time where we left off, going over the configuration options for the Web Listener. As you know, the Web Listener is a software construct that is used by the TMG firewall Web Publishing Rules to accept incoming requests for the rule. The Web Listener controls the web protocols that will be accepted as well as the authentication requirements.

Connections tab

Let’s now go to the Connections tab on the Web Listener and resume our discussion. There are several sections on this tab. The first one is the Client Connection Type. Here you have the following options:

  • Enable HTTP connections on port. This option allows you to accept non-TLS encrypted HTTP connections. The default port 80 is listed automatically, but you can change the port to another one if you like. Make sure that the client application is aware of the non-default port though, because otherwise the client won’t be able to connect on the alternate port.
  • Enable SSL (HTTPS) connections on port. This option allows you to accept TLS-encrypted HTTP connections. The default port 443 is listed, and once again, you can change it to another one if you like. Similarly to the HTTP connection, you need to make sure the client is aware of the non-default port if you’re going to change from the default.

The second section is the HTTP to HTTPS Redirection frame:

  • Do not redirect traffic from HTTPS to HTTPS. This option is pretty straightforward. If you select this, the traffic that comes in as HTTP traffic will stay HTTP traffic and there will be no SSL redirection.
  • Redirect authenticated traffic from HTTP to HTTPS. If you select this option, users will be redirected to an HTTPS connection if authentication is required. This is a good option to enable whenever you have chosen to enable authentication on the TMG firewall, since you never want the credentials to be sent out in the clear. If authentication is not required, then the connection will remain an HTTP unencrypted session.
  • Redirect all traffic from HTTP to HTTPS. This option enables you to forward all connections that are accepted by the Web Listener to an SSL connection. This is useful if you want to make the web site easy to access (users don’t have to remember to use SSL) and you’re not initially requiring authentication, but you want to keep the session secure – either because you are going to be asking for authentication later or perhaps because users will be entering some data that you’d rather not have transmitted in the clear over the Internet.

The last section has the Advanced button in it. However, when you click this, you find that the options you see there really aren’t very advanced :). In the Advanced Settings dialog box, you can set the number of allowed concurrent client connections for the web listener. This is the number of clients that can be connected to a web site at the same time using this Web Listener. The default setting here is Unlimited. However, if you want to reduce the number of connections that the Web Listener can accept, you can select the Maximum per server setting and then enter a value. The reason it says “per server” is because, if you have an array of TMG firewalls, each server in the TMG firewall array will be able to accept this many connections.

Finally, there is a Connection timeout (seconds) option that enables you to specify the length of time that you want the TMG firewall to wait before timing out as an idle connection. Note that the default setting is 15 minutes. You can change this if you have client applications that might want to stay connected longer while idle. You might remember that this was a bit of a challenge back in the Exchange ActiveSync days, because the connection timeout was causing ActiveSync push updates not to work correctly. Now, when you using the Exchange Server Publishing Wizard, there are no problems with timeouts anymore.

Figure 1

Certificates tab

Okay, now let’s click the Certificates tab. Here you can configure the certificates that the Web Listener will use when securing an SSL connection with clients. The first option that you see is Use a Single certificate for this Web Listener. You are typically going to use this option when there is a single IP address assigned to the Web Listener. The second option is Assign a certificate for each IP address. If the Web Listener has multiple IP addresses assigned to it, this option will allow you to select the IP address and assign a certificate to it. You would use this option if the Web Listener was being used in a Web Publishing Rule that was listening for connections on different Fully Qualified Domain Names (FQDN) and each IP address was assigned to a different FQDN.

Figure 2

When you click the Select Certificate button, you’ll see the Select Certificate dialog box. In the top section of this dialog box, you’ll see a list of certificates that have been installed on the TMG firewall. For each certificate, you’ll get information in the following fields:

  • Issued To. This is the subject name or the common name on the certificate. It’s very important to note that the incoming SSL request must be for this name. If the client request includes a name that is different from this one, the connection attempt will fail.
  • Validity. The TMG firewall is able to tell whether the certificate is valid or not. In the example in the figure below, you can see that the certificate is not valid because it has expired.
  • Issued By. This tells you the name of the certification authority (CA) that issued the certificate.
  • Expiration Date. This tells you the expiration date of the certificate. In this example, you can see that the certificate is past its expiration date.
  • Friendly Name. This tells you the friendly name that you might have assigned to the certificate when you requested or created it.

By default, all of the installed certificates are displayed. If you want to filter the list to see only the valid certificates that are installed on the TMG firewall, you can enable the Show only valid certificates option.

In the lower half of the dialog box you can see the Certificate Installation Details section. Here you get the following information:

  • Server Name. The server name is the name of the TMG firewall that the certificate is installed on. If you have a TMG firewall array, you will see the certificate installed on all the machines in the TMG firewall array.
  • Certificate Store. This tells you the name of the certificate store in which the certificate is stored. Web Listener certificates need to be stored in the local machine’s certificate store. It is very common for TMG firewall administrators to install certificates in the wrong location (for example, in a user account’s certificate store). Be careful not to do that! Always put them in the local machine’s certificate store.
  • Private Key. All Web Listener certificates must contain the associated private key. This is important because if the private key is not included with the certificate, then the certificate will not work.

Figure 3

At the bottom of the Certificates tab is the Advanced button. When you click the Advanced button you will see the Advanced Certificate Options dialog box. You don’t have a lot of choice here; there is the single option Certificate per server on all IP addresses. What does this dialog box do? Beats me. Try doing a Bing search for “ISA Server Advanced Certificate Options” and you’ll come up empty. Try some other permutations of this same search and you’ll still find nothing on this option. I guess they put this option there in case somebody calls Customer Support Services with a problem that CSS determines that this option will fix. In that case, I guess the only people who know what this option does are the TMG firewall Product Group and CSS! Even Tom, who usually can be counted on to know all things ISA/TMG, was stumped by this one.

Figure 4

That wraps up the Certificates tab. We still have a few tabs to go, but we’re out of time again.


In this article, we continued our series on the TMG firewall’s Web Publishing feature by going over some more of the settings in the Web Listener properties dialog boxes. Most of what we covered today was focused on SSL and the certificates that are bound to the TMG firewall’s Web Listener, which make secure client connections possible. One of the key issues that you need to remember is that the common/subject name on the certificate must be the same as the name in the client request. This is a common reason for SSL connection failures. Another common issue relates to the certificate’s validity. You need to make sure that your certificates have not expired. The good news is that the TMG firewall will alert you if your SSL certificates are about to expire. Next time, we’ll continue with our step-by-step journey through Web Listener properties and look at some advanced SSL settings (and this time they really are advanced). See you then –Deb.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top