Configure Certificate Profiles

Overview

Certificate Profiles are fundamental components in Palo Alto Networks firewalls used to validate digital certificates presented by clients or devices during authentication or secure communication establishment. They define the parameters the firewall uses to determine if a presented certificate is trustworthy and valid.

Essentially, a Certificate Profile tells the firewall:

Which Certificate Authorities (CAs) do you trust to sign certificates?
How should you check if a certificate, even if signed by a trusted CA, has been revoked (cancelled before its expiry date)?
What specific attributes within the certificate should be used to identify the user or device?
How should you handle situations where revocation status cannot be determined?

Configuring Certificate Profiles correctly is crucial for securely implementing features that rely on certificate-based authentication.

Common Use Cases

Certificate Profiles are referenced in various features, including:

Authentication Portal: Validating client certificates for portal access.
Multi-Factor Authentication (MFA): Often used as one factor or for device posture checking in MFA flows.
GlobalProtect VPN (Portals and Gateways): Authenticating users and/or devices connecting via GlobalProtect using client certificates.
Site-to-Site IPSec VPN: Authenticating peer VPN gateways using certificates instead of pre-shared keys.
SSL Decryption: Validating server certificates during SSL Forward Proxy decryption (though often uses built-in trust). Used more explicitly for client certificate validation in specific scenarios.
External Dynamic List (EDL) Server Validation: Validating the certificate presented by an EDL server hosting a list over HTTPS.
Dynamic DNS (DDNS) Secure Updates: Validating DDNS server certificates.
User-ID Agent / Terminal Server (TS) Agent Communication: Securing communication between the firewall and User-ID agents using certificates.
Management Access: Configuring certificate-based authentication for administrators accessing the firewall Web UI or CLI.
Panorama Communication: Securing communication between firewalls and Panorama using certificates.

     Be familiar with the common use cases where Certificate Profiles are applied, particularly GlobalProtect, IPSec VPNs, Authentication Portal, and administrative access.
    

Configuration: CA Certificates

The foundation of a Certificate Profile is the list of Certificate Authority (CA) certificates that the firewall trusts. A client certificate presented to the firewall will only be considered potentially valid if it chains up to one of the CA certificates listed in the profile.

Obtaining/Managing CA Certificates ( Device > Certificate Management > Certificates )

Importing Existing CA Certificates:
- If your organization uses an internal Enterprise CA (e.g., Microsoft AD Certificate Services), export the Root CA certificate (and potentially any Intermediate CA certificates in the chain) in PEM or DER format.
- Import these CA certificates into the firewall's certificate store ( Device > Certificate Management > Certificates > Import ). Ensure you mark them as trusted CA certificates during import.
- You might also need to import public CA certificates if validating external client certificates signed by well-known public CAs, although the firewall has a built-in list of common public CAs.
Generating a Self-Signed Root CA:
- The firewall can act as a Root CA itself ( Device > Certificate Management > Certificates > Generate ).
- Select "Self-Signed Root CA".
- Configure parameters like Common Name, cryptographic settings, and validity period.
- This self-signed CA can then be used to issue certificates for other purposes (e.g., firewall management, VPNs), and clients/devices would need to trust this firewall-generated Root CA.

Once CA certificates are present in the firewall's certificate store, they can be added to a Certificate Profile.

     Understand that Certificate Profiles rely on CA certificates already imported or generated on the firewall. Know the difference between importing an external CA and generating a self-signed CA on the firewall itself.
    

Configuration: Creating the Certificate Profile

Certificate Profiles are configured under Device > Certificate Management > Certificate Profile .

Steps:

Click Add to create a new profile.
Name: Provide a unique and descriptive name (e.g., GlobalProtect_Client_Cert_Check , Admin_UI_Cert_Auth ).
Location (Panorama/Multi-VSYS): Select the appropriate VSYS or choose 'Shared' if applicable.
CA Certificates Section:
- Click Add in this section.
- Select the CA certificate(s) from the firewall's certificate store that you want this profile to trust. You can add multiple CAs to a single profile.
- Only client certificates signed by one of these selected CAs (or an intermediate CA that chains up to one of them) will pass the initial trust check.
Configure Verification Settings (detailed next).
Configure Username Field (detailed later).
Click OK to save the profile.

     The core function starts here: linking the profile to the specific CAs whose issued certificates you intend to accept.
    

Configuration: Certificate Verification Settings

Beyond trusting the CA, the Certificate Profile defines how the firewall checks if a presented certificate, although validly signed, has been revoked (cancelled) by the CA before its natural expiration date. This is crucial for security, as compromised certificates need to be invalidated.

Two primary mechanisms are used:

Certificate Revocation List (CRL)

Concept: The CA periodically publishes a signed list (CRL) containing the serial numbers of all revoked certificates it has issued.
Firewall Action: When Use CRL is enabled, the firewall needs to periodically download the CRL from a distribution point (usually an HTTP or LDAP URL specified in the client certificate or the CA certificate). It then checks the serial number of the presented certificate against this downloaded list.
Configuration: Requires the firewall to have network connectivity to the CRL Distribution Point (CDP) URL. You configure the CRL Receive Timeout .
Pros/Cons: Simpler protocol, but lists can become large, and there's latency between revocation and publication/download.

Online Certificate Status Protocol (OCSP)

Concept: Provides a real-time method for checking revocation status.
Firewall Action: When Use OCSP is enabled, the firewall contacts an OCSP Responder server (usually specified in the certificate's Authority Information Access - AIA extension) for the specific certificate being validated. The OCSP responder provides a signed response indicating the certificate's status (good, revoked, or unknown).
Configuration: Requires the firewall to have network connectivity to the OCSP responder URL. You configure the OCSP Receive Timeout .
Pros/Cons: Provides more up-to-date status, less download overhead than large CRLs, but relies on the availability and responsiveness of the OCSP responder. Requires more complex request/response handling.

Profile Settings for Verification:

Use CRL: Enable checkbox to perform CRL checking.
Use OCSP: Enable checkbox to perform OCSP checking.

      
       Order:
      
      If both CRL and OCSP are enabled, the firewall attempts OCSP first. If the OCSP check fails (e.g., responder unreachable, timeout) or returns 'unknown', it then falls back to checking the CRL (if available and configured).

CRL Receive Timeout (seconds): Max time to wait for CRL download.
OCSP Receive Timeout (seconds): Max time to wait for OCSP response.
Certificate Status Timeout (seconds): How long the firewall caches a verified status (good or revoked) before re-checking.
Block session if certificate status is unknown: (Security Enhancement) If checked, sessions are blocked if neither OCSP nor CRL provides a definitive 'good' or 'revoked' status (e.g., both checks fail or time out). If unchecked, an unknown status might be treated as 'good' (less secure).
Block sessions if certificate status cannot be retrieved within timeout: (Security Enhancement) Explicitly block if the CRL/OCSP checks time out based on their respective timeout settings.
Block sessions if the certificate was not issued to the authenticating device (GlobalProtect only): Specific check for GlobalProtect client certificates.

     Understand the difference between CRL (list download) and OCSP (real-time query). Know the check order (OCSP then CRL). Recognize the importance of the "Block session if certificate status is unknown" and timeout settings for security posture.
    

Configuration: Username Field and Domain

When using client certificates for user authentication (e.g., GlobalProtect, Admin UI, Authentication Portal), the Certificate Profile needs to know which field within the certificate contains the user's identity (username).

Username Field Options:

Subject - Common Name (CN): Extracts the username from the Common Name (CN) field within the certificate's Subject distinguished name (DN).
- Example Subject: CN=johndoe, OU=Users, DC=corp, DC=com -> Username = johndoe
Subject Alternative Name (SAN) - Email: Extracts the username from the RFC822 Name (Email address) field within the certificate's Subject Alternative Name (SAN) extension.
- Example SAN: Email=john.doe@corp.com -> Username = john.doe@corp.com
Subject Alternative Name (SAN) - Principal Name: Extracts the username from the User Principal Name (UPN) field within the certificate's SAN extension. Common in Active Directory environments.
- Example SAN: UPN=johndoe@corp.com -> Username = johndoe@corp.com
None: Do not extract a username from the certificate. This is typically used when the certificate is used purely for device identification or pre-logon authentication, not primary user authentication.

     The choice of Username Field must match how usernames are populated in the client certificates issued by your CA. Mismatches will lead to authentication failures or incorrect user mapping.
    

Domain

Purpose: Optionally specify a domain name (e.g., NetBIOS domain name like `CORP`) to associate with the username extracted from the certificate.
Use Case: Helps User-ID map the certificate-derived username (which might lack a domain) to a fully qualified domain user (e.g., `CORP\johndoe`) for policy enforcement based on directory group membership.
Configuration: Enter the domain name in the `Domain` field.

     Know the different Username Field options (CN, SAN-Email, SAN-Principal Name) and their purpose in extracting user identity from a certificate for authentication and User-ID mapping.
    

Best Practices for Certificate Profiles

Enable Revocation Checking: Always enable both OCSP and CRL checking for robust validation, unless there's a specific, documented reason not to. Prioritize OCSP for timeliness but keep CRL as a fallback.
Configure Blocking for Unknown Status: For higher security, enable "Block session if certificate status is unknown" and "Block sessions if certificate status cannot be retrieved within timeout" . This prevents potentially revoked certificates from being used if revocation checking fails. Be aware this can cause outages if CRL/OCSP responders are unavailable. Monitor closely after enabling.
Tune Timeouts Carefully: Set CRL/OCSP Receive Timeouts appropriately based on network latency to responders. Too short may cause false failures; too long can delay user connections. Default (often 5 seconds) is usually reasonable, but monitor.
Use Correct Username Field: Ensure the selected Username Field (CN, SAN-Email, SAN-Principal Name) accurately matches where the user identity is stored in your issued client certificates.
Maintain CA Trust Store: Regularly review and update the CA certificates included in the profile and stored on the firewall. Remove expired or untrusted CAs.
Use Descriptive Names: Name Certificate Profiles clearly based on their intended use case (e.g., `GP_User_Cert_Profile`, `Admin_UI_CAC_Profile`).
Verify Network Connectivity: Ensure the firewall has network routes and policy rules allowing it to reach the necessary CRL Distribution Points (CDPs) and OCSP Responders (typically over HTTP/80). Use source NAT if necessary.

Diagrams: Certificate Profile Concepts

Sequence Diagram: Client Certificate Validation

Sequence diagram illustrating the steps firewall takes to validate a client certificate using a Certificate Profile, including OCSP and CRL checks.

Flowchart: Certificate Profile Decision Logic

Flowchart showing the decision logic for certificate validation based on Certificate Profile settings.

Graph: Certificate Profile Ecosystem

Graph showing relationships between Certificate Profiles, CAs, revocation services, and firewall features that utilize them.

State Diagram: Certificate Validation Status

State diagram showing the possible outcomes of the certificate validation process based on trust and revocation checks.

Troubleshooting Certificate Profile Issues

Failures related to Certificate Profiles often manifest as failed authentications (GlobalProtect, Admin UI, etc.) or failed secure connections (IPSec, EDL).

Common Issues & Checks:

Untrusted Issuer:
- Symptom: Connection fails, logs might indicate "Certificate issuer is not trusted".
- Cause: The CA certificate that signed the client/server certificate (or an intermediate CA in the chain) is not included in the 'CA Certificates' list of the applied Certificate Profile, or is not marked as trusted in the firewall's certificate store.
- Fix: Import the necessary Root CA and Intermediate CA certificates, ensure they are marked as trusted, and add them to the Certificate Profile.
Revocation Check Failure (CRL/OCSP):
- Symptom: Connection fails, logs might indicate "Certificate revoked", "Unable to get certificate CRL", "Unable to get OCSP response", "Certificate status unknown".
- Cause (CRL): Firewall cannot reach the CDP URL (network connectivity, routing, policy block, DNS failure), CRL is expired, CRL signature is invalid, CRL download timed out.
- Cause (OCSP): Firewall cannot reach the OCSP Responder URL, OCSP responder is down or slow, OCSP response signature is invalid, OCSP response indicates 'revoked' or 'unknown', OCSP request timed out.
- Fix:
  - Verify network connectivity (ping, traceroute from firewall CLI to CDP/OCSP URLs). Use appropriate source interface if needed.
  - Check Security Policy rules to ensure traffic (HTTP/80 typically) to CDP/OCSP URLs is allowed.
  - Verify DNS resolution for CDP/OCSP hostnames.
  - Check validity of the CRL/OCSP responder certificate itself.
  - Adjust CRL/OCSP timeouts in the Certificate Profile if necessary due to latency, but investigate underlying cause first.
  - Check the CA's infrastructure if CRL/OCSP is consistently unavailable.
  - Temporarily disable "Block session if certificate status is unknown" for testing, but re-enable for security.
- Troubleshooting Commands:
  debug pki validation enable yes level 9 (Use cautiously, generates lots of output)
  
  tail follow yes mp-log pki.log
  
  show certificate <cert-name> crl-status
  
  show certificate <cert-name> ocsp-status
  
  test certificate-status crl url <url>
  
  test certificate-status ocsp url <url> certificate <cert-name>
Username Extraction Failure:
- Symptom: Certificate validation might pass, but authentication fails, often with generic "Authentication failed" messages. User-ID mapping might fail.
- Cause: The "Username Field" setting in the Certificate Profile (CN, SAN-Email, SAN-Principal) does not match the field where the actual username is located within the presented client certificate.
- Fix: Inspect a sample client certificate to confirm where the username is stored (Subject CN, SAN Email, SAN UPN). Adjust the Certificate Profile's "Username Field" setting accordingly.
Expired Certificates: Ensure the client certificate, intermediate CA certificates, and root CA certificates are all within their validity periods. Check system time/NTP on the firewall.

     Troubleshooting often involves verifying the CA trust chain, checking network connectivity for CRL/OCSP, examining logs (`pki.log`, System, Auth), and ensuring the Username Field setting matches the certificate content.
    

PCNSE Exam Focus Points

Key areas related to Certificate Profiles for the PCNSE exam:

Purpose: Understand that Certificate Profiles define parameters for validating client/peer certificates, primarily focusing on issuer trust and revocation status checking .
Configuration Location: Know that Certificate Profiles are configured under Device > Certificate Management > Certificate Profile .
CA Certificates: Recognize that profiles rely on CA certificates already imported into the firewall ( Device > Certificate Management > Certificates ) and marked as trusted.
Revocation Checking Methods:
- CRL (Certificate Revocation List): Know it's a downloaded list of revoked serial numbers. Understand the need for CDP reachability.
- OCSP (Online Certificate Status Protocol): Know it's a real-time query to an OCSP responder. Understand the need for responder reachability.
- Check Order: Remember that if both are enabled, OCSP is checked first , and CRL is used as a fallback if OCSP fails or returns 'unknown'.
Key Verification Settings: Understand the implications of enabling/disabling CRL/OCSP, setting timeouts, and especially the security impact of the "Block session if certificate status is unknown" option.
Username Extraction: Know the options for the Username Field ( Subject - Common Name , Subject Alternative Name - Email , Subject Alternative Name - Principal Name , None) and their purpose in identifying the user from the certificate for features like GlobalProtect authentication or Admin UI login.
Common Use Cases: Be familiar with scenarios where Certificate Profiles are essential, such as GlobalProtect (Portal/Gateway), certificate-based IPSec VPNs, certificate-based Admin UI authentication, and Authentication Portal.
Troubleshooting Basics: Recognize common failure points like untrusted CAs, CRL/OCSP connectivity issues, and incorrect username field selection.

     Focus on the purpose of the profile, the difference and interplay between CRL and OCSP, the key configuration options (CA list, revocation checks, block on unknown, username field), and common application areas (GP, VPN, Admin Auth).
    

Certificate Profiles Knowledge Check (PCNSE Style)

Test your understanding of Certificate Profiles.

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

To generate new SSL/TLS certificates for web servers. To configure the encryption algorithms for IPSec VPNs. To define parameters for validating client/peer certificates, including trusted CAs and revocation checking. To store private keys associated with the firewall's own certificates.

2. Where in the PAN-OS GUI are Certificate Profiles configured?

Network > Network Profiles > SSL/TLS Service Profile Device > Certificate Management > Certificate Profile Device > Authentication Profile Objects > Security Profiles > Decryption

3. What must be done with Certificate Authority (CA) certificates before they can be added to a Certificate Profile?

They must be signed by Palo Alto Networks. They must be configured within an Authentication Profile. They must be exported to Panorama. They must be imported into the firewall's certificate store (Device > Certificate Management > Certificates) and marked as trusted CAs.

4. Which certificate revocation method involves the firewall downloading a published list of revoked certificate serial numbers?

CRL (Certificate Revocation List) OCSP (Online Certificate Status Protocol) SCP (Secure Certificate Protocol) LDAP (Lightweight Directory Access Protocol)

5. Which certificate revocation method involves the firewall sending a real-time query to a dedicated server for the status of a specific certificate?

CRL (Certificate Revocation List) OCSP (Online Certificate Status Protocol) CDP (CRL Distribution Point) AIA (Authority Information Access)

6. If both "Use CRL" and "Use OCSP" are enabled in a Certificate Profile, which method does the firewall attempt first?

CRL Whichever responds faster. OCSP Both simultaneously.

7. What is the security implication of NOT enabling "Block session if certificate status is unknown"?

It improves firewall performance significantly. It forces the firewall to only use CRL checking. It prevents users with valid certificates from connecting. It might allow a user with a potentially revoked certificate to connect if CRL/OCSP checks fail or time out.

8. Which "Username Field" option in a Certificate Profile would you use if the username is stored in the email address field of the certificate's SAN extension?

Subject - Common Name (CN) Subject Alternative Name (SAN) - Email Subject Alternative Name (SAN) - Principal Name None

9. Which feature commonly uses a Certificate Profile to validate client certificates for remote user access?

GlobalProtect Portal/Gateway Zone Protection Profile QoS Profile Log Forwarding Profile

10. When troubleshooting certificate validation failures, which firewall log often contains detailed information about PKI operations, including CRL/OCSP checks?

Traffic Log Threat Log PKI Log (`pki.log` via CLI) Configuration Log

11. If a client presents a certificate signed by an Intermediate CA, what must be included in the Certificate Profile's CA list for validation to succeed?

Only the Intermediate CA certificate. Only the client's certificate. The Intermediate CA certificate and the client's certificate. The Root CA certificate that issued the Intermediate CA certificate (or the Intermediate CA itself if explicitly trusted).

12. What network connectivity is required for successful CRL validation?

Connectivity from the firewall (usually management interface) to the CRL Distribution Point (CDP) URL (typically HTTP). Connectivity from the client device to the firewall's management interface. Connectivity between the HA peers over the HA2 link. Connectivity from the firewall to the client device over TCP port 389.

13. Setting the "Username Field" to "None" in a Certificate Profile is typically appropriate when:

Authenticating administrators via LDAP. Using certificates for GlobalProtect user authentication. Using certificates for device identification (e.g., IPSec peer) or pre-logon, where user identity is not derived from the certificate. The username is always located in the Subject CN field.

14. What potential issue can arise if the Certificate Status Timeout is set too low?

Increased security due to more frequent checks. Increased load on the firewall and CRL/OCSP responders due to frequent re-validation checks. Users being unable to connect with valid certificates. Failure to download CRLs correctly.

15. Which feature allows you to create a Certificate Authority directly on the Palo Alto Networks firewall?

Certificate Profile SSL/TLS Service Profile Authentication Profile Certificate Management (Generate option)

16. An administrator imports their Enterprise Root CA certificate but forgets to check the "Trusted Root CA" box during import. What is the likely result when using it in a Certificate Profile?

Certificate validation using this profile will fail because the CA is not explicitly trusted. The firewall will automatically trust it because it was imported. OCSP checks will work, but CRL checks will fail. The certificate cannot be added to the Certificate Profile.

17. Which certificate field is commonly used in Microsoft Active Directory environments to hold the User Principal Name (UPN)?

Subject - Common Name (CN) Subject Alternative Name (SAN) - Principal Name Subject - Organizational Unit (OU) Subject Alternative Name (SAN) - DNS Name

18. What is a potential downside of relying solely on CRLs for revocation checking?

It requires real-time connectivity to a responder for every check. It consumes excessive firewall CPU resources compared to OCSP. It cannot handle intermediate CA certificates. There can be a delay between certificate revocation and the publication/download of the updated CRL.

19. A user connects via GlobalProtect using a certificate. The Certificate Profile is configured with Username Field "Subject - Common Name" and Domain "CORP". The certificate's Subject CN is "jdoe". How will User-ID likely map this user?

CORP\jdoe jdoe jdoe@corp User mapping will fail.

20. Which troubleshooting step is most relevant if users report certificate validation failures after a CA administrator revoked several certificates?

Check the firewall's routing table. Verify the "Username Field" setting in the Certificate Profile. Ensure the firewall can reach and download the latest CRL or query the OCSP responder. Re-import the Root CA certificate into the firewall.