Using a Commercial Web Site Certificate to Publish Outlook Web Access (OWA) Part 4

Using a Commercial Web Site Certificate to Publish Outlook Web Access (OWA) Part 4
by Thomas W Shinder MD, MVP


Have Questions about the article? 
Ask at: http://tinyurl.com/gdajm  

In part 1 of this series on how to use commercial Web site certificate to publish your corporate OWA site, I went over the basics of SSL to SSL bridging and how the ISA firewall brings a much higher level of security to your OWA remote access solution compared to a conventional “hardware” firewall. After making the security advantages of the ISA firewall abundantly clear, we then went over the reasons why you would want to use a commercial Web site certificate instead of a privately generated certificate. We finished up by providing the roadmap for the overall commercial Web site certificate OWA publishing solution presented in this series.

In part 2 we started with the details of the configuration and began the process of requesting the commercial Web site certificate that will be subsequently bound to the Web listener used by an ISA firewall Web Publishing Rule.

In part 3 we exported the commercial Web site certificate with its private key from the OWA Web site and copied the certificate file to the ISA firewall. We then unbound the commercial Web site certificate from the OWA Web site and requested a private Web site certificate that uses a different common/subject name. We completed part 3 by creating a Web listener and bound the commercial Web site certificate to this Web listener, which will be used in this article when we create the Web Publishing Rule.

If you missed the first three parts of this series, then check them out at:

In this, part 4 of the series, we’ll perform the following procedures:

  • Create the Web Publishing Rule
    We ended up the last article by creating an SSL Web listener that binds the commercial Web site certificate to itself. We’ll use this Web listener in the Web Publishing Rule that publishes our OWA site.
  • Configure public and private name resolution
    If there is one thing that breaks an otherwise perfect OWA Web site publishing solution, it’s a misconfigured DNS infrastructure. Maintaining a slick, well-oiled DNS infrastructure is not difficult. You just need to pay attention of a few basic best practices and you’ll be able to provide quick, transparent access to your published Web sites for both internal and external network clients.
  • Test the solution
    The proof of the pudding is in the eating! We’ll finish up the series by testing the solution and check out the ISA firewall’s log files to see what’s happening under the hoot during the connection process.

Let’s get started!

Create the Web Publishing Rule


Figure 1: You are here

With the Web listener now in place, we’re ready to create the OWA Web Publishing Rule. This Web Publishing Rule will accept incoming connections to https://mail.msfirewall.org/exchange and forward those to the OWA Web site on the internal network. All users will be required to authenticate with the ISA firewall before any connections are allowed to the OWA Web site. This provides us with a superior level of security over that, provided by so-called “hardware” firewalls that just forward SSL connections to the OWA Web site.

Create the OWA Web Publishing Rule

Perform the following steps to create the OWA Web Publishing Rule:

  1. In the ISA firewall console, expand the server name and then click the Firewall Policy node.
  2. On the Firewall Policy node, click the Tasks tab on the Task Pane. Click the Publish a Mail Server link.
  3. On the Welcome to the New Mail Server Publishing Rule Wizard page enter a name for the rule in the Mail Server Publishing Rule text box. In this example, we’ll name the rule OWA Site. Click Next.
  4. On the Select Access Type page, select the Web client access: Outlook Web Access (OWA), Outlook Mobile Access, Exchange Server ActiveSync. Click Next.
  5. On the Select Services page, accept the default settings where the Outlook Web Access and Enable high bit characters used by non-English character sets options are enabled. Click Next.
  6. On the Bridging Mode tab, select the Secure connection to clients and mail server option and click Next.
  7. On the Specify the Web Mail Server page, enter the name of the internal OWA site in the Web mail server text box. You must enter the same name as the common/subject name on the Web site certificate bound to the OWA Web site. If you enter anything other than the common/subject name on the Web site certificate bound to the OWA Web site, the connection will fail. In this example, the common/subject name on the Web site certificate is owa.msfirewall.org so we’ll enter that into the text box. Click Next.


Figure 2

  1. On the Public Name Details page, select the This domain name (type below) option from the Accept requests for list. In the Public name text box enter the name that external users will use to access the OWA Web site. This name must be the same as the common/subject name on the Web site certificate bound to the Web listener used in this Web Publishing Rule. In this example, the common/subject name bound to the Web site certificate is mail.msfirewall.org so we will enter that in the Public name text box. Click Next.


Figure 3

  1. On the Select Web Listener page, select the SSL Listener entry from the Web listener list. Click Next.


Figure 4

  1. On the User Sets page, accept the default entry and click Next.
  2. Click Finish on the Completing the New Mail Server Publishing Rule Wizard page.
  3. Click Apply to save the changes and update the firewall policy.
  4. Click OK in the Apply New Configuration dialog box.

Have Questions about the article? 
Ask at: http://tinyurl.com/gdajm  

Configure Public and Private Name Resolution


Figure 5: You are here

At this point the certificates and the ISA firewall are all configured to create a working remote access OWA solution for your users. However, there’s one thing that you must make sure is in order for the solution to actually work in production, and that’s your DNS infrastructure. You must configure your DNS infrastructure to support name resolution for both internal and external network clients. It’s actually quite simple to configure and the good news is that once you have your DNS configured, there is rarely a need to make any changes to it.

First, you need to configure your internal clients to access the OWA site using the internal name of the site. The internal name of the site must be the same as the common/subject name on the OWA Web site certificate. In our current example, the common/subject name of the certificate bound to the OWA Web site is owa.msfirewall.org. Users must use this name to connect to the site, and the internal DNS server must resolve the name owa.msfirewall.org to the actual IP address of the site on the internal network.

Note:
I must say here that this is not a hard and fast rule. You do not, in all instances, need to map the IP address of the internal name of the OWA site to the actual IP address of the site. However, this makes it easier for most ISA firewall admins to understand. In more advanced configurations, it would not be appropriate to use the actual IP address of the OWA site for the internal DNS. One example of this situation is when the OWA Web site is on an internal network services segment perimeter, where the OWA Web server is behind an internal perimeter ISA firewall and there is a NAT Network Rule from the network services perimeter and the user networks. In this type of environment, the internal DNS would map the owa.msfirewall.org name to the IP address on the external interface of the ISA firewall used in the Web listener for the Web Publishing Rule publishing the internal OWA Web site located on the network services perimeter network.

Next, the external DNS must be configured to support the name used on the certificate bound to the Web listener used in the Web Publishing Rule used to publish the OWA Web site. In this example, the common/subject name on the Web listener is mail.msfirewall.org and external users must use this name in their requests in order to reach the OWA site through the ISA firewall. If they use another name, then the connection will fail not only because of a name mismatch error on the certificate and request, but also because the Web Publishing Rule is configured to accept connections only for those that include the Host Header mail.msfirewall.org.

The external DNS zone can be hosted on a server you maintain on your own network and published by your edge ISA firewall, or the external (public) zone can be hosted by your ISP or another public DNS hosting provider. The location of the external DNS zone doesn’t matter. What matters is that external clients can access the external DNS server to resolve the name you use on your commercial Web site certificate bound to the ISA firewall’s Web listener.

Now I have a confession to make. At the beginning of the article I said that we weren’t using a split DNS infrastructure in this solution. The confession is that wasn’t entirely true. In fact, its not true at all, since we are using the same second level domain name for internal and external access. The difference in the typical OWA publishing articles I do and this one is that we’re not using the same fully qualified domain name from end to end.

For example, in most articles I do on OWA publishing I use the same name, owa.msfirewall.org in the external DNS zone and the internal DNS zone. This allows us to use owa.msfirewall.org regardless of our location – internal users use the same name as external users. Pretty easy for everyone, eh?

The Pain of an Illegal Top Level Domain Name

The problem is that some sad souls must use illegal top level domain names, such as .local on their internal networks. These typically aren’t high production networks, and are more consistent with SOHO type networking, where they were locked in to a vendor solution that forced them to use this unfortunate naming scheme. If you’re stuck with this kind of configuration, don’t fear, there is a easy and effective workaround. Check out my article Supporting ISA Firewall Networks Protecting Illegal Top-level Domains: You Need a Split DNS! at http://www.isaserver.org/tutorials/2004illegaltldsplitdns.html

In the test network we’re using for the example discussed in this article series, I won’t deploy a full-on DNS solution for the sake of expediency. You will deploy a full internal and external DNS solution on your production network.

On our text network, the external client will have a HOSTS file entry for mail.msfirewall.org that maps to the IP address on the external interface of the ISA firewall, which in this case is 192.168.1.71. On the internal network, the Active Directory integrated DNS server on the Exchange Server maps owa.msfirewall.org to the IP address of the Exchange Server OWA Web site, which just so happens to the IP address of the domain controller, in this example. Since this isn’t the actual name of the Exchange Server (the actual name of the machine is EXCHANGE2003BE.msfirewall.org), I needed to manually add an entry for mail.msfirewall.org into the DNS zone database.

Test the Solution


Figure 6: You are here

Let’s have some fun and test the solution! Not so fast. Before we can test the solution on our lab network, we need to import the test CA certificates into the external client’s machine certificate store. Note that just like when we had to do this on the ISA firewall, this step is an artifact of our lab scenario. You will not have to do this when using a live commercial Web site certificate, since the commercial CA certificate provider’s root CA certificate is automatically included in your external Windows XP client’s machine certificate store.

Perform the following steps to install the test CA certificates on the client:

  1. At the Windows XP client computer, open Internet Explorer and go to http://www.verisign.com/server/trial/faq/index.html
  2. Click the Secure Site Trial Root CA Certificate link.
  3. On the Root CA Certificates page, copy the text in the text box into a Notepad document. Save the Notepad .txt file as commcacert.txt
  4. In Internet Explorer, click the Tool  menu and then click Internet Options.
  5. Click the Content tab. On the Content tab click the Certificates button in the Certificates frame.
  6. Click the Import button.
  7. On the Welcome to the Certificate Import Wizard page, click Next.
  8. On the File to Import page, click the Browse button to located the commcacert.txt file. Click Next.
  9. On the Certificate Store page, select the Automatically select the certificate store based on the type of certificate option and click Next.
  10. Click Finish on the Completing the Certificate Import Wizard page.
  11. Click Yes on the page informing you that you’re installing a certificate.
  12. Click Yes in the dialog box informing you that the import was successful.
  13. Click Close in the Certificates dialog box.
  14. Click OK in the Internet Options dialog box.

Now open Internet Explorer on the external client and connect to https://mail.msfirewall.org/exchange. Enter your username and password on the forms-based authentication page and open your mailbox. In this example we opened the default administrator’s mailbox.

When you look at the log files on the ISA firewall, you’ll see lines like those listed in the figures below. Here you can see that the first connection is to mail.msfirewall.org and then you can see the connections made from the ISA firewall to the internal Web server and those connections are made to owa.msfirewall.org.

Note:
If you can’t see the log file entries, please let me know, and I’ll post a larger version of the graphics.


Figures 7 and 8

Have Questions about the article? 
Ask at: http://tinyurl.com/gdajm  

Summary

In this, part 4 and the last part in our series on how to publish OWA Web sites using commercial certificates, we completed the configuration by creating the Web Publishing Rule that publishes the OWA Web site to the Internet. We then discussed the critical DNS infrastructure considerations you must address before you have a fully working solution and finished up by testing the solution and checking the ISA firewall’s log files to see what was going on under the hood during the connection process.

I hope you enjoyed this series and that you leaded a thing or two along the way. If there is a scenario or idea that you’d like to see me write an article about, send me a note with the subject line ISA firewall article idea to [email protected] and I’ll make sure to get the article on the top of the list for pending articles.

Thanks! – Tom

If you missed the first three parts of this series, then check them out at:

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