>
    GlobalProtect Certificate Best Practices
    Focus
    Download PDF
    Focus
    1. Home
    2. GlobalProtect
    3. Get Started
    4. Enable SSL Between GlobalProtect Components
    5. GlobalProtect Certificate Best Practices
    Download PDF
    GlobalProtect

    GlobalProtect Certificate Best Practices

    Table of Contents

    GlobalProtect Certificate Best Practices

    The GlobalProtect components require valid SSL/TLS certificates to establish connections. The best practices include using a well-known, third-party CA for the portal server certificate, using a CA certificate to generate gateway certificates, optionally using client certificates for mutual authentication, and using machine certificates for pre-logon access.
    The GlobalProtect components must have valid certificates to establish connection using SSL/TLS. The connection fails if you have invalid or expired certificates.
    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, generate a CA certificate using your dedicated CA server or Palo Alto Networks firewall, and then issue GlobalProtect portal and gateway certificates signed by the CA or an intermediate CA.
    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 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 gateway server certificate by selecting its associated service profile in a gateway configuration.
    • Generate a CA certificate on the firewall or CA server and use that CA certificate to generate all gateway certificates.
    • The CN and 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 can distribute the gateway root CA certificate to the GlobalProtect app based on the configuration (Trusted Root CA list in the Portal configuration Agent tab). However, it is not mandatory for the gateway root CA certificate to be pre-installed in the user's trusted certificate store or for the gateway certificate 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 that resides in the local machine store or system keychain. 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.

    Recommended For You

    © 2024 Palo Alto Networks, Inc. All rights reserved.