Global Protect won't allow login with error "Valid client certificate is required"

VPN
1

I’m very new to Palo Alto’s, work mostly with Sonicwalls.
We inherited a PA-220
A few end users use GlobalProtect (GP) for VPN. GP has internet facing portal that recently had its public SSL cert expire. Took me a very long time to figure out how to get that re-keyed and reapplied but that’s good now. Browsers show active external-CA signed SSL cert for the GP portal.

Unfortunately, now when users go to GP portal they’re faced with “Valid client certificate is required” error. I know this is due to needing a certificate on the endpoint certificate store, but I’ve exported a copy of every cert on the Palo Alto and imported into my personal store and I continue to get the error.

Anyone know what I’m missing?

https://preview.redd.it/eitttwhawgca1.png?width=675&format=png&auto=webp&s=68b9f6fb326a52d0d46df55a68fff616d60fce4c

2

looks like you’re using certificate auth. You need to read up on how cert auth works on paloalto, There are a lot of KB articles showing the examples.

3

I did try that, and while it works, I’m concerned that having one form of authentication without the cert would be a security risk. I appreciate your response :blush:

4

I remember the basic principles that I learned in my sec+ cert a couple years ago. maybe I need to re-read lol

5

Disable the cert. option on GP Portal.
You only need SSL/TLS Profile to present an SSL cert on the portal.

The other certificate option (under Authentication tab) are related to validating client certificates.
Portal: User cert
Gateway: Machine cert

6

Prior to the certificate expiring, was everything working?

What certificate profile do you have setup for authentication? Are they certificates issued from your internal PKI, or are the certs all locally generated on the firewall?

7

In the auth settings for the portal there is an AND / OR question about requiring:

  1. cert and user/pass
  2. cert or user/pass

You could sent it to OR, but I think the question is, did you intend to have AND when you built it? It’s much more secure then OR.

8

Probably the best question to ask in this moment is how familiar are you with how TLS or asymmetric encryption works?

9

Adding to this before that cert gets exported - exporting the cert from the cert auth profile and importing it won’t resolve. You will need to have a cert generated, with the associated private key, from the authority used for the cert auth profile on the local workstation.

Reviewing the docs AND having basic to mid PKI knowledge will be crucial to this implementation. I’d suggest getting with your AD/domain team for assistance as well.

10

Believe you might have responded to the thread instead of me (at least the response makes sense).

Gonna provide a bit of a crash course below:

So the fundamentals of asymmetric encryption relies on two sets of keys, the public key that anyone can see and the private key which is (or is assumed to be) a secret to anyone outside of the owner . These keys are linked together via the magic of math. This is generally seen as x509 based certificate keypairs in the wild.

In a basic TLS session (very very broadly), a connection will be formed using the following sequence:

Jill wants to send an encrypted message to Bob.

Jill uses Bob’s public key (from his accessible certificate) to encrypt the message.

Bob receives the encrypted message, and decrypts it with his private key.

This is grossly over simplified, but it explains it in a rough and understandable way. In the wild… You see encrypted sessions set up this way all the time. When you access your GP portal webpage, Google, ect, your workstation is using the offered public key to establish this connection as long as the certificate is from a source your system trusts (the certificates you’ve been exporting and importing into your workstations CA trust folder).

What’s happening on your GP tho (I’m guessing) is that the session is requiring two-way proof of identity from the workstation using the certificate authority that’s been assigned in the GP portal config. By this I mean… The firewall proves it is who it says it is using a certificate key-pair, and then the workstation does the same (with a certificate key-pair that was issued from the expected CA).

Double check your config to see what’s currently set up as the expected CA for the portal, and then double check your workstation (making sure you open up certificate management in a machine context) to make sure there’s a properly configured certificate from that CA installed on it.

There’s a bunch more I didn’t touch on, but this should be at least a starting point for you.

11

Unfortunately I’m not sure. I came into the ticket kind of halfway and the documentation leaves much to be desired.

I do know GlobalProtect was set to require both a cert and a username/password before I started messing with things. I’m wondering if maybe previously it was set up as a local CA and individuals were given certs signed by the Palo Alto itself. I may’ve deleted the local CA inadvertently while troubleshooting the externel CA not working.

12

I did see the AND/OR but I just don’t feel comfortable leaving it on OR. I have to either figure out these Certs or use another MFA method like Duo.

13

Log into the admin interface and go to device - - > Certificates, if all of your client certs are listed there then the 220 is the CA and is issuing them, if not then they’re coming from an external (to the firewall) source

14

You could also load a previous version of the config without committing to see if the certs on there. The firewall keeps a bunch on record. Just go back to an older date.

15

What is there is what I’ve added myself, which is the SSL CA that I chose to purchase from, along with the cert that they issued nested under it. That covers the web facing page.
I guess my question is, does that cert have anything to do with the one that is issued to end users to connect to VPN? Or is that key pairing completely different than the SSL CERT that I purchased?

16

That cert is separate. Look in Device > Certificate Management > Certificate Profile. What certificate profile are you using for auth? Is it from your internal PKI? What username field are you looking for? Who issues the actual user certificate and key to the endpoints?

17

The Cert Profile is using the external CA cert that I used for the web-facing GP portal. Username Field is ‘none’.

Ideally I would want the Palo Alto to just be a local CA and issue the certs that I can import into the cert stores of the VPN devices.

18

Hmm, and you’ve double checked that the endpoints have a certificate/key in their cert store from that CA? Is it a well-known CA? Do they have that certificate as trusted in their trusted root CA?

If you want to build the certs locally, you can following along with this video, but that will be a lot of overhead > https://www.youtube.com/watch?v=TFstISND5PE

If you ever want to sync up after hours (I’m in the US) I would be happy to take a look at your setup if you get stuck.

19

Thanks man, I really appreciate it.