Recently, I've seen an issue where if we use a computer that has its traffic routed through the PAN NGFW, we will get an error message from the website saying "Your connection is not private" with an error code: NET::ERR_CERT_COMMON_NAME_INVALID.
This happen to 2 different websites I've seen so far. When we looked at the certificate it looks like the certificate of the websites are expired.
However, the weird thing is that when the traffic is not routed through the firewall, for example, using a different computer and network, we are able to access those websites just fine with valid certificate.
The URLs that we encountered this issues are:
Please kindly let me know if you have experienced this issue before and how do you fix it.
In addition to what @OtakarKlier mentioned, when you're decrypting traffic you'll find that you have to manage certificates on the device a little bit for some providers. The firewall has a default list of trusted certificate authorities, but it doesn't trust everything that your browser will as an example. You might have to actually import the issuing CA certificates and mark them as trusted.
Hmmm... that is kind of an interesting failure... When connecting to zetta.net.au from behind the PA you get a certificate with a wildcard CN subject of "*.highway1.com.au" that expired Nov 5 2017 (hence the COMMON_NAME_INVALID error, it would also fail for certificate expiry). When connecting from a different ISP not behind a PA you get a certificate with a CN of "www.zetta.com.au" and an alternate name of "zetta.com.au", which is signed by Lets Encrypt and has an expiry of Dec 17 2022.
It looks like the server is giving out different certificates based on the client source and one of those certificates is expired/incorrect for the host. The certificate valid from/to dates should be passed thru the PA with decryption enabled, but the zetta.com.au certificate shows completely different dates. Checking another server I have that is signed by the exact same Lets Encrypt CA, both behind and separate from the PA show the exact same certificate dates and the Lets Encrypt signed cert decrypts behind the PA without issue. So it seems to not be a PA known CA authorities issue.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!