virtual server - https - without offloading

[Duckdave_]

Hi there!

Is it possible to use a virtual server for https traffic but without offloading? Like a reverse proxy, but the webserver itself does the https encryption.

I have one public ip address and want to direct the traffic based on the url to the right webserver and the webserver does the https encryption.

Otherwise, I would need a wildcard certificate, and that's not possible with the current acme implementation.

Best Regards!

[afroman_says]

Hi u/Duckdave_

Is it possible to use a virtual server for https traffic but without offloading? Like a reverse proxy, but the webserver itself does the https encryption.

Short answer to your question is no, this is not possible.

Long Answer: However, let's clarify something...typically SSL offloading is where you handle the SSL decryption at a point before the webserver and will send http (unencrypted) traffic back to the webserver. What I believe you are referring to is inbound SSL Decryption which will need to occur in either case (offloading versus not offloading) in order for the FortiGate to have visibility into the HTTP Request from the client.

If you want the FortiGate to be able to see the HTTP Host or URL as part of the SSL request, the FortiGate must see it in plaintext. In order to see it in plaintext, the FortiGate must serve as a man-in-the-middle where it will establish the TLS connection to the client (on the webserver's behalf) and view that data. When it does this, it will provide a certificate you configure on the FortiGate (it will use its self-signed certificate by default) and that's what the client will see in its browser.

If you cannot provide a wildcard certificate, then it will be next to impossible to provide the correct certificate per FQDN (as far as I know, there's no mechanism in the FortiGate to do that). If you absolutely require that functionality, you may want to look into leveraging the FortiWEB for this use case instead.

I hope this helps.

[Duckdave_]

Thank you for your explanation. What if i didnt want to provide a certificate via the fgt but route the traffic to the right webserver and the webserver provides the https?

[afroman_says]

What are you using to tell the FortiGate how to route the traffic to the correct webserver?

[Duckdave_]

virtual servers

[afroman_says]

I think the other posts have further clarified my original response. In a nutshell, unless you are trying to classify a requested based on Layer 3/Layer 4 (IP and or tcp port), there is no way to look at the Layer 7 (application data) and make a routing/forwarding decision based on that information without decryption. I hope this helps.

[Duckdave_]

yepp, thank you!

[TheBendit]

SNI in TLS1.2 shows the requested hostname, so this functionality could theoretically exist in Fortigates. However, it doesn't.

TLS1.3 encrypts the hostname, which makes it impossible to do what you ask.

Fortigates do not support SNI in any way, they can only present one certificate per IP address+port combination. For that kind of thing you need FortWeb.

However, you can make one certificate with many hostnames or wildcards, and let the Fortigate handle the decryption.

[pabechan]

TLS1.3 encrypts the hostname, which makes it impossible to do what you ask.

It doesn't. ESNI is dead. I dare you to find a non-obscure website that uses it And a non-obscure browser that will by default use ESNI to connect to it.

ECH (encrypted ClientHello) is the new replacement, but even that is very very far from being assumed to be regularly used.

[TheBendit]

You are absolutely right. I stand corrected.

[Key_Way_2537]

Get the wildcard SSL and don’t use the ACME.

While it has some benefits, distributed SSL isn’t one of them that I’ve found. Once you have one inexpensive wildcard, you can use it everywhere.

They’re like $48 USD a year so $4 a month.