The purpose of this blog post is to help configure the Apache Tomcat application server (AppServer) to serve Liferay pages over https. This blog specifically covers scenarios where SSL is terminated at the LoadBalancer or WebServer. When SSL is terminated at the LoadBalancer or WebServer layer, all requests are forwarded to the application server over http. When the application server is not configured to serve pages over https, all the pages rendered to the end user will serve content over http, and this causes browsers to throw mixed content warnings. If the user chooses to view insecure content any way, the data that flows from the user’s browser to the AppServer and could cause confidential user data open to vulnerability.
The Fix
To make the SSL termination work, and to make sure that the rendered items are considered secure by the browser, there are a few changes that are required at the LoadBalancer or WebServer layer. If your setup has a LoadBalancer that forwards requests to the WebServer, then your changes are required at the LoadBalancer only. If your setup doesn’t have a LoadBalancer and has a WebServer only, then your changes will be at the WebServer level.
Loadbalancer
At the LoadBalancer level, for incoming requests on https port, the following headers need to be added:
X-Forwarded-For: this header The X-Forwarded-For (XFF) http header field is a common method for identifying the originating IP address of a client connecting to a web server through an http proxy or load balancer. Please note that this header should be set to expose the internal IP address of the incoming request to the AppServer.
X-Forwarded-Proto: this header is a de facto standard for identifying the originating protocol of an http request, since a reverse proxy (or a load balancer) may communicate with a web server using http even if the request to the reverse proxy is https.
WebServer
Please note that the changes to this section are only required if you don’t have a LoadBalancer. To identify that the originating request was made via SSL, you could set a header at the Loadbalancer level to identify that the incoming request was made via https.
RequestHeader set X-Forwarded-Proto "https"Please note: For websites that have https enabled, you could set a re-write rule to redirect all http traffic to https using the following rule on the WebServer:
RewriteCond %{http:X-Forwarded-Proto} !https
RewriteRule . https://%{http_HOST}%{REQUEST_URI} [R,L]AppServer
Changes at the AppServer are very simple. The AppServer uses a configuration component called RemoteIPValve. Tomcat port of mod_remoteip, this valve replaces the apparent client remote IP address and hostname for the request with the IP address list presented by a proxy or a load balancer via a request headers (e.g. “X-Forwarded-For”).
Another feature of this valve is to replace the apparent scheme (http/https), server port and request.secure with the scheme presented by a proxy or a load balancer via a request header (e.g. “X-Forwarded-Proto”).
This Valve may be used at the Engine, Host or Context level as required. Normally, this Valve would be used at the Engine level.
If used in conjunction with Remote Address/Host valves then this valve should be defined first to ensure that the correct client IP address is presented to the Remote Address/Host valves. Please note that the internalProxies section that has been included here covers most but not all of the common internal LoadBalancer IP addresses.
<Valve className="org.apache.catalina.valves.RemoteIpValve"
internalProxies="10.d{1,3}.d{1,3}.d{1,3}|172.1[6-9].d{1,3}.d{1,3}|172.2[0-9].d{1,3}.d{1,3}|172.3[0-1].d{1,3}.d{1,3}|192.168.d{1,3}.d{1,3}|169.254.d{1,3}.d{1,3}|127.d{1,3}.d{1,3}.d{1,3}"
remoteIpHeader="x-forwarded-for"
protocolHeader="x-forwarded-proto"
protocolHeaderHttpsValue="https" />
Summary
In conclusion, while mixed content warnings sound very complex to fix, and are very common, in reality they are easy to fix. A few considerations that should be taken into account are to use relative urls instead of absolute urls. Content that is rendered on the page should have no non-https links. If planned appropriately from the beginning, the content on a site can be appropriately created from the get-go using secure links as needed. However, for items that are rendered dynamically on the page, RemoteIPValve is a very simple but powerful tool that can reduce the headaches that are associated with insecure content.
If you have questions on how you can best leverage AppServer configuration and / or need help with your Liferay DXP implementation, please engage with us via comments on this blog post, or reach out to us at https://www.xtivia.com/contact/ or [email protected].
Additional Reading
You can also continue to explore Liferay DXP by checking out The Top 10 New Features in Liferay DXP 7 from a functional perspective, or Top 5 New Features in Liferay DXP UI Development and Creating JAX-RS REST Services in Liferay DXP from a development perspective, or Top 5 DevOps Features in Liferay DXP from a devops perspective. You can also, checkout Portal properties changes in Liferay DXP.