Issues using Elliptic Curve DSA certificates with GlobalProtect agent

[fjwcash]

Anyone else come across this?  Anyone using ECDSA certs for their GlobalProtect Portal or Gateways?  Have you tried non-Windows/MacOS clients?

Configuring GlobalProtect Gateways to use ECDSA certs instead of RSA certs breaks everything except Windows, MacOS, and mobile agents.

As the SSL cert industry seems to be heading toward deprecating RSA certs in the 5-ish years, I thought I'd get a jump on things and test it out on our GP setup.  Added ECDSA certs to one Gateway, tested it with Windows and Android clients, and everything was good.  Ran it for a few weeks, and pushed it out to a second Gateway.  Tested that one with Windows, MacOS, and iOS client, and everything was good.  Pushed it out to all our Gateways except one, and no issues reported.  That was in July 2021.

One of the clients is a Grandstream VoIP phone running an old version of Android that we use for work-from-home staff.  As it's Android-based, we can use the built-in VPN client to connect to GlobalProtect via X-Auth.  Worked great until school started again in September.  The staff member could not keep the phone online for an hour, let alone a full workday.  Calls were choppy, calls were dropped, phone locked up, all kinds of issues.  Switched the GlobalProtect Gateway back to using RSA certs ... and all the issues went away.  (Didn't fix this one until this week, so there's no support ticket in for this one.)

Added a new user to one of the Gateways using ECDSA certs.  That user has an Ubuntu laptop.  Tried GP 5.2.x and 5.3.x (multiple versions of each).  Would not connect to the Gateway (Portal auth worked), would just hang the agent or give error messages about authenticating the server.  And you could not sign out of the agent, that option was missing from the client UI!  Had to force uninstall/install in order to change usernames in the agent, in order to test a connection to a different gateway.  Switched the GlobalProtect Gateway back to using RSA certs ... and all the issues went away.  (We have support tickets in for these two issues.)

We've now removed all traces of ECDSA certs from our GlobalProtect infrastructure.

[nikoolayy1]

What is the PanOS version of the gateways ? Please see:

https://docs.paloaltonetworks.com/compatibility-matrix/supported-cipher-suites.html

[fjwcash]

Oh, thought I had included the OS version, but guess that was a different topic.  🙂

PanOS 9.1.9 on all firewalls (portal and gateways).

The EC certificates work for Windows, MacOS, iOS, and Android GlobalProtect agents.

They fail for Linux GlobalProtect agents.  Tried with GP 5.1.x, 5.2.x, and 5.3.x (multiple versions of each, including the latest version of each).

[nikoolayy1]

You may need to provide the PanGPS logs that may show something usefull as you are having interesting issue.

Also please clarify if you mean you changed to ECDSA certficates on the Gateways and not the for ssl certificate client based authentication?

Also this is interesting as I do not see linux so maybe it is not supported yet but the TAC support should say and add Linux in the below link as this should have been done.

https://docs.paloaltonetworks.com/globalprotect/9-1/globalprotect-admin/globalprotect-cryptography/g...

[fjwcash]

We don't have the logs anymore as we've removed all ECDSA certificates from our GP setup.  The certs don't even exist anymore.  We don't use device certs, these were the certificates used in the gateway configuration.  This was simply changing the self-signed CA root certificate and the certificates used for the gateways (signed by the root CA) to ECDSA.  The portal uses our domain's wildcard cert.

With the ECDSA certificate enabled on the gateway, Windows and MacOS, Android and iOS GP clients were able to connect to the gateway without issues.  Linux clients, regardless of GP client version, would connect to the portal, authenticate the user, connect to the gateway, then error out with something along the lines of "can't authenticate server" when it went to establish the SSL connection to the gateway.  The really interesting part was that manually loading https://gateway.address/whatever-the-pre-flight-URL-is in a web browser on the same Linux station worked.  It was just the GP connection that failed.

Nothing in the gateway configuration on the firewall changed, except which certificate was in use (RSA or ECDSA).  We flipped it back to RSA, and Linux clients could connect without issue.  Flipped it back to ECDSA, Linux clients would not connect.  We even configured 1 gateway with RSA certs and another gateway with ECDSA certs, and would either get a working connection or a failed connection based on which username we logged in with (the username determines which gateway is used).

Tried with GP 5.1.x, 5.2.x, and 5.3.x and the results were the same.  Linux clients could not authenticate the gateway and would not establish a connection if the gateway used ECDSA certificates.

We've since moved back to RSA certificates for everything on our firewalls, and won't be looking into ECDSA anytime in the future.  We have more Linux stations than Windows in our workplace, so we need to make sure the Linux stations connect to GlobalProtect.