Publishing Exchange 2003 Outlook Web Access (OWA) with ISA Server 2000 – Part 3: SSL Bridging Drill Down and Requesting a Web Site Certificate


Publishing Exchange 2003 Outlook Web Access (OWA) with ISA Server 2000

Part 3: SSL Bridging drill down and requesting a web site certificate

By Thomas W Shinder, M.D.

In the first part of this series on how to publish the Exchange 2003 OWA site using ISA Server 2000, we went over some of the advantages the Exchange 2003 OWA site has over previous versions and a high level overview of the steps required to make the internal Exchange 2003 OWA available to external network users via ISA Server 2000 Web Publishing Rules. If you missed that article, you can check it out here.

Get the Book!

In the second part of this series we went over the concept of SSL bridging and how SSL ISA Server 2000 bridging provides unique protection in a way that no other firewall in its class can provide for your OWA 2003 Web site. We then had a short discussion on certificate services and enterprise CAs and ended up with a detailed account of how to install and configure an enterprise CA. If you need a refresher on what we did, check it out here.

In this, part 3 of our series on publishing the Exchange 2003 OWA Web site, we’ll cover the following topics:

  • Review ISA Server 2000 SSL bridging concepts with an eye on certificate configuration
  • We did a review of ISA Server 2000 SSL bridging in part 2 of this series. We’ll look at SSL bridging again in this article. This time, we’ll drill down a bit and look at an important detail relating to the configuration of the Web site certificate.

  • Request a certificate for the OWA Web site

  • The OWA site needs a certificate so that it can prove its identify to any computer that wants to connect to it using an SSL protected connection. The OWA client computer can be a computer on the internal network, or it can be the Web Proxy service on the ISA Server computer that is forwarding requests from external network clients.

  • Export the Web site certificate with its private key
  • The next step is to export the Web site’s certificate to a file. This certificate also contains the Web site certificate’s private key. This certificate is imported into the ISA Server firewall’s computer certificate store. After installing the Web site certificate into the ISA Server firewall’s computer certificate store, the ISA Server firewall will impersonate the Web site and establish SSL connections with the OWA clients.

  • Force SSL on the OWA Directories
  • You need to secure the data moving between the OWA Web site and the OWA mail clients. Anyone can easily intercept the unsecured information with a simple freeware network sniffer.

    Let’s get started!

    SSL to SSL Bridging and Web Site Certificate Configuration

    One of the most common reasons for ISA Server admins to give up on SSL, and SSL to SSL bridging, is due to problems with 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 Exchange 2003 OWA Web site.

    Take a look at the figure below.

    Figure 1

    1. The OWA 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 Server firewall checks its Web Publishing Rules to see if it has 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, then the packet will be handled based on the forwarding instructions included in the Web publishing rule. However, before the Web Proxy service has the opportunity to evaluate the URL, the SSL session must be established. The common name on the certificate the ISA Server uses to impersonate the OWA Web site must be the same as the FQDN used by the OWA client to connect to the site. In this example, the common name on the certificate the ISA Server firewall is using to impersonate the OWA Web site must be www.internal.net so that it matches the FQDN the external OWA client is using to access the OWA 2003 Web site.
     
  • The ISA Server 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 Server firewall and the OWA 2003 Web server on the internal network.


  • Note:
    All machines participating in this connection (the OWA client, the ISA Server firewall, the OWA Web site) must have the CA certificate of the Certificate Authority that issued the certificate in its Trusted Root Certification Authorities certificate store. We will discuss the precise details on how to do this later in this article

    Get the New Book!

    The connection breaks if the common name on the server certificate doesn’t match the name used by the client request. There are two places where the connection could break in the scenario above:

    • If the common name on the certificate used by the ISA Server firewall to impersonate the OWA 2003 site doesn’t match the server name (FQDN) used by the OWA client on the Internet

     

    • If the common name on the certificate on the OWA 2003 Web site doesn’t match the server name (FQDN) used by the Web Proxy service to forward the request to the OWA 2003 Web site on the internal network; the name in the request is determined by how you configure the Web Publishing Rule. We will cover this issue in detail in the next article in this series

    Keep these facts in the back of your mind as we work through the certificate request, certificate export, certificate import and finally the Web Publishing Rule. I’ll remind you of these issues when they enter into the equation.

    Step 5: Request a Certificate for the OWA 2003 Web site

    The Web site certificate request Wizard makes requesting a certificate from the enterprise CA easy. This is one of the reasons why we decided to use an enterprise CA. Perform the following steps at the OWA 2003 computer to request and install the Web site certificate:

    1. Click Start, point to Administrative Tools and click on Internet Information Services
    2. In the Internet Information Services Manager console, expand your server name and then expand the Web Sites node in the left pane of the console. Click on the Default Web Site node and then right click on it. Click the Properties command.
    3. In the Default Web Site Properties dialog box, Click on the Directory Security tab. Click on the Server Certificate button in the Secure communications frame.

    1. Read the information on the Welcome to the Web Server Certificate Wizard page, then click Next.
    2. On the Server Certificate page, select the Create a new certificate option and click Next.

    1. On the Delayed or Immediate Request page, select the Send the request immediately to an online certification authority option and click Next.

    1. On the Name and Security Settings page, type in a name for the certificate. This is a descriptive name and has no effect on the function of the certificate. Select the Bit length for the encryption key. The longer the bit length, the more secure the connection, but with a performance hit. We’ll select the default 1024 in this example and click Next.

    1. On the Organization Information page, type in an Organization name and an Organizational unit name. While these entries are not required, you should enter accurate information in these fields because you might want to use these fields in the future for mapping fields for access control. Click Next.

    1. Enter the common name of your site in the Common name text box on the Your Site’s Common Name page. Remember that this common name must be the same name as the Fully Qualified Domain Name (FQDN) that the external users will use to access your site. This is a critical entry because if you do not enter a correct Common Name on the certificate, your OWA publishing rule will not work. In this example we’ll use the common name

    www.internal.net. Click Next.

    1. Type in information about the location of the OWA Web site on the Geographical Information page. Then click Next.

    1. Type in an SSL port number in the SSL port this web site should use text box on the SSL Port page. This is the SSL port the OWA Web site on the internal network uses to listen for SSL requests. This value is not stored in the certificate and has no effect on what port number you use on the external interface of the ISA Server firewall to listen for incoming SSL request. I recommend you use the default value of 443. Click Next.

    1. Select your enterprise CA on the Choose a Certification Authority page. In this example we have a single enterprise CA, which is co-located with the domain controller and the Exchange 2003 server. Select the default value and click Next.

    1. Review your settings on the Certificate Request Submission page and click Next.

    1. Click Finish on the Completing the Web Server Certificate Wizard page.
    2. Leave the Default Web Site Properties dialog box open. We will need it to complete the certificate export process.

    Step 6: Export the Web Site Certificate with it’sPrivate Key

    The next step is to export the Web site certificate with its private key. The reason for this is the ISA Server firewall needs this certificate so that it can present itself to the world as www.internal.net. The heart of PKI is that only the true owner of a certificate has the private key. However, you can “impersonate” the true owner of the certificate by exporting the certificate along with the private key.

    Get the New Book!

    You can choose to remove the private key from the OWA site or leave it in place. You should not remove the private key from the Web site certificate at the OWA site itself, because the Web site still requires access to this key when identifying itself to clients that directly connect to it, or connect to the site via a route other than going through the ISA Server firewall.

    Perform the following steps to export the Web site certificate:

    1. Click the View Certificate button in the Secure communications frame on the Directory Security tab in the Default Web Site Properties dialog box.
    2. Click the Details tab on the Certificate dialog box. In the Details tab, click on the Copy to File button.

    1. Read the information on Welcome to the Certificate Export Wizard page and click Next.
    2. Select the Yes, export the private key option on the Export Private Key page. This allows the private key to be included with the certificate. YOU MUST SELECT THIS OPTION or else the OWA Web Publishing Rule will not work. Click Next.

    1. On the Export File Format page, select the Personal Information Exchange – PKCS #12 (.PFX) option (actually, you don’t have a choice, since the other options are grayed out). Place a checkmark in the Include all certificates in the certification path if possible option. This allows both the Web site certificate and any CA certificate in the hierarchical to be included in the exported file. REMOVE the checkmarks from the Enable strong protection (requires IE 5.0, NT 4.0 SP4 or above) and Delete the private key if the export is successful checkboxes. You must remove those checkmarks or your OWA Web Publishing Rule will not work. Click Next.

    1. On the Password page, type in a Password and Confirm password. Its important that you password protect this file because the private key can allow the holder to impersonate your site. If the private key were to fall into the wrong hands, they could impersonate your site and potentially steal value data. Click Next.

    1. On the File to Export page, type in a file name and path for the certificate file in the File name text box and click Next.

    1. Review your settings in the Completing the Certificate Export Wizard page. Then click Finish.
    2. Click OK on the Certificate Export Wizard dialog box.
    3. Close the Certificate dialog box. Click OK on the Default Web Site Properties dialog box.

    7. Force SSL on the OWA Web Site Directories

    A large amount of private data moves between the OWA Web site and OWA mail clients. You must secure this as it moves over the wire. If the information isn’t secured while “in flight” then anyone with a simple freeware network analyzer (sniffer) could gain virtually complete knowledge of your organization’s activities.

    Note that you do not need to force a secure channel. You can still establish an SSL connection with the site when you type https:// in the browser address bar. However, you leave it up to the discretion of the user when you make SSL optional. A good security policy does not leave data encryption decisions to the end user’s discretion.

    You need to force SSL on the following OWA directories:


    /exchange

    /exchweb

    /public

    The same procedure applies to each of these virtual Web site directories. Perform the following steps to force authentication on the OWA directories:

    1. In the Internet Information Services (IIS) Manager console, expand your server name and then expand the Web Sites node. Expand the Default Web Site node. Click on the Exchange node, then right click on it and click the Properties command.

    1. In the Exchange Properties dialog box, click on the Directory Security tab. On the Directory Security tab, click the Edit button in the Secure communications frame.

    1. On the Secure Communications page, put a checkmark in the Require secure channel (SSL) and Require 128-bit encryption checkboxes. This forces any host connecting to this directory to use 128-bit SSL. If the client cannot successfully negotiate a 128-bit SSL connection with the directory, then the connection request will fail. Click OK.

    1. Click Apply, then click OK in the Exchange Properties dialog box.
    2. Repeat steps 1 through 4 with the ExchWeb and Public folders in the Internet Information Services (IIS) Manager console.
    3. Right click on the server name in the left pane of the console, point to All Tasks and click on Restart IIS.

    1. Confirm that the Restart Internet Services on entry is appears in the What do you want IIS to do? drop down list box. Click OK.

    Get the Book!

    Summary

    In this article we began by expanding a bit on the SSL bridging process and how the common name on the certificate is a critical setting in the OWA Web Publishing process. We then requested a Web site certificate for the OWA Web site using the Certificate Request Wizard and then exported that certificate with its private key. We finished up by forcing SSL on the OWA directories.

    In the next installment of this series on how to publish an Exchange 2003 OWA Web site using ISA Server 2000, we’ll copy the certificate to the ISA Server firewall and import the certificate into the machine’s certificate store. We’ll also import the CA certificate into the Trusted Root Certification Authorities machine store. Once the Web site certificate is installed on the ISA Server firewall, we’ll be able to configure the Web Proxy service’s incoming Web Requests listener to use this certificate. See you then!

    I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=2;t=009703 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

    If you would like us to email you when Tom Shinder releases another article on ISAserver.org, subscribe to our ‘Real-Time Article Update’ by

    clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy!

    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