Skip to main content
dairu
dairu
New Member
July 23, 2023
Question

SSL Chain Broken on Fortigate to Fortiweb Setup

  • July 23, 2023
  • 2 replies
  • 9302 views

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.

 

 

2 replies

ebilcari
Staff
ebilcari
Staff
July 23, 2023

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.

VS.PNG

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

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

Emirjon
dairu
dairuAuthor
New Member
July 25, 2023

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
Christian_89
Contributor III
July 23, 2023

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
dairuAuthor
New Member
July 25, 2023

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
Staff
saneeshpv_FTNT
Staff
July 31, 2023

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,

 

 

Terms & ConditionsAccessibility statement