Troubleshooting Tip: A guide to FortiGate and certificate issues

Debbie_FTNT · ‎08-02-2023

Description

This article provides a basic understanding of certificates and some basic troubleshooting steps for a wide variety of certificate issues.

Scope

FortiOS.

Solution

FortiGate uses certificates in various different ways, and will need to interact with various different certificates as well.

Introduction:

A certificate itself is essentially a proof of identity, and contains a variety of fields. The most relevant fields for troubleshooting are usually:

Subject: The certificate subject, usually some kind of identifier like common name (CN), a URL or email.
Subject Alternative Name (SAN): Alternative names for the subject (Aliases), like additional DNS names or IPs.
Key Usage: What the certificate (and accompanying keypair) may be used for.
Extended Key Usage: What the certificate (and accompanying keypair) may be used for.

Validity (To/From): Start and End date the certificate is valid.
Basic Constraint: Is the certificate an authority or not.

Broadly speaking, there are three different types of relevant certificates:

Certificate Authority (CA): A certificate allowed to issue/sign other certificates.

A Root CA is a top-level certificate that needs to be trusted implicitly by a browser/client/FortiGate/networking equipment. Most Operating Systems (Windows, Linux, MacOS, FortiOS,...) come with a pre-installed cache of trusted Root CAs published and maintained by trusted organizations (DigiCert, Let's Encrypt,...).
An intermediate CA (sub-CA) is a Certificate Authority signed by another Certificate Authority. A sub-CA can trace back to a Root CA (possibly via muliple other sub-CAs).
All CA certificates should have the field Basic Constraint set to TRUE.
A certificate chain is the chain of certificates from the one presented back to the Root CA; as long as all certificates in the chain are valid and the Root CA trusted, the end certificate in the chain should also be trusted.
FortiGate needs to trust Certificate Authorities of servers it communicates with.
FortiGate uses a CA certificate for deep inspection; this needs to be trusted by clients sending traffic through deep inspection.

Server certificate: A certificate used by a server to prove its identity. This needs to be issued by a Certificate Authority, and is required in TLS-based communication like HTTPS or LDAPS. Extended Key Usage should include '(Web) Server Authentication'.

FortiGate uses a server certificate in various contexts:

GUI, API, Replacement Messages (HTTPS Server certificate under (Global) System -> Settings).
Captive Portal/Disclaimer (Certificate under (VDOM) User & Authentication -> Authentication Settings).
SSL VPN (Server Certificate under (VDOM) VPN -> SSL-VPN Settings).
IPSec VPN (Certificate Name under (VDOM) VPN -> IPSec Tunnels -> Edit Tunnel -> Authentication).

Client certificate: A certificate used by a client to prove their identity. This needs to be issued by a Certificate Authority, and is required in some certificate-based authentication mechanisms, like EAP-TLS. Extended Key Usage should include 'Client Authentication'.

- FortiGate uses client certificates to allow users to authenticate

- This happens primarily through user-peer configuration (CLI-only, 'config user peer'), with a subject and issuing CA defined; a client certificate matches a user peer if the subject matches and the certificate is issued by the expected CA.

- SSLVPN allows enabling a general client certificate requirement; with this setting, the client certificate subject is irrelevant, but the issuing CA must be trusted by the FortiGate.

CRL/OCSP: CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol) are mechanisms to allow clients to verify that certificates are still valid and not compromised in some way. CRL/OCSP is maintained by the issuing Certificate Authorities. These relevant URLs and OCSP protocol should NOT be blocked; some clients refuse to trust certificates if they cannot independently verify the certificate status via a CRL or OCSP.

Certificate management:

FortiGate allows for some Certificate Management, such as uploading CA certificates and server certificates. This is available globally and on a per-vdom basis, and might need to be enabled in System -> Feature Visibility.

A detailed guide (including how to import certificates, and create new certificates (CSRs)) is available in this section of the Administration Guide.

The following sections are particularly relevant:

Troubleshooting:

In general, when encountering any kind of certificate errors, the following should always be checked:

For the certificate in question:

Is it valid? Does it have the expected subject, SAN, Key Usage? The certificate, if acting as server certificate, should always have an SAN. Some browsers (like Chrome) refuse to accept server certificates with no SAN.
Is it issued by a trusted CA?

For the certificate chain:

Are all the certificates in the chain still valid?
Is the Root CA at the end of the chain trusted?

For CRL/OCSP:

The certificate might include links to a CRL, or links for OCSP, to be checked (usually in the fields 'CRL Endpoints' and 'Authority Info'/'AIA').
These need to be accessible from the client; adding an exemption policy for these URLs can be helpful.

Depending on the use case, further checks can be performed.

If the issue is with a server certificate on FortiGate (GUI, API, VPN, captive portal, replacement messages):

Verify again that the certificate is issued by a trusted CA: the FortiGate's default certificate is NOT issued by a trusted CA.
Either replace the server certificate with one issued by a trusted CA, or download the issuing CA certificate from FortiGate and import it into the clients to force them to trust it.
Check that the certificate subject and SAN match the FortiGate's URL.
Captive portal (and SSL VPN) FortiGate might have a specific hostname set; ensure the certificate's subject and/or SAN matches this.

If the issue is with a client certificate (certificate authentication against FortiGate):

Check the user peer configuration matches submitted client certificate (subject, issuing CA)
Check the certificate authentication is happening locally on FortiGate; with 802.1x/EAP-TLS FortiGate might simply be proxying the authentication to a remote RADIUS server. If the authentication is set to local, EAP terminates on FortiGate and it checks if the authentication is set to RADIUS. FortiGate simply proxies the traffic to RADIUS server and the RADIUS server checks certificates.

If the issue is with Deep Inspection:

Check that the CA set in SSL Inspection Profile on FortiGate is trusted by the client.
Check that the websites in questions do not use certificate pinning; with certificate pinning browsers expect a specific server certificate, or a server certificate issued by a specific CA, not just any trusted CA, and Deep Inspection interferes with that.
If the website in question uses certificate pinning, Deep Inspection cannot be applied.

Useful CLI commands:

View certificates and related configuration:

show certificate ca/local/remote/crl (Global)

show vpn certificate ca/local/remote/crl (VDOM)

show user peer (VDOM)

show vpn ssl/ipsec [...] (VDOM)

show firewall ssl-ssh-profile (VDOM)

Debug certificate-related processes:

diagnose debug app ike -1 (ipsec)
diagnose debug app sslvpn -1 (sslvpn)
diagnose debug app fnbamd -1 (general authentication)
diagnose debug app httpsd -1 (HTTPS-related debug)
diagnose debug wad [...] (proxy-related debug, like deep inspection)
diagnose debug console timestamp enable (prepend timestamps to debug messages)
diagnose debug enable (enable output)

Related articles: