>
    Keys and Certificates for Decryption Policies
    Focus
    Download PDF
    Focus
    1. Home
    2. PAN-OS
    3. Decryption
    4. Decryption Concepts
    5. Keys and Certificates for Decryption Policies
    Download PDF

    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 firewall can decrypt encrypted traffic.
    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 (DeviceCertificate Management, then Device Certificates) with the same subject and key, and one CA expires, delete (custom) or disable (predefined) the expired CA. If you do not delete or disable an expired CA, the firewall 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 to traffic, a session between the client and the server is established only if the firewall trusts the CA that signed the server certificate. In order to establish trust, the firewall must have the server root CA certificate in its certificate trust list (CTL) and use the public key contained in that root CA certificate to verify the signature. The firewall then presents a copy of the server certificate signed by the Forward Trust certificate for the client to authenticate. You can also configure the firewall to use an enterprise CA as a forward trust certificate for SSL Forward Proxy. If the firewall does not have the server root CA certificate in its CTL, the firewall will present a copy of the server certificate signed by the Forward Untrust certificate to the client. The Forward Untrust certificate ensures that clients are prompted with a certificate warning when attempting to access sites hosted by a server with untrusted certificates.
    For detailed information on certificates, see Certificate Management.
    To control the trusted CAs that your firewall trusts, use the DeviceCertificate ManagementCertificatesDefault Trusted Certificate Authorities tab on the firewall web interface.
    The following table describes the different certificates Palo Alto Networks firewalls use for decryption.
    Certificates Used With Decryption
    Description
    Forward Trust (Used for SSL Forward Proxy decryption)
    The certificate the firewall presents to clients during decryption if the site the client is attempting to connect to has a certificate signed by a CA that the firewall trusts. To configure a Forward Trust certificate on the firewall to present to clients when the server certificate is signed by a trusted CA, see Configure SSL Forward Proxy.
    By default, the firewall 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 Proxy Server certificates. For added security, consider storing the private key associated with the Forward Trust certificate on a hardware security module (see Store Private Keys on an HSM).
    Back up the private key associated with the firewall’s Forward Trust CA certificate (not the firewall’s master key) in a secure repository so that if an issue occurs with the firewall, you can still access the Forward Trust CA certificate. For added security, consider storing the private key associated with the Forward Trust certificate on a hardware security module (see Store Private Keys on an HSM).
    Forward Untrust (Used for SSL Forward Proxy decryption)
    The certificate the firewall 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 firewall does not trust. To configure a Forward Untrust certificate on the firewall, 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 firewall.
    Beginning in PAN-OS 8.0, 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 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 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.

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