Deep SSL Inspection CA Certificate Expiration Causing Global Untrusted Alerts
Expiration of the internal root or subordinate Certificate Authority (CA) configured in FortiOS Deep SSL/SSH Inspection profiles causes all re-signed HTTPS connections to immediately fail cryptographic validation, halting enterprise web access with critical untrusted certificate alerts.
Technical Root Cause Analysis
When FortiGate performs full Deep SSL Inspection, it acts as a cryptographic man-in-the-middle proxy. It terminates outbound TLS sessions initiated by client workstations, validates the upstream server certificate against public trust stores, and synthesizes a replacement server certificate on-the-fly containing the requested domain name (CN / SAN). This synthesized certificate is signed using the private key of a local Certificate Authority (CA) installed on the FortiGate (such as Fortinet_CA_SSL or an Enterprise Subordinate PKI CA).
When this local CA certificate reaches its Not After expiration timestamp, every synthesized certificate dynamically inherits the expired issuer validity window. Client web browsers (Google Chrome, Microsoft Edge, Mozilla Firefox, Apple Safari) instantly reject the TLS handshake with severe security warnings (NET::ERR_CERT_AUTHORITY_INVALID, SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE). In modern browsers, HSTS (HTTP Strict Transport Security) prevents users from clicking through or bypassing the alert, causing complete disruption to business-critical SaaS, banking, and cloud workloads.
Affected Firmware & Blast Radius Matrix
| Inspection Configuration | Client Impact | HSTS Bypass Capability | Remediation Requirement |
|---|---|---|---|
| Deep SSL Inspection (Full MITM) | Critical: Total HTTPS outage for all managed clients | Blocked (No user bypass allowed) | Rotate CA cert or toggle to Certificate-Inspection |
| Certificate-Inspection (SNI Only) | Unaffected: Client negotiates directly with web server | Normal TLS handshake | No immediate action required |
| Inbound SSL Acceleration | Critical: Inbound customers reject public web services | Blocked by external clients | Renew server certificate and intermediate bundle |
Software Scope: Affects all FortiOS versions (7.0, 7.2, 7.4, and 7.6). While root CA expiration is an operational lifecycle event, Bug 0867319 relates to the lack of proactive administrative alerting and missing automated rollover to standby subordinate CAs before the hard expiration event.
Step 01: Free Verification CLI (Safe Read-Only)
Execute these diagnostic commands to inspect all installed local and CA certificates, check exact expiration timestamps, and identify bound SSL profiles:
Diagnostic Commands
# 1. Check expiration timestamps of all local signing certificates
get vpn certificate local details | grep -E "Certificate name|Not After"
# 2. Inspect certificate validity and revocation status
diagnose vpn certificate check
# 3. List active SSL/SSH inspection profiles utilizing local CAs
show firewall ssl-ssh-profile | grep -E "config firewall ssl-ssh-profile|set caname"
# 4. Check active WAD SSL session metrics
diagnose test application wad 1Remediation & Workaround Steps (Teaser Preview)
Follow the emergency zero-downtime recovery procedure in the Ferrite interactive platform:
Frequently Asked Questions
Deep SSL inspection dynamically signs every external website certificate using the local CA on FortiGate. The moment that CA passes its expiration timestamp, every re-signed site is rejected by client browsers.
Switching firewall policies from Deep Inspection to 'certificate-inspection' (SNI inspection) stops on-the-fly certificate re-signing, immediately restoring web access without warnings.
Yes. If a new root CA is generated on FortiGate, its public certificate (.crt / .cer) must be installed into the Trusted Root Certification Authorities store on all client machines via GPO, Intune, or MDM.