Controlling GlobalProtect VPN Access with OCSP
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.
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.
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.
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.
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:
To perform the same steps for the GlobalProtect Gateway, go to Network > GlobalProtect, click Add and select the General tab as shown below:
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:
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):  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):  OCSP checking ... depth 2, URI: (null)
2014-04-03 23:47:41.538 +0200 debug: pan_ocsp_fetch_ocsp(pan_crl.c:2000):  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):  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):  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):  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):  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):  OCSP check result is 'revoked', depth 0
2014-04-03 23:47:41.539 +0200 debug: sslmgr_check_status(sslmgr_main.c:915):  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