Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 23 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 81743 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Certificate Warning with https set to "URL filtering only"

kdessis
Hi guys,

we installed a new system in a VM at a customer.

Enbaled Webfilter set to transparent mode and set HTTPS scan settings to "URL filtering only". This should normally not produce any certificate warnings... but IT DOES.
Any client who accesses a secure site gets a warning shot in the browser.
I disabled, enabled webfilter, restared the GW.. always same strange bahviour...

The only way at the moment is to enable "Do not proxy HTTPS traffic in transparent mode" but thats not what we want... 

...any ideas??

Cheers, kdessis


This thread was automatically locked due to age.
Parents
  • 0
    Hi there,

    all my customers  that do not use full https scanning have also these issue. I can't understand, why sophos says that is not a bug. The issue occurs because the error page is called by https://paththrough.host.domain.tld/static/logo.png

    All customers who want to use the web protection must rollout the utm ca certificates in their active directory domain.

    For me, that is absolutly a bug.
    €dit
    or must import the ca certificate in the local browser.

    regards
    mod
  • 0 in reply to mod2402
    .....
    All customers who want to use the web protection must rollout the utm ca certificates in their active directory domain.


    Another solution (easiest one) is to import certificate of internal AD CA server (if present) to UTM.

    Not a bug, UTM uses MITM not only for SSL decrypt and scan, but also for other things.  This post was from Michael Dunn, that I saved in my KB:

    The UTM uses HTTPS to provide user notification, perform browser authentication and secure other user interactions. By default, the UTM uses an automatically generated certificate for these HTTPS connections:
    o If the user requests an HTTP page and the proxy must interrupt (eg show a block/quota page) then it send the block page on the HTTP connection.
    o If the user requests an HTTPS page and the proxy must interrupt (eg show a block/quota page) then it send the block page on the HTTPS connection. It must MITM even if HTTPS scanning is off.
    o The only exception to this is some authentication where the initial request is HTTP but we switch it to HTTPS.
    o Note: if we do MITM in order to show a block page (quota warn, etc) it is only for that page display. Once they are back at the real site it will be using the real Certificate again.
    o For HTTPS we really don't have much other option. The only other thing we could do that would not involve MITM is just drop the connection without sending any page back to the user. For transparent mode that might end the browsing timing out and displaying a "cannot connect to server" error.
Reply
  • 0 in reply to mod2402
    .....
    All customers who want to use the web protection must rollout the utm ca certificates in their active directory domain.


    Another solution (easiest one) is to import certificate of internal AD CA server (if present) to UTM.

    Not a bug, UTM uses MITM not only for SSL decrypt and scan, but also for other things.  This post was from Michael Dunn, that I saved in my KB:

    The UTM uses HTTPS to provide user notification, perform browser authentication and secure other user interactions. By default, the UTM uses an automatically generated certificate for these HTTPS connections:
    o If the user requests an HTTP page and the proxy must interrupt (eg show a block/quota page) then it send the block page on the HTTP connection.
    o If the user requests an HTTPS page and the proxy must interrupt (eg show a block/quota page) then it send the block page on the HTTPS connection. It must MITM even if HTTPS scanning is off.
    o The only exception to this is some authentication where the initial request is HTTP but we switch it to HTTPS.
    o Note: if we do MITM in order to show a block page (quota warn, etc) it is only for that page display. Once they are back at the real site it will be using the real Certificate again.
    o For HTTPS we really don't have much other option. The only other thing we could do that would not involve MITM is just drop the connection without sending any page back to the user. For transparent mode that might end the browsing timing out and displaying a "cannot connect to server" error.
Children
  • 0 in reply to vilic
    Another solution (easiest one) is to import certificate of internal AD CA server (if present) to UTM.

    Not a bug, UTM uses MITM not only for SSL decrypt and scan, but also for other things.  This post was from Michael Dunn, that I saved in my KB:

    Hi vilic,

    yes this is one solution for managed clients. But what about smartphones, tablets, MACs and other unmanaged devices?

    Normaly you should never import a ca certificate with private key from another ca into the utm. The right way is, use an underlaying issuing ca just for the utm.

    The unmanaged devices are a big problem. They need a manual import. The user portal can not provide the webadmin ca cert (default config) or the VPN signing ca cert (with configured custom end user certificate).

    I can't understand why the blockpage must called over https...

    For me, this is a bug.

    regards
    mod
  • 0 in reply to mod2402
    I can't understand why the blockpage must called over https...

    My guess: because the original request was done over https. The UTM can't just send back http data over port 80 where the client is expecting a https response from server port 443. Something like that maybe? Could be completely wrong so don't take my word for it.. [:P]
  • 0 in reply to InformaticaOostkamp
    My guess: because the original request was done over https. The UTM can't just send back http data over port 80 where the client is expecting a https response from server port 443. Something like that maybe? Could be completely wrong so don't take my word for it.. [:P]


    Hi icto,

    this is not a response to the original request. This is a new generated request just for displaying the warn / block message.

    regards
    mod
Unfiltered HTML