Can I terminate TLS at FusionAuth?

[dan]

I want to terminate TLS at FusionAuth, can I do so?

[dan]

Yes. You can. FusionAuth listens on port 9011 for HTTP traffic and 9013 for TLS traffic. Review the configuration settings for changing these ports and other TLS specific information (such as configuring a certificate). This is a documented and supported configuration.

However, if you are sending TLS traffic directly to FusionAuth, you typically will want to serve traffic on port 443, since that is where users expect TLS traffic to be (https://example.com, for example, is implicitly https://example.com:443).

To have FusionAuth running at https://example.com, you'd have to run it as root, so it could bind to a privileged port (any port < 1024). That's a bad idea. You want to minimize the surface area of anything running as root. Instead, you should run FusionAuth (and all other processes you can!) as a non-root or non-privileged user so that if the FusionAuth process is compromised, or there is a vulnerability the process does not have access to the entire system.

A far better solution is to run a proxy like nginx on the same system as FusionAuth, and have the proxy terminate TLS. You can lock down FusionAuth to only accept connections from the proxy locally using a firewall.

There are other technical reasons to use a proxy:

• 3rd party proxies provide a lot of other benefits such as support for HTTP2
• FusionAuth is stateless, so you can have 1-N instances behind one proxy and have the requests distributed by a proxy. If you are sending requests directly to FusionAuth, scaling is more difficult.
• proxies are in general much better at managing TLS negotiation and provide simpler configuration.

Setting up a proxy is documented here, and here's a link to some community provided proxy configuration.

[matth]

@dan Is this speaking to an installed version rather than a container? We are running the container using port 9013 configured for SSL per the configuration reference and a load balancer in front of it handling exposing it on 443 so that the FusionAuth app is kept at 9013 for the load balancer to communicate with. The only difference is the load balancer is a separate resource in AWS since I'm not running it installed directly on an EC2 instance. My local I'm talking to 9013 directly, having issue in both environments though runtime wise, also running the container so there's also no risk of escalation there.

[dan]

@matth Ah, so what you are doing is:

browser <-TLS-> load balancer (port 443) <-TLS-> FusionAuth (port 9013)

Is that correct?

Have you loaded up a certificate chain and private key set as either filenames or content (and configured everything correctly)?

This scenario should work.

[matth]

@dan this is accurate and related post here: https://fusionauth.io/community/forum/topic/2579/runtime-exceptions-with-ssl-enabled/3

HiTrust regulations requirements is the reason it must be done this way.

[dan]

@matth Hmmm. Well it should work. If it doesn't, that's a bug.