Fortigate IPS and https traffic - don't want browsers having to load fortigate certs

[markmcgloin]

I saw this documentation describing how fortigate IPS can handle SSL traffic for deep content inspection:

"......In this schema, is clear that the SSL/TLS handshake is interrupted, and the FortiGate is required to present a certificate for the URL requested by the real client. This certificate is signed by the FortiGate itself. ............. But is needed to be clear that the Full SSL Inspection the certificate used to sign those sites (by default SSL_Proxy_Inspection into the FortiGate) is needed to be recognized as a valid CA. Otherwise, the warning message will be shown everytime an SSL/TLS connection is made. This certificate (SSL_Proxy_Inspection) must be installed in each PC to be used by their Operating System and/or for browsers/applications (Mozilla Firefox or Java JRE) which has its own Certificate repository." I am surprised that the fortigate can't load the cert and private key for our domain and make this appear as if the ssl connection from the client is to our  domain(s), i.e. no need for client to load a cert signed by fortigate. Loading signed fortigate certs into browsers is not an option

[Christopher_McMullan · Accepted solution]

Thank you for clarifying. In that case, you could use Virtual IPs to load balance between multiple real servers if you host a farm for the application(s) and offload the certificate onto the FortiGate as one option; otherwise, to strictly address deep inspection for vulnerabilities, the SSL/SSH inspection profile has another option in 5.2: Protecting SSL Server.

The default is to re-sign a certificate where multiple clients are connecting to multiple servers at unknown destinations. If you choose Protecting SSL Server in the profile instead, all you're doing instead is replacing one certificate with another - one that you host on the FortiGate itself, but that could have been generated for another host.

In the CLI, it would look like this:

config firewall ssl-ssh-profile edit <name> set server-cert-mode replace set server-cert <certificate> end end

You would previously have had to upload the certificate into the Local Certificates store in order to select it within the profile.

So getting back to my three options, they are specifically for re-signing certificates when many clients connect to many unknown servers. The first option meant you would install the certificate on each host, meaning each client. You already mentioned this is not what you wanted: I explained it for context only. The second option if you wanted to re-sign certificates was to deploy the FortiGate's certificate once instead of many times to each client, assuming they were internal clients you controlled, and you had a Windows Active Directory infrastructure in place. In that case, you could use Group Policy Objects to force the certificate down centrally. The third option was to generate a new certificate for the FortiGate within your Active Directory environment as an Intermediate CA, so that domain clients implicitly trust the FortiGate's identity because of the issuer of the FortiGate's CA certificate.

*None* of these options apply to replacing a certificate instead of re-signing. My new steps above sound like they're what you're actually looking for.

[Christopher_McMullan]

Could you specify where you found the snippet of documentation that you quoted? It would be good to update it internally to reflect the broader context it falls under.

You can indeed use domain PKI in order to avoid manually installing the certificate onto each host.

Generally speaking, for SSL inspection, you have three options:

1. Manually install the certificate onto each host

2. Deploy the existing FortiGate cert via GPO instead of installing it manually each time

3. Generate a CSR on the FortiGate for a new cert, and sign it from your Enterprise Root CA

In Windows, you would want to use the Intermediate CA template for the FortiGate's certificate, so that it can re-sign website certificates using the chain of trust that clients already have for their existing domain PKI infrastructure.

Make sure after generating the new certificate that you change all references in SSL/SSH inspection profiles to use the new cert instead.

[markmcgloin]

Hi

Just to be clear, I am looking for deep content inspection on inbound traffic in the fortigate firewall IPS module. We have potentially millions of end users accessing a multitude of applications behind our fortigates. Most apps will be under one domain but some may be under other domains

I have some questions regarding the 3 options you outlined:

1. Manually install the certificate onto each host

 - What certificate and what host? 2. Deploy the existing FortiGate cert via GPO instead of installing it manually each time

 - I don't understand what this means 3. Generate a CSR on the FortiGate for a new cert, and sign it from your Enterprise Root CA

 - Can fortigate manage multiple certs if we have apps across different domains?

thanks

[Christopher_McMullan · Accepted solution]

Thank you for clarifying. In that case, you could use Virtual IPs to load balance between multiple real servers if you host a farm for the application(s) and offload the certificate onto the FortiGate as one option; otherwise, to strictly address deep inspection for vulnerabilities, the SSL/SSH inspection profile has another option in 5.2: Protecting SSL Server.

The default is to re-sign a certificate where multiple clients are connecting to multiple servers at unknown destinations. If you choose Protecting SSL Server in the profile instead, all you're doing instead is replacing one certificate with another - one that you host on the FortiGate itself, but that could have been generated for another host.

In the CLI, it would look like this:

config firewall ssl-ssh-profile edit <name> set server-cert-mode replace set server-cert <certificate> end end

You would previously have had to upload the certificate into the Local Certificates store in order to select it within the profile.

So getting back to my three options, they are specifically for re-signing certificates when many clients connect to many unknown servers. The first option meant you would install the certificate on each host, meaning each client. You already mentioned this is not what you wanted: I explained it for context only. The second option if you wanted to re-sign certificates was to deploy the FortiGate's certificate once instead of many times to each client, assuming they were internal clients you controlled, and you had a Windows Active Directory infrastructure in place. In that case, you could use Group Policy Objects to force the certificate down centrally. The third option was to generate a new certificate for the FortiGate within your Active Directory environment as an Intermediate CA, so that domain clients implicitly trust the FortiGate's identity because of the issuer of the FortiGate's CA certificate.

*None* of these options apply to replacing a certificate instead of re-signing. My new steps above sound like they're what you're actually looking for.

[markmcgloin]

Thanks for this - I will investigate v5.2. Is it limited to one certificate per fortigate, i.e. can I still use this if we have servers across different domains

set server-cert <certificate>

[Ian_Harrison]

Hi

I found the following aritcle from Fortinet which I think is what you need: http://docs.fortinet.com/uploaded/files/2041/using-a-custom-certificate-for-SSL-inspection.pdf

It explains how to replace the built in cert with one that you can get from a public trusted provider.  This would mean when you visit a HTTPS site the fortigate would replace the cert with ots own, but this would be signed by a public authority so you should not get the unknown/untrusted cert error. 

Hope that helps

Ian

[Christopher_McMullan · Accepted solution]

You can use more than one certificate per FortiGate for replacement, though there are still limits. Look up the latest Max Values document under docs.fortinet.com. The two values that would limit you are:

SSL/SSH/deep inspection options (these are the inspection profiles)

-and-

the number of certificates (under System > Certificates > Local in the document)

For instance, the smallest FortiGate models have a limit of 32 deep inspection option profiles and 200 local certificates; in that case, your limit would be 32 as the smaller of the two numbers, if you used a different inspection profile to replace 32 different certificates.

[markmcgloin]

One last thing is whether the fortigate 300c supports scanning SSL encrypted traffic. I looked at the hardware spec and it states it supports content inspection but I am not sure if that is the same?

http://www.fortinet.com/sites/default/files/productdatasheets/FortiGate-300C.pdf

From docs on configuring ssl/ssh inspection

""If your FortiGate unit has the correct chipset it will be able to scan SSL encrypted traffic in the same way that regular traffic can be scanned""

[Shawn_W]

Thanks for the links. 

[Christopher_McMullan]

The documentation seems a little open-ended on whether or not a certain model has the correct chipset. All models can perform SSL content inspection based on my internal datasheets (so their accuracy is the weak link here, but I have no reason to mistrust them), though historically, this may not have always been the case.

What does differ between models is whether any ASIC chips are dedicated to content or security processing, or if all the inspection is performed by the CPU. You would definitely want to proceed with extreme caution before enabling SSL inspection on smaller models without NP/CP/SP chips, which the product datasheet should specify. You could very quickly compromise the performance of the firewall's other features.