About GlobalProtect Certificate Deployment
There are three approaches to deploying server certificates to GlobalProtect
components: a combination of third-party and self-signed certificates, using an enterprise
Certificate Authority (CA), or using self-signed certificates.
(Recommended) Combination of third-party
certificates and self-signed certificates—Because the GlobalProtect
app will be accessing the portal prior to GlobalProtect configuration,
the app must trust the certificate to establish an HTTPS connection.
Enterprise CA—If you already have your own enterprise CA, you can use this internal CA to
issue certificates for each of the GlobalProtect components and then import them
onto the firewalls hosting your portal and gateway. In this case, you must also
ensure that the endpoints trust the root CA certificate used to issue the
certificates for the GlobalProtect services to which they must connect.
Self-Signed Certificates—You can generate a self-signed CA certificate on the portal and
use it to issue certificates for all the GlobalProtect components. However, this
solution is not recommended since it's less secure than the other options. If
you do choose this option, end users will see a certificate error the first time
they connect to the portal. To prevent this, you can deploy the self-signed root
CA certificate to all endpoints manually or using some sort of centralized
deployment, such as an Active Directory Group Policy Object (GPO).
