\[Editor's Note: Email your Exchange Server and Outlook solutions (400 words maximum) to R2R at [email protected]. Please include your phone number. We edit submissions for style, grammar, and length. If we print your contribution, you'll get $100.\]
In the interest of security and secure data on Web pages, more and more companies are using Secure Sockets Layer (SSL). The more Microsoft Outlook Web Access (OWA) servers and Internet-available intranets that pop up, the more sense it makes to use SSL to encrypt data and, more important, usernames and passwords.
One problem with requiring SSL is that if people use a non-SSL connection to access a site, they get an error 403.4 that can confuse users who don't understand this technology. The error reads
HTTP Error 403 403.4 Forbidden: SSL required
This error indicates that the page you are trying to access is secured with Secure Sockets Layer (SSL). In order to view it, you need to enable SSL by typing "https://" at the beginning of the address you are attempting to reach. Please contact the Web server's administrator if the problem persists.
I know two ways to force users to use SSL connections without the confusion that receiving an error message causes: the error message redirect method or the virtual server redirect method.
The error message redirect method. When users select the Require Secure Channel when accessing this resource check box, they receive the 403.4 error message. To prevent users from getting this error message, you can create a simple HTML document, which Listing 1 shows, that redirects users to the SSL-enabled site and use it as your error page for error 403.4 instead of the default message.
The virtual server redirect method. On the site on which you require SSL, change the HTTP port from the default port 80 to another port not in use (e.g., port 65). Create a new virtual server that listens on port 80. Then, on the home directory page for the OWA Web site, select Redirect to another URL and enter your SSL-based URL.
I prefer the second method, primarily because it's a server-based redirection rather than a client-based action and—in theory, at least—much faster. Second, the server-based redirection works with any browser. If you're using the first method, when someone using an older browser hits a site, the META refresh tag might not work. However, an older browser might not support SSL either!
