If you haven't yet implemented Outlook Web Access (OWA) with Secure Sockets Layer (SSL), you should. OWA sessions aren't encrypted by default, and the communication between the Exchange server and the end-user browser is in clear text. Adding SSL to your OWA sessions ensures end-to-end encryption for the duration of the session. Most important, enabling SSL also lets users change their Windows NT passwords through the OWA client. In the absence of SSL, you can't change passwords.
Microsoft's Knowledge Base provides step-by-step information about how to apply SSL security on OWA. In particular, see "XCLN: Configuring Exchange OWA to Use SSL" (http://support.microsoft.com/support/kb/articles/q234/0/22.asp). You need to use a certificate from either a commercial Certificate Authority (CA) such as VeriSign or from Microsoft Certificate Server. The Microsoft article "How to Configure Certificate Server for Use with SSL on IIS" (http://support.microsoft.com/support/kb/articles/q218/ 4/45.asp) describes how to use a certificate.
Certificate Server is more appropriate for implementations of OWA that are intranet based so that a local authority can satisfy security requirements. If you want to deploy OWA for both intranets and extranets, a commercial certificate is better. When you acquire a certificate from VeriSign, VeriSign verifies your company credentials as part of the process. That way, a disinterested third party vouches for your credentials and confirms that you are who you say you are. Using a commercial certificate instead of Certificate Server is akin to having a legal document notarized. Both Certificate Server and a commercial certificate encrypt the session end to end.
