GlobalProtect Client Side Certificate Authentication Changes with PAN-OS 7.1.4

This document is focused on changes made in PAN-OS version 7.1.4/7.0.10 (Issue ID 95864) that may affect GlobalProtect deployments which are using client side certificate authentication. In particular, this relates to deployments where client certificates are signed using SHA512 or SHA384 hash algorithms. The issue may also affect users where client certificates are SHA1/SHA256 signed, but the CA certificate is signed by SHA384/SHA512.

Problem description

After upgrade to PAN-OS 7.1.4/7.0.10 (or higher), GlobalProtect clients are not able to authenticate using client side certificates signed with SHA512 or SHA384. GlobalProtect Agent is showing error message 'Required client certificate is not found'.

Behavior prior to PAN-OS version 7.1.4/7.0.10

Prior to version 7.1.4/7.0.10, we had the following behavior during SSL handshake between GlobalProtect Agent and GlobalProtect Portal/Gateway if TLS 1.2 is used:

• Client (GP Agent) is sending 'Client Hello' message
• Server (Firewall with GP Portal/Gateway configured) is sending 'Server Hello' message, along with server side certificate
• If client certificate verification is configured on firewall side ('Certificate Profile' configuration), server will send 'Certificate Request' message to the client
• 'Certificate Request' message contains (among other):

1. 'Distinguished Names' / List of CAs, server is expecting client certificate to be signed with

2. 'Signature Hash Algorithms' / List of hashes that the server supports**

**This message is sent only when TLS 1.2 is used; TLS 1.1/TLS 1.0 do not have this message specified in the standard

• We can see that the server is sending the following list of supported hash algorithms: SHA1, SHA256, SHA384 and SHA512

Client certificate verification process includes (among other):

1. Verifying that the client posseses the private key of the advertised certificate; This is done using 'Certificate Verify' message exchanged during the handshake

2. Verifying that the client certificate is signed by authority mentioned in the 'Issuer' filed (certificate chain verification)

• PAN-OS firewall supports SHA1 and SHA256 hashes for 'Certificate Verify' message verification, but SHA384 and SHA512 were not supported
• Higher hashes were incorrectly advertised in TLS 1.2 (in PAN-OS versions 7.1.3/7.0.9 and below)
• At the same time, the firewall is able to verify certiifcate chain using SHA1, SHA256, SHA384 and SHA512 
• Hashing algorithm used for 'Certificate Verify' message does not have to match the algorithm used to sign client certificate (which is done by CA)
• We can have SHA512 signed certificate, and 'Certificate Verify' message signed by SHA1 (algorithm used is determined by client side Operating System SSL stack)
• In TLS 1.2 'Certificate Verify' message can be signed by Any hash advertised by the server (in the list of supported hashes) 

'Certificate Verify' message is:

• Used to prove client posseses the private key of the certificate it has sent previously (during SSL handshake)
• Created by hashing previosly exchanged SSL handshake messages with the client's private key
• Often hashed using SHA1, and this hash is supported by the firewall

Even though the certificate was signed with SHA512, if 'Certificate Verify' message was signed with SHA1 or SHA256, we can still perform proper certificate verification: both for issuer/chain and client possession of private key

From firewall debug logs:

2016-09-26 10:40:49.276 +0200 debug: pan_ssl3_server_process_handshake(pan_ssl_server.c:1648): receive certificate verify
2016-09-26 10:40:49.276 +0200 debug: pan_ssl3_server_verify_client_certificate(pan_ssl_server.c:1358): In client cert, TLS1.2 or over is used with SHA1.

If 'Certificate Verify' message ended up being signed by SHA384 or SHA512 (both algorithms were advertised), we would not be able to verify certificate properly

Behavior in PAN-OS version 7.1.4 and later

In PAN-OS 7.1.4/7.0.10 we have the following behavior change during SSL handshake if TLS 1.2 is used:

• Client (GlobalProtect Agent) and Server (GlobalProtect Portal/Gateway) exchange SSL 'Hello' messages
• Server is requesting client certificate by sending 'Certificate Request' 
• 'Certificate Request' is now mentioning only the hashes we do actually support for 'Certificate Verifiy': SHA1 and SHA256

• If the client is using SHA384 or SHA512 signed client certificates, operating system can decide not to use them at all, since they are hashed with the algorithms not supported by the server 
• Similar can happen if the client certificate is signed with SHA256/SHA1 hash, but the CA is signed with SHA384/SHA512
• The end result may be that the client does not send the certificate at all and authentication fails 
• The authentication could be successful if the Operating System decided to send the certificate and use SHA1/SHA256 for 'Certificate Verify' message

Workarounds

TLS 1.1, as opossed to TLS 1.2, does not send 'Signature Hash Algorithms' list (supported hashes) in 'Certificate Request' message. If we limit TLS/SSL Profile binded to GlobalProtect Portal/Gateway to TLS 1.1, we can have similar behavior to pre-7.1.4/7.0.10 releases. We will not limit client side opeating system in sending certificates with higher hashes. Note that this deployment can still have issues if 'Certificate Verify' message is signed with SHA384/SHA512.

TLS 1.2 can be used for SHA1/SHA256 signed certificates.

If all certificates used are SHA384 or higher, protocol settings can be set to TLSv1.2 or higher

Note

PAN-OS 7.1.8 added support for SHA384 client side certificate. From the release notes:

"PAN‐62057 Fixed an issue where the GlobalProtect agent failed to authenticate using a client certificate that had a signature algorithm that was not SHA1/SHA256. With this fix, the firewall provides support for the SHA384 signature algorithm for client‐based authentication."