Publishing Exchange 2003 Outlook Web Access (OWA) with ISA Server 2000 Part 2: Understanding SSL Bridging and Installing an Enterprise CA

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

 Part 2: Understanding SSL Bridging and Installing an Enterprise CA

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.

In this, part 2 of the series, we’ll go over the concepts and procedures required to obtain a Web server certificate for the Exchange 2003 OWA Web site. This certificate will allow you to secure communications between the OWA client and the OWA Web site. In addition, this certificate will be used to allow the ISA Server to impersonate the OWA server.

In this article we’ll do the following:

You don’t need to request and issue a Web site certificate for the OWA Web site. However, there are many advantages to doing so:

You’ll miss out on all these advantages if you don’t issue a certificate to the Web site and use SSL. The good news is that it’s easy to issue and move certificates around, especially with the help of a Windows Server 2003 Certificate Server.

In order to appreciate how the ISA Server firewall works with SSL in protecting your OWA clients and OWA Web server, let’s look at the life cycle of a communication between the OWA client on the Internet and the Exchange 2003 OWA site on the internal network:

1. The OWA client on the Internet sends a request to the ISA Server firewall’s external interface.
2. An SSL session is negotiated between the OWA client on the Internet and the ISA Server Firewall’s external interface
3. After

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

4. The request is decrypted before the request is forwarded by the ISA Server firewall to the internal OWA Web server,. The decrypted packets received from the OWA client are examined by the ISA Server firewall. The validity of the request can be matched up against the settings in URLScan 2.5 (included with ISA Server 2000 Feature Pack 1), and with any antivirus application filters you’ve installed on the ISA Server firewall. If the Web Proxy service, URLScan and any 3^rd party antivirus and HTTP screening filters finds a problem with the request, it is dropped.
5. If the request is acceptable, the ISA Server firewall re-encrypts the packet using SSL and sends it to OWA server on the internal network.
6. The OWA server on the internal network decrypts the packet and decides to reply. The OWA server’s encrypts its response and sends it to the internal interface of the ISA Server firewall.
7. The ISA Server firewall decrypts the SSL packet it received from the OWA server on the internal network. It evaluates the packet like it did in step 4. If something is wrong with the response, the ISA Server firewall will drop the packet. If everything is OK, the ISA Server firewall re-encrypts the packet and forwards the response to the OWA client on the Internet via the already established SSL session.

You might be able to tell from reading the “lifecycle” story above that there are actually two different SSL sessions established to make the whole thing work:

• An SSL session between the OWA client on the Internet and the external interface of the ISA Server firewall
• A second SSL session between the internal interface of the ISA Sever firewall and the OWA server on the internal network

This is why we call it “SSL” bridging. The ISA firewall acts as a “bridge” between two different SSL “tunnels” (or sessions). Now you might ask “so what”?

The typical firewall in ISA Server’s price/performance class only performs a “reverse NAT” for published SSL sites. This is sometimes referred to as “SSL tunneling”. The firewall accepts the SSL packets on its external interface and forwards them to the published SSL server on the internal network via its internal interface. The application layer data in the communication are completely hidden inside the SSL tunnel because the firewall has no mechanism to decrypt, inspect, and re-encrypt the packets. Because this type of firewall is unable to make decisions about the encrypted data inside the SSL communication stream, it blissfully passes encrypted viruses, worms, and buffer overflow exploits between OWA clients and the OWA Web site on the internal network.

That’s why you want a firewall that can perform SSL bridging like ISA Server. This is just one for the many reasons why I think ISA Server is the firewall for any Exchange 2003 OWA publishing scenario.

One more thing before we move onto the next subject. It is possible for the ISA Server firewall to perform SSL to HTTP bridging. In the SSL to HTTP bridging scenario, the connection between the OWA client on the Internet and the external interface of the ISA Server is protected by SSL. The connection between the ISA Server firewall’s internal interface and the OWA server on the internal network is sent “in the clear” and not encrypted. This helps performance out a bit, since the ISA Server firewall does not need to devote processor cycles to re-encrypting the packets between its internal interface an the OWA site.

However, you have to consider the implications of SSL to HTTP bridging. Steve Riley, a Program Manager on the ISA Server team at Microsoft, has mentioned that the external user who connects to the OWA site using SSL expects the entire transaction to be protected. I agree with this assessment. The external OWA client enters into what can arguably be considered a “social contract” with the OWA 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 its on the ISA Server firewall, but it is not safe once its forwarded from the ISA Server firewall and the OWA site on the internal network.

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

• The available documentation on CAs and PKI is desultory
• The subject has the potential to be extremely complex and the existing documentation doesn’t simplify these complexities much
• You need to learn an entirely new vocabulary to understand the CA/PKI documentation; often the docs don’t define the new words or they use equally arcane terms to define the arcane term you’re trying to get the definition of
• There doesn’t seem to be a place to go to for the guy who just wants to get a CA setup and running so that he can use certificates for SSL and L2TP/IPSec authentication and encryption

I’m not going to do an entire course on PKI and the Microsoft CA, but I do want to try and 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 member servers in Active Directory domains. If you want to install the CA on a machine that is not a member of the domain, then install a Standalone Root or Standalone Subordinate CA. If you install a single Certificate Server, you’ll install it as an enterprise or standalone Root. Subordinate CAs are used in organization that have multiple CAs.

Should you use an enterprise CA or a standalone CA? There are many advantages to using an enterprise CA:

• You can use the Certificates MMC standalone snap-in to obtain a machine or user certificate – this feature is only available to domain member computers
• You can configure Group Policy to automatically issue machine and user certificates using a process called autoenrollment – this feature is only available to domain member computers
• You can use the Web enrollment site to obtain certificates via a Web interface

Standalone CA’s are not able to issue certificates using the Certificates MMC standalone snap-in or via autoenrollment. 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 a computer or user in the domain, someone has already pre-screened the domain member and deemed that member worthy of a certificate. The enterprise CA assumes that you have administrative control over all domain members 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 and more, I recommend you use the enterprise CA. I will assume that you’re using an enterprise CA for the remainder of this series.

In our example network we install Microsoft Certificate Servers on the Windows Server 2003 domain controller on the internal network. We will also install the Web enrollment site so that machines that are not domain members can request a certificate using the Web enrollment site. note that this procedure really doesn’t fit as Step 5 in the list of procedures outlined in part 1 of this article. Certificate Services should be installed on the domain controller right after the machine is promoted to a domain controller. However. because many admins have not installed a Microsoft Certificate Server, will will cover the procedure in this article. Will will pick up with Step 5 in part three of this series.

The Web enrollment site requires that IIS World Wide Web service be installed. The OWA site runs on IIS, so it is already installed.

Perform the following steps to install and configure an enterprise CA on a Windows Server 2003 computer:

4. In the Certificate Services dialog box, put a checkmark in the Certificate Services CA checkbox (figure 3). A Microsoft Certificate Services dialog box appears and informs you that you can not change the machine name or the domain membership of the machine while it acts as a certificate server. Read the information in the dialog box and click Yes.

5. Both the Certificate Services CA and Certificate Services Web Enrollment Support checkboxes are checked (figure 4). Click OK in the Certificate Services dialog box.

6. Click Next in the Windows Components dialog box (figure 5).

7. Select the Enterprise root CA option on the CA Type page. Click Next.

8. On the CA Identifying Information page, type in a Common name for this CA. The common name of the CA is typically the DNS host name or NetBIOS name (computer name) of the machine running Certificate Services. In this example, the name of the machine is WIN2003DC, so we will enter WIN2003DC in the Common name for this CA text box. The default Validity Period of the CA’s self-signed certificate is 5 years. Accept this default value unless you have a reason to change it. Click Next.

9. On the Certificate Database Settings page, use the default locations for the Certificate Database and Certificate Database Log. You do not need to specify a shared folder to store configuration information because this information will be stored in the Active Directory. Click Next.

10. Click Yes on the Microsoft Certificate Services dialog box (figure 9) that informs you that Internet Information Services must be stopped temporarily.

11. Click Yes on the Microsoft Certificate Services dialog box (figure 10) that informs you that Active Server Pages must be enabled on IIS if you wish to use the Certificate Services Web enrollment site.

12. Click Finish on the Completing the Windows Components Wizard page (figure 11).
13. Close the Add or Remove Programs window.

In this, part 2 of our series on using ISA Server 2000 to publishing an Exchange 2003 OWA site, we went over the rationale behind why you should set up a Certificate Server and issue a Web site certificate to the Exchange 2003 OWA site. Then we briefly discussed the different types of Certification Authorities and why the enterprise CA works best in the majority of cases. We ended up the article we a step by step procedure on how to install the enterprise Root CA on a Windows Server 2003 computer. In part three of this series on Publishing the Exchange 2003 OWA Web site using ISA Server 2000, we’ll go over the the steps required to request and install the Web site certificate, how to export the Web site certificate, and how to import the Web site certificate into the ISA Server firewall’s machine certificate store. 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