USG 500 default SSL certificate not trusted inside LAN (on content filter warn pages)

Emerald

Hi have a issue where when users hit a site that is set to warn by the content filter (ie i have one for uncategorized) users are getting a "

Your connection is not private"

NET::ERR_CERT_AUTHORITY_INVALID

certificate error from the zywall rather than the warning webpage.

Users can proceed and do get the zywalls content filtering "Access Restricted" page

Objects > Certificates > default looks good

Any pointers please?

Emerald

Here is a example,

I hit a site and should get warning page, but i get teh error

We then get past that error to get this page (which is what we want first..)

Zyxel_Jeff

Hi @Emerald

This phenomenon is caused by when the CF detects it's an unrated website and then would redirect to the CF built-in warning page but your browser doesn't trust Zyxel device's certificate. Please refer to this link USG60 - SSL VPN connect but "this connection is untrusted, there was another user who encountered a similar problem like yours.
 



I  can reproduce it as well.


To see the certificate info.



You will find it belong to the device's certificate.




So, you can trust this link and redirect to the CF warning page. Thanks.

Emerald

Thanks for response.

When you say "you can trust this link and redirect to the CF warning page" do you mean each user would do this each time they get the issue?

My customers users need to be spoon fed, they are getting this error and calling help desk. Anyway I can stop this and only present the CF page?

- i have pushed out the default cert via group policy (no good)

Thanks

zyman2008

Here my point of view,

Anyway I can stop this and only present the CF page?

There no option to disable the CF page in Zyxel firewall.
Even though it has this option. It'll cause other kind of support call for you. 
Since users will get a blank page said, "ERR_CONNECTION ..."

To set the "Unrated" web page action to "Pass" can decrease the chance to block unknow sites and complain from users. And I think that's acceptable balance between convenience vs security.

- i have pushed out the default cert via group policy (no good)

That's the way to do without each user involved.
But without SSL inspection enabled. Users will still get the certificate warning.
Even the certificate imported into every client devices.

It's the reality the HTTPs protocol designed to protect the man-in-the-middle.
No one can broke the rule. 

Emerald

Thanks for response, and apologies in im not seeing it, i do really value the support.

I do under stand why im getting this error, ive never done SSL inspection with any router due to the difficulty of deploying certificates to endpoints. - The URL is still the desired site but he page is from the zywall.

How come all is fine on a blocked webpage warning ? see pic below, we get the blocked page from zywall with no SSL error ? (yes the url is porn.com, the page content is from the zywall, yes hte site is "not secure" but i had no issue wiht error pages prior) - whats the difference?

Based on the above - really a better work around for me would be to "block" rather than "warn" at least the users get a clear message.

Could a work around be >> I see on the "general page" i can have a Redirect URL for blocked page. Would it be a valid feature request for a redirect URL for a Waring page

Thanks in advance

Zyxel_Jeff

How come all is fine on a blocked webpage warning ? see pic below, we get the blocked page from zywall with no SSL error ? (yes the url is porn.com, the page content is from the zywall, yes hte site is "not secure" but i had no issue wiht error pages prior) - whats the difference?

Emerald

Thanks for your feedback. It seems you use http URL not https URL so won't redirect to "need to trust certificate" page. You could use https URL and try it again. Thanks.

Zyxel_Jeff

Could a work around be >> I see on the "general page" i can have a Redirect URL for blocked page. Would it be a valid feature request for a redirect URL for a Waring page

Hi @Emerald

Thanks for your idea. We already considered implementing this feature in our next-generation firewall product. Thanks.