SSL Chain Broken on Fortigate to Fortiweb Setup

[dairu]

I got an odd situation with our SSL certificate.

Webserver under Fortiweb and FortiGate are configured, https website is working properly. Except for CA chain is broken. When using SSL checker tools, CA could not be seen. I might miss something on my configuration that CA could not be read.

May I know how do you usually setup your SSL cert with FG and Fweb?
We have multiple domains for a single Public IP and utilized SNI for those different websites.

Our setup is that Fortigate is configured with VIP going to the Fortiweb, with SSL inspection configured to 'Protecting SSL Server'. Local cert and CA Intermediate cert is uploaded correctly.
Then on the Fortweb side, we used SNI to handle the different cert of differnt domains. Meaning we also uploaded the local certificates, as well as the CA. Well all websites are working and no SSL error when visiting the sites. But if you run any SSL tools, CA chain is broken.

I tried different setup, and here's what I got. On Fortigate, If I change the SSL Inspection from 'Protecting SSL Server' to 'Multiple Clients Connecting to Multiple Server', CA Chain is restored. This would be my goal... But, with this setup different problem arose. Now all web visitors' Public IP traversing to the FortiWeb is not logging properly (logs the internal IP of Fortigate instead). Which I think means the SSL inspection is now not working on the Fortiweb. (By the way we have X-forwarded-for setting, which works well when 'Protecting SSL server' is enabled)

End goal should be: Certs and CA Chain working correctly, without compromising the logging of web visitor's Public IP. Appreciate any insight on how you would normally setup this. Already troubleshooting if for days with no luck.

[ebilcari]

Have you tried to configure FortiWeb under Virtual Servers in FGT? It will do the SSL offload without configuring a VIP and without using any SSL Inspection profile for the Firewall Policy.

https://docs.fortinet.com/document/fortigate/7.4.0/administration-guide/713497/virtual-server-load-b...

I've been also testing with VIP but couldn't make it work.

[dairu]

I'll try this, I'll let you know if this is successul. Though one thing to note is that our setup is quite tricky. As mentioned on my initial post, we are using SNI for mutiple domains, but our public IP is only one. Having 'Virtual Server' with 'Full SSL Offloading' might request for a cert. And I think Full SSL could only use one certificate. Where as VIP on Protecting SSL could use up to 10 certifcates.

[Christian_89]

Your problem seems to stem from some tricky issues in the SSL certificate chain and the interplay between the FortiGate and FortiWeb products. It looks like you have two primary goals:

1. Restore the SSL Certificate Authority (CA) Chain.
2. Maintain proper logging of visitor IP addresses.

When you change the SSL Inspection on FortiGate from "Protecting SSL Server" to "Multiple Clients Connecting to Multiple Server", the SSL CA Chain issue is resolved but it brings up another issue with logging the original client's IP address on FortiWeb. The "Multiple Clients Connecting to Multiple Server" mode will cause FortiGate to decrypt then re-encrypt traffic, changing the client IP seen by FortiWeb to FortiGate's internal IP. That's why you're seeing the internal IP of FortiGate in the logs.

Here are a few suggestions to troubleshoot and possibly solve your problem:

1. **Verify SSL Certificates**: Ensure that the correct SSL certificates (including intermediate certificates) are installed correctly on both FortiGate and FortiWeb. This is crucial for the SSL chain to be recognized correctly. You mentioned that they're uploaded correctly, but it might be worth double-checking.

2. **Deep Packet Inspection (DPI) SSL**: Instead of using "Multiple Clients Connecting to Multiple Server" or "Protecting SSL Server", you can try enabling Deep Packet Inspection (DPI) SSL on FortiGate. With DPI SSL, FortiGate can decrypt SSL traffic for inspection and then re-encrypt it, forwarding it to the server in its original form. However, you should be aware that this could impact performance.

3. **X-Forwarded-For (XFF) Headers**: If the original client IP is getting lost due to the SSL inspection settings on FortiGate, using X-Forwarded-For (XFF) headers might be a way to maintain visibility of the original client IP. You mentioned that you have X-Forwarded-For setting, but check if it's working as expected. It's possible that your FortiWeb isn't correctly configured to use these headers, or that they're being overwritten or removed.

4. **Contact Support**: Given the complexity of this issue and the many factors at play, it might be best to contact Fortinet's support for help with this specific configuration.

Remember that each setup can vary significantly depending on the specifics of your network architecture and your security requirements, so what works in one case might not work in another. Always make sure to thoroughly test any changes in a controlled environment before deploying them to your live systems.

[dairu]

On your suggestion #2, can you futher guide on how I can do the settings on Fortigate? I believe the Inbound DPI for FG is "Protecting SSL Server", but I might be wrong. 

[saneeshpv_FTNT]

Hi,

You ideal setup should be Fortigate having VIP to translate your Public IP to Private  Virtual IP on FortiWeb. FortiWeb being your Web Application Firewall decrypting SSL Connection using SNI based Certificate (with Complete Certificate Chain) for HTTP traffic inspection for Web Attacks.

So may I ask, why you enable SSL Inspection in Fortigate for your Published Web application (HTTP/S) if you FortiWeb is capable to perform the Filtering and blocking Web attacks. 

Best Regards,

[dairu]

Hi Saneeshpv,

Thank you for the response, would you mean I should disable SSL inspection on Fortigate? I did try to use the no-inspection, but for some reason other issue arises when there is no SSL inspection, Real IP of web visitor is not logging correctly even though x-forwarded-for is enabled. Seems it needs SSL inspection to get the Public IP of https web visitor. Would there be any appropriate setup for this?

[saneeshpv_FTNT]

Hi,

Again, why you are not allowing the Client Public IP address all the way to FortiWeb? Usually you only change the Destination IP from Public IP to FortiWeb Virtual IP, but the Source IP of the Client will remain unchanged and on the FortiWeb you enable X-Forwarded-For Header insertion so that your actual server will be able to know about the client IP address. (for accounting and logging purpose).

########

Add X-Forwarded-For:

Enable to include the X-Forwarded-For: HTTP header in requests forwarded to your web servers. If the HTTP client or web proxy does not provide the header, FortiWeb adds it, using the source IP address of the connection. If the HTTP client or web proxy already provides the header, it appends the source IP address to the header's list of IP addresses. This option can be useful if your web servers log or analyze clients’ public IP addresses, if they support the X-Forwarded-For: header. If they do not, disable this option to improve performance.

Please refer attached.

Best Regards,

[dairu]

Hi Saneeshpv,

There are alot of things to consider on why we need a Fortigate on top of Fortiweb. IPS is one, as it is only offered by Fortigate as the Firewall. We have also other ports aside from http/https that needs to be protected. We are following the ideal security practice on protecting our server thru Firewall and WAF. We cannot afford to just have WAF for security for a single Public IP.

As mentioned, x-forwared-for is already in place on Fortiweb. Which only works side-by-side when SSL inspection is enabled on Fortiweb,

[saneeshpv_FTNT]

Hi @dairu,

If you are forwarding traffic to FortiWeb, FortiWeb will only support HTTP based application. You need to enable SSL inspection on FortiWeb which is correct but not on the Fortigate. For IPS you can enable with out SSL inspection in Fortigate and for application level attack mitigation you are using FortiWeb which is capable enough to block all the OWASP top 10 Web attacks and you can also integrate AV/FortiSandbox for deep file analysis with FortiWeb and it also has its Application level DDOS and Bot defense mechanism in place with the advanced AI based Machine learning capabilities to analyze application request. So in any case I don't see any specific requirement for SSL inspection in Fortigate for Inbound Application Publishing when using FortiWeb.

Not sure If I am able to clarify things, if not please let me know your specific protocol use case and scenario which you are trying to achieve here.

Best Regards,