Certificate Management and SSL Inspection — this is the chapter where you learn how Fortinet FortiGate firewalls peek inside encrypted internet traffic to catch hidden threats. Without it, your firewall is essentially blind, letting viruses and hackers sneak through data that looks like a jumbled mess (encryption). For the NSE4 exam, you need to understand exactly how certificates work, why inspection is critical, and how to configure it without breaking the internet for your users.
Jump to a section
A simple way to picture Certificate Management and SSL Inspection
Have you ever received a package from a courier that looked a bit janky? The box was taped up oddly, or the return address was smudged, but you still signed for it because you were expecting something important? That is exactly what happens when your network does not inspect encrypted traffic.
Here is how it works in the real world. You order a birthday gift from an online shop. The shop packs it in a box and seals it with a special tamper-proof sticker (that is the digital certificate, like a passport for the package, proving the shop is legit). The courier picks it up and puts it on their van. Now imagine that van drives through a dangerous neighbourhood where thieves might swap the contents. If you just take the package at your door without peeking inside, you are trusting the sticker was never peeled off. That is normal, encrypted web traffic — your browser trusts the certificate and opens the box without checking.
But what if you are a large office building (a company) and every package needs to be inspected by security before it reaches the employee? The security team needs a master key that lets them open any sealed box without breaking the tamper-proof sticker permanently, so they can re-seal it perfectly afterwards. That is SSL Inspection. The security team is your FortiGate firewall. The certificate is the website’s identity card. The firewall uses a special ‘proxy’ certificate (like the security team’s master key) to decrypt the traffic, look inside for malware or data leaks, then re-encrypt it and send it on its way. If the original sticker was fake or damaged, the firewall blocks the delivery entirely.
So, SSL Inspection is your digital security team opening every sealed package at the loading dock, checking the contents, and re-sealing it with the office’s own tamper-proof sticker before handing it to the employee. This stops malicious packages from ever reaching the recipient.
Let us start with the absolute basics. When you visit a website like your bank or Gmail, you want the data you send (like your password) to be private. Encryption scrambles that data into a secret code that only the website can unscramble. The technology that does this is called SSL/TLS (Secure Sockets Layer / Transport Layer Security). It creates a secure tunnel between your browser and the web server.
To make this tunnel, the website must prove its identity. It does this using a digital certificate. Think of a digital certificate as a passport for a website. It contains the website’s name (like google.com), who issued the passport (a trusted company called a Certificate Authority, or CA, such as DigiCert or Let’s Encrypt), an expiration date, and a public key. Your browser has a built-in list of trusted CAs. When you connect to a site, the server presents its certificate. Your browser checks the CA’s signature. If the CA is trusted and the certificate is valid, your browser uses the public key to start the encrypted conversation.
Now, here is the problem for security professionals. All this encryption is great for privacy, but it is also great for hiding malware. A virus could be downloaded from a website, or a hacker could steal your data, and all the firewall sees is a blob of encrypted traffic. It cannot tell if that blob is a cat video or a ransomware attack. That is why we need SSL Inspection.
SSL Inspection (sometimes called HTTPS inspection or SSL/TLS decryption) is the process where a FortiGate firewall sits in the middle of the connection. Instead of just forwarding the encrypted traffic blindly, the firewall acts as a ‘man in the middle’ but for good reasons. Here is how it works step by step:
The user’s browser requests a website (e.g., https://example.com).
The FortiGate intercepts this request before it reaches the actual example.com server.
The FortiGate pretends to be example.com to the user’s browser. It creates a new, temporary certificate on the fly, signed by the FortiGate’s own internal CA certificate.
The user’s browser receives this temporary certificate. If the FortiGate’s CA certificate is installed and trusted on the user’s computer (you have to do this as an admin), the browser accepts it and establishes an encrypted connection with the FortiGate.
The FortiGate then opens a second, separate encrypted connection to the real example.com server, using the server’s original certificate.
Now the firewall has decrypted the user’s traffic on one side and the server’s traffic on the other side. It inspects the plain-text data (looking for viruses, malicious URLs, data leaks, etc.) using its security features like IPS (Intrusion Prevention System) and antivirus.
If the traffic is clean, the FortiGate re-encrypts it and sends it to the user. If it is malicious, the firewall blocks it.
This entire process happens in milliseconds. To the user, it feels like a direct connection. But the firewall has full visibility.
There are two main types of SSL Inspection profiles on FortiGate:
Full SSL Inspection (also called Deep Inspection): The firewall decrypts the traffic, inspects it, and re-encrypts it. This provides complete security but requires you to install a CA certificate on every device (otherwise users see browser errors).
SSL Certificate Inspection (sometimes called Certificate Inspection): The firewall does not decrypt the traffic. Instead, it only checks the certificate presented by the server. It verifies the certificate is valid, not expired, and comes from a trusted CA. It can block connections to servers with invalid certificates but cannot see the payload inside. This is faster and requires no client-side certificate installation, but it offers weaker security.
You configure these inspections using SSL/SSH Inspection profiles in the FortiGate GUI or CLI. You must also manage the CA certificate — the root certificate that the FortiGate uses to sign all the temporary certificates. If this CA certificate ever expires, all deep inspection will break, and users will lose internet access or see security warnings.
Certificate Management also involves knowing the difference between a self-signed certificate (generated by your own company) and a CA-signed certificate (bought from a trusted third party). For internal company servers, self-signed is fine. For public-facing websites, you need a CA-signed certificate. FortiGate can generate self-signed certificates for internal use, or you can import external certificates.
Finally, there is the concept of certificate revocation. If a certificate is compromised (stolen private key), it must be revoked. FortiGate can check against Certificate Revocation Lists (CRLs) or use OCSP (Online Certificate Status Protocol) to see if a certificate is still valid. This is a common exam point.
To sum up: SSL Inspection allows you to inspect encrypted traffic for threats. Certificate Management is about maintaining the trust infrastructure (CA certificates, server certificates, CRLs) that makes this inspection possible. Without proper management, your inspection breaks, and your network becomes blind.
Generate or Import a CA Certificate
You need a root Certificate Authority (CA) certificate that FortiGate will use to sign the temporary certificates it creates when inspecting traffic. You can generate a self-signed CA certificate directly in FortiGate under System > Certificates, or import an existing one if your organisation uses a corporate CA. This certificate is the foundation of trust for the entire SSL inspection process.
Distribute the CA Certificate to Client Devices
For Full SSL Inspection to work without security warnings, every client device (Windows, macOS, Linux, iOS, Android) must trust the FortiGate's CA certificate. You install it in the device's Trusted Root Certification Authorities store. This is typically done via Group Policy in Active Directory, MDM solutions like Intune, or manually. Skipping this step causes users to see 'Your connection is not private' errors on every HTTPS site.
Create an SSL/SSH Inspection Profile
In FortiGate, navigate to Security Profiles > SSL/SSH Inspection and create a new profile. Choose the type: Full SSL Inspection for deep decryption, or Certificate Inspection for simple certificate validation. Select the CA certificate you generated or imported. Configure any SSL exemptions for sites that must not be decrypted (e.g., banking portals). This profile defines exactly how the firewall will handle encrypted traffic.
Apply the SSL Inspection Profile to a Firewall Policy
Go to Policy & Objects > Firewall Policy and edit the policy that governs traffic from your internal network to the internet (usually LAN to WAN). In the 'Security Profiles' section, enable the SSL Inspection profile you created. Without this step, the profile exists but does nothing. The policy determines which traffic gets inspected.
Test and Troubleshoot
After applying the profile, test from a client device. Visit a website with a valid certificate. It should load normally. Check the FortiGate logs (Log & Report > Security Events) to see HTTPS sessions being logged with inspection details. If some websites break, identify the cause — often certificate pinning — and add those sites to the SSL exemption list in the profile. Verify that the CA certificate is properly installed on the testing device. Adjust exemptions as needed.
Imagine you are the IT administrator for a medium-sized company called ‘GreenLeaf Ltd’. You have 200 employees, all using laptops and phones provided by the company. You have a FortiGate firewall at the internet edge. Your CEO tells you that the company’s customer database was almost stolen last month because an employee clicked a link in a phishing email that downloaded a keylogger. The keylogger was hidden inside an encrypted HTTPS connection to a file-sharing site. The firewall saw nothing because it was not inspecting the traffic.
Your job is to implement SSL Inspection to prevent this from happening again. Here is exactly what you do:
First, you log into the FortiGate GUI. You navigate to System > Certificates. You check if there is already a CA certificate. If not, you generate one. This CA certificate is the master key. You name it ‘GreenLeaf-Root-CA’.
Next, you need to distribute this CA certificate to every single employee device. You do this through Group Policy in Windows Active Directory or through your Mobile Device Management (MDM) system like Microsoft Intune. You push the certificate to the ‘Trusted Root Certification Authorities’ store on every Windows laptop. You do the same for iPhones and Android devices via MDM profiles. This step is critical. If you forget it, every employee will see ‘Your connection is not private’ warnings on every HTTPS site, and they will call the helpdesk non-stop.
Then, you create an SSL/SSH Inspection profile. You go to Security Profiles > SSL/SSH Inspection. You choose ‘Full SSL Inspection’. You select the ‘GreenLeaf-Root-CA’ as the trusted root CA. You leave the default settings to inspect traffic to all destinations, but you may choose to exempt certain sites like banking websites or health portals (this is called an SSL exemption). You do this because some banking apps or healthcare portals break if you decrypt their traffic (they use a technique called certificate pinning).
You apply this SSL Inspection profile to the firewall policy that governs internet-bound traffic from your internal network (the LAN to WAN policy). Now all traffic passing through that policy gets inspected.
Finally, you test it. You visit a known malicious test site (like a sandbox site provided by Fortinet) from an employee laptop. The FortiGate blocks it because the IPS engine inside the inspection detects a threat in the decrypted data. You also check the logs in FortiAnalyzer or FortiGate’s log viewer to confirm that HTTPS sessions are being logged with URL categories and threat names.
Later, you discover that the company’s printer (an old model) is failing SSL inspection because it does not trust the FortiGate’s CA certificate. The printer needs to talk to a cloud service for scanning. You add the printer’s IP address to an SSL exemption list — effectively telling the firewall ‘do not decrypt traffic to or from this device’. This is another everyday job: managing exemptions for devices that cannot handle inspection.
You also set up a schedule to renew the CA certificate every two years. You set a calendar reminder. You know that if the CA certificate expires, all deep inspection stops working. You also configure CRL checking so that if any certificate is compromised, the firewall will reject it immediately.
This scenario shows that SSL inspection is not a ‘set it and forget it’ task. It requires ongoing certificate management, user communication, and troubleshooting when applications break.
The NSE4 exam tests Certificate Management and SSL Inspection heavily. You can expect multiple-choice, multiple-answer, and scenario-based questions. Here is exactly what Fortinet wants you to know:
The exam loves to ask about the difference between SSL Certificate Inspection and Full SSL Inspection. Here is the trap: many beginners think ‘Certificate Inspection’ is the deeper, more secure option because the name sounds official. It is not. Certificate Inspection only checks the certificate’s validity (expiry, issuer, revocation). It does not decrypt the traffic. Full SSL Inspection decrypts and inspects the content. On the exam, if a question says ‘inspect the payload for malware’, the answer is Full SSL Inspection. If it says ‘block connections with expired certificates’, the answer is Certificate Inspection. Memorise this distinction.
Another common exam topic is the CA certificate. Questions will ask: ‘What must be installed on client devices for Full SSL Inspection to work without certificate errors?’ The answer is the FortiGate’s CA certificate in the Trusted Root store. A trap answer is ‘the server’s public certificate’ — wrong, that is the website’s certificate. The FortiGate’s CA is the one you generate or import.
Expect questions on SSL Exemptions. The exam lists sites you can exempt from inspection. Why? Because some applications use certificate pinning and will break if traffic is decrypted. You must remember that banking and healthcare sites are common exemptions. Also, you can exempt by destination address (IP or domain) or by user group. The exam might give you a scenario: ‘Users cannot access their bank account after enabling SSL inspection. What do you do?’ Answer: Add the bank’s domain to the SSL exemption list.
The concept of Certificate Revocation Lists (CRL) and OCSP is tested. Questions will ask: ‘How does FortiGate verify a certificate has not been revoked?’ Answer: By checking a CRL (downloaded from the CA) or by using OCSP (an online protocol that asks the CA in real-time). The exam may ask which is faster (OCSP is real-time) versus which is more reliable offline (CRL can be cached).
There will be questions about self-signed certificates versus CA-signed certificates. Remember: self-signed certificates are fine for internal networks but not for public websites. A user browsing a public site with a self-signed certificate will see a security warning. The exam asks: ‘What type of certificate is typically used for internal company servers?’ Answer: Self-signed.
Another key point is the concept of certificate pinning. The exam defines it: when a client (browser or app) stores the exact certificate or public key of a server, and refuses to connect if the server presents a different certificate (even from a firewall’s proxy). This is why SSL inspection breaks some applications — the app sees the FortiGate’s certificate instead of the server’s real one, and rejects it. Fortinet wants you to know that you must either exempt those apps or use a certificate that matches the pinned key (which is rarely possible).
Finally, expect a question about the order of operations for SSL inspection. The firewall must first establish a connection with the client, then with the server. The exam might present a diagram and ask: ‘Which step happens first?’ The answer: the firewall accepts the client’s connection (the client hello).
To summarise the exam focus:
Know the two inspection types and their use cases.
Know that the CA certificate must be deployed to clients.
Understand SSL exemptions and why they exist.
Know CRL vs OCSP.
Know self-signed vs CA-signed.
Understand certificate pinning and its impact.
SSL Inspection allows FortiGate to decrypt and inspect HTTPS traffic to detect threats that would otherwise remain hidden inside encrypted tunnels.
Full SSL Inspection decrypts the entire traffic payload, while SSL Certificate Inspection only checks the validity and metadata of the certificate without decrypting the data.
For Full SSL Inspection to work without browser errors, you must deploy the FortiGate's CA certificate to every client device's Trusted Root Certificate store.
SSL exemptions are necessary for websites and applications that use certificate pinning or otherwise break when their traffic is decrypted, such as banking and healthcare portals.
Certificate Revocation Lists (CRLs) and OCSP are two methods FortiGate uses to verify that a certificate has not been revoked by its issuer.
A self-signed certificate is suitable for internal company servers, but a CA-signed certificate is required for public-facing websites to be trusted by browsers.
These come up on the exam all the time. Here's how to tell them apart.
SSL Certificate Inspection
Only validates the server certificate's expiry, issuer, and revocation status.
Does not decrypt the encrypted payload, so malware inside the traffic remains invisible.
Faster to process and requires no CA certificate deployment to client devices.
Full SSL Inspection
Fully decrypts the HTTPS payload to inspect content for threats like viruses and phishing URLs.
Provides complete visibility into encrypted traffic, allowing the firewall to block malicious payloads.
Slower due to decryption and re-encryption, and requires the CA certificate to be installed on all clients.
Self-Signed Certificate
Created by the organisation itself, not by a trusted third-party Certificate Authority.
Browsers do not trust it by default, causing security warnings for external users.
Free and easy to generate, suitable for internal testing and private network services.
CA-Signed Certificate
Issued and validated by a globally trusted Certificate Authority (e.g., DigiCert, Let's Encrypt).
Browsers trust it automatically, providing seamless user experience on public websites.
Costs money (or requires automation via ACME for free options) and involves a validation process.
CRL (Certificate Revocation List)
A periodically downloaded list of revoked certificate serial numbers from the CA.
Can provide offline verification if the list is cached, but may be outdated between updates.
Larger in size as the list grows; requires manual or scheduled download intervals.
OCSP (Online Certificate Status Protocol)
A real-time online query to the CA asking 'Is this certificate still valid?'
Provides up-to-the-minute revocation status, but requires an active internet connection to the CA.
Smaller overhead per query, but each certificate check generates a separate request.
Mistake
SSL Inspection is enabled by default on FortiGate and works immediately without any configuration.
Correct
SSL Inspection is not enabled by default. You must manually create an SSL/SSH Inspection profile and apply it to a firewall policy. You also must distribute the CA certificate to client devices, or users will see certificate errors.
Many beginners assume firewalls automatically inspect HTTPS traffic because it seems like a basic security function. They forget that encryption is designed to hide content, so the firewall needs explicit setup to break that encryption.
Mistake
SSL Certificate Inspection and Full SSL Inspection provide the same level of security.
Correct
SSL Certificate Inspection only checks the certificate metadata (validity, expiry, revocation). Full SSL Inspection decrypts the traffic and inspects the actual payload for malware, data leaks, and phishing content. Full inspection is far more secure.
The names are confusing. Beginners hear 'Certificate Inspection' and think it means inspecting the certificate deeply, but it actually means only inspecting the certificate, not the encrypted content. The word 'inspection' misleads them.
Mistake
If a website has a valid certificate from a trusted CA, the FortiGate will always allow it through SSL inspection without issues.
Correct
Even with a valid certificate, the FortiGate can block the site if the decrypted content contains malware, a malicious URL, or violates a security policy. Valid certificate does not mean safe content.
People conflate 'trustworthy certificate' with 'trustworthy website'. A malicious site can have a perfectly valid certificate. The exam tests that SSL inspection looks at content, not just the certificate.
Mistake
You do not need to worry about the CA certificate expiring because FortiGate automatically renews it.
Correct
FortiGate does not automatically renew self-generated CA certificates. You must manually track the expiry date and renew or replace the CA certificate before it expires. If it expires, all deep inspection breaks and users lose access.
Automatic renewal is common for public certificates via ACME (like Let's Encrypt), but FortiGate's internal CA does not have that feature. Beginners assume everything is auto-managed.
Mistake
Once you enable SSL inspection on a policy, it applies to all traffic including traffic between internal networks (LAN to LAN).
Correct
SSL inspection is only applied to traffic that matches the firewall policy you attached the profile to. By default, it is typically applied only to internet-bound (LAN to WAN) traffic. Internal traffic between subnets usually does not get inspected unless you create a separate policy.
Beginners think 'enabling once globally' works. But FortiGate operates by policies. You must explicitly assign the inspection profile to each policy.
Mistake
Certificate pinning only affects mobile apps, not web browsers.
Correct
Certificate pinning can be implemented in web browsers (via HTTP Public Key Pinning or HPKP) and in many desktop applications, not just mobile apps. Chrome and Safari have used pinning in the past. Modern browsers use other mechanisms, but the concept applies broadly.
The term 'pinning' is often discussed in the context of mobile apps (iOS and Android) because it is more common there. Beginners forget that browsers also had pinning features.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
This error appears because your computer does not trust the FortiGate's CA certificate. You must install the firewall's CA certificate in the Trusted Root store on every client device. Without it, browsers see the FortiGate's temporary certificate as untrusted.
SSL Inspection deals with HTTPS web traffic (port 443). SSH Inspection deals with secure shell connections (port 22) used for remote administration. Both can be configured in the same SSL/SSH Inspection profile on FortiGate, but they decrypt different types of encrypted traffic.
Technically yes, if Full SSL Inspection is enabled and the banking site is not exempted. The firewall sees the decrypted traffic including form submissions. This is why many organisations exempt banking and healthcare sites from inspection for privacy and compliance reasons.
Yes, it can add a small latency because the firewall must decrypt, inspect, and re-encrypt each packet. The impact depends on the firewall model and number of concurrent sessions. FortiGate hardware acceleration minimises this, but there is always some overhead compared to no inspection.
When the CA certificate expires, FortiGate can no longer generate valid temporary certificates for deep inspection. All HTTPS connections will either fail or produce certificate errors. You must renew or replace the CA certificate before it expires and redeploy the new certificate to all clients.
Some websites and applications use certificate pinning, where they expect a specific certificate from the server. When FortiGate replaces the server's certificate with its own temporary certificate, the app rejects it. You must add these sites to the SSL exemption list to allow them to pass without inspection.
You've finished Certificate Management and SSL Inspection. Continue through the NSE4 study guide to build a complete picture of the exam.
Done with this chapter?