Networking

SSL certificate options for secure access to Exchange Server through the Internet

Acquiring an SSL certificate before enabling Internet access to Exchange Server


Exchange 2003 has a great new feature that allows Outlook 2003 users to connect to an Exchange server over the Internet and work in Outlook as if they were connected on the internal network. This feature, which is called Exchange RPC Server, also provides secure transmission of data without requiring a VPN connection. It uses the RPC over HTTP service in Windows 2003 Server, and it protects data transmission by using an installed SSL certificate on the Exchange 2003 server.

However, before you can set up this process, you must install an SSL certificate on the Exchange server. How you go about doing this is the focus for this article.

Although in previous versions of Exchange you could establish the connection described above, it was unreliable due to several factors, such as host file configurations and ISP Internet configurations. In previous versions, the connection also transmitted data across the Internet insecurely.

Requirements for implementing an Exchange RPC server
The steps to complete the implementation of an Exchange RPC server are:
  1. Acquire an SSL certificate.
  2. Set up the Exchange RPC server.
  3. Set up Outlook 2003 clients.
  4. Set up the Exchange RPC server to run through an ISA server (optional).

Steps 2 through 4 will be covered in separate articles.

SSL certificate options
Using an SSL certificate requires that you have a certificate authority generate an SSL certificate. There are three certificate authority options.

Third-party certificate authorities
VeriSign and GeoTrust are examples of third-party certificate authorities. They provide SSL certificates for commercial and non-commercial sites across the Internet. Their SSL certificates are automatically recognized by the major Web browsers, such as Internet Explorer and Netscape Navigator.

The down side is that maintaining an SSL certificate can be expensive. This option is best when end users who are not a part of your organization, such as customers, will be using an SSL channel to connect to your Web and/or Exchange server.

Internal certificate authority
If your users connect through the Exchange server, you can maintain your own certificate authority infrastructure and distribute certificates as needed. This is a more affordable option than third-party certificate authorities. Microsoft Certificate Services can be used for this purpose and comes included as a service on Windows Server 2003.

Nonetheless, be aware that if the server becomes compromised, a hacker can corrupt Certificate Services and impersonate you to your end users. Also, if the hard drive fails, you can no longer authenticate your certificates. In either case, it generally means rebuilding your certificate authority infrastructure from scratch. The best way to minimize the impact of certificate corruption is to do the following:
  1. Install your root Certificate Authority on a hard drive that can be removed.
  2. Set up an Issuing (or Secondary) Certificate Authority. This will function as your day-to-day manager of certificates.
  3. Remove and store the hard drive containing your root Certificate Authority in a safe location, such as a safe deposit box or vault.
  4. Create and install an SSL certificate on the Exchange server using the Issuing Certificate Authority.

At this point, if the Issuing Certificate Authority gets corrupted or compromised, it can be rebuilt from the root Certificate Authority.

Self-SSL
Microsoft provides a third option for implementing an SSL certificate. Self-SSL is an IIS 6.0 resource kit tool. This option is obviously inexpensive, but is only recommended when you're using it with a small number of users. If you have a server dedicated to a project team or small office, this is an acceptable option. In this case, the source (or authority) for your SSL certificate is located on the Exchange server, so securing access to the server becomes very important.

Recommended security scenarios
While SSL certificates will help protect data transmission between Exchange and the Outlook clients, you still need to provide protection for the server. The following is a list of acceptable security scenarios, starting with the best:

Demilitarized Zone (DMZ)
A firewall is implemented on the router connected to the Internet (or traffic to and from the router is directed through the firewall). Behind the firewall there should be a server that works as both a proxy server (using a product like Microsoft Internet Security and Acceleration (ISA) Server) and as an Exchange Front-Engine server. A second firewall is placed between your internal network and the DMZ. Behind the second firewall, you place a complete Exchange server.

Modified DMZ scenarios
In this scenario, the Exchange server is placed within the DMZ or on the proxy server. You still maintain a second firewall that connects to your internal network.

Perimeter only
In this scenario, you have only one firewall that separates your internal network and the Exchange server from the Internet. You can use an integrated firewall/proxy server product, such as ISA Server, to serve in this capacity.

Editor's Picks