Fixed problem to switch to https with a nginx proxy

[Zatalyz]

I share a solution with you; I saw that there had been a few closed tickets on the subject, unfortunately without a relevant solution for my case. This will probably help others. Maybe it can improve FAQ or documentation :)

The situation :
I have a server with proxmox. All the traffic arrives at a first VM that serves as a proxy. Freescout is on another VM and receives traffic from this proxy. Unfortunately, the basic configuration didn't work: either we have mixed content (some of the links rewritten in https but not all of them) if the freescout .env is set with APP_FORCE_HTTPS=FALSE; or the site is inaccessible when we switch to APP_FORCE_HTTPS=TRUE, because Freescout's VM doesn't have ssl (certificat is on the proxy).

The trick is to add the parameter fastcgi_param HTTPS on; in one of the blocks of the conf nginx of the freescout VM, in the part location ~ \.php$.

On the proxy, the nginx configuration looks like this :

server {
	listen      10.0.0.10:80;
	server_name "freescout.mydomain.org";

	return      301 https://freescout.mydomain.org$request_uri;
}

server {
	listen      10.0.0.10:443 ssl http2;
	server_name "freescout.mydomain.org";

	ssl_certificate /etc/letsencrypt/live/freescout.mydomain.org/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/freescout.mydomain.org/privkey.pem;
	location / {
		proxy_set_header    Host $host;
		proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_pass          http://10.0.0.13/;
	}
}

And on the VM Freescout, the nginx configuration look like this :

server {
	listen 80;
	listen [::]:80;
 
	server_name freescout.mydomain.org;
 
	root /var/www/freescout/public;
 
	index index.php index.html index.htm;
 
	error_log /var/www/freescout/storage/logs/web-server.log;
 
	location / {
		try_files $uri $uri/ /index.php?$query_string;
	}
	location ~ \.php$ {
		fastcgi_split_path_info ^(.+\.php)(/.+)$;
		fastcgi_pass unix:/run/php/php7.3-fpm.sock;
		fastcgi_index index.php;
		fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		include fastcgi_params;
		fastcgi_param HTTPS on;
	}
	# Uncomment this location if you want to improve attachments downloading speed.
	# Also make sure to set APP_DOWNLOAD_ATTACHMENTS_VIA=nginx in the .env file.
	#location ^~ /storage/app/attachment/ {
	#    internal;
	#    alias /var/www/html/storage/app/attachment/;
	#}
	location ~* ^/storage/attachment/ {
		expires 1M;
		access_log off;
		try_files $uri $uri/ /index.php?$query_string;
	}
	location ~* ^/(?:css|js)/.*\.(?:css|js)$ {
		expires 2d;
		access_log off;
		add_header Cache-Control "public, must-revalidate";
	}
	location ~* ^/(?:css|fonts|img|installer|js|modules|[^\\\]+\..*)$ {
		expires 1M;
		access_log off;
		add_header Cache-Control "public";
	}
	location ~ /\. {
		deny  all;
	}
}

Now, it's work and all is on https !

[freescout-helpdesk]

Thanks for the information.

[breard-r]

More insight about why FreeScout was failing and why fastcgi_param HTTPS on; fixed it :

How FreeScout behave

In the HttpsRedirect middleware, FreeScout redirects to the https version if all the following conditions are met:

1. the force_https option is activated
2. the connection does not use https
3. the X-Forwarded-For http header is not set to https

For people who might read this ticket and do not know what the X-Forwarded-For is, here is a quick explanation : it is defined by RFC 7239 and is used to indicate the initial connection's protocol. In our case, it is used by the reverse-proxy, which handles the TLS termination and pass the request in plain http.

The force_https option allows FreeScout to redirect unsecured connection to http, but also forces it to behave as if the connection was secured even if it's not.

All of this is standard behavior and FreeScout handles it correctly.

The reverse-proxy configuration

In order to use FreeScout with a reverse-proxy that handles TLS, there is two things to do :

1. Set the force_https FreeScout option to true.
2. Have the reverse-proxy to set the X-Forwarded-For header with the correct value.

The force_https will have FreeScout to generate links that uses https, which prevents mixed content, while the X-Forwarded-For will prevent FreeScout from wrongly redirect a secure connection that appears to him to be unsecured.

What went wrong and how it was fixed

Every seems to be fine: force_https is activated and the reverse-proxy sets the X-Forwarded-For header:

proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;

However this configuration alone doesn't work. When opening FreeScout, it redirects to the same https page. And because we already are on the https page, it causes a infinite redirect loop. In fact, FreeScout behave as if it never received the X-Forwarded-For header.

This is due to the architecture itself: the reverse-proxy is on a virtual machine and FreeScout on a second one, which means that there is, on this second VM, an other web server that runs FreeScout. This web server does not knows it runs behind a reverse-proxy and, because the X-Forwarded-For header is a sensitive one that can be abused, it drops it for obvious security reasons. This is why FreeScout never received it although it was sent by the reverse-proxy.

Hence, the solution is to configure this second web server to add this header back. Using fastcgi_param HTTPS on; is one way to do it.

[freescout-helpdesk]

We've added a link to this information to the Installation Guide.