GlobalProtect appliance PCI Compliance

Showing results for 
Show  only  | Search instead for 
Did you mean: 

GlobalProtect appliance PCI Compliance


We're trying to get our VPN appliance PCI compliant and not sure what is going on, as it's automatically failing.


Minimum TLS is 1.2 and have disabled all the weak key exchanges. This was done prior to any PCI compliance requirement.


When we run the SSL test on, we're getting an A-.


The PCI report contains the below:


QID Detection Logic:
For a SSL enabled port, the scanner probes and maintains a list of supported SSL/TLS versions. For each supported version, the scanner does a SSL handshake to get a
list of KEX methods supported by the server. It reports all KEX methods that are considered weak. The criteria of a weak KEX method is as follows:
The SSL/TLS server supports key exchanges that are cryptographically weaker than recommended. Key exchanges should provide at least 112 bits of security, which
translates to a minimum key size of 2048 bits for Diffie Hellman and RSA key exchanges.

An attacker with access to sufficient computational power might be able to recover the session key and decrypt session content.

Change the SSL/TLS server configuration to only allow strong key exchanges. Key exchanges should provide at least 112 bits of security, which translates to a minimum
key size of 2048 bits for Diffie Hellman and RSA key exchanges.

TLSv1.2 ECDHE secp192r1 192 yes 96 low
TLSv1.2 ECDHE secp192k1 192 yes 96 low
TLSv1.2 ECDHE secp160r2 160 yes 80 low
TLSv1.2 ECDHE secp160r1 160 yes 80 low
TLSv1.2 ECDHE secp160k1 160 yes 80 low
TLSv1.2 ECDHE sect193r2 193 yes 96 low
TLSv1.2 ECDHE sect193r1 193 yes 96 low
TLSv1.2 ECDHE sect163r2 163 yes 81 low
TLSv1.2 ECDHE sect163r1 163 yes 81 low
TLSv1.2 ECDHE sect163k1 163 yes 81 low


The appliance is running 9.1.8. 

Any ideas on how to resolve it?




L0 Member

Me too! Have you figured it out yet?

L1 Bithead

Feature Request ID: 19980. Customer is requesting the ability to individually select which Elliptical Curves are used with ECDHA on sessions. Currently several easily broken curves are in use and undocumented, however, vulnerability scanners such as Qualys has discovered this weakness. The ability for a customer to select which curves are available for use provides a simple mechanism to alleviate this issue.


Currently it is unresolved. We have no CVE indicating vulnerability. Please reach out to your SE to be added to the FR.

It seems to have been an issue with the PCI compliance scanner.

We submitted the report to them and they accepted it and passed.

L0 Member

Have we had any movement on this? Or any solution? Got quite a few customers complaining about this at the moment.

L1 Bithead

if you want to customise the ssl-tls-profile to get an A or A+


create a new ssl/tls profile for globalprotect then using the cli modify the globalprotect profile to remove the unwanted combinations


see example below


TestSSL {
protocol-settings {
min-version tls1-2;
max-version tls1-2;
auth-algo-sha1 no;
auth-algo-sha256 no;
auth-algo-sha384 yes;
enc-algo-3des no;
enc-algo-aes-128-cbc no;
enc-algo-aes-128-gcm no;
enc-algo-aes-256-cbc yes;
enc-algo-aes-256-gcm yes;
enc-algo-rc4 no;
keyxchg-algo-dhe yes;
keyxchg-algo-ecdhe yes;
keyxchg-algo-rsa no;


set shared ssl-tls-service-profile protocol-settings auth-algo-sha1 no
set shared ssl-tls-service-profile protocol-settings keyxchg-algo-rsa no



Unfortunately, this still fails for our scan. ECDHE needs to be disabled for ours to pass.

However setting 

set shared ssl-tls-service-profile protocol-settings keyxchg-algo-rsa yes

set shared ssl-tls-service-profile protocol-settings keyxchg-algo-ecdhe no

passes PCI scans, but then users with apple devices (and some windows) cannot connect. It will not proceed past the pre-auth stage, even though the last log entry is "success".

looking at the supported release guidance post - 9.1.8, it might be worth upgrading the appliance past 9.1.8.

L0 Member

We're having the exact same problem as well and an report was not accepted.

We are on the latest release of the 9.1.x code. There is no fix for this.

The only workaround we have is to disable the ECDHE key exchange, and all the weak RSA ciphers. This does give us an approved scan.

However, this breaks the application for Apple devices (and any others) that look for the ECDHE keys almost exclusively. In GlobalProtect, the user is left with a blank white box, and cannot enter credentials.

  • 9 replies
  • 47 Subscriptions
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!