Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
BK_LGW
New Contributor

Cert Error - SSH Inspection (FW Cert Has Been Installed On PC)

Hello all. Web filtering with Full SSL Inspection, we've deployed the FW default certificate to end user PCs and for the most part inspection runs without a hitch. Sometimes however we get a cert error like the one I've attached (I was testing to make sure the FW completely kills UltraSurf). The certificate says it's from *.fortinet.com when it should say it's from "ultrasurf.us" or whichever website the user was trying to get to in the first place. Why does this happen? I'd appreciate any guidance you can offer.

 

10 REPLIES 10
hubertzw
Contributor III

There are some web servers which don't let you decrypt the traffic. You can verify it by accessing the same URL using Edge or IE, they don't support HKPK (HTTP public key pinning). You can force users to use web browser which don't support this feature or add the URL to the exemption list

Bromont_FTNT

You said you want to block ultrasurf.us right? So basically the Fortigate is trying to show the Blocked Page which of course would have the Fortinet certificate but the browser is expecting ultrasurf

BK_LGW

hubertzw wrote:

There are some web servers which don't let you decrypt the traffic. You can verify it by accessing the same URL using Edge or IE, they don't support HKPK (HTTP public key pinning). You can force users to use web browser which don't support this feature or add the URL to the exemption list

Thanks for the reply. I hadn't considered HPKP. I did try it in other browsers but it failed there as well. We also had a user encounter this problem with www.youtube.com and I'm assuming they allow us to decrypt. 

hubertzw

You said you tested it with different browser. Do you see the same error? Do you have Fortinet CA uploaded to all Internet browsers? Firefox and Chrome have different locations.

BK_LGW

I've tried it with both the default cert shipped with the FW (which has been deployed to the PCs via GPO, and in Firefox's own store). I also used a cert from our internal enterprise CA which was already trusted by all our domain joined PCs. My following tests will be using the enterprise CA cert which also works. My test at the moment is going to Google and searching for "gambling websites" and "porn websites" since I know it should block these. I then try to browse to them. I've done that across all the browsers available: Chrome, Firefox, Edge, IE. My observations thus far:

[ul]
  • Some websites are allowed because they're not categorized as gambling - that's fine. will handle another day.
  • Some websites are properly blocked - and the cert is issued with path SUBCA (enterpise) - FW - hostname of site that was blocked (e.g. https://m.casiplay.com)
  • Some websites throw Insecure Connection - CN-invalid; the *.fortinet.com is used in the cert and doesn't match the hostname of the "blocked" site so I get that error but why does fortinet.com show up? And why does it seem to be random? 
  • The porn ones all seem to throw the CN-invalid error so is it that they all use HPKP as well? I tried all browsers and nada. [/ul]
  • hubertzw

    Probably you do full inspection with Fortinet CA, the only problem is why it can't generate correct copy of the original server certificate. If you see once internal CA certificate and sometimes the internal CA it means you have 2 polices, is that correct?

    HPKP is supported by some web servers, the feature is not commonly implemented.

    emnoc
    Esteemed Contributor III

    Use curl with the "-v" and look at the cert issuer or the . HTTPS lock in your browsers. If the  issuer and web-server cert are showing fortinet for the issues or what ever is in your . rootCA  CN that means the fortinet is MiTM. Now if the web-server cert is showing "cn=*.fortinet.com" you have something else going on.

     

    if you get in front of the FGT what does the  website cert show ? is it trusted and all intermediate certs are present ?

     

    HTTP pinning is a issue but in reality it's being phased out in the internet community. You can check for original website and any Pining in the server responses. I would be very doubtful a porn web-site is using http key pining fwiw.

     

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    emnoc
    Esteemed Contributor III

    * SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305

    * ALPN, server accepted to use h2

    * Server certificate:

    subject: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=sni.cloudflaressl.com

    *  start date: Oct 18 00:00:00 2018 GMT

    *  expire date: Oct 18 12:00:00 2019 GMT

    *  subjectAltName: host "ultrasurf.us" matched cert's "ultrasurf.us"

    *  issuer: C=US; ST=CA; L=San Francisco; O=CloudFlare, Inc.; CN=CloudFlare Inc ECC CA-2

    *  SSL certificate verify ok.

    * Using HTTP2, server supports multi-use

    * Connection state changed (HTTP/2 confirmed)

    * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0

    * Using Stream ID: 1 (easy handle 0x7fad86002c00)

    > HEAD / HTTP/2

    > Host: ultrasurf.us

    > User-Agent: curl/7.54.0

    > Accept: */*

    PCNSE 

    NSE 

    StrongSwan  

    PCNSE NSE StrongSwan
    BK_LGW
    New Contributor

     

    emnoc wrote:

    Use curl with the "-v" and look at the cert issuer or the . HTTPS lock in your browsers. If the  issuer and web-server cert are showing fortinet for the issues or what ever is in your . rootCA  CN that means the fortinet is MiTM. Now if the web-server cert is showing "cn=*.fortinet.com" you have something else going on.

     

    if you get in front of the FGT what does the  website cert show ? is it trusted and all intermediate certs are present ?

     

    HTTP pinning is a issue but in reality it's being phased out in the internet community. You can check for original website and any Pining in the server responses. I would be very doubtful a porn web-site is using http key pining fwiw.

     

    Thanks for your reply, emnoc. Getting from behind the FGT will be a little tricky but I can do that and get back to you. It usually does result in fully trusted cert chain whenever I disable SSL inspection on my test rule and of course, the website can be freely visited. I'll attach a pic showing the HTTPS info as requested. Please let me know if anything else will help you help me.

     

    Another weird thing: I realize all my attempts that fail in this manner are trying to go to a 208.91.112.55 IP address. In fact, when I use nslookup on ultrasurf.us or rarbg.to or thepiratebay.org they all return that IP address. Curious since our DNS server doesn't have a specific entry for that IP address.

    Labels
    Top Kudoed Authors