topic Re: Problem with HTTPS Inspection in Firewall and Security Management

Problem with HTTPS Inspection

Ricardo_Galvan — Fri, 03 Apr 2020 15:39:40 GMT

Good Morning,

I am having an issue with HTTPS inspection and the user check page.

I have set up inbound/outbound in our DR envrionent successfully, I am now working on our production environment, however I am running into the following error.

when I go to any https site the inspection works correctly I get our ca issuing the cert more or less as the man in the middle and the site opens with no errors, when I go to any site which is subject to URLF or APC I get the following error,

SAN cert is in place, this error is on all browsers
Your connection is not private
Attackers might be trying to steal your information from dcfw-private.xxxx.net (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID

when I click on the Advanced the following error

This server could not prove that it is dcfw-private.xxxx.net; its security certificate is from dcfw.xxxx.net. This may be caused by a misconfiguration or an attacker intercepting your connection.

Keeping in mind, I configured everything the same including the SAN cert except for the names and IP's. All certs look the same with SAN, CN, Subject they have the same path with all the same Certs inline

Re: Problem with HTTPS Inspection

_Val_ — Sat, 04 Apr 2020 09:38:52 GMT

Are you using the same certificate for both inbound and outbound? The issue you are having, which direction it happens with?

Re: Problem with HTTPS Inspection

PhoneBoy — Sun, 05 Apr 2020 03:31:33 GMT

Because you're not getting a certificate generated by HTTPS Inspection in this case, you are getting the UserCheck certificate, which by default is a self-signed certificate.

You can replace this certificate with one signed by a CA the end user browser already trusts from here:

Otherwise, you will have to configure the end user browsers to trust this self-signed certificate.

Re: Problem with HTTPS Inspection

Ricardo_Galvan — Mon, 06 Apr 2020 13:08:26 GMT

thank you all for assistance in figuring this one out..

all certificates are correct and in the correct location on the gateways and machines. this was a self inflicted wound. we have two FQDN's resloving to the same IP when only one is correct for the portal to work correctly.

Ric