Certificate config for GlobalProtect - (SSL/TLS, Client cert profiles, client/machine cert)
Environment
Global Protect Setup
Resolution
This document describes the basics of configuring certificates in GlobalProtect setup. Please note that there can be other ways to deploy certificates for GlobalProtect which are not covered in this document.
A. SSL/TLS service profile - Specifies Portal/gateway server cert, every portal/gateway needs one.
B. Certificate profile(if any) - Used by portal/gateway to request client/machine certificate
C. Installing client/machine cert in end client
A. SSL/TLS service profile
In the context of GlobalProtect, this profile is used to specify GlobalProtect portal/gateway's "server certificate" and the SSL/TLS "protocol version range". If same interface serves as both portal and gateway, you can use the same SSL/TLS profile for both portal/gateway. If portal/gateway are served through different interfaces, you can use same SSL/TLS profile as long as the certificate includes both portal/gateway IPs/FQDNs in its Subject Alternate Name(SAN), if not, create different profiles for portals and gateways as needed.
The pre-requisite to create SSL/TLS profile is to either generate/import the portal/gateway "server certificate" and its chain
- To import a certificate generated externally, navigate to Device>Certificate Management>Certificates and click on 'import' at the bottom.
- To generate a certificate on the firewall, navigate to Device>Certificate Management>Certificates and click on 'generate' at the bottom.
If the server cert is signed by a well-known third-party CA or by an internal PKI server
1. Import the Root CA (private key is optional)
2. Import intermediate CAs if any (private key is optional)
3. Import the server cert signed by the above CAs "with" private key.
IMPORTANT!
- Subject Alternative Name (SAN) should exist with at least one entry and the IP or FQDN being used for portal/gateway 'must' be one of the entries in that SAN list.
- If the SAN does not have the above entry, the certificate validation will fail on the gateway and will cause the connection to fail.
- Should not be of type CA. It must be of type end-entity.
- As a good practice, it is better to use FQDN instead of IP. Keep this consistent across the configuration and also educate the end users to use this FQDN/IP in the GlobalProtect client's portal field. Eg. if portal/gateway can be reached at fqdn 'vpn.xyz.com' or IP 1.1.1.1; and if the certificate references the fqdn 'vpn.xyz.com', then the users 'must' use 'vpn.xyz.com' instead of '1.1.1.1'.
4. SSL/TLS profile
(Location: Device>Certificate Management>SSL/TLS Service Profile)
-Name - Give any name for this profile
-Certificate - Reference the server cert from step 3
-Protocol Settings - Select the minimum and maximum versions of ssl/tls for the ssl transaction between client and server
5. Reference this SSL/TLS profile in portal/gateway as needed.
If the server cert needs to be generated on the Palo Alto Networks firewall
1. Generate a root cert with common name of any unique value. (other than IP or FQDN of portal/gateway)
(Location: Device>Certificate Management>Certificates click Generate at the bottom of the screen)
2. (optional) Generate a intermediate cert signed by above root cert. Specify its common name as any unique value. (other than IP or FQDN of portal/gateway)
3. Generate a sever cert signed by the above intermediate cert.
a. This cert's common name 'must' match the portal/gateway's IP or FQDN if subj alt name(SAN) does not exist in this cert. In PAN firewalls, SAN can be created under the optional 'certificate attributes' of type 'hostname', 'IP' or 'email'.
b. If SAN exists with atleast one entry, then the IP or FQDN being used for portal/gateway 'must' be present in that SAN list.
c. Should not be a CA.
d. As a good practice, it is better to use FQDN instead of IP. Keep this consistent across the configuration and also educate the end users to use this FQDN/IP in the GlobalProtect client's portal field. For example. if the portal/gateway can be reached at fqdn 'vpn.xyz.com' or IP 1.1.1.1; and the certificate references the fqdn 'vpn.xyz.com', the users 'must' use 'vpn.xyz.com' instead of '1.1.1.1'.
4. SSL/TLS profile
(Location: Device>Certificate Management>SSL/TLS Service Profile)
- Name - Give any name for this profile
- Certificate - Reference the server cert from step 3
- Protocol Settings - Select the minimum and maximum versions of ssl/tls for the ssl transaction between client and server
5. Reference this SSL/TLS profile in portal/gateway as needed.
B. Certificate Profile
(Location: Device>Certificate Management>Certificate Profile)
Certificate profile specifies a list of CAs and Intermediate CAs. When this certificate profile is applied to the config, the portal/gateway will send a client certificate request to the client to request for a client/machine cert signed by the CA/intermediate CA specified in the cert profile. It is recommended to place both the root and intermediate CAs in this profile, instead of just root CA.
IMPORTANT!
-Client certificate refers to user cert, it can be used for 'user-logon'/'on-demand' connect methods. Used to authenticate a user.
-Machine certificate refers to device cert, it can be used for 'pre-logon' connect method. This is used to authenticate a device, not a user.
1. Import the "Root CA" that signed the client/machine cert into Device > Certificate Management > Certificates (optional private key)
2. Import the "intermediate CAs" if any that signed the client/machine cert into Device > Certificate Management > Certificates (optional private key)
3. Go to Device > Certificate Management > Certificate Profile, click Add.
4. Give a name to the profile.
5. Add the root and intermediate CAs from Step 1 & 2.
6. Note: Username field by default is set to 'None', in a typical setup where username is pulled from LDAP/RADIUS authentication, you can leave this to none. On the other hand, if certificates are the only method of authentication, that is, if you do not have RADIUS/LDAP for portal/gateway authentication then you must change username field from none to 'Subj' or 'Subj Alt' to extract username from the client certificate common name or email/principal name. Failing to do this will result in a commit failure.
7. (optional) Check CRL or OCSP if the portal/gateway needs to verify the client/machine cert's revocation status using CRL or OCSP. Please use this with caution as it can result in clients failing to connect if used in conjunction with 'Block session if certificate status is unknown'.
8. Reference this certificate profile portal/gateway as needed.
C. Installing client/machine cert in end client
When importing a client/machine certificate, import it in PKCS format which will contain its private key.
Windows -
1. Click Start>Run, type mmc to open Microsoft certificate management console.
2. Go to File > Add/Remove Snap-in:
IMPORTANT!
3. Click Certificates>Add and select one or both of the below:
a. To add client(user) certificate, select 'My user Account'. This is used for 'user-logon' and 'on-demand' since it authenticates a user.
b. To add machine(device) certificate, select 'Computer Account'. This is used for 'pre-logon' as it authenticates a machine.
4. Import client/machine certificate into mmc.
a. If you are importing client certificate, import it to 'Personal' Folder under 'My user account'
b. If you are importing machine certificarte, import it to 'Personal' Folder under 'Computer Account'
5. Similarly import the Root CA in the 'Trusted Root Certificate Authorities and Intermediate CAs(if any) in the 'Intermediate Certification Authorities'
IMPORTANT!
6. Once imported, double click the imported client/machine certificate to make sure
a. It has private key
b. Its certificate chain is full upto its root CA. If the chain is missing root CA or intermediate CA, import them to their respective folders as explained in Step 5.
7. At this point, the certificates are imported on the client, so you can close the mmc console without saving it.
macOS
- Open Keychain Access and go to the System keychains:
- Ensure that all applications have access to the private keys of the device and the Root CA certs: