Next-Generation Firewall
Keys and Certificates
Table of Contents
Expand All
|
Collapse All
Next-Generation Firewall Docs
-
-
-
-
-
-
-
- PAN-OS 12.1
- PAN-OS 11.2
- PAN-OS 11.1
- PAN-OS 11.0 (EoL)
- PAN-OS 10.2
- PAN-OS 10.1
- PAN-OS 10.0 (EoL)
- PAN-OS 9.1 (EoL)
- PAN-OS 9.0 (EoL)
- PAN-OS 8.1 (EoL)
-
- PAN-OS 12.1
- PAN-OS 11.2
- PAN-OS 11.1
- PAN-OS 10.2
- PAN-OS 10.1
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.
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:
|
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.