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

Printer Friendly Page

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.

Tags (3)
Comments

This was helpful but the step for generating the client cert appears to be missing. 

You MUST have an TLS/SSL profile setup such that downstream clients trust the cert ? (aka either have the root CA it is signed by (and any intermediate's) in their trusted cert store .. aka internal PKI, or public trusted CA cert in their store)

You can't just setup self-signed PKI .. set a cert in the profile and then when connecting with client just do a 'trust anyway' acceptance ?

 

Because for PORTAL I do get a popup complaining of a cert issue (of course.. stands to reason) and I can just hit 'go anyway'.

But at GATEWAY, I get a server certificate validation failed.. and connection stops..

It would be useful if this article explained what specific Key Usage and Enhanced Key Usage attributes need to be present on the certificate selected in the SSL/TLS Service Profile assigned to the GlobalProtect Portal and Gateway.  When I use a Service Profile that is assigned a self-signed certificate generated on the PAN NGFW, I am able to successfully connect but when I use a Service Profile that is assigned a certificate signed by our trusted internal CA, I get an error telling me that "The server certificate is invalid".

 

I have noticed that the self-signed and internal-CA-signed certificates have different Key Usage and Enhanced Key Usage attributes from each other, with my internal-CA-signed certificates being applicable for use for less usages overall.

 

And yes, I am sure that both the PAN NGFW I'm using as a GP portal/gateway and the client I am testing with trust the certificate signed by the internal CA.

@scottsander, please allow me to see what we can do to update this article with the information that you asked.

 

As far as the error, we will need more information on the cert you are currently using and the exact details on what is currently listed as "usage" on that cert.  And go from there.

@jdelio, sorry for the long delay before my response.  The cert I am trying to use has the following usage:

 

Key Usage:

  • Digital Signature
  • Key Encipherment (a0)

 

Enhanced Key Usage:

  • Server Authentication (1.3.6.1.5.5.7.3.1)

 

It was generated using the same certificate template we use for web server certificates.

@scottsander

Now I need to apologize for the delay in responding. 

I am not sure why that error message is showing up, so I would have to suggest getting a Support Case opened on this so they could help identify this issue/cause.

@scottsander did you get a resolution to this issue you can share?

Anyone else having issues with GP portal not sending certificate request in TLS handhsake? I have certificate profile configured, but GP doesn't request a certificate at all.