Understanding the Need for Third-Party CAs

By and large, the most common approach to securing an OWA server with SSL is to buy a certificate from a third-party certificate authority such as Verisign, Thawte, or one of many other enterprise certificate authorities. These companies exist as a trusted third-party vendor of digital identity. Their job is to validate that their customers are really who they say they are, and to generate the digital certificates that validate this for digital communications that require encryption, such as SSL.

For example, if CompanyABC wishes to create a certificate to install on its OWA server, it sends the certificate request to the third-party certificate authority (CA), who then follows up by researching the company, calling the CompanyABC employees , and conducting interviews to determine the validity of the organization. Based on the information obtained from this process, the third-party CA then encrypts the certificate and sends it back to CompanyABC, which then installs it on its server.

Because the third-party CA is registered on nearly all the web browsers (the most common ones always are), the client automatically trusts the CA and, subsequently, trusts the certificate generated by CompanyABC. It is because of this seamless integration with the majority of the world's browsers that third-party enterprise CAs are commonly utilized.

Internal certificate authorities, built and maintained by the internal IT branch of an organization, are more cost effective. Expensive third-party certificates (which can run up to $1000 a year in some cases) can be eschewed in favor of internally generated certificates. This also gives an organization more flexibility in the creation and modification of certificates. Windows Server 2003 includes the option of installing an enterprise certificate authority on an internal server or set of servers, giving administrators more options for SSL communications. The biggest downside to an internal CA is that, by default, not all browsers have the required certificate patch that includes the internal CA as part of the default installation, and therefore receive the error illustrated in Figure 12.3 when accessing a site secured by this certificate.

The only way to avoid this type of error message from appearing is to add the internal CA to the client's list of trusted root authorities, which can be a difficult prospect if OWA access is to be made available to browsers around the world. An enterprise certificate authority is automatically trusted by domain members , which can make this easier for an organization to deploy, but can still limit the deployment of a seamless solution. It is this limitation that sometimes stops organizations from installing their own CAs.

Either third-party CA certificate generation or internal CA generation is required for SSL support on OWA. These deployment options are illustrated in the subsequent sections of this chapter.

Installing a Third-Party CA on an OWA Server

If a third-party certificate authority will be used to enable SSL on an OWA server, then a certificate request must first be generated directly from the OWA Server. After this request has been generated, it can be sent off to the third-party CA, who then verifies the identify of the organization and sends it back, where it can be installed on the server.

If an internal CA will be utilized, this section and its procedures can be skipped, and readers can proceed directly to the subsequent section, "Using an Internal Certificate Authority for OWA Certificates."

NOTE

Although it is not a direct part of ISA Server, having an SSL-protected OWA server is the first step in protecting traffic to the OWA server, and is therefore illustrated in this chapter. It is possible to secure an OWA server without using SSL, through basic HTTP securing techniques, but it is highly recommended to use SSL where possible.

To generate an SSL certificate request for use with a third-party CA, perform the following steps:

After the certificate request has been generated, the text file, which will look similar to the one shown in Figure 12.5, can then be emailed or otherwise transmitted to the certificate authority via its own individual process. Each CA has a different procedure, and the exact steps need to follow the individual CA's process. After an organization's identity has been proven by the CA, it sends back the server certificate, typically in the form of a file, or as part of a the body of an email message.

The certificate then needs to be installed on the server itself. If it was sent in the form of a .cer file, it can be imported via the process described in the following steps. If it was included in the body of an email, the certificate itself needs to be cut and pasted into a text editor such as Notepad and saved as a .cer file. After the .cer file has been obtained, it can be installed on the OWA server through the following process:

At this point in the process, SSL communication to the OWA server can be allowed, but forcing SSL encryption requires more configuration, which is outlined in the later section titled "Forcing SSL Encryption for OWA Traffic."

Using an Internal Certificate Authority for OWA Certificates

If a third-party certificate authority is not utilized, an internal CA can be set up instead. There are several different CA options, including several third-party products, and it may be advantageous to take advantage of an existing internal CA. If none is available, however, one can be installed on an internal (non-ISA) Windows Server 2003 system in an organization.

Installing an Internal Certificate Authority

On a domain member (not the ISA Server) server or, more commonly, on a domain controller, the Certificate Authority component of Windows Server 2003 can be installed using the following procedure:

NOTE

This procedure outlines the process on a Windows Server 2003 system. It is possible to install and configure a CA on a Windows 2000 system, through a slightly different procedure.

From the subsequent dialog box, shown in Figure 12.7, select what type of certificate authority is to be set up. Each choice of CA type has different ramifications , and each one is useful in different situations. The following is a list of the types of CAs available for installation:

• Enterprise root CA An enterprise root CA is the highest level certificate authority for an organization. By default, all members of the forest where it is installed trust it, which can make it a convenient mechanism for securing OWA or other services within a domain environment. Unless an existing enterprise root CA is in place, this is the typical choice for a home-grown CA solution in an organization.

• Enterprise subordinate CA An enterprise subordinate CA is subordinate to an existing enterprise root CA, and must receive a certificate from that root CA to work properly. In certain large organizations, it may be useful to have a hierarchy of CAs, or the desire may exist to isolate the CA structure for OWA to a subordinate enterprise CA structure.

• Stand-alone root CA A stand-alone root CA is similar to an enterprise CA, in that it provides for its own unique identity and can be uniquely configured. It differs from an enterprise CA in that it is not automatically trusted by any forest clients in an organization.

• Stand-alone subordinate CA A stand-alone subordinate CA is similar to an enterprise subordinate CA, except that it is not directly tied or trusted by the forest structure, and must take its own certificate from a stand-alone root CA.

After choosing the type of CA required, continue the CA installation process by performing the following steps:

Installing an Internal Certificate on the OWA Server

After the Internal CA is in place, the OWA server can automatically use it for generation of certificates. To use an internal CA to generate and install a certificate on an OWA server, use the following technique:

CAUTION

The following procedure requires the ISA Server to be a domain member of the forest where the enterprise certificate authority is installed. If the ISA server is not a domain member, such as in the scenarios where ISA is a stand-alone server in the DMZ of an existing firewall, the enterprise CA cannot be accessed directly. Instead, the certificate must be installed either through use of a third-party CA or from the internal CA via web auto-enrollment. The procedure for installing an enterprise CA certificate on a stand-alone ISA Server via web auto-enrollment is covered in Chapter 7.

After installation, the certificate can be viewed by clicking on the View Certificate button of the Directory Services tab under the Virtual Server properties.

After SSL is placed on a server, SSL encryption is made available on the OWA server. If the Enterprise Certificate Authority was installed in an Active Directory domain, then all the domain members will include the internal CA as a trusted root authority and connect to OWA via SSL with no errors. External or non-domain members, however, need to install the Enterprise CA into their local trusted root authorities to avoid the error message described in the previous section.

Forcing SSL Encryption for OWA Traffic

After either a third-party or a local internal certificate has been installed on an OWA server, it is typical to then set up the OWA server to force SSL traffic, rather than allow that traffic to use the unencrypted HTTP protocol. This is especially necessary given the fact that most users simply connect to the OWA server from their browser by typing in the name of the server, such as mail.companyabc.com, which defaults to the unencrypted http:// prefix, rather than the encrypted https :// prefix. To solve this problem, SSL encryption must be forced from the OWA server via the following procedure:

NOTE

Although it may seem like it is better to force SSL on the entire site, it is not actually required, and can also interfere with some of the functionality that may be needed, such as automatic redirection of users, covered in the next section of this chapter. The Exchange and Public virtual directories are the only default directories that should have their information encrypted.

Customizing and Securing an OWA Website from Internal Access

Before Outlook Web Access can be secured with ISA, it should pass through a series of internal securing procedures. This helps to mitigate the risk of internal attack against the OWA server, and prepares it for being further secured with ISA Server. The following section deals with best practice methods to optimize and secure the OWA site with standard Windows and Exchange methods . After the site is secured in this fashion, the ISA specific mail publishing rules can be applied.

Redirecting Clients to the Exchange Virtual Directory

By default, any clients that access an OWA implementation by simply typing in the name of the server, such as mail.companyabc.com, do not gain access to OWA, as the full patch to the Exchange virtual directory (for example, http://mail.companyabc.com/exchange) must be entered. For external access through ISA, methods to automate this process are described later, but for internal access (without using ISA), a simple trick automates this procedure. To set up the automatic redirection to the Exchange virtual directory, perform the following steps on the OWA server:

With the automatic redirect in place, the OWA server is configured to automatically add the /exchange to the URL that the user enters.

Creating a Custom SSL Error to Redirect HTTP Traffic to SSL

One of the downsides to forcing SSL encryption on the OWA server is that the users receive a 403.4 error message similar to the one shown in Figure 12.12 when they try to connect to the OWA server using the standard http protocol.

Although a handful of users would be able to recover from this error message and put the https:// as the prefix to the URL, a large number of them would probably not, which could make the OWA login process less than transparent and frustrating to many. A simple fix to this problem is to generate a custom error message to replace the 403.4 message with one that will automatically redirect the users to the https:// OWA namespace.

The 403.4 error message must be replaced by a custom ASP web page that redirects the requestor to the SSL website and the Exchange virtual directory on the server. The code of the ASP file can be input in Notepad and should be exactly as follows (do not replace any of the variables with real server names ):

<%
     If Request.ServerVariables("SERVER_PORT")=80 Then
         Dim strSecureURL
         strSecureURL = "https://"
         strSecureURL = strSecureURL & Request.ServerVariables("SERVER_NAME")
         strSecureURL = strSecureURL & "/exchange"
         Response.Redirect strSecureURL
     End If
   %>

The high-level process to create this message is as follows:

After the file is created, the virtual directory must be changed to allow anonymous connections and to use the proper application pool. If this is not done, users will not be properly redirected. Perform the following steps to set this up:

The last step is to actually change the 403.4 error message to use the custom ASP page. To do this, follow these steps:

At this point, the Exchange Outlook Web Access server is now configured to automatically redirect all users to SSL encrypted traffic, the first step to securing the OWA server for access from the Internet. In addition, the server is positioned to have ISA Server 2004 secure the access to the IIS Virtual Server, through ISA's mail publishing rules.

NOTE

For more information on using this technique to redirect to SSL connections, reference MS KB article #555126 at the following URL:

http://support.microsoft.com/kb/555126

Summarizing OWA Virtual Server Settings

It is sometimes difficult to keep track of the particular SSL and authentication settings that constitute best practice OWA design. Consequently, Table 12.1 is provided to give administrators a quick glance at best practice OWA virtual server and virtual directory settings. This table is meant to be used as a general guideline for organizations seeking a laundry list of standard settings.

Table 12.1. OWA Virtual Server Settings

NOTE

Table 12.1 lists a full spectrum of potential virtual directories that an OWA server may use. Depending on what is installed and/or enabled, they may or may not be present on a particular OWA virtual server. The subsequent chapter of this book, Chapter 13, "Securing Messaging Traffic," has detailed information on setting up some of these features, such as OMA, RPC-HTTP, and ActiveSync.

CAUTION

Service packs and hotfixes can have the effect of erasing custom changes made in IIS Manager, including SSL and Authentication settings on virtual directories. One of the first things that should be done after applying patches or service packs should be to double-check these settings and validate functionality.