FreeIPA behind HTTP proxy with different hostname

Jan Pazdziora



The FreeIPA server provides Web user interface to its administrators and users. When the interface needs to be accessible across DMZ or in general from different network, the HTTP proxy might have different hostname than the FreeIPA server itself. Then the HTTP proxy needs a couple of special configuration tweaks to satisfy FreeIPA's requirements.

Front-end proxy

Assume we have FreeIPA server in internal network, named We want to provide access to its Web user interface to users outside of that internal network, and we will set up HTTP proxy for that.

If the HTTP proxy is running on Fedora, we will install the necessary packages with

webipa# dnf install -y httpd mod_ssl

For production setup, we might want to get proper certificates issued, for this testing setup we will just use the autogenerated self-signed defaults.

We will configure the proxy in the _default_:443 virtual host in /etc/httpd/conf.d/ssl.conf:

SSLProxyEngine on
ProxyPass /
ProxyPassReverse /

We can then enable and start the Apache HTTP Server service:

webipa# systemctl enable httpd
webipa# systemctl restart httpd

If the FreeIPA server is on internal network, the proxy which might be in demilitarized zone might not be able to resolve its internal hostname (to get its IP address). In that case, we might need to set it up locally, for example in /etc/hosts.

We can now access the proxy on and we should see our browser redirected to and the logon page shown.

Attempting to log in

We got the proxy working and we see the logon page which came from the FreeIPA server but when we now enter login and password and hit Login, we will see message

Your session has expired. Please re-login.

and we do not get logged in.

The reason for this is the HTTP cookie handling ― the FreeIPA server uses cookies for domain and the Set-Cookie header value might be

ipa_session=d98d6801e791e116899bdd51f7d186f8;; Path=/ipa; Expires=Sun, 05 Jun 2016 08:49:23 GMT; Secure; HttpOnly

Since the request that the browser sent was for, the cookie does not domain-match and will be ignored by the browser and not sent with subsequent HTTP requests.

We can extend the configuration with directive which will map the cookie domain values:


After restarting the httpd service, we can retry the logon attempt. This time we will get error

IPA Error 911: RefererError Missing HTTP referer. <br/> You have to configure your browser to send HTTP referer header.

We are certain that we have browser set up to send the HTTP referer header but that header does not reach the FreeIPA server. Why? The referer as seen by the browser is, not, and the FreeIPA server is checking for the exact hostname match.

We need another mapping in the configuration, this time for the HTTP request's Referer header:

RequestHeader edit Referer ^https://webipa\.example\.com/

We change the referer value sent by the browser to the value that the FreeIPA server wants to see. After another httpd service restart, we are now able to log in and use FreeIPA server's Web UI.

Whole configuration

The configuration change that needs to be done to configure HTTP proxy which will use different hostname than the real FreeIPA server can be summed up as

<VirtualHost _default_:443>
# ...
# add the following directives
SSLProxyEngine on
ProxyPass /
ProxyPassReverse /
RequestHeader edit Referer ^https://webipa\.example\.com/

Accessing the server via HTTP or via different name

In our example we have set up the proxy to access the FreeIPA server using its proper hostname and using its prefered protocol HTTPS. Should we want to make the connection via HTTP, or use different hostname in the proxied request (for example IP address), we might need to do some additional changes in the FreeIPA server's configuration so that it does not attempt to "fix" the incorrect requests. Example can be found in writeup about FreeIPA behind SSL proxy.