Connecting to my customer's GP vpn, most of my browsers display NET::ERR_CERT_AUTHORITY_INVALID

[charliegil]

In the not too distant past, I could fire up my customer's vpn allowing me to access their network while maintaining my own.  In other words, I could surf my development sites, get my business' email, and basically function while working.  Something changed, and now when I enable their VPN, 95+% of my network connections report:

"Your connection is not private

Attackers might be trying to steal your information from globalprotect.customer.com

NT::ERR_CERT_AUTHORITY_INVALID"

I only see this behavior on any machine that is not a member of their domain.  In fact, I have seen this coming from their globalprotect.customer.com.  My support ticket with corporate IT has been open for 2+ months.  I'm not hopeful of a resolution.  I've spoken to others in local IT support, and they have the same issue, but they just shrug their shoulders.

Anything I can check?  It smells like a configuration in the back end, but I'm looking for some suggestions I can feed back to them.

[charliegil · Accepted solution]

I knew this would happen.  Company puts up LIVEcommunity as a teaser.  No support whatsoever.  VMware is just as bad.  Please, God, give me PulseSecure.

[Adrian_Jensen]

This is the community support forum, which is monitored by some PA support employees, but is not support. Simple facts... yes first line PA support sucks... If you have opened a ticket with PA support and it hasn't been answered in months then harass support/your sales person and get it escalated. If you don't have a support contract then they aren't going to respond to you.

As for your particular question... It sounds like you are on someone else's business network who is running a PA firewall and your laptop is not part of their domain/not managed by them. It also sounds like they have enabled SSL decryption on the firewall. This decrypts most/all SSL traffic passing thru the firewall, between the client and server, so the PA can inspect the data for URL/content filtering, threats, malware/viruses, etc. It does this by breaking the SSL between you and the server and re-encrypting it with a SSL certificate generated by the PaloAlto. Your browser correctly identifies that the SSL certificate does not have a valid CA authority because your laptop only has known public CAs.

SSL decryption on the PaloAlto is done by creating (or using an existing) corporate root CA. This internal CA is then distributed to all the PCs as a trusted root CA authority (usually via the AD domain). When the client makes a connection to "www.example.com" the PA intercepts the connection, initiates a SSL connection to the destination server itself, and then re-encrypts the internal connection between the client and firewall with the corporate CA. The client trusts this connection because it knows this internal CA, but your laptop does not because you only have public CAs.

You can verify this by examining the SSL cert delivered to your PC when you go to "www.example.com" on the internal network. The certificate signer will be something like "ExampleCorpCA", instead of a well known CA like DigiCert/Entrust/NetworkSolutions/etc. If so then Example should be able to provide you with their corporate root CA certificate (and possibly intermediaries CA) to load into your own trusted certificate store. If Example is choosing to decrypt traffic passing thru their firewall... then that is on them.