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:
Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=user1/name=VPN/emailAddressemail@example.com
Subject: C=US, ST=CA, L=Menlo Park, O=Quantifind, OU=Ops, CN=user2/name=VPN/emailAddressfirstname.lastname@example.org
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?
Solved! Go to Solution.
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/emailAddressemail@example.com
The client error now reads:
Ganteway VPN-MTV: No valid certificate found. Please contact your IT administrator.
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.
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.
@MickBall 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.
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
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.
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 . . .
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=188.8.131.52/name=user1/emailAddressfirstname.lastname@example.org
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.
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/emailAddressemail@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:
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.
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 Live Community as a whole!
The Live Community thanks you for your participation!