How to configure per-client certs on GlobalProtect?

[dannyman]

NOTE: the freeware pfsense firewall can configure a working VPN with user passwords and user certs (2FA) inside of 20 MINUTES. With Palo Alto Networks, I'm on WEEK 6.

Where I am at:
1) I have GlobalProtect working with password auth. (Had to call tech support, who knew what steps were missing from the documentation.)
2) I want to have 2FA: so, I spun up a CA (easy-rsa) to provide a CA cert, and generate per-user certs. (pfSense will just do this for you in the GUI, but I did the process described here: https://openvpn.net/index.php/open-source/documentation/howto.html#pki)
3) I can get password + cert working with the unsupported Linux client. (https://github.com/dlenski/openconnect)

4) I can get password + cert working with the unsupported Linux client, using either my personal cert, or another user's personal cert. (WTF?)
5) We have tried and tried and tried again to "import" a personal cert on MacOS but anywhere we import a cert with the "Keychain Access" app GlobalProtect comes back with the same error: "The client certificate to establish the GlobalProtect connection was not found." 

Our client certs have Subject fields that look like this:
User=user1:
Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=user1/name=VPN/emailAddress=ops@example.com

User=user2:
Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=user2/name=VPN/emailAddress=ops@example.com

Questions:
A) How in the name of all that is good do you get a user cert imported on MacOS?
B) My Certificate Profile is configured for Username Field: Subject (common-name) ... what should I have in there?
C) Or, are my cert Subject's in a form that won't work for GlobalProtect: what should they look like?

Thanks,

-danny

[dannyman]

Some progress, maybe:

In the Gateway config, on the Agent tab, there's an option to add a Trusted Root CA and check "Install in Local Root Certificate Store" which seems to help convince the Mac Keychain Access app that the certificate I am supplying is legit.

Per this article, the CN needs to match the Gateway, so my certs now read:
Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=vpn.example.com/name=user1/emailAddress=user1@example.com

The client error now reads:
Ganteway VPN-MTV: No valid certificate found. Please contact your IT administrator.

[dannyman]

I dug up the GlobalProtect logs on the client and found a message that the SSL service profile on the gateway was different from the root CA I was pushing from the portal. This is true, as it was using our comodo cert. I created a new cert for the gateway which is signed by my local CA, and did up a new SSL service profile, and now that error is gone. I can load any number of certificates onto the client Mac OS that are viewed as valid because they are signed by my CA. However, none of them ever get picked up by the GlobalConnect client and all I ever get on the Mac is a gateway error: No valid certificate found.

So, I'm stuck back where I have been.

[Mick_Ball]

Hi @dannyman

I'm not sure how using username and password plus user cert works on the PA.

we do have Mac's and IPads connecting with the above but have username/password  plus a device cert, not a user specific cert.

the certificate profile "username field" is set to "none".

going back a few years we did have issues trying to mix with both,

it may be just trying to set the cert profile to "none" to see if you still get the error.

are you only getting the errors on the gateways and not the portal.

[dannyman]

@Mick_Ball yes if I Certificate Profile == None then I can LDAP Auth just fine.

Maybe the way to do this is to try turning off LDAP Auth and see if I can get Cert Auth working on its own, then turn LDAP back on.

[Mick_Ball]

What i meant was not set cert profile to none but go into the cert profile and Change the "username field"  to "none". Instead of common name etc....

you may have done this and i misunderstood previous post

[dannyman]

Oh yeah, I have tried that and just tried again. Even with Username none, the Mac client cannot find a certificate. The only way to get this working is to disable Certificate Profile. I have yet found no circumstances under which the Mac client finds a certificate which it will try to use with the server.

The Linux openconnect will, of course, use any signed cert you pass to it on the command line, and if username is configured in the Certificate Profile, any certificate with or without a matching username will be accepted.

[dannyman]

Q: How do I get the certificate to be read by the GlobalProtect client on MacOS?

A: The key will only be used by Mac GlobalProtect client IF CN=<IP address of the gateway>.

A: Import the key to the system using PKCS12 instead of PEM. (Source: Step C)

In my case:
openssl pkcs12 -export -out user.pfx -inkey user.key -in user.crt -certfile ca.crt

One problem down . . .

[dannyman]

To better understand how this work, I have disabled LDAP Auth on the GW. Given a key like this:

Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=65.50.203.123/name=user1/emailAddress=user1@example.com

IF Certificate Profile Username: Subject (common-name), THEN user is listed as the IP address in the CN.
IF Certificate Profile Username: Subject Alt (Email), THEN user is listed as the IP address in the CN.
IF Certificate Profile Username: Subject Alt (Principal Name), THEN user is listed as the IP address in the CN.
IF I delete the key from the client and import one with a different CN, THEN user is listed as the IP address in the previous CN.

I figured out the "GlobalConnect Service" is still running between tests, so now when testing I reboot the Mac between tests. (This is faster than the PAN Commit process.) At this point, I can not replicate connect-with-certificate-only.

I suspect that the best PAN might support is user password auth plus valid certificate that does not map to a user.

[dannyman · Accepted solution]

PALO ALTO NETWORKS SECURITY VULNERABILITY: GlobalProtect 2FA password + certificate does not verify that certificate matches user

Reboot-between-experiments ... load up a virgin System ...

Certificate Profile > Username Field: Subject

Gateways > Authentication > Client Authentication *none*

User key like this:

Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=djh/name=Daniel Howard/emailAddress=djh@example.com

Mac GlobalProtect will load the key in PKCS12 format.
User shows up as djh.

*****

Certificate Profile > Username Field: Subject

Gateways > Authentication > Client Authentication *LDAP*

Mac GlobalProtect will only let me log in as the user in the CN on the certificate.

This achieves 2FA:

• User needs to have their SSL cert.
• User needs to know their password.

On the unsupported Linux openconnect client, I can log in with any signed cert. There is no server-side enforcement that the user matches the certificate. This is a surprising vulnerability in a security product: that we rely on a client to enforce the server's authentication credentials.

[Mick_Ball]

you have been busy,,, nice one.

prepare to hit a wall.....

if using client auth profile you will need to set cert profile username field to none....

however... not sure what would happen if cn in cert is the same as the ldap username.

I need to ask.... do you need this to work. seems a bit odd identifying the user name twice...

i would have thought that ldap + device cert would suffice. 

[santonic]

@dannyman

I see that you succesfully setup user auth with client certificates and LDAP, where username matches LDAP login. I succeeded in that as well.

Did you do any testing with Subject Alt - Email? because I have situation where I can't control CA and can't put LDAP usernames in certificate subject. However each certificate has email in subject alternative name attribute. But no matter what i select, PA keeps using subject field as username. Tested on 8.0.8 and 8.0.10.

[dannyman]

@santonic I tested your very question out on the previous page. All I got to work was having the CN match the username.

Alternatively, you can run a patched version of openconnect, which doesn't enforce username matching.

https://github.com/dlenski/openconnect

Caveat: in my opinion, that GP is relying on the client to enforce an InfoSec rule is a bug. After some run-around, Palo Alto agreed that this was a bug, so they might fix it one day if they haven't already.

[santonic]

Ok ty. Seems it is a bug then. But I would hope they would fix it since November. Especially as it seems to me they only need to read different field from cert.

I'll open a case to see if any progress has been made on this.

[Guillermo1234]

Exactly the same behavior in 2022 with PAN-OS 10.1.6-h6.

Something that I find strange is that I do not need to upload the certificate of the client/machine to the FW