Detections
Analytics

1.6.3 Ensure that the Certificate Securing Remote Access VPNs is Valid - GlobalProtect Gateways

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

The Certificate used to secure Remote Access VPNs should satisfy the following criteria:

It should be a valid certificate from a trusted source. In almost cases this means a trusted Public Certificate Authority, as in most cases remote access VPN users will not have access to any Private Certificate Authorities for Certificate validation.

The certificate should have a valid date. It should not have a 'to' date in the past (it should not be expired), and should not have a 'from' date in the future.

The key length used to encrypt the certificate should be 2048 bits or more.

The hash used to sign the certificate should be SHA-2 or better.

When the Certificate is applied, the TLS version should be 1.1 or higher (1.2 is recommended)

Rationale:

If presented with a certificate error, the end user in most cases will not be able to tell if their session is using a self-signed or expired certificate, or if their session is being eavesdropped on or injected into by a 'Man in the Middle' attack. This means that self-signed or invalid certificates should never be used for VPN connections.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

Create a CSR and install a certificate from a public CA (Certificate Authority) here:
Navigate to Device > Certificate Management > Certificates
Apply a valid certificate to the HTTPS portal:
Navigate to Network > GlobalProtect > Portals > Portal Configuration > Authentication > SSL/TLS Profile
Apply a valid certificate to the GlobalProtect Gateway:
Navigate to Network > GlobalProtect > Gateways > Authentication > SSL/TLS Service Profile
Configure the Service Profile to use the correct certificate
Ensure that the Minimum TLS version is set to 1.1 or 1.2 (1.2 is recommended).

Impact:

Not using a trusted Certificate, issued by a trusted Public Certificate Authority means that clients establishing VPN sessions will always see an error indicating an untrusted Certificate. This means that they will have no method of validating if their VPN session is being hijacked by a 'Monkey in the Middle' (MitM) attack. It also 'trains' them to bypass certificate warnings for other services, making MitM attacks easier for those other services as well.

Default Value:

Not configured

References:

'PAN-OS Administrator's Guide 9.0 (English) - GlobalProtect Certificate Best Practices' - https://docs.paloaltonetworks.com/globalprotect/9-0/globalprotect-admin/get-started/enable-ssl-between-globalprotect-components/globalprotect-certificate-best-practices.html

'PAN-OS Administrator's Guide 9.0 (English) - Deploy Server Certificates to the GlobalProtect Components' - https://docs.paloaltonetworks.com/globalprotect/9-0/globalprotect-admin/get-started/enable-ssl-between-globalprotect-components/deploy-server-certificates-to-the-globalprotect-components.html#

See Also

https://workbench.cisecurity.org/files/2692

Item Details

References: CSCv6|14.2, CSCv7|14.4

Plugin: Palo_Alto

Control ID: 97efb9e0b4cbe42f358f9626a02868b800686b229d9d759a6e0df3b55680ba76