The situation is: you have an web application or URL that you would like to force your users (or yourself) to use the secure https protocol rather than the unencrypted http protocol. This is easy to do with Apache and .htaccess.

Create or add to the .htaccess file in the root of the web directory you would like to force redirect for. Add the following lines:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

This says that if https is off, reload the page at the same location using HTTPS instead.

For Firefox and Opera only: Use the Google Secure Pro Greasemonkey script to force these Google programs to use SSL in your browser. It changes any accesses via http to https which is supported by Google, this secures your connection between your browser and Google’s servers.

If you do any type of work using Google’s services where private data is exchanged, I would highly recommend this greasemonkey script to secure your communications!

Apache’s mod_proxy module is simply one of the best Apache modules out there. With it, you can do all sorts of things that you usually would not be able to do if you are behind a firewall or other limited network situations.

A problem that recently came up for me was how Microsoft Outlook Web Access (OWA) needs to run on an exchange server, however my linux server is the one that faces the internet (I have the firewall forward the ports to this server). I also purchased an SSL certificate for one domain, so I wanted to use this certificate to access OWA with a proper validating certificate.

All sounds well and good. Using this mod_proxy configuration should work:
ProxyPreserveHost On

#OWA
ProxyPass /exchange https://exchangserver.example.com/exchange
ProxyPassReverse /exchange https://exchangeserver.example.com/exchange
ProxyPass /Exchange https://exchangeserver.example.com/exchange
ProxyPassReverse /Exchange https://exchangeserver.example.com/exchange
ProxyPass /exchweb https://exchangeserver.example.com/exchweb
ProxyPassReverse /exchweb https://exchangeserver.example.com/exchweb
ProxyPass /public https://exchangeserver.example.com/public
ProxyPassReverse /public https://exchangeserver.example.com/public
ProxyPass /iisadmpwd https://exchangeserver.example.com/iisadmpwd
ProxyPassReverse /iisadmpwd https://exchangeserver.example.com/iisadmpwd

Problem - it works ok - except in IE it will prompt you for the password indefinately and not allow you in. In Firefox (Mozilla) it rejects your password, until you hit cancel, then enter your password and it finally allows you in.

To fix this issue, you need to disable “Integrated Windows Authentication”. In the IIS administration panel, go to the website for your exchange server (”Default site” by default) and find the exchange share (This is most likely “Exchange” and “Public”). From there, right click, go to Properties->Directory Security->Anonymous Access and Authentication Control. Make sure “Basic Authentication” is checked while “Integrated Windows Authentication” is unchecked. Do this for any other Exchange shares. This allows authentication to work OK.

Second problem… in OWA, in Internet Explorer only, when you try to view your inbox the “Loading…” message appears indefinately. Microsoft’s Knowledgebase Article 280823 has a few workarounds for this problem, none of which worked for me. OWA apparently has two modes that it runs in, “rich” and “reach” modes. The “rich” client, which it uses for Internet Explorer, can have issues when running behind a firewall. It uses http-dav components which are not passed through correctly.

Now a fix, let’s make sure all clients run in “reach” mode! Using apache, we can hard-code the User agent that will hit the Exchange server. We use the mod_header module of apache, so make sure you compile it in with –enable-headers. Note: this only works with Apache 2.0. Once you have this compiled in, let’s set the User agent:
RequestHeader set User-Agent "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7)"
You can use whatever you’d like in the user-agent string, as long as Outlook Web Access does not think it is IE, then it will serve the “reach” client.

After correcting all of the above issues, Outlook Web Access finally works in both Internet Explorer and Firefox.