VeriSign certificate & deep packet inspection

[Chris_Harrington]

Hello, has anyone successfully created a pcks12 certificate using openssl and VeriSign to install a VeriSign certificate on a Fortigate device for the ssl deep packet inspection? If so, how did you do it? -Chris

[thors_hammer]

For ssl scanning you need a (sub-)ca-certificate. Is VeriSign signing this certificate signing requests? -Thors_Hammer

[Chris_Harrington]

Yes, VeriSign is signing the request. Well, I' m assuming they are since they process the csr and offer me a PKCS7/x509 certificate back. :) Here is what I did: Per Fortinet KB http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD30586 I used 2 of the 3 commands on the referenced site (http://webdesign.about.com/od/ssl/ht/new_selfsigned.htm) I cannot use the 3rd command because it creates a self signed cert. Here are the commands used: -openssl genrsa -des3 -out certificate.key 2048 -openssl req -new -key certificate.key -out certificate.csr I submitted the csr to verisign and got my new pkcs7 (.p7b) certificate. I decided that I need to verify that the key, csr, and certificate match. I downloaded the verisign cert in x509 format (certificate.cer) and ran these commands to verify the certificate matches the private key: openssl rsa -noout -modulus -in certificate.key openssl req -noout -modulus -in certificate.csr openssl x509 -noout -modulus -in certificate.cer the keys matched since it looks like you need to convert to pem from pkcs7 I run this: openssl pkcs7 -print_certs -in certificate.p7b -out certificate.pem Now, I think I need to reverify that the keys match so I do this: openssl x509 -noout -modulus -in certificate.pem The keys still match, good So now I need to convert to a pkcs12 cert. I did this: openssl pkcs12 -export -inkey certificate.key -in certificate.pem -out certificate.p12 I am prompted to the export password, I do. So now I try to import it into the fortigate System \ Certificate \ Local Certificates Import Type = PKCS12 Certificate Certificate with key file = certificate.p12 Password = the password Error - Failed to import pkcs12 file. What am I doing wrong?

[michellem812]

I have a similar problem - I have a GoDaddy cert, and am trying to use it with the UTM Proxy Option. Since the certificate includes an intermediate cert, the Fortigate isn' t seeing CA:true or Key Usage = Certificate Signing for my GoDaddy cert (tech support verified that one of those must be true for the UTM Proxy option to work with SSL inspection). I did get it to install using the openssl option after loading the .cer files that I received from GoDaddy into Microsoft and then exporting to PKCS#12 and using openssl to convert to a certificate that Fortigate would accept (http://www.doitfixit.com/index.php?option=com_content&view=article&id=153:importing-a-microsoft-iis-... ). However, that still did not provide the CA:true or KeyUsage=Cert Signing that Fortigate says is necessary for the cert to be used by UTM Proxy Options. Has ANYONE gotten a third-party cert to work with Fortigate' s UTM Proxy Options? I can get it to work with the SSLVPN, just not for deep packet inspection. And I don' t want a self-signed one by my domain controller, since I have too many non-domain devices on the network that would still get the cert error screen. Just curious if anyone has this working.

[ejhardin]

Has ANYONE gotten a third-party cert to work with Fortigate' s UTM Proxy Options?

Not possible... This is not a fortigate issue. You will have the same problem with other vendors, watchguard, cisco, sonicwall, etc... I don' t know of a SSL vendor that would allow you to have a public CA cert. Private certs are you only option.

[michellem812]

From what I' m seeing with the open incident with FG tech support, I think you' re right. I cannot get a public CA cert, and that is what FG wants for the UTM Proxy option. I don' t want to require users to install a certificate on their devices, since I have thousands of different devices, not all of them managed, so I think I' ll have to forgo the SSL deep scan option. However, I wish the FG documentation was more clear on this aspect. At least my certificate will work with SSL-VPN.

[veechee]

I don' t see what' s not clear in the documentation. This is not a Fortinet problem. VeriSign/GoDaddy/etc aren' t issuing certificates for *.* hostnames, so how would you ever expect these to work for deep packet SSL inspection? If it was possible to install certificates that are universally trusted by devices onto firewalls/routers, then SSL would be a completely useless protocol. If someone tries to get in the middle of your users, they SHOULD see a warning! If a certificate isn' t trusted by a reputable authority and issued for that specific website, they SHOULD see a warning! If you don' t want them to see it, you need to take very deliberate steps not to: 1) issue a trusted certificate from your domain controller (as this should be a highly secure certificate authority in your organization) or 2) on un-managed devices, give them a certificate that they must install which will be trusted for the same purpose. The user should DEFINITELY have to take specific, deliberate steps in order to avoid seeing warnings. If SSL interception was as easy as you wish it to be, entire countries would be doing it, not to mention entire service providers, airports/hotels/cafes. SSL would be broken and nobody would trust it for anything at all.

[michellem812]

I realize that I don' t fully understand the SSL options for the deep packet SSL inspection - which is why I posted to the forum, hoping for helpful responses. I didn' t find the documentation clear - and I also spoke with 2 Fortinet tech support agents who both told me that I should be able to take a purchased SSL cert to use for the SSL inspection so that no cert installation on a device is necessary. It has not worked with a purchased cert and they are still researching why. If it is a simple matter of " only trusted certs from your domain controller will work with SSL deep pack inspection" then it would be nice to have that listed in the documentation, and for their tech support staff to just tell me that.

[Rick_H · Accepted solution]

michellem812, I was sort of new to certificates when I first started messing with this as well. In case you haven' t gotten the answer you' re looking for let me explain what you' ll need to do: First, the reason the signed cert from Verisign (or from any other Certificate Authority) isn' t working is because what you actually need is a Certficate Authority cert (a sub-ca or ca as mentioned above). No public Certificate Authority will issue a sub-ca or ca level cert to a customer because it would allow that customer to sign further certificates and appear as if they were that public Certificate Authority. This would break the " trust" for that vendor. The cert you received from Verisign is likely to be a run-of-the-mill server certificate. It can be used to sign traffic for a device with a particular address only and cannot be used to sign further certs, which is what you need. The FortiGate uses the ca or sub-ca certificate to dynamically create and sign further server certificates for the hosts you attempt reach through it. The short explanation of this process is that it is an authorized " man-in-the-middle" attack on the SSL-secured traffic where the FortiGate asserts itself as the source of your traffic and talks to the remote host on your behalf. It then relays the responses back to you signed with a new cert it generated from the ca/sub-ca for that session. To acquire the ca/sub-ca cert you' ll have to setup a private Certificate Authority within your organization. Setting one of those up would take up more time than I have, but if you are in a Microsoft environment (AD2003 or greater) then the process isn' t too difficult. After you have your private CA setup you will then need to distribute the CA cert to your internal hosts so that they trust it (again, easy to do with Active Directory GPOs) and finally import that ca/sub-ca cert into the FortiGate. It seems a lot more complex than it really is. Just do some research on setting up a Private Key Infrastructure (PKI) for your organization and you' ll have the tools you need to get HTTPS inspection working. As a side piece of advice: when setting up your PKI consider having at least two CA servers. The first, the root CA, should issue a cert to the second subordinate-CA. Then shut down the first and only issues further certs from the sub-CA. This will allow you to easily revoke certificates should your Certificate Authority ever become compromised.

[michellem812]

Rick H - thanks for the clear explanation. I think for our purposes setting up the HTTPS inspection will be more than what we need, since I can do enough with the Application Control (ie, blocking https youtube and facebook). I thought with v5 that the HTTPS inspection somehow was able to work with a regular cert, but I understand now that it is still man-in-the middle and would need a private cert to really work. I will just continue with non-HTTPS utm proxy options. Thank you for the easy to read explanation.