I'm troubleshooting a customer network that uses the same FortiGate model and firmware as our own office. The customer suddenly couldn't access prodemand.com, an automotive parts and labor quoting site, while we could access it normally from our office. Other HTTPS sites worked without issue, and the site's GeoTrust certificate appeared valid, matched the domain, and was current through September 14, 2026.
The firewall's security logs repeatedly reported that the SSL connection was blocked because it couldn't retrieve the server certificate. I eventually created a higher-priority internal-to-WAN rule for the site, its login domain, and the database UI subdomain, with SSL inspection disabled. The site immediately worked. I had to add the Wi-Fi network to the rule as well, since it wasn't included in the original internal address group. This also meant disabling antivirus and other security inspection features for that traffic.
I verified that the certificate appeared the same from both locations, found no obvious web-filter issue, and confirmed that DNS and ping resolved to the expected address. Curl failed with a similar SSL error, while other websites continued to work normally. Rebooting the firewall and modem made no difference.
What could cause this on only one FortiGate installation when the hardware and firmware are otherwise identical? I'd like to identify the underlying issue and remove the SSL-inspection bypass instead of leaving this as a security workaround.
4 Answers
The two firewalls must differ in some meaningful way, even if the firmware and hardware match. Compare the SSL inspection profile, certificate retrieval settings, DNS servers used by the firewall, enabled cipher suites, routing, and any upstream filtering. Fortinet’s documented troubleshooting for the “unable to retrieve server’s certificate” event is a good place to start, because that message usually means the firewall couldn’t complete its own connection to the remote server rather than that the endpoint rejected the certificate.
Test the connection from several angles: curl with verbose output, OpenSSL’s client command, and a packet capture taken on the firewall. The important details are the TLS ClientHello and ServerHello, the negotiated protocol and cipher, and whether the remote server sends a complete certificate chain. Also check every Layer 6-aware device between the firewall and the internet. A proxy, upstream security service, different NAT path, or DNS result can make two otherwise identical firewalls behave differently.
Verbose curl failed with a similar error. I didn’t get to OpenSSL or a packet capture because the customer’s endpoints were all in use and the firewall wasn’t remotely managed, so deeper testing will probably require an onsite visit.
Compare DNS resolution from the firewall with resolution from the client machines. The firewall may be retrieving the certificate from a different address than the endpoints use, especially if the customer’s DNS service returns different records, uses filtering, or has an incomplete IPv6 path. A stale or unreachable CDN address could affect only this site. Check the firewall’s DNS cache, upstream DNS configuration, IPv4 versus IPv6 behavior, and the actual destination IP in a capture.
Also verify the trust chain independently. The customer firewall may have an outdated CA bundle or a missing GeoTrust intermediate even though the endpoint trusts the site normally. Comparing the leaf certificate alone won’t prove the full chain is identical; inspect the complete chain delivered by the server and confirm the relevant root and intermediate certificates are available to the FortiGate. If the chain is malformed or the server behaves differently depending on the destination IP, bypassing inspection would explain why the connection works.
I compared the visible certificate from both locations and it looked identical, but I didn’t fully compare the delivered intermediate chain or the firewall’s CA bundle. That’s another area I need to check before accepting the bypass rule as the final fix.
That troubleshooting path looks very relevant because the firewall is reporting the exact same certificate-retrieval failure. I’m going to compare the inspection and certificate-fetch settings more closely.