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 in /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 theundertow
subsystem within thedefault-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.