Apache ReverseProxy for OWA

Here’s how I was able to get ReverseProxy working on Apache to protect an Exchange 2007 OWA instance. You’ll note that in certain areas I have the same thing multiple times with slight changes in capitalization. Microsoft does not understand case sensitivity nor POSIX compliance. All of the following goes inside a VirtualHost, of course. Please note, this was figured out on my own without official documentation (since I couldn’t find any) and would love to hear if you found something else. We also are not running rpc over https, so I’m not sure if the rpc directories are correct.

<IfModule mod_proxy.c>
SSLProxyEngine on
RequestHeader set Front-End-Https “On”

# Proxy all of the sub-directories, otherwise go to /owa/
# You’ll notice that some of these subdirectories are spelled
# multiple ways – MS can’t give us a definitive answer…

# Fix trailing slash problem
RedirectMatch permanent /$ https://external.mail.server/owa/
RedirectMatch permanent /owa$ https://external.mail.server/owa/

# Needed for Blackberry Phones
<Location /EWS>
ProxyPass https://internal.mail.server/EWS
ProxyPassReverse https://internal.mail.server/EWS
</Location>

# Enables legacy pre 2007 Exchange connections
<Location /exchange>
ProxyPass https://internal.mail.server/exchange
ProxyPassReverse https://internal.mail.server/exchange
</Location>

<Location /Exchange>
ProxyPass https://internal.mail.server/Exchange
ProxyPassReverse https://internal.mail.server/Exchange
</Location>

# Enables legacy pre 2007 Exchange connections
<Location /exchweb>
ProxyPass https://internal.mail.server/exchweb
ProxyPassReverse https://internal.mail.server/exchweb
</Location>

<Location /Exchweb>
ProxyPass https://internal.mail.server/Exchweb
ProxyPassReverse https://internal.mail.server/Exchweb
</Location>

# Enables Windows Mobile ActiveSync
<Location /Microsoft-Server-ActiveSync>
ProxyPass https://internal.mail.server/Microsoft-Server-ActiveSync
ProxyPassReverse https://internal.mail.server/Microsoft-Server-ActiveSync
</Location>

# Something about AutoDiscover is important
<Location /Autodiscover>
ProxyPass https://internal.mail.server/Autodiscover
ProxyPassReverse https://internal.mail.server/Autodiscover
</Location>

<Location /AutoDiscover>
ProxyPass https://internal.mail.server/AutoDiscover
ProxyPassReverse https://internal.mail.server/AutoDiscover
</Location>

<Location /autodiscover>
ProxyPass https://internal.mail.server/autodiscover
ProxyPassReverse https://internal.mail.server/autodiscover
</Location>

<Location /autoDiscover>
ProxyPass https://internal.mail.server/autoDiscover
ProxyPassReverse https://internal.mail.server/autoDiscover
</Location>

# Not sure if we need the rest of these
<Location /OAB>
ProxyPass https://internal.mail.server/OAB
ProxyPassReverse https://internal.mail.server/OAB
</Location>

<Location /public>
ProxyPass https://internal.mail.server/public
ProxyPassReverse https://internal.mail.server/public
</Location>

<Location /Public>
ProxyPass https://internal.mail.server/Public
ProxyPassReverse https://internal.mail.server/Public
</Location>

<Location /rpc>
ProxyPass https://internal.mail.server/rpc
ProxyPassReverse https://internal.mail.server/rpc
</Location>

<Location /RPC>
ProxyPass https://internal.mail.server/RPC
ProxyPassReverse https://internal.mail.server/RPC
</Location>

<Location /Rpc>
ProxyPass https://internal.mail.server/Rpc
ProxyPassReverse https://internal.mail.server/Rpc
</Location>

<Location /rpcwithcert>
ProxyPass https://internal.mail.server/rpcwithcert
ProxyPassReverse https://internal.mail.server/rpcwithcert
</Location>

<Location /RpcWithCert>
ProxyPass https://internal.mail.server/RpcWithCert
ProxyPassReverse https://internal.mail.server/RpcWithCert
</Location>

<Location /UnifiedMessaging>
ProxyPass https://internal.mail.server/UnifiedMessaging
ProxyPassReverse https://internal.mail.server/UnifiedMessaging
</Location>

<Location /unifiedmessaging>
ProxyPass https://internal.mail.server/unifiedmessaging
ProxyPassReverse https://internal.mail.server/unifiedmessaging
</Location>

<Location /unifiedMessaging>
ProxyPass https://internal.mail.server/unifiedMessaging
ProxyPassReverse https://internal.mail.server/unifiedMessaging
</Location>

# Really doubt we need this – should probably remove
<Location /aspnet_client>
ProxyPass https://internal.mail.server/aspnet_client
ProxyPassReverse https://internal.mail.server/aspnet_client
</Location>

# Actual Proxy for OWA (web browser based mail)
ProxyPass /owa/ https://internal.mail.server/owa/
ProxyPassReverse /owa/ https://internal.mail.server/owa/
</IfModule>

Sorry the formatting is a little messed up :(

New location for SSL Certificates

So I am just starting to use RHEL/CentOS 5 on newer servers and starting to find some of things that were changed. Normally (in versions 3 or 4) the SSL certificate files were stored in /etc/httpd/conf/ssl.key, etc. Now when you install mod_ssl to enable the https server, the default location for these certificates is in /etc/pki/tls/ (certs & private). It makes sense to move it to a more central location so that it is common with other TLS/SSL oriented services.

I have also just upgraded a server to 5.1 and everything seems to be running well!

Intermediate or Chain SSL Certs on BigIP 4.5

If you do a search out on the Internet today for instructions on how to properly chain a SSL certificate from a provider like GoDaddy on BigIP load balancing appliance (more specifically the older 4.5 version), you will find a confusing and complicated set of instructions that don’t even work. I’m not sure why it’s not documented, since it is an easy thing to do.

The first thing you want to do is setup the SSL cert like you normally would through the Proxies | Cert Admin tab. Generate your key and send off your CSR. When you get the cert back, associate the CRT with the key and you are done with the normal part.

Now, the next thing you want to do is install the intermediate or chain certificate that you received from the provider. For example, if you bought a SSL cert from GoDaddy, then create another cert called gd-intermediate to match the name of the certificate bundle they sent you. In this case though since you have no key or csr to match it to, choose “import” from the top of the Cert Admin page. Then choose certificate, and then browse to the intermediate cert file they sent you.

Once you have both certificates installed, you can now create the SSL proxy that will utilize those certificates. Choose the main certificate and key like a normal SSL proxy, then click next. You’ll notice that on the third page (when clicking next), that there will be an option for Client Chain File. Open the dropdown menu and select the intermediate key you installed earlier. Finish the creation of the SSL proxy and you’re set!