I'm troubleshooting a customer network using a FortiGate firewall with the same model, firmware, and general setup as the firewall at our MSP office. The customer cannot access prodemand.com, an automotive parts and labor quoting service, while the site loads normally from our office and other HTTPS sites work correctly at the customer location.
The site presents a valid GeoTrust certificate that matches the domain and is valid until September 14, 2026. There are no obvious web-filter violations, and I found no evidence of a man-in-the-middle issue. However, the FortiGate logs repeatedly report that the SSL connection is blocked because it was unable to retrieve the server certificate. CURL fails with a similar error, although DNS and ping resolve to the expected address.
As a test, I created a higher-priority internal-to-WAN policy for the site, its login domain, and the database UI subdomain, with SSL inspection disabled. The site immediately worked. I later had to add the customer's Wi-Fi network to the policy as well. Since disabling inspection also required turning off antivirus and other security profiles, I'd prefer to find the real cause instead of keeping this exception.
What could make SSL inspection fail for only this site on the customer's firewall when an apparently identical firewall at our office works normally? Could this be related to DNS differences, certificate retrieval, cipher negotiation, FortiGate configuration, or something upstream?
4 Answers
The two firewalls probably differ in a detail that isn’t obvious from the model and firmware versions. Compare the SSL/SSH inspection profiles, TLS settings, DNS servers, routing, interface settings, FortiGuard connectivity, and any policy-specific security profiles. Also check whether the failing unit can resolve the site and independently establish a TLS connection to the server. FortiGate’s specific “unable to retrieve server certificate” troubleshooting guidance is worth following because it commonly points to certificate-fetching or TLS negotiation problems rather than a bad certificate on the endpoint.
Check DNS from both places, including the DNS settings used by the FortiGate itself. The customer’s clients and the firewall might be getting different addresses for the site, or one location could be reaching an IPv6, CDN, or regional endpoint that behaves differently. Compare the resolved A and AAAA records, test the exact destination IPs, and verify that the firewall can reach the certificate chain’s servers without filtering or routing problems.
A packet capture would be the most useful next step. Capture traffic from the firewall while testing the site and compare the ClientHello, ServerHello, certificate exchange, TLS version, and cipher suite with a working connection from the other location. Also test with curl in verbose mode and OpenSSL’s s_client if available. The important question is whether the server sends a certificate at all, whether the FortiGate cannot retrieve it, or whether the TLS negotiation is rejected before the certificate arrives.
CURL fails with a similar error, but I haven’t yet been able to collect a packet capture or run OpenSSL. We may need to schedule an onsite visit to investigate further.
Verify the complete certificate chain and the trusted CA configuration on the affected FortiGate. Comparing the leaf certificate in a browser is not enough: the firewall may be failing to retrieve or validate an intermediate certificate, or its trusted CA package may be outdated or damaged. Confirm that the relevant GeoTrust root and intermediates are present, then check FortiGuard and system time connectivity as well. If the certificate chain is fine, compare the customer’s SSL inspection profile and firmware build byte-for-byte with the working unit.
That matches the error we’re seeing, so I’m going to work through the certificate-retrieval troubleshooting and compare the two configurations more carefully.