cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
Highlighted

Problem with HTTPS Inspection

 

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

0 Kudos
3 Replies
Highlighted

Re: Problem with HTTPS Inspection

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

0 Kudos
Highlighted
Admin
Admin

Re: Problem with HTTPS Inspection

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:

Screen Shot 2020-04-04 at 8.29.40 PM.png

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

0 Kudos
Highlighted

Re: Problem with HTTPS Inspection

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