I have a question about HTTPS inspection. As per Checkpoint website:

In outbound HTTPS inspection, when a client in the organization initiates an HTTPS connection to a secure site, the Security Gateway:

  1. Intercepts the request.
  2. Establishes a secure connection to the requested web site and validates the site server certificate.
  3. Creates a new SSL certificate for the communication between the Security Gateway and the client, sends the client the new certificate and continues the SSL negotiation with it.
  4. Using the two SSL connections:
    1. It decrypts the encrypted data from the client.
    2. Inspects the clear text content for all blades set in the Policy.

      > 3. Encrypts the data again to keep client privacy as the data travels to the destination web server resource.

HI want to enable HTTPS insection in fortigate FW but i did not get enough information in their website about so i am checking the same in Checkpoint's website. But i ended up in having more doubts.t

  1. How FW validates Server's Certificate?

  2. To verify the Certificate FW shd have trusted Root Certificates, if its not verifiying then there is no use of enableing HTTPS inspection as we are not able to authenticate Server itself.

  3. To encrypt the data firewall should generates the Session key, FW encrypts the session key using public key of Server and sends to server. This key is used for Encryption and Decryption of Data.

  4. Client PC also should generate the session key for encryption and decryption, Does client generates same key as generated by Firewall? Two tunnnels will establish once inspection is enabled, which keys are using to Encrypt/Decrypt the data in System end and Firewall End...

1 Answer 1


... because firewall does not have trusted root certificates.

The firewall does have a set of trusted root certificates. They are not necessarily exactly the same as the client has in the browser but there will be overlap for the commonly used CA. And it might even be intentional to let the firewall trust less CA then the browser does.

  • ...but note that, in my testing, Checkpoint doesn't do any validation that certificate == target... If you go to 'google.com' and get a valid certificate for 'evil.com', it'll let you right through. Hey, the certificate is valid...
    – gowenfawr
    Commented Jul 6, 2016 at 11:52
  • @gowenfawr: if this is the case that would be a major issue. How did you test, i.e. does the firewall even know the expected hostname? Commented Jul 6, 2016 at 12:23
  • This was with the Checkpoint offering that acted as an HTTP CONNECT proxy, so the firewall knows the name the client wishes to connect to. I tested by putting different certs onto my domain (say example.org) and then going to example.org in my browser. Checkpoint happily let me through if there was a valid cert for example.org OR somethingelse.com, but not if there was a self-signed cert for example.org. (This was 2 years ago, looking for an outbound certificate whitelisting proxy... I ended up writing my own in Python.)
    – gowenfawr
    Commented Jul 6, 2016 at 12:33
  • @gowenfawr: based on your description this looks like a serious bug for me. But if this was already 2 years ago I would expect reports about it. And this report from 2012 shows several such issues with other products but does not find anything with Checkpoint. If you still can reproduce the problem and if this is a default setup (i.e. admin did not explicitly weaken certificate checks) I would be interested in more details about this test setup. Commented Jul 6, 2016 at 13:26
  • IIRC this was with the URL Filtering Software Blade and using the "Lite" HTTPS filtering, which is the CONNECT proxy version and not the full TLS MITM Interception... which is probably why it's not on that report, which deals with Interception. If I can figure out how to download the 30-day eval I'll reproduce...
    – gowenfawr
    Commented Jul 6, 2016 at 13:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .