(Recommended) Combination of third-party certificates
and self-signed certificates
—Because the end clients will be
accessing the portal prior to GlobalProtect configuration, the client
must trust the certificate to establish an HTTPS connection.
Enterprise Certificate Authority
—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(s). In this case,
you must also ensure that the end user systems/mobile devices trust
the root CA certificate used to issue the certificates for the GlobalProtect
services to which they must connect.
—You can generate a self-signed
CA certificate on the portal and use it to issue certificates for
all of the GlobalProtect components. However, this solution is less
secure than the other options and is therefore not recommended.
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 end user systems
manually or using some sort of centralized deployment, such as an
Active Directory Group Policy Object (GPO).