>
    Keys and Certificates
    Focus
    Download PDF
    Focus
    1. Home
    2. Next-Generation Firewall
    3. Certificate Management
    4. Keys and Certificates
    Download PDF
    Next-Generation Firewall

    Keys and Certificates

    Table of Contents

    Keys and Certificates

    Understand the fundamental concepts of digital certificates and cryptographic keys needed for secure communications on Palo Alto Networks firewalls.
    Understanding how certificates and keys work together is essential for network security. While certificates verify identities and contain public keys, private keys (securely stored on your device) provide cryptographic proof of certificate ownership and decrypt incoming communications.
    Cryptographic keys are numerical strings typically generated through mathematical operations involving random numbers and large primes. These keys transform data, such as passwords and shared secrets, from unencrypted plaintext to encrypted ciphertext and from encrypted ciphertext to unencrypted plaintext. Keys can be symmetric (the same key encrypts and decrypts) or asymmetric (one key encrypts and a mathematically related key decrypts). This mathematical relationship enables secure communications without requiring the exchange of secret keys beforehand.
    The SSL/TLS protocol use public-key cryptography (or asymmetric cryptography) to establish secure web communications. Each key pair in this system consists of a public key and a private key. A website's SSL/TLS certificate contains the public key, which is shared freely. The private key is kept hidden. Private keys can be stored on firewalls, in keystores, or in hardware security modules (HSMs). Together with certificates, keys ensure that sensitive data remains protected during transmission.
    Key management is critical to your NGFWs security posture. Private keys require safeguarding, as compromise could allow attackers to impersonate legitimate services or decrypt sensitive communications. Palo Alto Networks NGFWs provide secure storage for private keys and robust key management features to help you maintain the integrity of your encryption infrastructure.
    The following table describes the various keys and certificates that Palo Alto Networks firewalls and Panorama use.
    For maximum security, use different keys and certificates for each application or use case.
    Palo Alto Networks Device Keys and Certificates
    Certificate or Key Usage
    Description
    Administrative Access
    Secure access to firewall or Panorama administration interfaces (HTTPS access to the web interface) requires a server certificate for the MGT interface (or a designated interface on the dataplane if the firewall or Panorama does not use MGT) and, optionally, a certificate to authenticate the administrator.
    Authentication Portal
    In deployments where Authentication policy rules identify users who access HTTPS resources, designate a server certificate for the Authentication Portal interface. If you configure Authentication Portal to use certificates for user identification (instead of, or in addition to, interactive authentication), deploy client certificates as well. For more information on Authentication Portal, see Map IP Addresses to Usernames Using Authentication Portal.
    Forward Trust
    For outbound SSL/TLS traffic, if a firewall acting as a forward proxy trusts the CA that signed the certificate of the destination server, the firewall uses the forward trust CA certificate to generate a copy of the destination server certificate to present to the client. To set the private key size, see Configure the Key Size for SSL Forward Proxy Server Certificates. For added security, store the private key on a hardware security module (HSM).
    Forward Untrust
    For outbound SSL/TLS traffic, if a firewall acting as a forward proxy doesn't trust the CA that signed the certificate of the destination server, the firewall uses the forward untrust CA certificate to generate a copy of the destination server certificate it presents to the client.
    SSL Inbound Inspection
    The keys that decrypt inbound SSL/TLS traffic for inspection and policy enforcement. For this application, import a private key for each server that is subject to SSL/TLS inbound inspection. See Configure SSL Inbound Inspection.
    Firewalls use the Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE) algorithm to perform strict certificate checking. This means that if the firewall uses an intermediate certificate, you must reimport the certificate from your web server to the firewall and combine the server certificate with the intermediate certificate (install a chained certificate). Otherwise, SSL Inbound Inspection sessions that have an intermediate certificate in the chain will fail. To install a chained certificate:
    1. Open each certificate (.cer) file in a plain-text editor such as Notepad.
    2. Paste each certificate end-to-end with the Server Certificate at the top with each signer included below.
    3. Save the file as a text (.txt) or certificate (.cer) file (the name of the file cannot contain blank spaces).
    4. Import the combined (chained) certificate into the firewall.
    GlobalProtect
    All interaction among GlobalProtect components occurs over SSL/TLS connections. Therefore, as part of the GlobalProtect deployment, deploy server certificates for all GlobalProtect portals, gateways, and Mobile Security Managers. Optionally, deploy certificates for authenticating users also.
    The GlobalProtect Large Scale VPN (LSVPN) feature requires a CA signing certificate.
    Site-to-Site VPNs (IKE)
    In a site-to-site IPSec VPN deployment, peer devices use Internet Key Exchange (IKE) gateways to establish a secure channel. IKE gateways use certificates or preshared keys to authenticate the peers to each other. You can configure and assign the certificates or keys when defining an IKE gateway on a firewall.
    Master Key
    The firewall uses a master key to encrypt all private keys and passwords. If your network requires a secure location for storing private keys, you can use an encryption (wrapping) key stored on an HSM to encrypt the master key. For details, see Encrypt and Refresh Master Keys Using an HSM.
    Secure Syslog
    The certificate to enable secure connections between the firewall and a syslog server. See Syslog Field Descriptions.
    Trusted Root CA
    The designation for a root certificate issued by a CA that the firewall trusts. The firewall can use a self-signed root CA certificate to automatically issue certificates for other applications (for example, SSL Forward Proxy).
    Also, if a firewall must establish secure connections with other firewalls, the root CA that issues their certificates must be in the list of trusted root CAs on the firewall.
    (Panorama managed firewalls) The Trusted Root CA setting for a CA must be configured as part of the template configuration, and not part of the template stack configuration. If you configure the Trusted Root CA setting for a CA as part of the template stack configuration, the associated templates do not inherit the setting for the CA.
    Inter-Device Communication
    By default, Panorama, firewalls, and Log Collectors use a set of predefined certificates for the SSL/TLS connections used for management and log forwarding. However, you can enhance these connections by deploying custom certificates to the devices in your deployment. These certificates can also be used to secure the SSL/TLS connection between Panorama HA peers.

    Certificates

    Digital certificates (also known as X.509 certificates or SSL/TLS certificates) contain a cryptographic key to encrypt plaintext or decrypt ciphertext. Each certificate includes a digital signature to authenticate the identity of the issuer. Certificate authorities (CAs) issue these certificates to verify the identity of entities such as clients or servers.
    On Palo Alto Networks firewalls, certificates play a crucial role in device and user authentication and securing communications. When properly implemented and managed, certificates help ensure that traffic remains encrypted, endpoints are authenticated, and communications are secure from eavesdropping and tampering.
    A digital certificate contains several basic fields or components:
    • Version–The version of the encoded certificate.
    • Serial Number–A unique integer given to the certificate (unique for all certificates issued from the same CA)
    • Signature–The identifier for the cryptographic algorithm the CA used to sign the certificate
    • Issuer–The CA that signed and issued the certificate
    • Validity–The time window a certificate is valid between
    • Subject–The entity to which the certificate was issued
    • Subject Public Key Info–Contains the public key and identifies the algorithm with which the key is used (for example, RSA, DSA, or Diffie-Hellman)
    • Unique Identifiers–Present only in version 2 or 3 certificates, these identifiers handle potential reuse of subject and issuer names over time
    An organization that issues certificates can establish a hierarchy of CAs. The root CA has a self-signed certificate. Each subordinate CA has a certificate that is signed by the next highest CA in the hierarchy. A certificate chain is the certificate of a particular CA, plus the certificates of any higher CAs up through the root CA.
    A certificate issuer must be in the authenticating party's list of trusted certificate authorities. Optionally, the authenticating party verifies the issuer did not revoke the certificate (see Certificate Revocation).
    Palo Alto Networks supports several certificate types to accommodate different security needs:
    • Enterprise CA certificates (unlike most certificates purchased from a trusted, third-party CA) leverage your organization's existing public key infrastructure (PKI) and can automatically issue certificates for applications such as SSL/TLS decryption or large scale VPN deployments.
    • External CA certificates come from trusted third-party CAs–either well-known public CA or enterprise CAs–and provide broader recognition outside your organization.
    • Device certificates enable secure access to certain cloud services.
    • Self-signed certificates offer a way to quickly generate certificates without external validation, which is useful for testing or internal applications. The owner and issuer of self-signed certificates are the same. You can obtain, provision, and renew these certificates through Palo Alto Networks firewall interfaces.

    © 2025 Palo Alto Networks, Inc. All rights reserved.