In order to set up SSL on any Exchange 2000 or 2003 server, you simply obtain a Web server certificate from a certificate
authority (CA). You then configure the Exchange virtual directory in your Default Web site on the Exchange 2000 server to only allow secure HTTP (https://) connections. This will encrypt communications from the Web-based clients to the Exchange server end-to-end using Public Key Cryptography.
An example of a public CA is the well known and very popular VeriSign, which will lease you a certificate that must be renewed periodically. It is also possible to establish your own CA on a Windows 2000 server and manage your own certificates. The process of configuring SSL for OWA is fully detailed in Microsoft KB article 320291, Turning On SSL for Exchange 2000 Server Outlook Web Access.
The next step, as you alluded to, would be to create rules on your firewall(s) to allow communication on ports 80 (HTTP) and 443 (HTTPS) from every external address to your Exchange 2000 server and vice versa. Since your Exchange 2000 server is most likely using a private IP address, you can use Network Address Translation (NAT) on your firewall to translate a public IP address (of your firewall) to the private IP address of your Exchange 2000 server.
So why create a front-end server? A common reason is to add one more layer of security to the mix. Front-end servers do not store data. Therefore they can be locked down and fortified to a greater degree than your current back-end server. Front-end servers can also be strategically placed on the network in a de-militarized zone (DMZ). This area sits between your private network and the Internet, giving you even more control over what communication you will allow in and out of your environment. One or more of these reasons could easily justify you adding a front-end server to your Exchange organization.
If you do decide to go with a front-end server in a DMZ, be prepared to have to open additional ports on your internal firewall to allow the front-end server to function as a member of your Active Directory domain, as described in Microsoft KB article 280132, Exchange 2000 Windows 2000 Connectivity Through Firewalls.
As an alternative to a front-end server, you can consider two other options. You could add a Microsoft ISA (Internet Security and Acceleration) server and use the ISA server to "publish" OWA. This is also known as proxy. The Microsoft ISA server can function as an external firewall, internal firewall and proxy server all-in-one. Microsoft ISA is also Exchange friendly, making it fairly easy to use in a Microsoft-centric environment. See KB article 290113, How to publish Outlook Web Access behind Internet Security and Acceleration Server. And finally, if an upgrade to Exchange 2003 is on your horizon, then it might be worth your time to research RPC over HTTP. Exchange Server 2003 running on Windows Server 2003 can be configured as an RPC proxy server. Outlook 2003 can be configured to send its RPC communications to the server encapsulated in a HTTP header. This can be further secured by enabling SSL communications on the RPC proxy server. This would give you thick client functionality and secure connections without a VPN connection. If you would like more information on RPC over HTTP reach KB article 833401, How to configure RPC over HTTP on a single server in Exchange Server 2003.
Do you have comments on this Ask the Expert Q&A? Let us know.
More information from SearchExchange.com:
Dig deeper on Outlook Web Access
Related Q&A from Richard Luckett
There are a number of actions to take to implement OWA security, including obvious ones like creating strong password policies. Admins should also ...continue reading
Our resident Microsoft Lync expert explains where to find IP phones that are compatible with Microsoft Lync Server.continue reading
While Cisco IP phones are not directly compatible with Microsoft Lync Server, there are ways to make them compatible. Lync guru Richard Luckett ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.