Certificate for https traffic

[v20100]

Not sure it is in the correct thread. Running on 200D 5.4.8   This is mainly for AV. In order to detect viruses, we needed to add the SSL/SSH inspection and by selecting "Certificate Inspection", the firewall now detects viruses but only for non encrypted traffic. As most of the traffic is now via https, we need to select instead "Deep Inspection" However, all the sites now come with certificate errors. The engineer assigned to our case, told us that we need to install the Fortigate certificate on all our workstations, which is not really possible. too many devices (windows, IOS, MAc and Android) and too many browsers He said the alternative was to purchase a CA certificate and install it, but was not able to advise further.   Have many of you used that technique? I am guessing that it becomes more and more common to implement viruses/malware scanning at the gateway level, and this would be the easiest method now that 90% traffic is encrypted?   What CA would you recommend? We already have a 'standard' certificate installed on the Fortigate for SSLVPN to avoid the errors. When requesting the CA certificate, do we also use the same DNS name? And it will not interfere with the current cert installed for SSLVPN?   Thanks in advance

[blackhole_route]

emnoc wrote:
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 )  

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.

[localhost · Accepted solution]

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]

agreed

The bottomline the OP needs to  determine what certificate to use and how to deploy it to the webclient

[Deepakkhw]

Hi, Can I purchase a Certificate Authority that allows Decrypt and Scan without needing to deploy anything to clients? No, you cannot. HTTPS is designed so that you cannot. Consider the implications if this was not true. If you took your phone to a coffee shop and logged on to their free wifi to do banking, would you like the coffee shop to be able to see all your bank account information? Because your phone is communicating with the bank's website using HTTPS, and because the coffee shop cannot spy on the traffic without you getting a warning, you know that communication is secure. A coffee shop (or your company) cannot use a Sophos web proxy to silently decrypt all HTTPS traffic without the user allowing it, either by having them install a CA or go through browser warnings. You must use the CA that comes with the firewall or create your own CA certificate, which can be a self-signed root. Your Microsoft Active Directory also has its own Certificate Authority (see Active Directory Certificate Services) where you can create an intermediate/leaf CA that you can use within the firewall. If it were possible to purchase a signing CA that is ultimately authenticated by a public root CA, it would break the whole trust model on which SSL authentication is based. The trust model depends on the organizations who control the trusted root certificates being selective and applying strict criteria about when they allow a certificate to be signed. For example, they should only sign a certificate for google.com if the person requesting the certificate can prove that they control that domain. But if they issued a certificate to a third party that could be used to sign whatever certificate that third party likes, they would basically be delegating the ability to create and sign certificates for ANY domain that would be trusted automatically by ANY browser. It would allow the purchaser of that certificate to set up their own website and pretend to be google.com, or facebook.com, or wellsfargo.com or anyone they like, and browsers would just accept it. Regards, Deepak Kumar

[emnoc]

Agreed 100% with  Kumar analysis.

Ken Felix

[Hasanen_Bashir]

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

[sw2090]

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.

[live89]

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 ..