GlobalProtect Certificate Best Practices

The following table summarizes the SSL/TLS certificates you will need, depending on which features you plan to use:
Certificate
Usage
Issuing Process/Best Practices
CA certificate
Used to sign certificates issued to the GlobalProtect components.
If you plan on using self-signed certificates, we recommend that you generate a CA certificate on the portal, and then use that certificate to issue the required GlobalProtect certificates.
Portal server certificate
Enables GlobalProtect apps to establish an HTTPS connection with the portal.
  • This certificate is identified in an SSL/TLS service profile. You assign the portal server certificate by selecting its associated service profile in a portal configuration.
  • Use a certificate from a well-known, third-party CA. This is the most secure option and ensures that the user endpoints can establish a trust relationship with the portal and without requiring you to deploy the root CA certificate.
  • If you do not use a well-known, public CA, you should export the root CA certificate that was used to generate the portal server certificate to all endpoints that run the GlobalProtect app. Exporting this certificate prevents the end users from seeing certificate warnings during the initial portal login.
  • The Common Name (CN) and, if applicable, the Subject Alternative Name (SAN) fields of the certificate must match the IP address or FQDN of the interface that hosts the portal.
  • In general, a portal must have its own server certificate. However, if you are deploying a single gateway and portal on the same interface, you must use the same certificate for both the gateway and the portal.
  • If you configure a gateway and portal on the same interface, we also recommend that you use the same certificate profile and SSL/TLS service profile for both the gateway and portal. If they do not use the same certificate profile and SSL/TLS service profile, the gateway configuration takes precedence over the portal configuration during the SSL handshake.
Gateway server certificate
Enables GlobalProtect apps to establish an HTTPS connection with the gateway.
  • This certificate is identified in an SSL/TLS service profile. You assign the portal server certificate by selecting its associated service profile in a gateway configuration.
  • Generate a CA certificate on the portal and use that CA certificate to generate all gateway certificates.
  • The CN and, if applicable, the SAN fields of the certificate must match the FQDN or IP address of the interface where you plan to configure the gateway.
  • The portal distributes the gateway root CA certificates to agents in the client configuration, so the gateway certificates do not need to be issued by a public CA.
  • In general, each gateway must have its own server certificate. However, if you are deploying a single gateway and portal on the same interface for basic VPN access, you must use a single server certificate for both components.As a best practice, use a certificate signed by a public CA.
  • If you configure a gateway and portal on the same interface, we also recommend that you use the same certificate profile and SSL/TLS service profile for both the gateway and portal. If they do not use the same certificate profile and SSL/TLS service profile, the gateway configuration takes precedence over the portal configuration during the SSL handshake.
(Optional) Client certificate
Used to enable mutual authentication when establishing an HTTPS session between the GlobalProtect apps and the gateways/portal. This ensures that only endpoints with valid client certificates are able to authenticate and connect to the network.
  • For simplified deployment of client certificates, configure the portal to deploy the client certificate to the apps upon successful login using either of the following methods:
    • Use a single client certificate across all GlobalProtect apps that receive the same configuration. Assign the Local client certificate by uploading the certificate to the portal, and then selecting it in a portal agent configuration.
    • Use simple certificate enrollment protocol (SCEP) to enable the GlobalProtect portal to deploy unique client certificates to your GlobalProtect apps. Enable this by configuring a SCEP profile, and then selecting that profile in a portal agent configuration.
  • Use one of the following digest algorithms when you generate client certificates for GlobalProtect endpoints: sha1, sha256, sha384, or sha512.
  • You can use other mechanisms to deploy unique client certificates to each endpoint when authenticating the end user.
  • Consider testing your configuration without the client certificate first, and then add the client certificate after you are sure that all other configuration settings are correct.
(Optional) Machine certificates
A machine certificate is a client certificate that is issued to an endpoint. Each machine certificate identifies the endpoint in the subject field (for example, CN=laptop1.example.com) instead of the user. The certificate ensures that only trusted endpoints can connect to gateways or the portal.
Machine certificates are required for users configured with the pre-logon connect method
  • Use one of the following digest algorithms when you generate client certificates for GlobalProtect endpoints: sha1, sha256, sha384, or sha512.
  • If you plan on using the pre-logon feature, use your own PKI infrastructure to deploy machine certificates to each endpoint prior to enabling GlobalProtect access. This approach is important for ensuring security.
    For more information, see Remote Access VPN with Pre-Logon.
Table: GlobalProtect Certificate Requirements
For details about the types of keys for secure communication between the GlobalProtect endpoint and the portals and gateways, see Reference: GlobalProtect App Cryptographic Functions.

Related Documentation