XG 230 SFOS 16.01.1 Web Policy Certificate Error

Matt,

are you getting the certificate error with the ip or by name?

Can you share a screenshot?

Thanks

The error comes up with the IP.  The policy warning page comes up fine (screenshot below), but after clicking proceed, you are directed to the page with the certificate error(screenshot below).

Thanks for you help.

Matt,

as you can see the Browser knows that is requested facebook and the certificate returned is from another ip address (XG firewall), so the browser is telling you a probable main the middle attack.

With Firefox, it works! I am not sure about Internet Explorer how to fix it!

I was able to get the problem to go away by generating a self signed cert, trusting that cert, and changing the firewall to use that cert for the admin page & user portal.

There are two certificates involved.

The first is that in order to do man-in-the-middle, the XG is a Certificate Signining Authority and will generate certificates on the fly.  You need to install the CA onto the box as a trusted authority, and this is seperate for IE and FF (they have their own storehouses).

The second is that some on-box pages (such as WebAdmin, User Portal) use a certificate.  This is a single certificate that you need to trust.  By default it is a self-signed cert, but you could generate and upload your own.  Note that if you do things like change the hostname, you may need to regerate the certificate to match the new hostname - which means you need to trust the new one.

There are two certificates involved.

The first is that in order to do man-in-the-middle, the XG is a Certificate Signining Authority and will generate certificates on the fly.  You need to install the CA onto the box as a trusted authority, and this is seperate for IE and FF (they have their own storehouses).

The second is that some on-box pages (such as WebAdmin, User Portal) use a certificate.  This is a single certificate that you need to trust.  By default it is a self-signed cert, but you could generate and upload your own.  Note that if you do things like change the hostname, you may need to regerate the certificate to match the new hostname - which means you need to trust the new one.

Thanks for the input Michael.  So as of right now I have resolved the issue for my internal domain users.

I would really like to have this working without errors for our guest users who connect through wifi, but as far as I can tell the guests would have to trust the XG as a certificate signing authority. This means the only way I can implement a web policy without errors on our wifi network would be to install our certs on any guest users.  That would be a bit crazy. 

Please let me know if I am missing something here.  I appreciate the help.

Matt

HTTPS decryption is basically that you intercepting and looking at all encrypted traffic.

There is no way of doing that to your guest wifi without those users knowing and allowing it either by installing a CA or excepting every access.  That is the whole point of https - no one can snoop on your traffic without you allowing it.

So as an admin you will have to balance - how much security do you want versus how much intrusion your users can accept.  If your guest wifi is like an starbucks and your users are all the general public, then maybe you will choose to not decrypt and scan their traffic.  If your guest wifi is a BYOD for your office and all your users are employees, maybe you want to enforce it.