.NET Core 3.1 SSL offloading issue.
Hello Experts!
I have gotten an issue dumped in my lap. I am a SysAdmin by trade and enjoy my craft, not developing and here is just why:
We offload our SSL to a HA pair of Load Balancer. That works fine. Traffic comes in HTTPS, gets converted to HTTP and ships it along to the server (Server 2012 R2).
So here is where things get messy:
This application is built with .NET Core 3.1. On the server, going HTTPS to the site everything runs without issue (it requires a login). Going HTTP to the site it just boots you back out to the login screen, no error no warning, just login over and over. The Dev claims it to be a security feature to ensure traffic is secure (which I understand) and per the Dev cannot be turned off (core doesn't allow it to be off, which I don't understand).
Going through the Load Balancer yields the same result as HTTP on the server (makes sense as it is being delivered there as HTTP).
Here where the assistance is needed.
In the Load Balancer we header tag the following:
HTTP_FRONT_END_HTTPS On
HTTP_X_FORWARDED_PROTO https
HTTP_X_FORWARDED_FOR (client IP)
The headers get modified, I requested that a full header site be placed there for viewing, and they are being tagged.
Not sure why Forwarded_For needs to be there but here we are.
This should allow .NET Core 3.1 to see the load as HTTP, but alas it does not. I think it is an app problem, but here we are with it now being my issue.
Thank you as always for any assistance that can be provided.
I have gotten an issue dumped in my lap. I am a SysAdmin by trade and enjoy my craft, not developing and here is just why:
We offload our SSL to a HA pair of Load Balancer. That works fine. Traffic comes in HTTPS, gets converted to HTTP and ships it along to the server (Server 2012 R2).
So here is where things get messy:
This application is built with .NET Core 3.1. On the server, going HTTPS to the site everything runs without issue (it requires a login). Going HTTP to the site it just boots you back out to the login screen, no error no warning, just login over and over. The Dev claims it to be a security feature to ensure traffic is secure (which I understand) and per the Dev cannot be turned off (core doesn't allow it to be off, which I don't understand).
Going through the Load Balancer yields the same result as HTTP on the server (makes sense as it is being delivered there as HTTP).
Here where the assistance is needed.
In the Load Balancer we header tag the following:
HTTP_FRONT_END_HTTPS On
HTTP_X_FORWARDED_PROTO https
HTTP_X_FORWARDED_FOR (client IP)
The headers get modified, I requested that a full header site be placed there for viewing, and they are being tagged.
Not sure why Forwarded_For needs to be there but here we are.
This should allow .NET Core 3.1 to see the load as HTTP, but alas it does not. I think it is an app problem, but here we are with it now being my issue.
Thank you as always for any assistance that can be provided.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The Dev is out today, but if I had to take a stab at it, most likely they left the Configure for HTTPS button checked when creating the app.
I'll circle back tomorrow.
I'll circle back tomorrow.
I think they might have configured it on their own as well, we really do not know how they are setting up the app. It is a good idea to check with them and get the clarity.
ASKER
I shall do my best!
You could take the overhead and direct the loadbalancer to setup a secure session to the backend systems as a test.
If you can create another vip on the loadbalancer that targets one of the systems using the https
and then see if it works.
If you can create another vip on the loadbalancer that targets one of the systems using the https
and then see if it works.
You could configure the loadbalancer to devide and forward to HTTPS ..
While your loadbalancer will be doing double work...
Alternatively fix the application whether it is IIS that on the sevurity has SSL required......
Confirm, by going to the server directly via http and see what happens.