Technical Tip: FortiGate unable to access several FortiGuard services due to CRL scope errors (September 2026)

Description

This article provides information on a recent issue (reported 2026-09-09) where FortiGates are unable to access several FortiGuard services that utilize certificates signed by DigiCert High Assurance EV Root CA.

Scope

FortiGate, FortiProxy, FortiPAM, etc.

Solution

When the issue occurs, administrators may observe that TLS connections from the FortiGate to FortiGuard services will not succeed, and running debugs of the forticldd and updated process may result in the following output being observed:

diagnose debug application update -1
diagnose debug application forticldd -1
diagnose debug enable
[...]
[365] __ssl_crl_verify_cb: Cert error 44, different CRL scope. Depth 2
[1436] SSL_dump_handshake_err: Certificate failed verification. Error: 44 (different CRL scope), depth: 2, subject: /C=US/O=DigiCert Inc/OU=http://www.digicert.com/CN=DigiCert High Assurance EV Root CA.
[...]

Currently, all Anycast FortiGuard services may be impacted by this issue, though Unicast FortiGuard services are not impacted (see the following for a list of services by URL: Anycast and unicast services). FortiGuard Secure DNS services should not be impacted at this time either.

Resolution/workarounds:

At this time, the only workaround available for FortiGate administrators is to switch from Anycast-based FortiGuard to the older Unicast-based FortiGuard servers (see: Technical Tip: FortiGuard is not reachable via Anycast default method). This works because the Unicast servers utilize certificates issued by a different certificate authority that does not have this CRL/IDP configuration.

Access the FortiGate over SSH, or from the FortiGate's GUI, open a CLI Console:

Paste these commands:

config system fortiguard
set fortiguard-anycast disable
set protocol udp
set port 8888
set sdns-server-ip 208.91.112.220 173.243.140.53 210.7.96.53 200.91.112.220
end

diagnose debug application update -1
diagnose debug enable
execute update-now

These commands modify the protocol used by the FortiGate to communicate with the FortiGuard servers and disable Anycast-based communication. The command 'execute update-now' forces the FortiGate to start an immediate FortiGuard update of the internal databases, not the firmware version. Commands 'diagnose debug application update -1' and 'diagnose debug enable' will enable debugging to expose the real-time output of the update process for verification.

Note: These commands do not affect production or passing-through traffic.

After pasting the commands, it is expected to regain connectivity within a few minutes

Update (2026-09-11): DigiCert has since reverted the Issuing Distribution Point (IDP) entry for multiple root CRLs, including those relevant for DigiCert High Assurance EV Root CA and DigiCert SHA2 Extended Validation Server CA. FortiGates and other Fortinet products should regain connectivity to Anycast FortiGuard services over time. The relevant CRL for this situation can be checked directly by going to the following DigiCert CRL link: http://crl4.digicert.com/DigiCertHighAssuranceEVRootCA.crl

Update (2026-09-30):
It looks like that DigiCert has stabilized the situation.

Additionally, administrators currently using Anycast FortiGuard are recommended to clear the CRL cache on the FortiGate with the following procedure:

config system fortiguard
   set fortiguard-anycast disable
end
config system fortiguard
   set fortiguard-anycast enable
end

While the immediate issue should be resolved at this time, Fortinet will continue to work towards improving the certificate revocation handling on the FortiGate to avoid this issue in the future.

Background:

For context, Anycast-based FortiGuard services currently utilize certificates signed by the 'DigiCert SHA2 Extended Validation Server CA' intermediate certificate authority (CA), which in turn is signed by the 'DigiCert High Assurance EV Root CA' root certificate authority. For example, the following is a representation of the current certificate chain of trust for globalupdate.fortinet.net:

Within the end-entity certificate (issued to the FortiGuard service) and the intermediate CA certificate is an extension designated CRL Distribution Points. These contain URIs corresponding to Certificate Revocation Lists (CRLs) that can be used to check the certificate's status.

Root cause of issue:

This issue is composed of multiple contributing factors that together result in TLS handshake issues:

Part 1: DigiCert updates the contents of the CRL file.

• As shown above, DigiCert SHA2 Extended Validation Server CA (the intermediate CA certificate used to sign a number of FortiGuard Anycast server certificates) currently uses the following URI as a CRL distribution point: http://crl4.digicert.com/DigiCertHighAssuranceEVRootCA.crl.

• On September 9th, 2026, at 18:38:53 GMT, DigiCert updated the contents of DigiCertHighAssuranceEVRootCA.crl to add a new extension called Issuing Distribution Point (IDP). An IDP extension specifies a list of CRL-related URLs, and any certificate being checked against this CRL must include a CRL Distribution Point entry that matches one of these URLs.

• This is not a concern for the intermediate DigiCert SHA2 Extended Validation Server CA, as its CRL URL is indeed present within the IDP entry of the CRL file itself. However, a critical point here is that the Issuer field of DigiCertHighAssuranceEVRootCA.crl is recorded as 'DigiCert High Assurance EV Root CA'.

• For more information on CRLs (including CRL distribution points and IDPs), refer to the following third-party documentation on DigiCert's website: Certificate revocation list (CRL).

Part 2: Certificate checks on the FortiGate.

• On the FortiGate, certificate revocation checks are performed in two cases:

  • Case 1: When the certificate includes a CRL Distribution Point extension, the FortiGate will download the CRL and check the certificate against it.

  • Case 2: When the Issuer field of a downloaded CRL matches the Subject of the certificate, the FortiGate will perform a check.

• In this case, the Issuer of the CRL was always 'DigiCert High Assurance EV Root CA', but the IDP extension was not present in the CRL file until the recent change.
  FortiGate will check for an IDP extension whenever a CRL check is performed. However, IDP extensions are not typically present in the CRLs of intermediate CAs, and so this issue is not commonly encountered.

• Once the IDP extension was added to the CRL, the FortiGate would assess the 'DigiCert High Assurance EV Root CA' certificate in the chain for certificate revocation. It is at this point that the problem occurs.

• Since the DigiCert High Assurance EV Root CA certificate does not contain any CRL Distribution Point extensions (Root CA certificates do not generally contain CRL entries within them), it compares against the included IDP and ultimately fails the check, resulting in the TLS handshake being terminated.

• Important: no certificates have been revoked at this time; the issue is strictly related to how certificate revocation checks are performed and how DigiCert's addition of the IDP extension to the CRL has triggered this behavior.

To summarize: DigiCert has made a technically acceptable change within DigiCertHighAssuranceEVRootCA.crl by adding the IDP extension. However, a behavior present within the FortiOS certificate revocation check triggers and results in the DigiCert High Assurance EV Root CA certificate not passing the check. This results in TLS handshakes being halted to FortiGuard Anycast services due to CRL/certificate verification failures.

Note: If FortiGuard connectivity issues are still present after all of the above due to '__ssl_crl_verify_cb: Cert error 44', open a ticket with Fortinet TAC and ask for Support to check the situation; refer to: Technical Tip: How to create a ticket for Fortinet TAC.