verance
asked on
Help with reverse-proxy Apache OWA setup
All,
I am working on hiding an Exchange server within the internal network and using a Linux system within the DMZ to process incoming webmail requests in a reverse-proxy setup.
Currently the Exchange server (2003) is setup with a Verisign certificate to provide https:// access to OWA. The firewall only allows 443 (https) and 25 (smtp) access to this system.
I have been looking over the following two links as a guide to this process.
http://3cx.org/nucleus/plugins/print/print.php?itemid=46
http://blog.scottlowe.org/2005/12/03/protecting-owa-with-apache/
My reverse-proxy setup is a Linux server / Apache 2, with the webserver's configuration handled within a Virtual Hosts file (instead of in the main body of the conf file).
As I am going through this I am faced with the following questions.
1.) Currently to access OWA one would type in https:// followed by the external address of the OWA server. In the case of the ProxyPass and ReverseProxyPass statements in the articles - why http:// instead of https:// Is it the RequestHeader directive to set Front-End-Https "On" that takes care of this?
2.) Currently the Exchange server has it's Verisign certificate running on the IIS server to provide secure web traffic. It appears in these articles that the proxy server now controls the Verisign certificate and the internal OWA server is returned to http:// - no certificate - Is this correct? Am I having the current web certificate regenerated to work under an Apache server instead of IIS?
3.) Could you please check my Virtual Hosts config vs. ones you've seen work and let me know if any changes need to be made?
This is a very important project that I need to have up soon!!!
Below is the current configuration of my Virtual Hosts file on the Exchange server (with actual names disguised):
#
# Virtual Hosts
#
# Using name-based virtual hosting.
#
##########################
#
NameVirtualHost *:80
NameVirtualHost *:443
#
# Using mod_rewrite to fix a problem when percent symbols are in
# the subject line of the OWA email (the email subject is used
# in the web query). The entire URI is passed to a small
# bash script that replaces all occurrences of the % symbol
# with the URI escape sequence (%25). That seems to make everything
# happy.
#
SSLProxyEngine on
ProxyPreserveHost on
RewriteEngine On
RewriteMap damnpercent prg:/usr/local/bin/percent
RewriteCond $1 ^/exchange/.*\%.*$
RewriteRule (/exchange/.*) ${damnpercent:$1} [P]
ProxyRequests Off
#
<VirtualHost *:443>
DocumentRoot /usr/local/apache2/htdocs/
RequestHeader set Front-End-Https "On"
ProxyRequests Off
ProxyPreserveHost On
ErrorLog logs/interceptor.mydomain.
CustomLog logs/interceptor.mydomain.
SSLEngine On
SSLCertificateFile /usr/local/apache2/webmail
<Location /exchange>
ProxyPass http://mail.mydomain.com/exchange
ProxyPassReverse http://mail.mydomain.com/exchange
SSLRequireSSL
</Location>
<Location /exchweb>
ProxyPass http://mail.mydomain.com/exchweb
ProxyPassReverse http://mail.mydomain.com/exchweb
SSLRequireSSL
</Location>
<Location /public>
ProxyPass http://mail.mydomain.com/public
ProxyPassReverse http://mail.mydomain.com/public
SSLRequireSSL
</Location>
<Location /iisadmpwd>
ProxyPass http://mail.mydomain.com/iisadmpwd
ProxyPassReverse http://mail.mydomain.com/iisadmpwd
SSLRequireSSL
</Location>
CacheDisable *
</VirtualHost>
##########################
I am working on hiding an Exchange server within the internal network and using a Linux system within the DMZ to process incoming webmail requests in a reverse-proxy setup.
Currently the Exchange server (2003) is setup with a Verisign certificate to provide https:// access to OWA. The firewall only allows 443 (https) and 25 (smtp) access to this system.
I have been looking over the following two links as a guide to this process.
http://3cx.org/nucleus/plugins/print/print.php?itemid=46
http://blog.scottlowe.org/2005/12/03/protecting-owa-with-apache/
My reverse-proxy setup is a Linux server / Apache 2, with the webserver's configuration handled within a Virtual Hosts file (instead of in the main body of the conf file).
As I am going through this I am faced with the following questions.
1.) Currently to access OWA one would type in https:// followed by the external address of the OWA server. In the case of the ProxyPass and ReverseProxyPass statements in the articles - why http:// instead of https:// Is it the RequestHeader directive to set Front-End-Https "On" that takes care of this?
2.) Currently the Exchange server has it's Verisign certificate running on the IIS server to provide secure web traffic. It appears in these articles that the proxy server now controls the Verisign certificate and the internal OWA server is returned to http:// - no certificate - Is this correct? Am I having the current web certificate regenerated to work under an Apache server instead of IIS?
3.) Could you please check my Virtual Hosts config vs. ones you've seen work and let me know if any changes need to be made?
This is a very important project that I need to have up soon!!!
Below is the current configuration of my Virtual Hosts file on the Exchange server (with actual names disguised):
#
# Virtual Hosts
#
# Using name-based virtual hosting.
#
##########################
#
NameVirtualHost *:80
NameVirtualHost *:443
#
# Using mod_rewrite to fix a problem when percent symbols are in
# the subject line of the OWA email (the email subject is used
# in the web query). The entire URI is passed to a small
# bash script that replaces all occurrences of the % symbol
# with the URI escape sequence (%25). That seems to make everything
# happy.
#
SSLProxyEngine on
ProxyPreserveHost on
RewriteEngine On
RewriteMap damnpercent prg:/usr/local/bin/percent
RewriteCond $1 ^/exchange/.*\%.*$
RewriteRule (/exchange/.*) ${damnpercent:$1} [P]
ProxyRequests Off
#
<VirtualHost *:443>
DocumentRoot /usr/local/apache2/htdocs/
RequestHeader set Front-End-Https "On"
ProxyRequests Off
ProxyPreserveHost On
ErrorLog logs/interceptor.mydomain.
CustomLog logs/interceptor.mydomain.
SSLEngine On
SSLCertificateFile /usr/local/apache2/webmail
<Location /exchange>
ProxyPass http://mail.mydomain.com/exchange
ProxyPassReverse http://mail.mydomain.com/exchange
SSLRequireSSL
</Location>
<Location /exchweb>
ProxyPass http://mail.mydomain.com/exchweb
ProxyPassReverse http://mail.mydomain.com/exchweb
SSLRequireSSL
</Location>
<Location /public>
ProxyPass http://mail.mydomain.com/public
ProxyPassReverse http://mail.mydomain.com/public
SSLRequireSSL
</Location>
<Location /iisadmpwd>
ProxyPass http://mail.mydomain.com/iisadmpwd
ProxyPassReverse http://mail.mydomain.com/iisadmpwd
SSLRequireSSL
</Location>
CacheDisable *
</VirtualHost>
##########################
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Originally I had separate proxypass entries defined for each of the OWA components, but once it was determined SSL bridging was needed, I just collapsed them to a single entry.
SSL bridging with Apache is very simple. It's just a matter of specifying https instead of http for the ProxyPass and ProxyPassReverse entries.
If all you OWA users come in via the reverse proxy, it doesn't really matter what cert you put on the IIS server as it is never directly seen. You could even use a self signed cert.
In my situation, I have users access OWA via the reverse proxy and some on dedicated links that access the OWA server directly, so in that instance, I exported the cert from Apache and imported into IIS, so that I had the same Thawte signed cert on the reverse proxy and OWA server.
SSL bridging with Apache is very simple. It's just a matter of specifying https instead of http for the ProxyPass and ProxyPassReverse entries.
If all you OWA users come in via the reverse proxy, it doesn't really matter what cert you put on the IIS server as it is never directly seen. You could even use a self signed cert.
In my situation, I have users access OWA via the reverse proxy and some on dedicated links that access the OWA server directly, so in that instance, I exported the cert from Apache and imported into IIS, so that I had the same Thawte signed cert on the reverse proxy and OWA server.
ASKER
All,
Thx for the help so far.
I have run into the following wall when trying to access the OWA site via a web browser.
In a test lab I built under VMWare a DC, Exchange server, XP workstation, and the Linux Proxy server.
When I request the URL: https://mail.mycorpdomain.com/exchange I am presented with the error:
400 Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
https://internalnameofproxyserver.mycorpdomain.com
In testing I proceeded with the following:
The document root for this webserver is '/www'
I created a basic 'index.html' file and placed it within the document root. Restarted the webserver and entered the same https:// url as above. The simple page I created came up fine.
I am running a test SSL certificate that I created on the Linux proxy server.
Looking in the apache error_log file I have two warnings - neither of which should affect this test:
RSA server certificate CommonName (CN) `mail.mycorpdomain.com' does NOT match server name!?
RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
Apache access logs show:
192.168.88.1 - - [12/Sep/2007:03:45:29 -0700] "GET / HTTP/1.1" 200 100 <--- test with index.html file
192.168.88.1 - - [12/Sep/2007:03:46:01 -0700] "GET /exchange HTTP/1.1" 200 473 <--accessing OWA
In both cases it indicates a 200 for the error code - successful.
My question is - what am I missing on the proxy side to allow Apache to integrate properly with OWA?
Thx for the help so far.
I have run into the following wall when trying to access the OWA site via a web browser.
In a test lab I built under VMWare a DC, Exchange server, XP workstation, and the Linux Proxy server.
When I request the URL: https://mail.mycorpdomain.com/exchange I am presented with the error:
400 Bad Request
Your browser sent a request that this server could not understand.
Reason: You're speaking plain HTTP to an SSL-enabled server port.
Instead use the HTTPS scheme to access this URL, please.
https://internalnameofproxyserver.mycorpdomain.com
In testing I proceeded with the following:
The document root for this webserver is '/www'
I created a basic 'index.html' file and placed it within the document root. Restarted the webserver and entered the same https:// url as above. The simple page I created came up fine.
I am running a test SSL certificate that I created on the Linux proxy server.
Looking in the apache error_log file I have two warnings - neither of which should affect this test:
RSA server certificate CommonName (CN) `mail.mycorpdomain.com' does NOT match server name!?
RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
Apache access logs show:
192.168.88.1 - - [12/Sep/2007:03:45:29 -0700] "GET / HTTP/1.1" 200 100 <--- test with index.html file
192.168.88.1 - - [12/Sep/2007:03:46:01 -0700] "GET /exchange HTTP/1.1" 200 473 <--accessing OWA
In both cases it indicates a 200 for the error code - successful.
My question is - what am I missing on the proxy side to allow Apache to integrate properly with OWA?
ASKER
One additional: I cleaned up my virtual hosts config a bit - this is the current contents of that config file:
#
# Virtual Hosts
#
# Use name-based virtual hosting.
#
# NameVirtualHost *:80
NameVirtualHost *:443
#
<VirtualHost *:443>
ServerAdmin webmaster@mycorpdomain.com
DocumentRoot /www/webmail
ServerName mail.mycorpdomain.com
ErrorLog logs/webmail/error_log
CustomLog logs/webmail/access_log common
SSLEngine On
SSLCertificateFile conf/ssl.crt/server.crt
SSLCertificateKeyFile conf/ssl.key/server.key
RequestHeader set Front-End-Https "On"
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /exchange http://mail.mycorpdomain.com/exchange/
ProxyPassReverse /exchange http://mail.mycorpdomain.com/exchange/
ProxyPass /exchweb http://mail.mycorpdomain.com/exchweb/
ProxyPassReverse /exchweb http://mail.mycorpdomain.com/exchweb/
ProxyPass /public http://mail.mycorpdomain.com/public/
ProxyPassReverse /public http://mail.mycorpdomain.com/public/
ProxyPass /iisadmpwd http://mail.mycorpdomain.com/iisadmpwd/
ProxyPassReverse /iisadmpwd http://mail.mycorpdomain.com/iisadmpwd/
# CacheDisable *
</VirtualHost>
#
# Virtual Hosts
#
# Use name-based virtual hosting.
#
# NameVirtualHost *:80
NameVirtualHost *:443
#
<VirtualHost *:443>
ServerAdmin webmaster@mycorpdomain.com
DocumentRoot /www/webmail
ServerName mail.mycorpdomain.com
ErrorLog logs/webmail/error_log
CustomLog logs/webmail/access_log common
SSLEngine On
SSLCertificateFile conf/ssl.crt/server.crt
SSLCertificateKeyFile conf/ssl.key/server.key
RequestHeader set Front-End-Https "On"
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /exchange http://mail.mycorpdomain.com/exchange/
ProxyPassReverse /exchange http://mail.mycorpdomain.com/exchange/
ProxyPass /exchweb http://mail.mycorpdomain.com/exchweb/
ProxyPassReverse /exchweb http://mail.mycorpdomain.com/exchweb/
ProxyPass /public http://mail.mycorpdomain.com/public/
ProxyPassReverse /public http://mail.mycorpdomain.com/public/
ProxyPass /iisadmpwd http://mail.mycorpdomain.com/iisadmpwd/
ProxyPassReverse /iisadmpwd http://mail.mycorpdomain.com/iisadmpwd/
# CacheDisable *
</VirtualHost>
ASKER
Situation resolved.....
Here is how I fixed it:
1.) I suspected the warning that the certificate name not matching the server name was valid. Since I will not be running any other webs on the reverse proxy box I moved the settings from the separate virtual-hosts file (/conf/extra/httpd-vhosts.
2.) In the file /etc/hosts I incorrectly put the IP address of the reverse proxy server (instead of the internal OWA server) here. The hosts file needs to know the IP address of the internal mail server - however I was redirecting it back to itself - duh!
I'm going to make a copy of the internal OWA certificate and place it into the proxy server to allow forms-authentication to continue to work.
Props to msklizmantas: & tintin for helping on this solution
Here is how I fixed it:
1.) I suspected the warning that the certificate name not matching the server name was valid. Since I will not be running any other webs on the reverse proxy box I moved the settings from the separate virtual-hosts file (/conf/extra/httpd-vhosts.
2.) In the file /etc/hosts I incorrectly put the IP address of the reverse proxy server (instead of the internal OWA server) here. The hosts file needs to know the IP address of the internal mail server - however I was redirecting it back to itself - duh!
I'm going to make a copy of the internal OWA certificate and place it into the proxy server to allow forms-authentication to continue to work.
Props to msklizmantas: & tintin for helping on this solution
ASKER
The idea of keeping Forms Based Authentication active is appealing (storing the user's login credentials in a cookie instead of in the browser - plus it looks better).
Naturally the majority of the article I've researched on using SSL bridging speak of using that with ISA - not much in the way of adapting it into Apache.
Do you know of any articles on this configuration - sharing the SSL cert between the front-end and back-end?
The way it's setup here - all users come in through the same reverse-proxy - no subdomains.
Are you allowed to shorted your reverse proxy config because of the SSL bridging (not having to include a proxypass and proxyreverse for each exchange owa subfolder in IIS?