SharePoint with Apache mod_proxy

The Apache Software Foundation provides a reverse proxy module named mod_proxy and mod_ssl (which extends functionality into SSL). This is a non-authenticating reverse proxy similar to function to Microsoft’s IIS Application Request Routing module. This article will cover getting a single Web Application on a single SharePoint server behind the reverse proxy over SSL on port TCP/443. We will be starting from the same VM as used in the previous blog post about using CentOS and iptables, so familiarize yourself with that before continuing as that will be the base configuration moving forward. By now I will assume that you’re familiar enough with vi to know how to save files. In addition, I will assume that the Domain Controller on the Hyper-V Internal vSwitch is at 192.168.0.2 and the SharePoint server is at 192.168.0.3. In addition, our SharePoint server is going to have an SSL certificate of sharepoint.corp.nauplius.net, and of course that is what our Web Application will be. This particular SSL certificate has been issued from StartSSL (it’s free).

The first step will be to modify the networking on the CentOS virtual machine.

vi /etc/sysconfig/network-scripts/ifcfg-eth0

Add a new line:

PEERDNS=no

This will disable the DHCP client (dhclient) from automatically adding the DHCP servers DNS information to /etc/resolv.conf (which is what allows the VM to automatically resolve domain names). Instead, we’re going to manage that using the internal Domain Controller over eth1!

vi /etc/sysconfig/network-scripts/ifcfg-eth1

Add a new line:

DNS=192.168.0.2

Next, let’s edit the resolv.conf

vi /etc/resolv.conf

Change it so it reads:

search <Active Directory FQDN>
192.168.0.2

The next step is to bring up and down both interfaces.

ifcfg down eth0
ifcfg up eth0
ifcfg down eth1
ifcfg up eth1

Once both interfaces are back up, your Windows Servers should continue to have name resolution connectivity to the Internet. In addition, /etc/resolv.conf should show the static settings you inputted (cat /etc/resolv.conf). In addition, you should be able to ping, from the CentOS VM, to the internal servers by IP and FQDN. Next, we need to install a few packages on CentOS. Apache (for mod_proxy), mod_ssl (for SSL support), and bind_utils (for dig, similar to nslookup on Windows).

This allows iptables to accept SSL traffic to the reverse proxy (locally).

The next section will not be quite as easy. We will be dealing with SSL certificates on the CentOS VM. In order to do this properly, we’ll need to upload certificates to the CentOS VM and unlike Windows, it isn’t quite the point-and-click affair with PFX.

Most SSL certificate vendors will offer an unencrypted private key as well as public key file. You’ll want both of these. In addition, you’ll also want the appropriate Certificate Authority SSL certificate bundle (this contains the public certificate chain for your SSL certificate). If your SSL vendor does not offer these file types, you’ll need to use OpenSSL to convert the files to the appropriate file formats. For reference, here will be my file names:

Unencrypted private key: sharepoint.key

Public key: sharepoint.cer

CA bundle: startssl-bundle.pem

In addition to this, specifically for mod_ssl, we will need a single file that contains both the public and unencrypted private key in a single file. It should be in the following format:

You can use a program like Notepad++ to edit the sharepoint.key and sharepoint.cer files to create the new files with the public and private key contained within it. This will be the Public-Private key bundle, and saved as sharepointpubpriv.crt. Now all of these files need to be transferred to the CentOS VM. In order to do this, we’ll use a protocol called SCP. This protocol allows you to transfer files over SSH. Thanks to our default iptables rules, SSH is already open on our eth0 interface! Grab a copy of WinSCP and copy these files over to a directory (e.g. /root).

The next step is to copy over the files to the appropriate default locations.

In my example, I’ve removed the Listen 80 as well as the default VirtualDirectory. This is a reverse proxy intended to only listen on 443 and serve requests to our internal SharePoint server. There are many other settings within here that you can modify and likely should modify, but this is not an in depth lesson on Apache security.

The next step is to modify the ssl.conf file.

vi /etc/httpd/conf.d/ssl.conf

LoadModule ssl_module modules/mod_ssl.so should be present at the top of this configuration file.

Instead of providing you specific lines to set, here is the entire configuration. Again we’re using my example domain here, so adjust to fit your needs.

Make sure at the end of the ProxyPass and ProxyPassReverse lines you end them with a “/” at the end of the path, otherwise relative paths will not be returned properly to the reverse proxy and you’ll see unexpected results.

Once the changes are configured, run

service httpd restart

Any errors will be logged in the log files at /var/log/httpd/error_log and sharepoint_ssl_error_log. To watch error_log in real time, run:

tail -f /var/log/httpd/error_log

The last step would be to edit the hosts file on any client computer to target, in this case, sharepoint.corp.nauplius.net at the IP of the eth0 interface. If everything goes well, we should be prompted for credentials and let right through to the SharePoint site!