Confirming how different certificates are used in SSL Inspection

[tanr]

Hi All,

FortiGate 300D (and others) v5.4.1. Using FortiAuthenticator 4.1.1 as local CA, among other things.

I've started running full SSL inspection on a subset of users, with my own CA certificate, which the users trust.  This all appears to work fine.  My question has to do with the two other certificates that are in use by the SSL Inspection profiles.  I didn't notice their use initially since they aren't visible in the GUI view of the SSL Inspection profiles.  From the CLI, the three certificate references are:

config firewall ssl-ssh-profile

  edit <ProfileName>

    set caname "MY_CA_CERT"     set certname "Fortinet_SSL"

    set untrusted-caname "Fortinet_CA_Untrusted"

Unfortunately, the 5.4.1 GUI only shows and lets you edit the caname certificate.  I'd like to make sure my understanding of the use of these different references to certificates is correct before I change them.  From the CLI docs:

caname - CA certificate used by SSL Inspection 

  - My interpretation - CA certificate the client trusts to allow the SSL inspection to happen without warnings

certname - Certificate containing the key to use when re-signing server certificates for SSL inspection   - My interpretation - Certificate used to sign (well, re-sign) certificates that are getting handed back to web servers on the wan. If this is the case, it is concerning because even if this certificate is SUPPOSED to be unique, it has the names Fortinet and FortiGate all over it, which I don't want to advertise.  So, I assume I just change this (from the CLI since no GUI access to this) to one of my own client certificates that is marked as being able to sign certificates?  Nothing else special needed for this cert?

untrusted-caname - Untrusted CA certificate used by SSL Inspection - I really don't know what this is for.  This didn't exist in 5.2.  Anybody familiar with this one?

Thanks in advance for advice and pointers.

[mrbbs]

Good question, I would like to see an answer on this one as well.

After having enabled DPI last week, this week we receive certificate errors with Fortigate untrusted CA for certain SSL websites.

[hmtay_FTNT]

Hello tanr, mrbbs,

Quoting your understanding: 

caname - CA certificate used by SSL Inspection    - My interpretation - CA certificate the client trusts to allow the SSL inspection to happen without warnings

That is correct. The caname certificate is used by the FortiGate to resign the original server certificate.

You understanding of certname is not correct. 

certname - The certificate whose local key pairs will be used to replace the original server's certificate keys.

E.g. 

set caname "Fortinet_CA_SSL" set untrusted-caname "Fortinet_CA_Untrusted" set certname "Fortinet_SSL"

My Fortinet_SSL has the key:

Public Key Info Key Algorithm: RSA Key Parameters: 05 00 Key Size: 2048 Public Key: 30 82 01 0A 02 82 01 01 00 B7 06 EF 5D 84 31 FC D5 58 9B F5 15 34 67 50 D7 0D 6A 0A ED E3 2A 0B 39 FC 01 44 1D 38 73 BC 7B 18 0D 3C 0D 1C EE 56 07 DC 4F 02 D6 D1 D8 36 C8 91 D4 15 94 C5 B3 CF 46 71 7E A7 54 8D A5 89 F4 F0 47 AC BA 33 32 00 17 78 11 8F 63 EF 05 42 0D 2B 03 93 B1 9C EF E4 A6 4E 4B D6 BF 23 7C 70 DD 21 87 06 66 42 A4 1B B7 45 7E BE 9E B2 11 C8 88 55 02 4D 71 E9 1C CC FD 48 62 A2 BE C5 78 0D FC 79 C5 18 D8 D1 12 A7 5E 91 C5 E4 CE 43 DB 32 61 3E 77 C0 FD 25 4E C2 99 14 E2 AF 10 B1 77 F9 C4 02 26 55 04 F0 43 EC 9B E5 6B AB BC 15 81 92 7D 6D EA C9 EF 08 80 36 44 1C C5 63 E6 D3 F7 E9 EB 63 8B F3 D3 70 D0 CD 08 51 D8 3B D7 8B D4 4E 89 63 72 DC 85 04 A2 5B 8C C5 40 D4 5E 61 DE 0D AA 29 DE 23 DC B7 04 0F D5 A9 29 D4 E7 98 37 68 3F 1E DE AD 45 61 F1 3D 42 6A CB F1 6D 7F 3B 72 6D 02 03 01 00 01

My Fortinet_CA_SSL has the key:

Public Key Info Key Algorithm: RSA Key Parameters: 05 00 Key Size: 2048 Public Key: 30 82 01 0A 02 82 01 01 00 C0 E0 41 D2 81 C3 32 37 24 2B 08 AC AD D4 6F 9C 6A CC 50 D1 D4 4D E8 87 73 45 BF 87 E3 D1 68 A0 AF A6 A4 5F FE 1C E4 F2 C1 16 54 C3 0A 26 F0 3E 51 E8 0E 34 EF BB 00 CE 7C F3 00 FC 38 8C E5 C7 B5 EF BC DA 39 76 44 E5 46 B9 32 43 4B 4D A8 DE BD 84 C9 11 CE 2E 11 7C 7B BA 87 28 29 56 21 95 7B 5F 57 A3 E5 B9 41 F3 A4 9F 6D 66 32 A4 AE 63 63 CF 61 23 C5 E2 68 37 BD 33 C5 E9 13 25 8E D8 74 B8 84 A4 15 E7 4D 29 1C 11 7C 1E E4 66 2C B3 AF 9E AA 7C 8D 31 4A E1 E2 32 20 4F 6A 7A 65 86 EB C4 60 93 F8 0A 57 5C 74 D2 EA 22 7D B0 DA 37 7C 26 B5 19 AA 1A D6 4A 76 67 5E 29 2E A0 CF F5 B2 5E 03 61 1E 31 E9 98 82 F5 06 BD 98 F6 40 CC 73 93 23 BF E6 42 89 CA 52 FE 31 7A C4 F4 3C 95 37 0F B1 BB 06 DE 3B 6D 76 93 AE E4 77 88 AB 52 FA D2 15 D9 12 7B B0 B6 FC E3 6C 1B 75 46 E5 8B 02 03 01 00 01

In the image attachment, I access the Facebook website. You can see from the certificate information, the FortiGate resigned the original Facebook's certificate with Fortinet_CA_SSL and replaced the resigned certificate's public key with the Fortinet_SSL certificate's key.

untrusted-caname - The FortiGate will use this CA Certificate if the FortiGate cannot authenticate the server certificate, e.g. untrusted root CA, expired, self-signed certificate.

Here's how you can test. Go to "https://badssl.com" and you can try out the different Certificate errors and see how it is replaced. 

The certname and untrusted-caname works only in proxy mode. I hope this explains better what the 3 lines do. Thanks!

HoMing

[mrbbs]

Hello HoMing,

Thank you for your answer on this matter.  However for me it's still unclear what the issue is and more importantly, how we can solve it.

Regularly I hear from users that search results within google.com are not reachable anymore, 10 minutes later they're again. 

They also can't login to certain HTTPS website of suppliers.

If I go and check the certificate then it's always Fortinet Untrusted CA:

On the portal of Office365 from Microsoft the site is protected by the Fortigate CA.  You can login but as soon as you want to list content (like Active users) the site fails with an internal server error.

When I disable the policy for deep ssl inspection I can list those users.

So apparently still some issues to be tackled before we can use this in production.

Cheers,

Kevin

[hmtay_FTNT]

Hello Kevin,

There's a few reasons that could cause the problems you have. We may need to check your configuration to find out what causes deep-inspection to fail. Here's some of the main reasons why they might not work.

1. If you are using proxy-mode inspection, try to maintain the latest version of any 5.x branch. E.g. if you are using 5.2, use the latest 5.2.xx branch and the same for 5.4. Many of the big Internet service providers constantly experiment with new protocols. This is especially true for Google. In the past year or so, they have introduced new cipher suites that we have to add support for. Without the new OS or IPS Engine (will explain in point 2), the FortiGate will not be able to do the decryption.

2. If you are using flow-mode inspection, you want to use the latest stable IPS Engine. In flow-mode, IPS Engine does the SSL decryption.

3. Did you set "Untrusted SSL Certificates" to Block? 

Can you send me a packet capture when you run into the internal server error on Office365? I will check and see why did the session fail. Thanks!

HoMing

[mrbbs]

Hello HoMing,

Thank you for your answer and sorry for the late reply.

I upgraded today to the v5.4.4 from v5.4.2 and it solved the Office365 problems.

Good to know we should keep updated on the latest firmware versions.

We are indeed using Proxy mode inspection but no IPS.

At the moment we are testing google search results, as sometimes these results were available and sometimes they were not.  I'm awaiting the feedback of our test group later this week.

At the moment we still have issues with https://admit.proximus.be

It has an SSL certificate provided by Globalsign nv/sa

I changed the setting to block untrusted SSL certificates to block.

I keep you updated on further findings.

Thanks for the follow up!

Kevin

hmtay wrote:

Hello Kevin,

There's a few reasons that could cause the problems you have. We may need to check your configuration to find out what causes deep-inspection to fail. Here's some of the main reasons why they might not work.

1. If you are using proxy-mode inspection, try to maintain the latest version of any 5.x branch. E.g. if you are using 5.2, use the latest 5.2.xx branch and the same for 5.4. Many of the big Internet service providers constantly experiment with new protocols. This is especially true for Google. In the past year or so, they have introduced new cipher suites that we have to add support for. Without the new OS or IPS Engine (will explain in point 2), the FortiGate will not be able to do the decryption.

2. If you are using flow-mode inspection, you want to use the latest stable IPS Engine. In flow-mode, IPS Engine does the SSL decryption.

3. Did you set "Untrusted SSL Certificates" to Block? 

Can you send me a packet capture when you run into the internal server error on Office365? I will check and see why did the session fail. Thanks!

HoMing

[mrbbs]

Hi HoMing,

It seems that my last reply isn't posted.  So I try to repeat my findings.

1. We upgraded to v5.4.4 and the google search problems and the problem with Office365 is resolved. Now we know it is critical to follow the latest firmware versions to have the certificates updated.

3. We have changed and set "Untrusted SSL Certificates" to block.

Meanwhile the issue with the *.proximus.be website is still present.  I even added *.proximus.be to the exemption list but IE is displaying a certificate warning where you can normally continue to the site.  But if you click continue it keeps searching for the site but is stuck on this page.

Any suggestions how we can resolve this last issue?

Kind regards,

Kevin

[hmtay_FTNT]

Hello Kevin,

Glad to know some part of the problem is solved. Now, the case with https://admit.proximus.be is unusual. Back then, when I looked at your old posts, I thought it was weird that the Fortigate would put it under "Untrusted". On my side, when I traced the Certificate up to the Root CA, my Fortigate does have the Root CA's public key in the Trusted list. And when I do a live test, mine was okay.  Can you send me your configuration file and a packet capture when you try to access the site? You can PM me those files. Can you let me know which policy ID are you using too? I will see if other policies overlap and might have been the source of the problem. If you exempted the link, it should not intercept the certificate. Thanks.

HoMing

[hmtay_FTNT]

Kevin,

I get a different result when I try to access "secure.proximus.be". When I looked at the original Root CA list, the Root CA should be trusted by the FortiGate trusted list. Can you get me a packet capture when you try to access that site without deep-inspection? I suspect that maybe the server returns a different certificate based on location.

[mrbbs]

I've just sent you a PM with a link to the logfiles.