Monthly Archives: June 2014

Use Apache 2.4.x as a secure reverse proxy for JBoss Wildfly

Published / by maurice / Leave a Comment

Quite some time ago, I wrote a post about using Apache as a secure reverse proxy for JBoss AS5. The development of both web servers and application servers has not come to a stand-still, so I felt it was time for a follow-up – not in the least because I have to configure such a set-up again myself.

This time around, Apache httpd has advanced to version 2.4 (the Ubuntu distro I’m using, 14.04 LTS, comes with version 2.4.7; the latest version available is 2.4.9); the JBoss application server has been going through versions AS6, AS7 and finally – reflecting a new naming scheme – Wildfly8 (I’m using version 8.1.0.Final).

For me, Apache is installed i/etc/apache2/, and you may install Wildfly anywhere (I’ll use {$wildfly-home-dir} to denote the path).

Note: The JBoss documentation expresses a preference for mod_cluster when putting the app server behind an Apache. However, this component is – as far as I can tell – only available for httpd 2.2.x (x >= 8), and trying to included the precompiled modules in an httpd 2.4 led to errors.

I decided to keep the default Apache installation and use mod_proxy_ajp instead; that was possible since I didn’t need the advantages mod_cluster advertises to have over its alternatives.

Securing the connection

To enable SSL security on the connection, enable the following parts in the /etc/apache2 directory by creating a symbolic link in the *-enabled subdirectories that point to the *-available subdirectories:

  • /etc/apache2/mods-enabled$ sudo ln -s ../mods-available/ssl.conf

 

  • /etc/apache2/mods-enabled$ sudo ln -s ../mods-available/ssl.load

 

  • /etc/apache2/mods-enabled$ sudo ln -s ../mods-available/socache_shmcb.load
  • /etc/apache2/mods-enabled$ sudo ln -s ../mods-available/rewrite.load

 

  • /etc/apache2/sites-enabled$ sudo ln -s ../sites-available/default-ssl.conf

To make sure that all calls are made secure, redirect calls to the normal HTTP endpoints by adding an appropriate entry in the default virtual host configuration:

  • In /etc/apache2/sites-enabled/000-default.conf:
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

Note 1: The preferred RedirectPermanent directive didn’t seem to work properly for me. Maybe I just mis-configured something for that.

Note 2: An official SSL certificate needs to be purchased and installed to remove the warning browsers issue when landing on a page on the server. I’m not delving deeper into this issue here, see the mod_ssl description for details.

Enable the AJP protocol in Wildfly

To be accessible for the calls through the reverse proxy, Wildfly must expose a port on which it listens for traffic following the AJP protocol.

  • Add an entry to the {$wildfly-home-dir}/standalone/configuration/standalone.xml file, in the undertow subsystem within the default-server section:
    <name="ajpListener" scheme="http" socket-binding="ajp"/>

That’s all, because the corresponding socket binding is enabled by default (see bottom of that file), on port 8009.

Setting up Apache as a secure reverse proxy for Wildfly

Enable the following modules in order to be able to use mod_proxy_ajp:

  • /etc/apache2/mods-enabled$ sudo ln -s ../mods-available/proxy.conf

  • /etc/apache2/mods-enabled$ sudo ln -s ../mods-available/proxy.load

  • /etc/apache2/mods-enabled$ sudo ln -s ../mods-available/proxy_ajp.load

Activate the secure reverse proxy to the application server:

  • Add a proxying entry to the /etc/apache2/mods-enabled/proxy.conf file:
    ProxyPass / ajp://localhost:8009/
  • Enable secure proxying in the /etc/apache2/sites-enabled/default-ssl.conf file:
    SSLProxyEngine on

Taking it for a test run

Now fire up the application server:

  • {$wildfly-home-dir}/bin/standalone.sh

and (re)start the webserver:

  • sudo service apache2 restart

and go to the root of your installation (which may be  http://localhost/  if you’re trying this out locally). What you should see now is a warning from your browser, telling you the certificate that’s used by the site you’re trying to access is not trusted. If you choose to ignore this warning – you can, i.e. if you trust your own server – then you should be redirected to the landing page of the Wildfly installation (or anything you have deployed in the root context instead), served over a secure SSL connection.