Description
This article describes a basic understanding of certificates and some basic troubleshooting steps for a wide variety of certificate issues.
Scope
FortiGate.
Solution
FortiGate uses certificates in various ways and will need to interact with various 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 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, etc.) 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 multiple 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 is trusted, the end certificate in the chain should also be trusted.
- FortiGate needs to trust the Certificate Authorities of the 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).
Chain of trust: It is not always necessary to have an intermediate certificate in the certificate store.
The browser uses the chain of trust method, where the server sends the full chain of certificates, which includes the intermediate certificate, the root certificate, and the server certificate.
It also sends a hash with an intermediate certificate, which is signed by the private key of the root CA. If a browser can decrypt that hash using the root certificate's public key, it means the certificate is genuine.
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.
- SSL VPN 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 Certificates.
The following sections are particularly relevant:
- Import a certificate
- Generate a CSR
- Procuring and importing a signed SSL certificate
- Microsoft CA deep packet inspection
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, and Key Usage? The certificate, if acting as a 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.
- Is the vulnerability scan report a false positive.
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. - Check if the vulnerability scanner reports a false positive. Sometimes FortiGate is installed with an internal CA certificate for internal access. The vulnerability scanner is flagging this because the certificate is not issued by a widely recognized public Certificate Authority (CA), and it is bound to an internal IP, which typically doesn't align with external scanning criteria. The scanning was done on FortiGate External (Public IP). External certificates are typically expected to match public domain names, not internal IP addresses. Internal CA certificates, by design, are not trusted by external clients or scanners, leading to false positives in reports.
If the issue is with a client certificate (certificate authentication against FortiGate):
- Check the user peer configuration matches the 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 the RADIUS server, and the RADIUS server checks certificates.
If the issue is with Deep Inspection:
- Check that the CA set in the SSL Inspection Profile on FortiGate is trusted by the client.
- Check that the websites in question 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 <-- SSL VPN.
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 documents:
Technical Tip: TLS and the user of Digital Certificates.
Technical Tip: Certificate Errors when accessing a blocked page.
Technical Tip: Certificate Errors in Admin Access.
Technical Tip: Certificate warnings while accessing FortiGate.
FortiGate Cookbook: Preventing certificate warnings with Default Certificates.
Technical Tip: FortiGate PKI certificate usage guide
Technical Tip: FortiGate HTTPS/SSL Certificate Installation (PFX, PKCS12 and PEM)
Technical Tip: How does FortiGate checks the Website Certificates and allow/deny the SSL connection
