Network Security
Keys and Certificates for Decryption Policies
Table of Contents
Expand All
|
Collapse All
Network Security Docs
-
- Security Policy
-
- Security Profile Groups
- Security Profile: AI Security
- Security Profile: WildFire® Analysis
- Security Profile: Antivirus
- Security Profile: Vulnerability Protection
- Security Profile: Anti-Spyware
- Security Profile: DNS Security
- Security Profile: DoS Protection Profile
- Security Profile: File Blocking
- Security Profile: URL Filtering
- Security Profile: Data Filtering
- Security Profile: Zone Protection
-
- Policy Object: Address Groups
- Policy Object: Regions
- Policy Object: Traffic Objects
- Policy Object: Applications
- Policy Object: Application Groups
- Policy Object: Application Filter
- Policy Object: Services
- Policy Object: Auto-Tag Actions
- Policy Object: Devices
-
- Uses for External Dynamic Lists in Policy
- Formatting Guidelines for an External Dynamic List
- Built-in External Dynamic Lists
- Configure Your Environment to Access an External Dynamic List
- Configure your Environment to Access an External Dynamic List from the EDL Hosting Service
- Retrieve an External Dynamic List from the Web Server
- View External Dynamic List Entries
- Enforce Policy on an External Dynamic List
- Find External Dynamic Lists That Failed Authentication
- Disable Authentication for an External Dynamic List
- Policy Object: HIP Objects
- Policy Object: Schedules
- Policy Object: Quarantine Device Lists
- Policy Object: Dynamic User Groups
- Policy Object: Custom Objects
- Policy Object: Log Forwarding
- Policy Object: Authentication
- Policy Object: Decryption Profile
- Policy Object: Packet Broker Profile
-
-
-
- The Quantum Computing Threat
- How RFC 8784 Resists Quantum Computing Threats
- How RFC 9242 and RFC 9370 Resist Quantum Computing Threats
- Support for Post-Quantum Features
- Post-Quantum Migration Planning and Preparation
- Best Practices for Resisting Post-Quantum Attacks
- Learn More About Post-Quantum Security
-
-
-
- Investigate Reasons for Decryption Failure
- Identify Weak Protocols and Cipher Suites
- Troubleshoot Version Errors
- Troubleshoot Unsupported Cipher Suites
- Identify Untrusted CA Certificates
- Repair Incomplete Certificate Chains
- Troubleshoot Pinned Certificates
- Troubleshoot Expired Certificates
- Troubleshoot Revoked Certificates
Keys and Certificates for Decryption Policies
Decryption requires keys and certificates to establish trust between a client and a
server so the Next-Generation Firewall can decrypt encrypted traffic.
Where Can I Use This? | What Do I Need? |
---|---|
|
No separate license required for decryption when using NGFWs or
Prisma Access.
Note: The features and capabilities available to you in
Strata Cloud Manager depend on your active license(s).
|
Keys are strings of numbers typically generated using a mathematical operation involving
random numbers and large primes. Keys transform strings, 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 is used to
encrypt and decrypt) or asymmetric (one key is used for encryption and a mathematically
related key is used for decryption). Any system can generate a key.
X.509 certificates establish trust between a client and a server to establish an SSL
connection. A client attempting to authenticate a server (or a server authenticating a
client) knows the structure of the X.509 certificate and therefore knows how to extract
identifying information about the server from fields within the certificate, such as the
FQDN or IP address (called a Common Name or CN within the
certificate) or the name of the organization, department, or user to which the
certificate was issued. A certificate authority (CA) must issue all certificates. After
the CA verifies a client or server, the CA issues the certificate and signs it with a
private key.
If you have two CAs with the same subject and key, and one CA expires, delete (custom) or disable
(predefined) the expired CA. If you don't delete or disable an expired CA, the
Next-Generation Firewall (NGFW) can build a chain to the expired CA
if it is enabled in the trusted chain resulting in a Block page.
When you apply a decryption policy rule to traffic, a session between the client and the
server is established only if the NGFW trusts the CA that signed the
server certificate. To establish trust, the NGFW must have the server
root CA certificate in its certificate trust list (CTL) and use the public key in the
root CA certificate to verify the signature. Next, the NGFW presents a
copy of the server certificate signed by the Forward Trust certificate to the client for
authentication.
Alternatively, you can configure the NGFW to use an enterprise CA as a
Forward Trust certificate for SSL Forward Proxy. If the NGFW does not
have the server root CA certificate in its CTL, it presents a Forward Untrust copy of
the server certificate to the client. The Forward Untrust certificate ensures that
clients receive a certificate warning when attempting to access sites hosted by a server
with untrusted certificates.
You can also use certificates when excluding servers from SSL decryption for
technical reasons, such as certificate pinning. SSL decryption requires keys and certificates to establish the NGFW as a trusted
third party and to establish trust between a client and a server to secure an SSL/TLS
connection. SSH decryption doesn't require certificates.
You can also verify the revocation status of certificates
used for decryption.
Checking the revocation status of
certificates used for SSL/TLS decryption adds time to the process of establishing
the session. The first attempt to access a site might fail if the verification does
not finish before the session times out. For these reasons, verification is disabled
by default.
For detailed information on certificates, see Certificate Management.
To control the trusted CAs that your NGFW trusts, use the
Default Trusted Certificate Authorities tab on your web
interface.
The following table describes the different certificates used for decryption.
Certificates Used With
Decryption | Description |
---|---|
Forward Trust (Used for SSL Forward Proxy
decryption) | The certificate the NGFW presents to clients during decryption if the site the
client attempting to connect to has a certificate signed by a CA
that the NGFW trusts. To configure the Forward Trust
certificate presented to clients when the server certificate is
signed by a trusted CA, see Configure SSL Forward Proxy. By default, the NGFW determines the key size to use for the client certificate
based on the key size of the destination server. However, you can
configure the key size for
SSL Forward Proxy server certificates. For added security, consider
storing the private key associated with the Forward Trust
certificate on a hardware security module (HSM). (See Store Private Keys on an
HSM.) Back up the private key associated with the NGFW's Forward Trust CA certificate
(not the NGFW's master key) in a secure
repository so that if an issue occurs with the NGFW, you can still access the Forward Trust CA certificate. For
added security, consider storing the private key associated with
the Forward Trust certificate on an HSM. (See Store Private Keys on an
HSM.) |
Forward Untrust (Used for SSL Forward Proxy
decryption) | The certificate the NGFW presents to clients during decryption if the site the
client is attempting to connect to has a certificate that is signed
by a CA that the NGFW does not trust. To configure a
Forward Untrust certificate, see Configure SSL Forward Proxy. |
SSL Inbound Inspection |
The certificates of the servers on your network for which you want to
perform SSL Inbound Inspection of traffic destined for those
servers. Import the server certificates onto the NGFW
or management platforms for NGFW or Prisma Access.
Beginning in PAN-OS 8.0, NGFWs use the Elliptic
Curve Diffie-Hellman Ephemeral (ECDHE) algorithm to perform
strict certificate checking. This means that if the NGFW uses an intermediate certificate, you must
reimport the certificate from your web server to the NGFW after you upgrade to a PAN-OS 8.0 or later
release 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 fail. To install a chained
certificate:
|
SSL Decryption and Subject Alternative Names (SANs)
Some browsers require server certificates to use a Subject Alternative Name (SAN) to
specify the domains the certificate protects. These browsers no longer support
certificate matching based on a server certificate's Common Name (CN). SANs enable a
single server certificate to protect multiple hostnames or domains, while CNs are
less well-defined than SANs and can protect only a single domain or all first-level
subdomains on a domain.
If a server certificate contains only a CN, browsers that require a SAN will not
allow end users to connect to the requested web resource. To address this, NGFWs can add a SAN to the impersonation certificate they generate,
establishing themselves as trusted third-parties during SSL decryption. When a
server certificate contains only a CN, the NGFW performing SSL
decryption copies the server certificate CN to the impersonation certificate SAN.
The NGFW presents the impersonation certificate with the SAN to the
client, and the browser is able to support the connection. End users can continue to
access the resources they need, and the NGFW can decrypt the
sessions.
To enable SAN support for decrypted SSL traffic, update the decryption profile
attached to the relevant decryption policy rule:
- (PAN-OS & Panorama) Select Objects Decryption SSL Decryption SSL Forward Proxy and select Append certificate’s CN value to SAN extension.
- (Strata Cloud Manager)
- Select ManageConfiguration NGFW and Prisma Access Security Services Decryption.
- Select or create a decryption profile. Under the SSL Forward Proxy section of the SSL/TLS Decryption settings, select Advanced. Then, under Server Certificate Verification, select Append certificate's CN value to SAN extension.
- Save the Advanced SSL Forward Proxy Settings, and then Save the profile.
- Click Push Config to activate the settings.
SSL Decryption for Elliptical Curve Cryptography (ECC) Certificates
The NGFW automatically decrypts SSL traffic from websites and
applications using Elliptic Curve Cryptography (ECC) certificates, including
Elliptic Curve Digital Signature Algorithm (ECDSA) certificates. As
organizations transition to using ECC certificates to benefit from the strong
keys and small certificate size, you can continue to maintain visibility into
and safely enable ECC-secured application and website traffic.
Decryption for websites and applications using ECC certificates is not
supported for traffic that is mirrored; encrypted traffic using ECC
certificates must pass through a NGFW directly for the NGFW to decrypt it.
You can use a hardware security module (HSM) to
store the private keys associated with ECDSA certificates.
Perfect Forward Secrecy Support for SSL Decryption
Perfect Forward Secrecy (PFS) is a secure communication protocol that prevents the
compromise of one encrypted session from leading to the compromise of multiple
encrypted sessions. With PFS, a server generates unique private keys for each secure
session it establishes with a client. If an attacker compromises a server's private
key, they can only access the single session associated with that key. An attacker
cannot retrieve data from past and future sessions because the server establishes
each connection with a uniquely generated key.
You can decrypt SSL sessions established with Perfect Forward Secrecy, maintaining
PFS protection for past and future sessions. This includes SSL sessions with servers
that present Elliptic Curve Cryptography (ECC) certificates or Subject Alternative
Name (SAN) certificates. Decryption profiles support the Diffie-Hellman (DHE) and
Elliptic Curve Diffie-Hellman (ECDHE) key exchange algorithms by default. To enable
PFS support for decryption, apply a decryption profile with the
DHE and ECDHE key exchange algorithms selected to
an SSL Inbound Inspection or SSL Forward Proxy decryption policy rule.
If you use the DHE or ECDHE key exchange algorithms to enable PFS support for SSL
decryption, you can use an hardware security module (HSM) to
store the private keys for SSL Inbound Inspection.
When you configure SSL Inbound Inspection and use a PFS cipher, session
resumption is not supported.
