The HTTP(s) protocol is supported and used for various things. Primarily the WebInterface uses the port. However, its also used for WebDAV and for Server Administration. HTTP(s) is also used for tunneling FTP to make it secure, and to accelerate file transfers in the WebInterface with the integrated CrushTunnel as part of the high speed file transfers.

Trust Headers allow for trusting a front end identity management solution that inserts trust headers into the HTTP responses so CrushFTP doesn't need to validate authentication.

The trust headers work like this:

Say you have the header X-Trusted-Username then you would enter in a value in CrushFTP of:

X-Trusted-Username=user_name

You are mapping header values to CrushFTP values.

So the trust of the server comes down to the identity management controlling headers and in no way allowing anyone access to the server who could spoof the header. CrushFTP is blindly trusting the header if present with whatever username as having been already authenticated. So any exposure of the CrushFTP server to the outside internet makes it insecure, or exposure on the LAN, etc. It must always be behind the identity management solution your using.

For reverse proxy, if Apache is doing HTTPS and CrushFTP is doing HTTP, those protocols are "opposite". Precede the reverse proxy path with a "!" as in the example screenshot for the reverse proxy path of "/crushftp/". This tells CrushFTP the user's protocol is the opposite of what CrushFTP's thinks it is.

You can also make CrushFTP the reverse proxy server protecting a back end resource.

HTTPS ports can have individual keystores mapped to the port as well, or use *SNI* to have multiple keystores mapped to the port.

Require valid client certificate will block all connections unless they have been previously configured to provide a SSL client certificate.