Apache 2 or Nginx as a highly secure (PFS) SSL encrypting reverse proxy for eXo Platform 4.0

This guest post is published from an original article by Eric Taïeb Walch.

The goal of this tutorial is to explain, including all the subtleties, how to run eXo Platform 4.0 behind a reverse proxy using Apache 2 or Nginx on GNU/Linux (Debian).

The goals of the reverse proxy are:

  • Securing the eXo platform by hiding it behind the proxy
  • Offloading SSL encryption to the proxy and supporting Perfect Forward Secrecy
  • Using advanced modules such as:
    • caching modules
    • security modules:
      • mod_security on apache or naxsi web application firewall on Nginx
    • Google’s mod pagespeed, etc.
    • Google SPDY 3.1 (only stable on Nginx at the moment).

Using advanced modules is beyond the scope of this topic but might be included in a future post.

All the instructions below are valid for any web server—for instance, Hudson/Jenkins install, and Atlassian web apps such as Jira, Fisheye, Bamboo, etc. It should also work with your own web app running on any platform. It is pure http proxying.

For the sake of simplicity we’ll use the eXo Platform installed in directory EXO_PLATFORM running on default port 8080.

More information on this great enterprise social portal platform can be found here: http://www.exoplatform.com

At the time of this writing the latest community release is 4.0.5 available in 12 languages.

Let’s move on to the main event of the evening!

Getting Started


  • Basic knowledge of GNU/Linux (Debian especially as instructions will be given for Debian-based distributions but may be easily applicable for RedHat/CentOS using the yum package manager)
  • Being familiar with Apache or Nginx configuration directives
  • eXo platform installed and running on Tomcat (using public platform distribution) listening on port 8080
  • Debian server(s) installed and running.

Preliminary Steps

Installing required components/servers:

The reverse proxy (Nginx or Apache) can be installed on the same server as eXo or on a separate server. Nevertheless, it is highly recommended to install the proxy on a dedicated server as it will be more secure. In fact, running the proxy on another server will allow you to expose only the proxy ports (80 & 443) to the “outside” world and keep eXo only listening to the internal infrastructure requests.

  • Enough with the words. Let’s see what it looks like:


Installing the Reverse Proxy

First you have to choose between Nginx and Apache 2. I personally favor Nginx as it has a lot better support for cutting-edge web technologies such as web sockets, streaming, SPDY 3, etc. Moreover, it seems that it scales very well while keeping a smaller memory footprint.

  • On Debian/Ubuntu install the proxy:

For Nginx:

For Debian/Ubuntu, in order to authenticate the Nginx repository signature and to eliminate warnings about a missing PGP key during installation of the Nginx package, it is necessary to add the key used to sign the Nginx packages and repository to the apt program key ring. Please download this key from our website, and add it to the apt program key ring with the following command:

For Debian replace the codename with the Debian distribution codename (i.e. wheezy), and append the following to the end of the /etc/apt/sources.list file:

For Ubuntu replace the codename with the Ubuntu distribution codename, and append the following to the end of the /etc/apt/sources.list file:

For Debian/Ubuntu run the following commands:

NOTE: These instructions come straight from Nginx official documentation: http://nginx.org/en/linux_packages.html#mainline

For Apache 2:

After successfully installing you need to activate mod ssl and mod proxy_http and its dependencies. This is easily done on Debian:

Configuring the Virtual Host for eXo’s Frontend

Let’s assume your eXo platform installation is reachable at the following address:

We’ll also assume you have a certificate and private key for SSL encryption located at /etc/ssl/certs/exo.mydomain.com.crt and /etc/ssl/private/exo.mydomain.com.key

Last but not least, as shown on the diagram above, we’ll assume that the proxy server’s IP address is and that the eXo platform server’s IP address is

Please adapt to your infrastructure’s hostname (exo.mydomain.com) and IP addresses if need be.

On Nginx:

Create a file called exo.mydomain.com.conf in:

with the following contents:

The directive try_files specifies that Nginx will try to locate the requested resource in its document root (/var/www/ in this example). If it fails to find it, it will proxy the request to the @exo backend. This is quite useful as it allows you to place static files in /var/www and they will be served.

The directive client_max_body_size 10m; sets the maximum HTTP post size (i.e. maximum file size upload among others).

You can also play with caching using the following directive (refer to Nginx documentation here http://wiki.nginx.org/ReverseProxyCachingExample):

This setup is the most secure SSL setup configuration (see Forward Secrecy below) as it avoids the weak ciphers and prefers the best ones (it might be too secure for old browsers such as Internet Explorer 6, although you should not be using Internet Explorer 6 anyway).

CREDITS: https://gist.github.com/plentz/6737338

More on Perfect Forward secrecy can be found here: https://en.wikipedia.org/wiki/Forward_secrecy

You need to generate a Diffie-Hellman certificate with this command (this will take some time depending on the performance of your server):

NOTE: You can also enable Google’s SPDY protocol if your Nginx build supports it (the packages installed from the sources above have SPDY 3.1, 1.5.12, and it works perfectly). You can check by running Nginx-V to see the compile time options. If you see SPDY, then your Nginx build is SPDY enabled.

To enable it in your eXo’s virtual host, just add SPDY after the SSL directive. The configuration line (2nd line) above should look like this:

Google’s SPDY 3.1 protocol speeds up pages’ loading time considerably. More information can be found here: https://code.google.com/p/mod-spdy/

This module is bundled in Nginx’s latest mainline release (1.5.12 on April 2014). On Ubuntu you can add the following official Nginx Mainline PPA: https://launchpad.net/~nginx/+archive/development

On Apache:

Create a file called exo.mydomain.com (append .conf to the filename if running Apache version >=2.4) in /etc/apache/sites-available with the following contents, /etc/apache/sites-available/exo.mydomain.com(.conf):

Credits: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

IMPORTANT NOTE: if you host other NAME-BASED virtual hosts (multiple vhosts on one single IP address) it is advised to set eXo’s virtual host as the default one as non TLS/SNI web clients will only see the default virtual host.

On Nginx this is supplied by the ‘default’ keyword in the following line:

Or if you enabled SPDY:

On Apache 2 you just need to write eXo’s virtual host as the first one.

Activate the Virtual Host

For Nginx:

If you created the config file as described above in /etc/nginx/conf.d/exo.mydomain.com.conf you don’t need to do anything else.

For Apache:

Configuring eXo’s Tomcat Connector for Reverse Proxy Operations

Open EXO_PLATFORM/conf/server.xml and modify the port 8080 connector as follows:

The important line is:

This tells Tomcat that it’s running behind an SSL enabled reverse proxy for which the DNS name is exo.mydomain.com and the connection scheme is https.

Increasing Maximum Open Files

As this configuration is optimized for speed, the SPDY feature can lead to a vast amount of open files on Tomcat 7.

Therefore, depending on your GNU/Linux setup, you might need to increase the maximum open files.

On Debian this is done in two steps:

System wide:

Edit /etc/sysctl.conf and add/modify this entry (you may increase/decrease the values):

Then for the user running the eXo platform:

Edit /etc/security/limits.conf and add (in the example below user Exo is running Tomcat):

Then check /etc/pam.d/su file and make sure that the following line is not commented:

Automatic Redirection of Plain HTTP to HTTPS

Below you will find typical Apache and Nginx rewrite rules to redirect http to https.

WARNING: It breaks the mobile app on Android (haven’t tested on iOS). The developer is aware and answered on a Google Playstore comment.

Add this on top of your virtual host configuration file:

For Nginx:

For Apache:

Cherry on the Cake: Custom Error Pages to Handle eXo Maintenance

Both Nginx and Apache can handle custom pages for http errors—especially a nice placeholder page for error 503 under maintenance (when the eXo Tomcat server is down or restarting).

This proves particularly useful for handling scheduled downtimes that occur during offline backups where the eXo server might need to be stopped.

You can also, using the same method, create a custom error page for 404 not found.

First you need to create an html page (50x.html in the example below) and store it (together with its assets) under the document root (defined in your virtual host configuration file, /var/www in this tutorial).

Then add these directives in the virtual host configuration file:

For Nginx:

For Apache:

Result: Qualys SSL Audit

For the Nginx configuration above:


The Full Audit in PDF format is available here.

You can test your installation at: https://www.ssllabs.com/ssltest/analyze.html

That’s all for now.

Stay tuned for additions to this tutorial and other posts related to JavaEE, Systems, Networks and Software architecture.

Thanks for reading, sharing and +1-ing!

Thanks again to Eric Taïeb Walch for his great post. Make sure to check his original article as Eric will make regular updates to his work.

Join the eXo tribe by registering for the community and access tutorials, support, and downloads!

About Eric Taïeb Walch

15 years in developing architectures for realtime web based finance/e-trading, high availability, high performance using JavaEE and Open source software. Loves JBoss, Apache Group, GNU/Linux, Debian. Connect with Eric on LinkedIn.

Eric hosts the Teknologist’s Blog about “Systems, software design, architectures, experiences / experiments shared with the masses. 100% OpenSource. GNU is not Unix.”

Be part of the discussion, share your comments