Certificate Authentication Overview

This guide covers configuring certificate-based authentication for administrator access to the Palo Alto Networks firewall web interface and for GlobalProtect deployments.

Using certificates enhances security by replacing or supplementing password-based authentication with cryptographic verification.

Key areas covered:

Configuring Certificate Profiles to define trusted CAs and validation settings.
Setting up Certificate-Based Authentication for Web UI access.
Understanding certificate requirements for GlobalProtect deployments (Portal/Gateway, Client/Machine Certs).
Configuration examples for GlobalProtect using certificates only and on iOS devices.
Troubleshooting common certificate-related issues in GlobalProtect.

Certificate management, profiles, and their application in authentication (Web UI, GlobalProtect) are important topics for PCNSE.

Certificate Profiles: Introduction & Configuration

Certificate profiles define user and device authentication parameters for various firewall features including Authentication Portal, MFA, GlobalProtect, IPSec VPNs, administrative web interface access, and more.

They specify:

Which Certificate Authority (CA) certificates the firewall should trust for validating client/server certificates.
How to verify certificate revocation status (CRL/OCSP).
How revocation status constrains access.
How to extract the username from a certificate (if used for authentication).

Steps to Configure a Certificate Profile:

Obtain CA Certificates: Ensure the CA certificate(s) that signed the client/server certificates you intend to validate are present on the firewall ( Device > Certificate Management > Certificates ). You can Generate them on the firewall or Import them from your PKI.
Identify the Profile:
- Navigate to Device > Certificate Management > Certificate Profile and click Add .
- Enter a descriptive Name (e.g., `GP-Client-Cert-Validation`, `Admin-WebUI-Cert-Auth`).
- (Multi-VSYS) Select the appropriate Location (VSYS or Shared).
Assign CA Certificates:
- In the CA Certificates table, click Add .
- Select the relevant CA Certificate from the dropdown or Import it directly.
- (Optional) Configure Default OCSP URL or OCSP Verify CA Certificate if overriding default behavior is needed (rare).
- Click OK . Repeat for all necessary CAs (e.g., Root and Intermediate CAs in a chain).
Configure Username Extraction (Important for Cert-Only Auth):
- Select the Username Field dropdown to specify how the firewall should extract the username if the certificate is used as the primary authentication factor (e.g., for Web UI admin access or GlobalProtect cert-only auth).
  - Subject: Typically uses the Common Name (CN) field.
  - Subject Alt: Uses an attribute from the Subject Alternative Name (SAN) extension (Email or Principal Name).
  - None: Does not extract a username. Use this if certificate validation is secondary to another authentication method (like RADIUS/LDAP) that provides the username.
Configure Revocation Checking (Recommended): See next section.
Click OK to save the profile.
Commit the changes.

Understand that Certificate Profiles link trusted CAs to specific validation settings (revocation, username field) and are applied to features like GlobalProtect or Admin Auth settings.

Certificate Profiles: Revocation Checking (CRL/OCSP)

Configuring revocation checking ensures that compromised or invalid certificates are not accepted, even if they haven't expired.

It is highly recommended to enable revocation checking for security.

Configuration Options within Certificate Profile:

Use CRL: Enables checking against a Certificate Revocation List (CRL). The firewall must be able to download the CRL from the distribution point specified in the certificate or configured manually.
Use OCSP: Enables checking against an Online Certificate Status Protocol (OCSP) responder. The firewall queries the responder URL specified in the certificate's Authority Information Access (AIA) extension or a default URL configured in the profile.
Enable Both (Recommended): Check both Use CRL and Use OCSP . The firewall will attempt OCSP first and fall back to CRL if the OCSP responder is unavailable.
CRL/OCSP Receive Timeout: Time (seconds) the firewall waits for a response from the respective service.
Certificate Status Timeout: Overall time (seconds) the firewall waits for a definitive status before potentially timing out the request. Governed by the lesser of this value and the relevant Receive Timeout(s).
Block sessions if certificate status is unknown: If checked, sessions are blocked if the CRL/OCSP response explicitly indicates the status is 'unknown'. If unchecked, these sessions are allowed.
Block sessions if certificate status cannot be retrieved within timeout: If checked, sessions are blocked if the firewall cannot get *any* response (revoked, good, or unknown) from CRL/OCSP within the timeout period. If unchecked, these sessions are allowed. Leaving this unchecked when revocation is enabled significantly weakens security, as unreachable revocation servers won't block potentially revoked certificates.
Block sessions if the certificate was not issued to the authenticating device: (GlobalProtect Only) Compares the certificate serial number (often in Subject) against the Host ID reported by the GP client. Useful for machine certificate validation.
Block sessions with expired certificates: Ensures certificates past their validity date are rejected. Should generally always be checked.

Carefully consider the "Block session..." options. Blocking on unknown status or timeout enhances security but can cause connection issues if CRL/OCSP responders are unreliable. Allowing sessions in these cases reduces availability impact but increases risk.

Understand the difference between CRL and OCSP and the implications of the various "Block session..." options.

Web UI Cert Auth: Overview

As a more secure alternative to password-based authentication to the firewall web interface, you can configure certificate-based authentication for administrator accounts.

This method relies on administrators having a valid client certificate (issued by a CA trusted by the firewall) installed in their browser. Authentication involves the browser presenting the certificate and the firewall verifying its validity and signature, instead of prompting for a password.

Enabling certificate-based authentication for *any* administrator disables the username/password logins for *all* administrators accessing the web interface. Plan the rollout carefully.

Benefits:

Eliminates password-based attacks (brute-force, credential stuffing) against the web UI.
Provides stronger identity verification.
Can be part of a two-factor authentication strategy if the client certificate's private key is protected by a passphrase or hardware token.

Prerequisites:

A working Public Key Infrastructure (PKI), either internal or using the firewall as a CA.
Ability to issue and distribute client certificates securely to administrators.
Administrators must import their certificates into their web browsers.

Web UI Cert Auth: Configuration Steps

Ensure you have completed the prerequisites: a CA certificate exists on the firewall, and administrators can receive/install client certificates.

Generate/Import CA Certificate: (If not already done) Ensure the CA certificate that will sign/has signed the admin client certificates is loaded on the firewall ( Device > Certificate Management > Certificates ). Mark it as a trusted CA if imported.
Configure Certificate Profile: Create a Certificate Profile specifically for admin web UI authentication ( Device > Certificate Management > Certificate Profile ).
- Add the CA certificate from step 1 to the CA Certificates list.
- Set the Username Field to Subject (or potentially Subject Alt if usernames are stored there). This tells the firewall how to map the certificate to an Administrator Account name.
- Configure CRL/OCSP revocation checking as needed (highly recommended).
- Click OK .
The 'Username Field' setting is crucial for mapping the certificate to the admin account.
Apply Certificate Profile Globally for Admin Auth:
- Navigate to Device > Setup > Management .
- Edit the Authentication Settings section.
- In the Certificate Profile dropdown, select the profile created in step 2.
- Click OK .
This step globally enables certificate authentication for the web UI and disables password logins.
Configure Administrator Accounts: For each administrator using certificate authentication:
- Navigate to Device > Administrators . Add or Edit the administrator account.
- Ensure the Name field exactly matches the username extracted from the certificate based on the Certificate Profile setting (e.g., the CN in the Subject field).
- Check the box Use only client certificate authentication (Web) .
- Assign the appropriate Administrator Type (Role Based or Dynamic). The Authentication Profile setting on the admin account itself is ignored when this checkbox is selected for web UI access.
- Click OK .
Issue & Distribute Client Certificates: Generate a client certificate signed by the designated CA for each administrator. Ensure the Subject CN (or relevant field) matches their firewall username. Securely export (with private key, e.g., P12/PFX) and distribute these certificates.
Install Client Certificates: Administrators must import their P12/PFX file into their browser's certificate store.
Commit Changes: Commiting the change in Step 3 (applying the Certificate Profile globally) will likely restart the management server, terminating your session. You will need your *own* client certificate installed in your browser to log back in after the commit.
Verify Access: Administrators should access the firewall's web UI URL. The browser should prompt for certificate selection. After selecting the correct certificate, they should be logged in without a password prompt.

Simplified sequence diagram of successful Web UI certificate authentication.

GP & Troubleshooting: Client/Server Certificate Requirements

Using certificates effectively in GlobalProtect requires specific certificate attributes and configurations.

Server Certificate (Portal/Gateway) Requirements:

Extended Key Usage (EKU): Must include Server Authentication (1.3.6.1.5.5.7.3.1) .
Subject Alternative Name (SAN):
- Must contain at least one entry.
- The exact FQDN or IP address used by clients to connect to the Portal/Gateway *must* be present in the SAN list (DNS Name or IP Address type).
- If the connection address doesn't match a SAN entry, certificate validation will fail on the client.
Type: Must be an End-Entity certificate, not a CA certificate.
Private Key: The firewall must have the private key associated with the server certificate.
Chain: The full certificate chain (Intermediate CAs, Root CA) should ideally be trusted by the client OS or imported onto the client.

Client Certificate (User/Machine) Requirements:

Extended Key Usage (EKU): Must include Client Authentication (1.3.6.1.5.5.7.3.2) .
Subject Common Name (CN):
- Cannot be empty if used for username extraction (Certificate Profile set to 'Subject') on PAN-OS versions prior to 8.1.
- On PAN-OS 8.1+, empty CN is technically allowed if SAN is present and marked critical (per RFC 5280), but having a meaningful CN is generally recommended.
Private Key: The client device must have the private key associated with the client certificate.
Chain: The certificate must be signed by a CA that is trusted by the firewall (i.e., the CA is included in the Certificate Profile assigned to the Portal/Gateway authentication settings).

Knowing the required EKUs (Server Auth, Client Auth) and the importance of SAN matching for server certificates is crucial for troubleshooting GP certificate issues.

GP Example: Certificate-Only Authentication

This configuration allows GlobalProtect clients to authenticate using *only* a client certificate, without any user credential prompt.

This simplifies the login process but relies entirely on the security and proper issuance/revocation of client certificates.

Configuration Steps:

Certificates: Ensure Server and Client certificates meeting the requirements (see previous section ) are generated/imported. Ensure the Root CA (and any Intermediates) for the client certificates are on the firewall.
Certificate Profile: Create a Certificate Profile ( Device > Certificate Management > Certificate Profile ).
- Add the CA(s) that sign the client certificates.
- Set Username Field to Subject (or Subject Alt) to extract the username from the certificate for policy and logging.
- Configure revocation checking (recommended).
SSL/TLS Service Profile: Create or use an existing SSL/TLS Profile ( Device > Certificate Management > SSL/TLS Service Profile ) that references the correct Server Certificate for the Portal/Gateway.
GlobalProtect Portal Configuration: ( Network > GlobalProtect > Portals )
- Go to the Authentication tab. Click Add.
- Give the Client Authentication configuration a name.
- Set Authentication Profile to None .
- Set Certificate Profile to the one created in Step 2.
- (Optional) Configure OS check, etc.
- Click OK.
- Go to the Agent > [Agent Config] > App tab.
- Ensure Save User Credentials is disabled/unchecked.
- Set Authentication Override settings appropriately if needed (e.g., specify allowed cookie lifetime if generating cookies). Consider disabling cookie authentication if relying solely on certificates per connection attempt.
- Ensure Enable Single Sign-On (SSO) is *unchecked*.
GlobalProtect Gateway Configuration: ( Network > GlobalProtect > Gateways )
- Go to the Authentication tab. Click Add.
- Give the Client Authentication configuration a name.
- Set Authentication Profile to None .
- Set Certificate Profile to the one created in Step 2.
- (Optional) Configure OS check, etc.
- Click OK.
Install Certificates on Client:
- Install the Root CA (and any Intermediates) into the client's Trusted Root Certification Authorities store (Machine store recommended for reliability).
- Install the Client Certificate (with private key, P12/PFX) into the client's Personal store (User store for user-logon/on-demand, Machine store for pre-logon).
Commit changes on the firewall.
Verify Connection: The GlobalProtect client should connect automatically (or after clicking Connect) without prompting for username/password, using the installed client certificate. The username seen in logs/policy should be the one extracted from the certificate.

Key elements for cert-only auth: Auth Profile = None, Certificate Profile selected (with username extraction), client certificate installed correctly with private key and trusted chain.

GP Example: iOS Certificate Authentication

Configuring GlobalProtect certificate authentication on Apple iOS devices requires careful certificate deployment, often using tools like Apple Configurator or an MDM solution.

Requires GlobalProtect App 5.0+ and iOS 12.0+.

Configuration Steps (Summary):

Firewall Configuration: Configure Portal, Gateway, Certificate Profile, and SSL/TLS profile as described previously (similar to Cert-Only Auth or combined with user credentials if needed). Ensure certificates meet requirements (see Requirements ).
Certificate Deployment (using Apple Configurator 2 as example):
- Install Apple Configurator 2 on a macOS machine.
- Create a new Configuration Profile ( File > New Profile ).
- Under the Certificates payload:
  - Add the Root CA certificate that signed the server certificate.
  - Add any Intermediate CA certificates for the server certificate chain.
  - Add the Client Certificate (Identity Certificate) in .p12 format (including private key). Provide the password if the .p12 is encrypted.
- Under the VPN payload:
  - Configure a new VPN connection.
  - Set Connection Type to Custom SSL .
  - Set Identifier to net.paloaltonetworks.GlobalProtect.vpn .
  - Enter the Server address (Portal address).
  - Set User Authentication to Certificate .
  - Select the Client Certificate (Identity Credential) added in the Certificates payload.
  - Set Provider Bundle Identifier to net.paloaltonetworks.GlobalProtect.client .
- Save the Configuration Profile (.mobileconfig file).
- Deploy the profile to the iOS device using Apple Configurator (connect via USB) or an MDM solution.
Trust Root CA on iOS Device: This is a crucial step often missed.
- On the iOS device, after the profile is installed, go to Settings > General > About > Certificate Trust Settings .
- Find the Root CA certificate (and any Intermediate CAs) that signed the Portal/Gateway's server certificate.
- Toggle the switch to Enable Full Trust for these CAs.
Connect via GlobalProtect App: Launch the GP app. It should use the deployed configuration and certificate to connect.

Failure to enable "Full Trust" for the server's Root CA in iOS settings is a common cause of connection failures, even if the profile and certificates are deployed correctly.

GP Troubleshooting: Empty CN in Client Certificate

Symptom: GlobalProtect client certificate authentication fails. Firewall logs (detailed below) or packet captures may show errors related to parsing the client certificate, specifically mentioning issues finding the common name (CN).

Firewall Global Counters ( show counter global filter packet-filter yes delta yes after failed attempt) might show increments in:

proxy_client_cert_parse_error
proxy_ssl_invalid_cert

Packet diag logs ( debug dataplane packet-diag set log feature flow basic ssl basic proxy basic ) might show:


     debug: pan_proxy_cfg_client_cert_handler(pan_proxy_cfg.c:1244): receive client cert
     

     debug: pan_x509_parse_dn(pan_x509.c:519): didn't find common name
     

     debug: pan_x509_parse_tbs_certificate(pan_x509.c:1998): pan_x509_parse_dn() failed
     

     ...
     

     Error: pan_proxy_cfg_client_cert_handler(pan_proxy_cfg.c:1292): failed to parse client cert

(Logs from PAN-OS 8.0 example in source)

Cause:

The client certificate being presented has an empty Subject Common Name (CN) field.
While RFC 5280 allows empty subjects if a critical Subject Alternative Name (SAN) extension is present, PAN-OS versions prior to 8.1 did not fully support certificates with empty CNs for client authentication.
Even on PAN-OS 8.1+, if the SAN extension exists but is not marked as critical when the Subject is empty, the firewall might reject the certificate as non-RFC compliant during parsing (as shown in the secondary log example in the source).

Resolution:

Re-issue Client Certificate: The most reliable solution is to have the CA re-issue the client certificate with a non-empty, meaningful Subject Common Name.
Check SAN Critical Flag (8.1+): If using PAN-OS 8.1+ and an empty Subject CN is absolutely necessary, ensure the Subject Alternative Name (SAN) extension exists AND is marked as 'critical' within the certificate structure itself. Consult your CA documentation on how to achieve this.
Upgrade PAN-OS: If running a version prior to 8.1, upgrading might improve compatibility, but ensuring a valid CN or correctly formatted critical SAN is preferred.

Empty Subject CNs in client certificates can cause unexpected authentication failures, especially on older PAN-OS versions or if SAN extensions are not correctly marked critical.

GP Troubleshooting: Kerberos SSO & Cert Auth Conflict

Symptom: GlobalProtect connection fails when using Kerberos SSO combined with Client Certificate authentication ( Client Authentication set to User Credentials AND Client Certificate Required ). The specific error seen in the firewall system logs ( less mp-log gpsvc.log ) is:


     Authentication failed. Username in client cert ([CertUsername]) is different from the input ([KerberosUsername]). User name from certificate is [CertUsername]. Input user name is [KerberosUsername]

Cause:

The firewall is configured to extract a username from the client certificate (Certificate Profile's Username Field is set to Subject or Subject Alt ).
The firewall is also performing Kerberos SSO, which provides a username from the Kerberos ticket (e.g., the User Principal Name or sAMAccountName).
The firewall attempts to compare the username obtained from the certificate with the username obtained from Kerberos. If they do not match exactly (including case and domain format), the authentication fails as a security check.

Resolution:

Navigate to the Certificate Profile used for client authentication ( Device > Certificate Management > Certificate Profile > [profile-name] ).
Change the Username Field setting from 'Subject' or 'Subject Alt' to None .
Click OK .
Commit the changes.

Explanation: By setting the Username Field to 'None', you tell the firewall *not* to extract a username from the certificate for comparison purposes when Kerberos is also used. The firewall will still validate the certificate against the trusted CA and check revocation status, but it will rely solely on the username provided by the successful Kerberos SSO authentication for identity. The certificate acts purely as a required *factor* for authentication, not as the source of the username in this combined scenario.

Understand how combining multiple authentication factors (Kerberos + Certificate) requires careful configuration of how usernames are derived and compared.

When requiring both credentials (obtained via Kerberos SSO in this case) AND a client certificate, set the Certificate Profile's Username Field to 'None' to avoid username mismatch errors.

Interactive Quiz: Certificate Authentication

Test your understanding of Palo Alto Networks Certificate Profiles and Authentication.

1. What is the primary purpose of a Certificate Profile on a Palo Alto Networks firewall?

To generate server certificates for the firewall. To store private keys securely. To define trusted CAs and certificate validation settings (revocation, username extraction) for features like GP or Admin Auth. To configure SSL/TLS protocol versions.

2. When configuring Certificate-Based Authentication for the Web UI, what happens immediately after committing the change that applies the Certificate Profile in Authentication Settings?

All users are immediately logged out but can log back in with passwords. Only the committing administrator needs a certificate immediately. The firewall automatically generates client certificates for all administrators. The management web server likely restarts, terminating sessions, and ALL subsequent Web UI logins require a valid client certificate.

3. In a Certificate Profile, what does setting the 'Username Field' to 'Subject' typically instruct the firewall to do?

Extract the username from the Common Name (CN) field of the certificate's Subject. Extract the username from the Subject Alternative Name (SAN) extension. Ignore the certificate for username information and rely on another method. Use the certificate's serial number as the username.

4. Which Extended Key Usage (EKU) is typically required for a GlobalProtect Portal/Gateway server certificate?

Client Authentication Server Authentication Code Signing IPsec Tunnel

5. What is a critical requirement for the Subject Alternative Name (SAN) extension in a GlobalProtect Portal/Gateway server certificate?

It must contain the exact FQDN or IP address that clients use to connect. It must contain the administrator's email address. It must be marked as 'critical'. It is optional if the Common Name matches the connection address.

6. When configuring GlobalProtect for certificate-only authentication (no user credentials prompt), what should the 'Authentication Profile' typically be set to in the Portal and Gateway authentication settings?

A profile pointing to the Local User Database. A profile using SAML authentication. None The same Certificate Profile used for validation.

7. Which certificate store on a Windows client machine should a user's client certificate (with private key) typically be imported into for GlobalProtect 'user-logon' or 'on-demand' connections?

Computer Account - Trusted Root Certification Authorities Current User - Personal Computer Account - Personal Current User - Trusted Root Certification Authorities

8. On an iOS device using GlobalProtect with certificate authentication, what extra step is often required after deploying the configuration profile containing the certificates?

Manually enabling "Full Trust" for the server's Root CA in Settings > General > About > Certificate Trust Settings. Restarting the iOS device twice. Re-installing the GlobalProtect app. Entering the certificate password in the GlobalProtect app settings.

9. If GlobalProtect fails with the error "Username in client cert is different from the input" when using Kerberos SSO and Certificate Authentication together, what is the likely misconfiguration?

The Kerberos server profile is incorrect. The client certificate has expired. The SSL/TLS Service Profile is missing. The Certificate Profile's 'Username Field' is set to 'Subject' or 'Subject Alt' instead of 'None'.

10. On PAN-OS 8.0 and earlier, what issue might arise if a client certificate used for GlobalProtect authentication has an empty Subject Common Name (CN)?

The firewall automatically uses the email address from SAN. The connection succeeds but logs a warning. The firewall may fail to parse the certificate, leading to authentication failure. GlobalProtect prompts the user to manually enter a username.

11. When configuring a Certificate Profile for revocation checking, what is the recommended approach if both OCSP and CRL are available?

Enable only OCSP for faster checks. Enable both OCSP and CRL for redundancy (OCSP preferred, CRL fallback). Enable only CRL as it's more widely supported. Disable revocation checking if certificates have short validity periods.

12. In a Certificate Profile, what does checking "Block sessions if certificate status cannot be retrieved within timeout" achieve?

It enhances security by preventing connections if the revocation status (good, revoked, or unknown) cannot be determined due to CRL/OCSP reachability issues. It improves performance by skipping revocation checks during peak hours. It allows connections even if the OCSP responder explicitly returns an 'unknown' status. It automatically generates a temporary allow rule if the CRL server is down.

13. Which file format is typically used when exporting a client or machine certificate *with its private key* for installation on a client device (Windows/macOS/iOS)?

PEM (.pem, .crt) DER (.der) Base64 Encoded PKCS#12 (.p12, .pfx)

14. For GlobalProtect certificate-only authentication, where do you specify the CA certificate(s) that the firewall should use to validate incoming client certificates?

In the SSL/TLS Service Profile. In the Authentication Profile. In the Certificate Profile assigned to the Portal/Gateway's Client Authentication settings. Device > Certificate Management > Trusted Root CAs list.

15. When deploying certificates to iOS using Apple Configurator for GlobalProtect, what 'Connection Type' should be selected in the VPN payload?

IPSec (Cisco) Custom SSL L2TP IKEv2

16. What is the primary function of an SSL/TLS Service Profile in the context of GlobalProtect?

To define trusted CAs for client certificate validation. To configure CRL and OCSP settings. To specify the authentication method (RADIUS, LDAP, etc.). To specify the server certificate the Portal/Gateway presents to clients and the allowed SSL/TLS protocol versions.

17. If a server certificate used by GlobalProtect is signed by an Intermediate CA, what must be ensured for successful client validation?

The client must trust the Root CA, and the firewall should ideally send the Intermediate CA certificate during the TLS handshake. The Intermediate CA certificate must be imported into the client's Personal store. The SSL/TLS Service Profile must reference the Intermediate CA certificate directly. The Intermediate CA must also have the 'Server Authentication' EKU.

18. When is a 'Machine Certificate' typically used in GlobalProtect?

For authenticating the user during on-demand connections. For encrypting traffic within the VPN tunnel. For authenticating the device during 'pre-logon' connections before a user logs into the machine. For authenticating the GlobalProtect Gateway to the Portal.

19. In the Certificate Profile setting "Block sessions if the certificate was not issued to the authenticating device", what two pieces of information are compared?

Certificate Subject CN and the username from Kerberos. An attribute in the certificate (often serial number in Subject) and the Host ID reported by the GlobalProtect client. The certificate's issuer and the firewall's hostname. The certificate's expiry date and the current system time.

20. Which is NOT a primary function of a Certificate Profile?

Specifying trusted CA certificates. Enabling CRL or OCSP checking. Defining how to extract a username from a certificate. Specifying the server certificate the firewall uses for SSL/TLS.