Keys and Certificates for Decryption Policies
Focus
Focus
Network Security

Keys and Certificates for Decryption Policies

Table of Contents

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:
  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.

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)
    1. Select ManageConfiguration NGFW and Prisma Access Security Services Decryption.
    2. 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.
    3. Save the Advanced SSL Forward Proxy Settings, and then Save the profile.
    4. 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.