Controlling GlobalProtect VPN Access with OCSP

Controlling GlobalProtect VPN Access with OCSP

13612
Created On 09/25/18 17:42 PM - Last Updated 04/20/20 23:38 PM


Resolution

Overview

The GlobalProtect configuration has the ability to authenticate users based on username/password, or on certificates. When using certificates to connect, it is a valuable benefit to use an OCSP server to check for revocation status of the certificate, so that the users are denied access if the certificate is revoked. This setup is beneficial when it is used for consultants, as they are allowed access to some projects for a period of time and than the access is revoked.

Details

Palo Alto Networks devices have the option to generate certificates for these types of users, and if the OCSP responder is configured on the device it allows the capability to revoke access, if needed. Because of this scenario, an OCSP responder is needed on the Palo Alto Networks firewall.

To setup the OCSP go to, Device > Certificate Management > OCSP Responder and click Add.

Enter a name for the OCSP Responder and use the IP address of the firewall as the the Host Name.

Screen Shot 2014-04-18 at 3.48.50 PM.png

As soon as the OCSP Responder is configured and committed, it is now possible to generate certificates on the firewall that are using the OCSP Responder to check the revocation status. To create certificates go to Device > Certificate Management > Certificates and click Generate. While creating new certificates be sure to use the OCSP Responder that is filed. This allows the connections that are authenticated initiated from the user, and holds the certificates that are checked with the OCSP server.

Screen Shot 2014-04-18 at 5.16.17 PM.png

To create a Certificate Profile for the VPN users, which will be verifying the revocation status with the OCSP, go to Device > Certificate Management > Certificate Profile.

Specify the parameters for the username (in this case is the subject), the CA that signs the certificates and the OCSP URL.

Note: Make sure to enable the usage of OCSP, CRL can also be enabled, but be aware that the OCSP will have precedence, because it is more reliable than the CRL.

Screen Shot 2014-04-18 at 5.21.33 PM.png

In the GlobalProtect Portal configuration the user authentication should be performed based on the Client Certificate Profile.

To setup go to Network > GlobalProtect > Portals, click Add and select Portal Configuration:

Screen Shot 2014-04-18 at 5.26.42 PM.png

To perform the same steps for the GlobalProtect Gateway, go to Network > GlobalProtect, click Add and select the General tab as shown below:

Screen Shot 2014-04-18 at 5.28.06 PM.png

The users can login using certificates, which are validated using the OCSP. If access for user is no longer needed, revoke the certificate.

To revoke the certificate, go to Device > Certificate Management > Certificates and select the certificate, click on the Revoke button.

After the revoke, the status of the certificate will change from green "valid" to red "revoked" as shown in the example below:

Screen Shot 2014-04-18 at 5.32.48 PM.png

From the CLI, check the revocation status of the issued certificate for the specific OCSP (or for all) by using the command below:

> debug sslmgr view ocsp all

Current time is: Thu Apr 3 21:49:46 2014

Count Serial Number(HEX) Status      Next Update               Revocation Time Reason        Issuer Name  Hash  OCSP Responder URL

----  ------------------ --------    ------------------------  ------------------------  -----------  -----------------------

[ 1]  10                 revoked     Apr 04 21:41:39 2014 GMT  Apr 03 21:44:54 2014 GMT  7ccb1b43     http://10.193.17.2/CA/ocsp

[ 2]  0D                 valid       Apr 03 22:41:39 2014 GM                             df89db2d     http://10.193.17.2/CA/ocsp

When a user tries to login with a revoked certificate the firewall will check with the OCSP and deny access.

This can be verified by the sslmgr.log, see the examples below:

2014-04-03 23:47:41.537 +0200 debug: sslmgr_check_status(sslmgr_main.c:655): [0] start checking OCSP, status for certificate chain, num: 3; block unknown: no; from DP: yes

2014-04-03 23:47:41.537 +0200 [OCSP] URL http://10.193.17.2/CA/ocsp  serialno: 0D

2014-04-03 23:47:41.538 +0200 [OCSP] URL http://10.193.17.2/CA/ocsp  serialno: 10

2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:1996): [0] OCSP checking ... depth 2, URI: (null)

2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2000): [0] No AIA URL, skip checking OCSP for depth 2.

2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:1996): [0] OCSP checking ... depth 1, URI: http://10.193.17.2/CA/ocsp

2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2045): [0] OCSP check result is 'valid' for level 1 per cache

2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:1996): [0] OCSP checking ... depth 0, URI: http://10.193.17.2/CA/ocsp

2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2045): [0] OCSP check result is 'revoked' for level 0 per cache

2014-04-03 23:47:41.538 +0200 debug: sslmgr_check_status(sslmgr_main.c:709): [0] OCSP check result is 'revoked', depth 0

2014-04-03 23:47:41.539 +0200 debug: sslmgr_check_status(sslmgr_main.c:915): [0] final status: revoked; reason: ; depth: 0; BY OCSP

2014-04-03 23:47:41.539 +0200 Send cookie:5 session:0 status:4 to DP

owner: ialeksov



Attachments
Actions
  • Print
  • Copy Link

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

Attachments
Choose Language