HTTPS port (9013) not exposed?
-
We are attempting to upgrade to fusion auth 1.41.3 from 1.36.7. Previously 1.36.7 exposed port 9013 for HTTPS via the Docker image. Now it appears that it does not?
The same docker compose bindings that were used previously now don't appear to work:
image: fusionauth/fusionauth-app:1.41.3 ports: - 9013:9013
I see in the startup that it is exposing 9011 and 9012 as HTTP but I don't see anything about 9013 or HTTPS:
fusionauth_1 | 2022-12-01 07:14:03.005 PM INFO io.fusionauth.http.server.HTTPServer - Starting the HTTP server. Buckle up! fusionauth_1 | 2022-12-01 07:14:03.041 PM INFO io.fusionauth.http.server.HTTPServer - HTTP server listening on port [9011] fusionauth_1 | 2022-12-01 07:14:03.042 PM INFO io.fusionauth.http.server.HTTPServer - HTTP server started successfully fusionauth_1 | 2022-12-01 07:14:03.042 PM INFO io.fusionauth.http.server.HTTPServer - Starting the HTTP server. Buckle up! fusionauth_1 | 2022-12-01 07:14:03.052 PM INFO io.fusionauth.http.server.HTTPServer - HTTP server listening on port [9012] fusionauth_1 | 2022-12-01 07:14:03.053 PM INFO io.fusionauth.http.server.HTTPServer - HTTP server started successfully
I attempted to specify the HTTPS port as well but that did not seem to change things:
- FUSIONAUTH_APP_HTTPS_PORT=9013
-
@zradick said in HTTPS port (9013) not exposed?:
attempted to specify the HTTPS po
I have the same issue. It appears they conveniently forgot to properly document HTTPS on dev/prod modes so that its easier to use their hosted solution.
If you do manage to have a frontal proxy in front of the plain text port that is open by default, you get this error in the UI that I can't find a way to fix it.
(I know the dns name may be confusing, just asume it says fusionauth-dev...*)
-
We've encountered the same issue - updating from 1.36.8 to 1.42.0 we found the HTTPS server on port 9013 is no longer running. I assume this is related to the switch to Netty introduced in 1.37.0.
Is there any way to get the HTTPS server running on the latest version, or plans to reintroduce this?
Might be a little pedantic but it would feel more secure if login credentials were encrypted end-to-end, not just flying around our VPC in cleartext after the SSL is terminated on the load balancer.
-
@rpy I think this is the issue you are looking for: https://github.com/FusionAuth/fusionauth-issues/issues/1996
This is slated for release 1.43, which should be out in the next month or so (could be sooner, we're trying to get a few more bugfixes in there).