Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
I find it strange that Fortinet does not have a built-in public certificate that should be used for this. Surely, if it says it can scan for viruses/etc on the fly, it should provide the facility out of the box!
It's not possible to buy such public intermediate CA certificate! This would totally break SSL encryption. You'd be able to fake every SSL Website/Service worldwide.
Public intermediate CA certificates will be limited to specific domains, to which you are allowed to deploy certificates for. This is not what you need for deep ssl inspection.
With a private CA, you can do anything you want. Like creating your own SSL certificates for www.ubs.com, www.paypal.com, etc.
This is exactly what the Fortigate is doing when deep ssl inspection is enabled. It's decrypting the SSL connection, and creating a new encrypted connection with its own CA certificate. It will generate a new connection, because it does not have the private key for the website or the CA it's intercepting (in my example Verisign & online.citi.com). So a 'deep inspected' SSL connection to online.citi.com is divided in two seperate connections.
online.citi.com <--1--> fortigate <--2--> internal computer
1: public trusted certificate. Signed by VeriSign Class 3 Public Primary CA
2: privately trusted ceritificate. Signed by YourFortigate
There is no easy way around here. If you want to open and inspect SSL connections, you have to create your own CA Certificate and deploy it or use the one which is already on the Fortigate and deploy that one.
If there is not enough knowledge to setup an own PKI, I suggest you deploy the CA certificate already on the Fortigate.
Btw. this is not a Fortigate/Fortinet limitation, this is just how SSL interception works.
Also note.. you thoroughly need to this before enabling it globaly. Because it will most likely not work with some services/application you are using right now.
emnoc wrote:This is incorrect as far as I’m aware. Even in explicit proxy deployments, ssl interception with a signing certificate is still required. With explicit proxy, the FGT does have the domain being requested provided by the connect from the client. But the ssl handshake is proxied (not terminated) on the FortiGate, and therefore it is unable to inspect the http payload inside the ssl connection unless ssl deep inspection (aka ssl interception or MITM) is used.
You do have one more option that could be explored, and which requires NO cert and only will work for HTTP/HTTPS/FTP but has other gotchas If your goal is to inspect HTTPS/HTTP , defined the fortigate as explicit proxy and then you can do all that you want with out deploying certs across devices. You will still need to publish the proxy to the clients which is the gotcha ( WPAD or PAC )
I find it strange that Fortinet does not have a built-in public certificate that should be used for this. Surely, if it says it can scan for viruses/etc on the fly, it should provide the facility out of the box!
It's not possible to buy such public intermediate CA certificate! This would totally break SSL encryption. You'd be able to fake every SSL Website/Service worldwide.
Public intermediate CA certificates will be limited to specific domains, to which you are allowed to deploy certificates for. This is not what you need for deep ssl inspection.
With a private CA, you can do anything you want. Like creating your own SSL certificates for www.ubs.com, www.paypal.com, etc.
This is exactly what the Fortigate is doing when deep ssl inspection is enabled. It's decrypting the SSL connection, and creating a new encrypted connection with its own CA certificate. It will generate a new connection, because it does not have the private key for the website or the CA it's intercepting (in my example Verisign & online.citi.com). So a 'deep inspected' SSL connection to online.citi.com is divided in two seperate connections.
online.citi.com <--1--> fortigate <--2--> internal computer
1: public trusted certificate. Signed by VeriSign Class 3 Public Primary CA
2: privately trusted ceritificate. Signed by YourFortigate
There is no easy way around here. If you want to open and inspect SSL connections, you have to create your own CA Certificate and deploy it or use the one which is already on the Fortigate and deploy that one.
If there is not enough knowledge to setup an own PKI, I suggest you deploy the CA certificate already on the Fortigate.
Btw. this is not a Fortigate/Fortinet limitation, this is just how SSL interception works.
Also note.. you thoroughly need to this before enabling it globaly. Because it will most likely not work with some services/application you are using right now.
agreed
The bottomline the OP needs to determine what certificate to use and how to deploy it to the webclient
PCNSE
NSE
StrongSwan
Agreed 100% with Kumar analysis.
Ken Felix
PCNSE
NSE
StrongSwan
Hey,
you need a CA and create A CSR after that attached it with your device , let me know if you still have a difficulies to support you
v20100,
For your basic understanding:
if you want to inspect encrypted connections you do have to use deep inspection - correct so far!
Basically in this case your FortiGate has to do somewhat Man-in-the-middle (MitM). This means it has to catch the encrypted connection and decrypt it, inspect it and then re-encrypt it and hand it on to the client.
To encrypt you need the private key for the certificate and your FGT will of course not have private keys of remote side certificates. So the FGT must use it's own certificate to do this. For this Fortinet shipped the FGTs with a self-signed Fortinet certificate plus CA Certificate which is used by default. Since it is self-signed you will indeed have to roll the Fortinet CA Certificate out to your client to enable them to validate that certificate. Otherwise your clients will give you certificate errors like you reported.
Since you would afair need a sub-ca certificate for deep inspection which you might not get in public as someone wrote before the best solution will be to set up your own CA and publish it'S CA to your clients and the FGT and then generate the sub-ca with it. I'd btw recommend to initialize certificate generation for a FGT by creating a csr on the FGT because it then already has the keys.
That's also the way I do it here.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Hi,
AFAIK, yes you need to install the fortigate certificate on all the workstations in order to trust the firewall the in inspecting your workstation traffic . using the certmgr.msc from cmd . I think you can do this via GPO if its many workstations .
This is true not only in Fortigate enviroments , we used to do that in other environments using other vendors proxies ..
Thanks
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1546 | |
1030 | |
749 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.