Assess Internet-Facing FortiGate TLS Certificates

This guide walks through assessing internet-facing FortiGate firewalls by examining their TLS certificate configuration. You will learn how to identify weak certificates, expired certificates, and misconfigurations that could expose your network to man-in-the-middle attacks or service outages. Before starting, ensure you have administrative access to the FortiGate (via GUI or CLI) and know the public IP or domain name of the gateway you are assessing.

What You’ll Need

• FortiGate admin credentials (read-only is sufficient)
• The public IP or FQDN of the FortiGate interface
• A local machine with openssl or an online TLS checker (optional but helpful)

Step-by-Step

1. Identify the internet-facing interface. Log into the FortiGate GUI. Go to Network > Interfaces. Look for interfaces with a WAN role or a public IP address. Note the interface name (e.g., port1, wan1).
2. Check if HTTPS admin access is enabled. On the same interface list, click the edit icon for the WAN interface. Under Administrative Access, see if HTTPS is checked. If it is, the gateway is serving a TLS certificate for admin login.
3. Retrieve the certificate currently bound to HTTPS. Go to System > Certificates. Look for a certificate that is marked as the default or is referenced in the HTTPS service. Note its name, issuer, and expiration date.
4. Inspect the certificate details in the GUI. Click on the certificate name. Check the Subject and Issuer fields. Verify the subject matches the public hostname or IP you are using to access the gateway. If it is self-signed, it will show the FortiGate’s own name as issuer.
5. Use OpenSSL to assess the live certificate. On your local machine, run: openssl s_client -connect your-fortigate-ip:443 -servername your-fortigate-hostname. This shows the actual certificate presented to clients. Look for the subject, issuer, and validity dates.
6. Check for certificate chain issues. In the OpenSSL output, look at the certificate chain. Ensure the server sends the full chain (intermediate + root). If the chain is incomplete, some clients will fail to validate. You can test with openssl s_client -showcerts and count the certificates returned.
7. Verify the certificate is not expired. Compare the notAfter date with today’s date. If it is expired, clients will get a security warning. Note the exact expiration date for planning renewal.
8. Check the key strength and algorithm. In the OpenSSL output, look for the Server public key is line. Ensure it is at least 2048-bit RSA or 256-bit ECDSA. Also check the signature algorithm (e.g., SHA256withRSA). Avoid SHA-1 or 1024-bit keys.
9. Assess if the certificate is trusted by browsers. Check the issuer. If it is a well-known CA (like Let’s Encrypt, DigiCert, etc.), it is trusted. If it is self-signed or from an unknown CA, browsers will warn users.
10. Review the certificate’s subject alternative names (SANs). Use openssl x509 -in cert.pem -noout -text after saving the certificate. Ensure the SANs include the exact hostname you use. If not, the certificate will not be considered valid for that hostname.
11. Check for protocol and cipher weaknesses. While not strictly certificate evidence, the TLS configuration affects certificate security. Use openssl s_client -tls1_2 and -tls1_3 to see if old protocols are disabled. Weak ciphers can undermine even a strong certificate.
12. Document your findings. Record the certificate subject, issuer, expiration date, key size, signature algorithm, and any chain issues. Note whether the certificate is trusted or self-signed. This becomes your assessment report.

Common Mistakes

• Assuming all WAN interfaces serve HTTPS. Only interfaces with HTTPS admin access enabled will present a certificate. Others may not respond on port 443.
• Ignoring the hostname mismatch. A certificate may be valid but for a different domain. If you access the gateway via IP, the certificate will not match, causing warnings.
• Forgetting to check the full chain. Many FortiGate configurations only upload the leaf certificate, missing the intermediate. This breaks validation for many clients.
• Overlooking the renewal date. Certificates expire. An assessment that does not note the expiration date is incomplete.
• Using outdated tools. Some online checkers may not show the exact certificate served by the FortiGate due to caching. Always verify with a direct OpenSSL connection.

Tips

• Use a dedicated hostname. For production, assign a hostname like vpn.example.com to the FortiGate and get a certificate for that name. This avoids IP mismatch issues.
• Automate renewal. If using Let’s Encrypt, configure automatic renewal via the FortiGate’s built-in ACME client (available in recent firmware).
• Export the certificate for offline analysis. Use openssl s_client -showcerts and save the output to a file for detailed inspection with openssl x509.
• Check multiple ports. If the FortiGate also serves SSL VPN on a different port (e.g., 10443), test that port as well. The certificate may differ.
• Document the certificate in your asset inventory. Include the serial number, expiration, and responsible owner to avoid surprises.

Troubleshooting

• OpenSSL connection fails with “unable to get local issuer certificate”. This means the FortiGate is not sending the intermediate certificate. Upload the full chain to the FortiGate under System > Certificates.
• Certificate shows as “Not trusted” in browsers. Check the issuer. If it is self-signed, you must either install the CA on clients or replace it with a public CA certificate.
• Certificate is expired. Renew it immediately. If you cannot renew, at least disable HTTPS admin access on the WAN interface to reduce exposure.
• Hostname mismatch warning. Either change the hostname to match the certificate or get a new certificate that includes the hostname you use.
• OpenSSL times out. Ensure the FortiGate is reachable on port 443 from your location. Check firewall policies on the FortiGate that may block your IP.
• Certificate appears to be for a different service. If you have multiple virtual servers, ensure the correct certificate is bound to the HTTPS admin service. Check the System > Admin Settings for the HTTPS certificate selection.

Frequently Asked Questions

Can I use a self-signed certificate for an internet-facing FortiGate?

Technically yes, but browsers will show warnings, and many automated clients will refuse to connect. It is not recommended for production.

How do I know if my FortiGate is using a weak key?

Run openssl s_client and look for the public key line. If it says 1024 bit or less, it is weak. Also check the signature algorithm for SHA-1, which is deprecated.

What is the difference between the certificate in the GUI and the one served?

The GUI shows the certificate stored on the device. The served certificate is what clients actually receive. They should match, but if you have multiple certificates, the wrong one might be bound.

How often should I assess my FortiGate’s TLS certificate?

At least monthly, and always after any certificate renewal or firmware upgrade. Automated monitoring is better.

Can I renew a certificate without downtime?

Yes, if you use a CA that allows re-issuance and you upload the new certificate before the old one expires. The FortiGate will start serving the new one immediately after upload.

What does “certificate chain incomplete” mean?

It means the FortiGate is only sending the leaf certificate, not the intermediate CA certificate. Clients need the full chain to validate the certificate. You must upload the intermediate certificate as well.

Related

• Prevent Websites Tracking You: 12 Real Fixes
• Leapfrog Parent Account Setup Guide
• Command Line Redirection Basics & Examples