Palo Alto Networks Knowledgebase: Certificate config for GlobalProtect - (SSL/TLS, Client cert profiles, client/machine cert)

Certificate config for GlobalProtect - (SSL/TLS, Client cert profiles, client/machine cert)

76858
Created On 02/07/19 23:54 PM - Last Updated 02/07/19 23:54 PM
VPNs
Resolution

This document descibes 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!

  • If subj alt name(SAN) does not exist in this cert: This cert's common name(CN) 'must' match the portal/gateway's IP or FQDN .
  • If SAN exists with atleast one entry, then the IP or FQDN being used for portal/gateway 'must' be one of the entries in that SAN list. In this case the CN can be anything, it does not matter since only SAN will be used to match IP/FQDN.
  • 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'.

cert-chain.png

 

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

 SSL-TLS-profile.png

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)

Rootcert.png

 

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)

 Intermediate.png

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'.

 

 Servercert.png

 

 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

 SSL-TLS-profile.png

 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.

 

client-certprof.png

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.

1.JPG

2. Go to File > Add/Remove Snap-in:add-remove-snapin.png

 

 

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.

snap in 1.png

 

 

 snap in 2.png

 

 

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'

 

snap in 3.png

 

 

5. Similarly import the Root CA in the 'Trusted Root Certificate Authorities and Intermediate CAs(if any) in the 'Intermediate Certification Authorities'

 

snap in 4.png

 

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.

 snap in 6.png

 

 snap in 7.png

 

7. At this point, the certificates are imported on the client, so you can close the mmc console without saving it.



Attachments
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClFoCAK&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Attachments
Choose Language