KB ID 0001729
Problem
Do you inspect the traffic on your network? You have a firewall? Maybe an IDS appliance? That’s good news, do you inspect HTTPS traffic? In most cases the answer is no. Because either you do not have the capability, or enabling SSL Inspection will degrade the firewall’s performance so much that you accept the risk.
At time of writing (Early 2021) it’s estimated that 85% of all web traffic is now encrypted. Let that sink in, 85% of the web traffic traversing your firewalls and security appliances is potentially not even getting looked at, because it’s encrypted.
Probably over ten years ago I was at a security convention, and the speaker asked the crowd “What’s TCP Port 443?”, This prompted the obvious answer of “It’s HTTPS!” No, its the universal hacking and exploitation port!
Do something ‘Nefarious‘ and it’s best to do it over HTTPS, (or protect it with SSL encryption.) The last time I was asked to look at inspecting HTTPS traffic, it had such an adverse affect on the firewalls performance, the client looked at extra hardware (SourceFire at the time,) to do this instead of the firewalls, and the firewalls in question were a pair of ASA-5585 SSP40’s (that’s a 6 FIGURE price tag!).
When I saw the comparison of degradation between firewall vendors I was somewhat skeptical, but Fortinet do make some bold claims. Typically their marketing and sales ‘Battlecards’ show about 15% degradation with SSL inspection enabled, (that’s on a 500E) and that is typically compared to 73% degradation on a Cisco Firepower (4000 series), or 79% on a Palo Alto (5220), or 79% on a Check Point (15600). Note: I’ve not checked these figures.
So how easy is it to setup? Well to be honest it’s painfully simple, just bear in mind on a FortiGate there’s two ‘Types’ of SSL Inspection;
- SSL Certificate Inspection: The FortiGate Checks the certificates presented to ensure the common name is correct, (resolvable) and checks it against a database of problem URLs and certificates.
- SSL Full Inspection (Deep Packet Inspection): The Fortigate ‘Brokers the SSL traffic’ and sits in the middle, it decrypts and re-enrypts the traffic before sending it onto the end user, or the remote server. To do this it needs to be able to generate and sign certificates for any domain, and you need to trust it to do so.
If you are already running a FortiGate, you probably already have SSL certificate inspection enabled on your default internet access policy and didn’t even realise it! Below we will look at deep packet inspection.
FortiGate SSL Inspection (Simply)
WARNING: Read the whole article first, simply turning this on without some forethought and planning (in production) will result in bad things happening! Remember your clients’ have to trust the Firewall and at the moment they probably do not!
The FortiGare has its own built in Certification Authority, initially I’ll use that (below I’ll demonstrate how I would do this with a ‘proper’ domain PKI deployment). From the firewalls management page System > Certificates > Locate the Fortigate_CA_SSL certificate and download it.
Put that certificate on one of your client machines and then import/trust it. Below I’m making things as difficult as possible, and using Kali Linux, on a Windows box, double click the cert import it, and manually place it into ‘Trusted Root Authorities’ store.
Note: If you use Firefox as a browser, you will need to take extra steps see this article.
Now on the ‘Policy’ that’s being applied to your web traffic, we need to alter the SSL inspection. Policy & Options > Firewall Policy (or IPv4 Policy on older models) > Locate your policy for normal web traffic and edit it.
Change SSL Inspection to ‘deep-inspection’ > OK
Note: In the example shown below, I have AntiVirus inspection enabled, I mention this because that’s what I will use to test that SSL inspection is working.
So now when my clients go to any https:// website, the certificate that the client sees, is actually signed by the firewall NOT a publicly signed certificate vendor.
To ‘Test’ that you can go to the Eicar website (if you didn’t know Eicar produce files for testing AntiVirus and AntiMalware solutions) and attempt to download one of the files (Note: MAKLE SURE you attempt to download from the HTTPS section!)
What Next?
Well that was easy! Now for a real world deployment. Your problem is getting your client to trust the firewalls CA Signing certificate. You have THREE OPTIONS
Option 1: Manually install the certificate on your clients, if you have a small organisation then that might be a good option, the built in cert lasts ten years, you will probably have a new firewall before that certificate expires.
Option 2: Distribute the FortiGates CA signing certificate by Group Policy. For medium sized deployments, of if you are one of those that’s typically terrified of certificates, this might be your option.
Option 3: You have a properly deployed Certificate Services PKI deployment already, you can issue a SubCA certificate to the firewall to do the signing with, and your domain clients will trust it automatically.
I wont insult your intelligence explaining Option 1, but Options 2 and 3 I will outline below.
Deploying FortiGate CA Signing Certificate By Group Policy
On the Fortigate you need to download a copy of the CA certificate it uses, typically it is called Fortigate_CA_SSL. From the management GUI > System > Certificates > Select Fortigate_CA_SSL > Download > Save a copy somewhere you can get to it.
On a domain controller > Administrative tools >Group Policyy Management > Create a new policy (or you can edit an existing one.) Below I’m linking mine to the root of my domain, you may want to link yours to the OUs that your computer objets are in.
Edit the new policy and navigate to;
[box]
Computer Configuration > Policies > Windows Settings > Security Settings >Public Key Policies > Trusted Root Certification Authorities
[/box]
Right click > Import.
Follow the wizard, navigate to and select the certificate from the FortiGate > Make sure that it gets put in the Trusted Root Certification Authority store!
Close the policy editor, then wait a couple of hours or Force a Domain Policy Refresh.
Replace FortiGate SSL Inspection CA Cert with a Microsoft Certificate Services SubCA Cert
This would be my preferred choice, if you have a proper PKI deployment in your domain your client will already trust it, so all you have to do is use a SubCA cert to the firewall. If you don’t have a PKI deployment yet, but this is the correct route to take run though the following first to get up and running;
Microsoft PKI Planning and Deploying Certificate Services
Even with your own Microsoft Certificate Services deployment, it’s just worth a quick check that you already have a template for ‘Subordinate Certification Authority‘. (it’s typically deployed by default).
I’m going to apply for my certificate using the ‘Certificate Authority Web Enrollment Role’ (this is an additional role you can add to Certificate Services to give you this nice web portal for getting certificates). Web browse to https://(FQDN-of-Certificate-Server}/Certsrv (Note: yours may be on http://) > Request a Certificate > Advanced Certificate Request > Create and Submit a Request to this CA.
- Template: Subordinate Certification Authority
- Name: The FQDN of the firewall (must be resolvable in DNS!)
- Email to Country/Region: Fill out as applicable
- Key Size: 2048
- Mark keys as exportable: Ticked
Submit.
Install this certificate.
Use MMC to Inspect User Certificates
This will have dropped the certificate in YOUR user certificate container, we now need to locate and export it.
Windows Key +R > mmc.exe > File > Add/Remove Snap-in > Certificates > Add > Select User Account.
Expand Certificates – Current User > Personal > Certificates > Locate the certificate > All Tasks > Export.
Next > Yes: Export the private key > Next > Personal Information Exchange (PFX) > Next > Password (Type and confirm password you will remember) > Change the encryption to AES256–SHA256 > Next > Select a location to save the certificate > Next > Finish.
Back at the FortiGate > System >Certificates > Import Local Certificate.
Type: PKCS # 12 > Upload > Locate and select the certificate you exported above > Enter The password > Upload > OK.
FortiGate: Create SSL Inspection Profile
Security Profiles > SSL/SSH Inspection > Create New.
Give the policy a sensible name > Change the CA Certificate to the one you just uploaded > OK.
To use that Profile in your web access policy, Policy & Objects > Firewall Policy > Locate the policy that defines web traffic and edit it.
Change the SSL Inspection to use your new profile > OK.
Now you can test the deployment by going to an https secure website (like this one!) and taking a look at the certificate, it should have been issued by your SubCA/Firewall.
Related Articles, References, Credits, or External Links
NA
Nothing less than excellent article.
ThanQ
Does the FQDN of the firewall need to be resolvable by public DNS or just internally?
Internally 🙂
What if I want to use public certificate ? Because I want to apply SSL inspection for my guest user. In this case I cant add Fortinate CA as trusted their computer. I tried to do this with my wildcard certificate. But it didn’t work.
Then you are snookered – you would have to create a policy for guests that did not do SSL inspection.
Thanks, this article is well done.
Would we use Dynamic Local Certificates to achieve this via Fortimanager?
I’ve not deployed or worked with FortiManager, so I cant comment. But I’ll throw it open..
P
Would the same certificate work for the authentication captive portal on port 1003? Normally, that requires a different AD CS template.
In all honesty I dont know but I’ll throw it open for comment….
P
Is it possible if we can use publicly signed certificate for dpi instead of self signed one?
It would need to be trusted as a SubCA Certificate – IF you can find someone who will sell you one, then it would not be cheap, (you could then essentially start issuing trusted certs to anyone.)
my deep inspection is not showing in Fortigate60F
WHY does it need to be CA certificate?
It makes zero sense!
Seb
Because the Forti needs to be able to ‘Sign” certificates on the fly – as you make https requests.
Only a CA can sign and issue certificates.
Try it and connect to https://www.petenetlive.com – then look at the cert – it will be issued and signed by the Forti – but the PNL site cert is obviously issued by a publically signed CA.