In this tutorial we will learn how to do client certificate authentications when WildFly is located behind a reverse proxy.
The most common use cases for reverse proxies are:
- When the reverse proxy is located on a DMZ
- When youe Web applications are located on a VLAN (e.g. private network).
- When the reverse proxy reads the initial request, then it initiates a new (even if similar) request to the internal Web applications.
The problem is that, by definition, an HTTPS request’s content cannot be spied. This is why when putting a reverse proxy behind the client and the Web application, the HTTPS stream will be broken and we will loose all the client certificate data contained in the X509 client certificate .
Let’s see how to safely forward the client certificate data to the web application running on WildFly. Let’s start from the front-end, where we will set the SSL information headers:
RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s" RequestHeader set SSL_CIPHER "%{SSL_CIPHER}s" RequestHeader set SSL_SESSION_ID "%{SSL_SESSION_ID}s" RequestHeader set SSL_CIPHER_USEKEYSIZE "%{SSL_CIPHER_USEKEYSIZE}s"
Then, on WildFly, enable the certificate-forwarding=”true” attribute on the Undertow server:
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=certificate-forwarding,value=true)
This will result in the following configuration:
<subsystem xmlns="urn:jboss:domain:undertow:10.0" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other" statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}"> <buffer-cache name="default"/> <server name="default-server"> <http-listener name="default" socket-binding="http" redirect-socket="https" certificate-forwarding="true"/>