>
    Strata Copilot
    Decryption Profiles
    Focus
    Download PDF
    Focus
    1. Home
    2. Network Security
    4. Decryption Basics
    5. Decryption Profiles
    Download PDF
    Network Security

    Decryption Profiles

    Table of Contents

    Decryption Profiles

    Decryption profiles control SSL/TLS and SSH connection settings, such as protocol versions, server certificate, and other checks for traffic matching decryption rules.
    Where Can I Use This?What Do I Need?
    • NGFW
    • Prisma Access
    No requirements.
    Decryption profiles specify the checks and connection parameters that apply to traffic you decrypt or exclude from decryption. These settings harden network security by preventing risky connections, such as sessions with invalid certificates or weak protocols. After creating a decryption profile, associate it with a decryption policy rule. Next-Generation Firewalls (NGFWs) enforce the profile settings on traffic that matches the conditions of a decryption policy rule.
    You can create decryption profiles for each type of decryption: SSL Forward Proxy, SSL Inbound Inspection (Proxy), and SSH Proxy. You can also create a no-decryption profile for traffic you choose not to decrypt—such as traffic containing personal or sensitive information or traffic subject to local laws and regulations. This often includes traffic to the health-and-medicine and financial-services categories. Each profile type has different checks to configure: certificate verification checks, session mode checks, and failure checks. Decryption profiles for SSL decryption additionally define TLS connection parameters.
    You can also use the default decryption profile, which enforces basic, recommended protocol versions and cipher suites for decrypted SSL/TLS traffic.
    Don’t weaken the decryption profile you apply to most sites by accommodating less secure sites. Instead, create one or more separate decryption profiles for sites that must remain accessible but don’t support strong protocol versions or cipher suites.
    You can also create separate decryption profiles for different types of URL categories to fine-tune security versus performance for traffic that doesn't contain sensitive material.
    • Apply a decryption profile to all decryption policy rules, including rules for traffic you don't decrypt. No-decryption profiles block sessions with expired certificates and untrusted issuers as an extra precaution.
    • Enable the tighter decryption controls described in SSL Decryption, No Decryption, and SSH Proxy.

    Decryption Profile Settings

    Settings vary by type of decryption profile. The Profile Settings and Profile Types Matrix shows which checks apply to each type of decryption profile.
    • Unsupported Mode Checks—These settings block sessions that use weak risky protocol versions and cipher suites. If you don’t block sessions with unsupported modes, users see warning messages when they connect to potentially unsafe servers. However, they can click through the warning to access these sites.
      • Block sessions with client authentication
        This option blocks sessions that require client authentication unless the session involves a site on the decryption exclusion list. The NGFW can’t decrypt sessions that require client authentication because it needs both client and server certificates to perform bidirectional decryption, and with client authentication, the NGFW only knows the server certificate. Enable this option only if no critical applications require client authentication.
        If you don’t block sessions requiring client authentication, the NGFW allows the session when it attempts decryption and adds an entry containing the URL or IP address of the server, the application, and corresponding decryption profile to its Local SSL Decryption Exclusion Cache.
      • Block sessions with unsupported cipher suites
        This option blocks sessions if the NGFW doesn’t support the cipher suites a client presents during the SSL/TLS handshake. To specify the key exchange algorithms, encryption algorithms, and authentication algorithms the NGFW supports, edit the SSL Protocol Settings in your decryption profiles.
      • Block sessions with unsupported algorithms
        This option blocks sessions if the client or server presents SSH algorithms PAN-OS doesn't support. For a list of supported SSH algorithms, see PAN-OS Decryption Cipher Suites.
      • Block sessions with unsupported versions
        This option blocks sessions if the client or server presents SSL/TLS protocol versions the NGFW doesn't support. To specify the minimum and maximum SSL/TLS protocol versions allowed on your network, edit the SSL Protocol Settings in your decryption profiles.
    • Failure Checks—These settings block sessions if system resources are insufficient to perform decryption or a required component such as a hardware security module (HSM) with private keys for decryption is not available, which prevents decryption.
      • Block sessions if resources not available
        When enabled, the NGFW drops traffic if it lacks the resources to decrypt the traffic. This prevents encrypted traffic from entering your network uninspected and prevents leakage. However, blocking sessions when resources aren’t available may make sites that users normally can access temporarily unreachable.
        Weigh your company’s security compliance stance and the importance of the user experience against tighter security when deciding whether to enable this option. Alternatively, consider using NGFW models with more processing power to decrypt more traffic if resource limitations become problematic. Size Next-Generation Firewalls for Decryption Requirements describes considerations to make when determining your decryption and NGFW sizing needs.
      • Block sessions if HSM not available
        This option blocks sessions if a hardware security module (HSM) is not available to sign certificates.
        If you store private keys on an HSM, consider your compliance rules about where the private key must come from and how to handle encrypted traffic when the HSM isn’t available. If your company mandates the use of an HSM for private key signing, enable this option. If your company is less strict about this, don't enable this option. Further, if the HSM is critical to your business, run it in a high availability (HA) pair.
        If the HSM is down, the NGFW can only decrypt sites for which it has cached the HSM response.
      • Block downgrade on no resource
        This option prevents NGFWs from downgrading a TLSv1.3 connection to TLSv1.2 when an NGFW has no available TLSv1.3 processing resources. Instead, when it exhausts its TLSv1.3 resources, the NGFW drops TLSv1.3 traffic. However, blocking downgrade when resources aren’t available might make sites that users normally can access temporarily unreachable. If you don’t enable this option, the NGFW downgrades connections to TLSv1.2 when it exhausts TLSv1.3 resources.
        Weigh your company’s security compliance stance and the importance of the user experience against tighter security when deciding whether to enable this option. Consider creating a separate decryption policy rule and profile to govern the decryption for sensitive traffic for which you don’t want to downgrade the TLS version.
      • Block sessions on SSH errors
        This option blocks sessions when SSH errors occur.
    • Server Certificate Verification—These settings block sessions with invalid, compromised, or suspicious server certificates to ensure users communicate with legitimate servers and that data is transmitted securely. For example, you can prevent executives whose traffic you don't inspect from accessing websites with expired certificates.
      • Block sessions with expired certificates
        This option blocks sessions with servers that have expired certificates and prevents access to potentially insecure sites. If you don't enable this option, users can connect with and transact with potentially malicious sites despite warnings about their safety.
      • Block sessions with untrusted issuers
        This option blocks sessions with servers that have untrusted certificate issuers. Untrusted issuers may indicate meddler-in-the-middle, replay, or other attacks.
      • Block sessions with unknown certificate status
        This option blocks SSL/TLS sessions when a server certificate has a revocation status of unknown.
        This setting may tighten security too much for general use as certificate status may be unknown for multiple reasons. However, it may be appropriate for high-security areas of the network like data centers.
      • Block sessions on SNI mismatch with Server Certificate (SAN/CN)
        This option automatically denies any sessions where the Server Name Indication (SNI) doesn't match the Subject Alternative Name (SAN) or Common Name (CN) fields of a server certificate. This prevents SNI spoofing and reduces the risk of visiting a malicious website. Palo Alto Networks recommends enabling this option if you configure an explicit proxy or transparent proxy. For more information, refer to Configure a Web Proxy in the PAN-OS Networking Administrator's Guide.
      • Block sessions on certificate status check timeout
        This option blocks sessions when certificate revocation checks (CRL or OCSP) time out, even if a certificate is valid. Revocation servers can be slow to respond, so this option introduces a tradeoff between security and user experience. Consider your company’s security compliance stance when deciding whether to enable this option.
        • If you enable this option and timeouts occur frequently, you can increase the Certificate Status Timeout (sec) value. This interval limits the time that an NGFW waits for a response from either the CRL or OCSP service. In the following figure, this value has been increased to 8 (the default is 5 seconds):
        • Enable both verification methods for better coverage. Server certificates can contain the CRL URL in the CRL Distribution Point (CDP) extension or the OCSP URL in the Authority Information Access (AIA) certificate extension.
        For a step-by-step procedure, see Verify Revocation Status of Certificates Used for SSL/TLS Decryption.
      • Restrict certificate extensions
        This option limits the certificate extensions in the server certificate to key usage and extended key usage and blocks certificates with other extensions. In certain deployments, other certificate extensions may be necessary. Enable this option only if your deployment doesn't require additional certificate extensions.
      • Append certificate’s CN value to SAN extension
        This option ensures users can access web resources on browsers that require SSL/TLS certificates to include the Subject Alternative Name (SAN) extension and don't support Common Name (CN) matching, when the certificate is missing the SAN extension. The NGFW addresses this issue by adding the SAN extension (based on the CN) to the impersonation certificate.
      • Automatically Fetch Intermediate Certificates
        This option enables the NGFW to download missing intermediate certificates from the URL in the Authority Information Access (AIA) extension after a server presents an incomplete certificate chain during the TLS handshake. The NGFW caches these certificates for up to 1 week and uses them to validate the server in future SSL Forward Proxy connections.
      • Bypass Server Certificate Verification
        Enabling this option disables all other Server Certificate Verification settings. To minimize potential risks of bypassing certificate checks, apply decryption profiles with this setting enabled only to decryption policy rules that control traffic to trusted servers that are known to fail certificate validation.
        This option enables the NGFW to ignore server certificate issues (for example, missing intermediate certificates) and present a Forward Trust certificate to force decryption. Because this option disables other certificate checks, you must acknowledge a warning to enable it. To protect against unknown vulnerabilities, the NGFW does not save these sessions to the session cache; thus, session resumption isn't supported.
    The following table lists the checks you can enable for each decryption profile type.
    SettingsProfile Types
    SSL Forward ProxySSL Inbound InspectionSSH ProxyNo Decryption
    Server Certificate VerificationBlock sessions with expired certificatesYesNoNoYes
    Block sessions with untrusted issuersYesNoNoYes
    Block sessions with unknown certificate statusYesNoNoNo
    Block sessions on SNI mismatch with Server Certificate (SAN/CN) YesNoNoNo
    Block sessions on certificate status check timeoutYesNoNoNo
    Restrict certificate extensionsYesNoNoNo
    Append certificate’s CN value to SAN extensionYesNoNoNo
    Automatically Fetch Intermediate CertificatesYesNoNoNo
    Bypass Server Certificate Verification Yes No No No
    Unsupported Mode ChecksBlock sessions with unsupported versionsYesYesYesNo
    Block sessions with unsupported cipher suitesYesYesYesNo
    Block sessions with unsupported algorithmsNoNoYesNo
    Block sessions with client authenticationYesNoNoNo
    Failure ChecksBlock sessions if resources not availableYesYesYesNo
    Block sessions if HSM not availableYesYesNoNo
    Block downgrade on no resourceYesYesNoNo
    Block sessions on SSH errorsNoNoYesNo

    Decryption Profile: SSL Decryption

    The SSL Decryption tab manages settings for SSL Forward Proxy and SSL Inbound Inspection. Both profile types include settings for various checks, such as unsupported mode checks, failure checks, and client extensions. You can also specify the TLS versions, key exchange algorithms, encryption algorithms, and authentication algorithms that a client, server, and NGFW (acting as a proxy) can negotiate. Only the SSL Forward Proxy profile includes options for server certificate verification.
    You may need to allow traffic on your network from sites that use client authentication and are not in the predefined sites on the SSL decryption exclusion list. Create a decryption profile that allows sessions with client authentication. Add it to a decryption policy rule that applies only to the servers that host the application. To further increase security, you can require multi-factor authentication to complete the user login process.
    The following sections summarize the profile settings and recommendations for SSL Forward Proxy, SSL Inbound Inspection, and the SSL Protocol Settings. Select an option to learn more about the unique settings and recommendations offered.

    SSL Forward Proxy

    The SSL Forward Proxy decryption profile controls server verification, session mode checks, and failure checks for outbound SSL and TLS traffic defined in the Forward Proxy decryption policy rules to which you attach the profile.
    SSL Forward Proxy can't decrypt some sessions, such as sessions with client authentication or pinned certificates because the NGFW is a proxy device. Being a proxy also means that the NGFW does not support high availability (HA) sync for decrypted SSL sessions.
    The following figure shows the general best practice recommendations for SSL Forward Proxy decryption profiles, but the settings you use also depend on your company’s security compliance rules and local laws and regulations. There are also specific best practices for perimeter internet gateway decryption profiles and for data center decryption profiles.

    SSL Inbound Inspection

    The SSL Inbound Inspection decryption profile controls the session mode checks and failure checks for inbound SSL/TLS traffic defined in the Inbound Inspection decryption policy rules to which you attach the profile. The following figure shows the general best practice recommendations for Inbound Inspection decryption profiles, but the settings you use also depend on your company’s security compliance rules and local laws and regulations.
    SSL Inbound Inspection can't decrypt some sessions, such as sessions with client authentication or pinned certificates, because the NGFW is a proxy device. Being a proxy also means that the NGFW does not support high availability (HA) sync for decrypted SSL sessions.

    SSL Protocol Settings

    The SSL Protocol Settings tab controls the protocol versions and cipher suites supported for SSL Forward Proxy and SSL Inbound Inspection. You can decide whether to allow vulnerable or weak SSL/TLS protocol versions, encryption algorithms, and authentication algorithms. SSL Protocol Settings apply to outbound SSL Forward Proxy traffic and inbound SSL Inbound Inspection traffic. These settings don’t apply to SSH Proxy traffic or traffic that you don’t decrypt.
    General Guidelines
    Always use the strongest protocols and cipher suites possible. Weak protocols and ciphers have known vulnerabilities that attackers can exploit. Avoid weakening the decryption profile you apply to most sites for a few exceptions. Instead, create separate decryption profiles for applications and websites that rely on outdated protocols or ciphers. For example, to support a business-critical legacy site that uses a weak encryption algorithm, create a decryption profile with only that algorithm enabled. Then, create a dedicated decryption policy rule that allows traffic to the legacy site (specify the URL as the destination). Next, apply the decryption profile to the decryption policy rule. Finally, place the decryption policy rule above your general decryption policy rules. This approach allows you to support legacy applications without weakening your overall security posture.
    The following figure shows the general best practice recommendations for SSL Protocol Settings. There are also specific best practices for perimeter internet gateway decryption profiles and for data center decryption profiles.
    When you configure SSL Protocol Settings for SSL Inbound Inspection traffic, create separate profiles for servers with different security capabilities. For example, if one set of servers supports only RSA, the SSL Protocol Settings only need to support RSA. However, the SSL Protocol Settings for servers that support PFS should support PFS. Configure SSL Protocol Settings for the highest level of security that the target server you're protecting supports, but check performance to ensure that the NGFW and Prisma Access resources can handle the higher processing load that higher security protocols and algorithms require.
    Protocol Versions
    • Set Min Version to TLSv1.3 for the strongest security. Business sites that value security support TLSv1.3. However, if a site or category of sites only supports weak or outdated ciphers, evaluate whether the site hosts a legitimate business application. If yes, create a decryption profile with a Min Version equal to the strongest cipher that the site supports. Then, apply this profile to decryption policy rules that target only the specific site or sites in question. If the site belongs to a category of sites that you don’t need for business purposes, use URL filtering to block access to the entire category.
      Qualys SSL Labs SSL Pulse web page provides current statistics on the percentages of different ciphers and protocols in use on the 150,000 most popular sites in the world so you can see trends and understand how widespread worldwide support is for more secure ciphers and protocols.
    • Set Max Version to Max rather than a specific version, so that as the protocols improve, the NGFW or Prisma Access automatically supports the newest and best protocols. Whether you intend to attach a decryption profile to a decryption policy rule that governs inbound (SSL Inbound Inspection) or outbound (SSL Forward Proxy) traffic, avoid allowing weak algorithms.
      If your decryption policy supports mobile applications, many of which use pinned certificates, set the Max Version to TLSv1.2. Because TLSv1.3 encrypts certificate information that wasn’t encrypted in previous TLS versions, the NGFW can’t automatically add decryption exclusions based on certificate information, which affects some mobile applications. Therefore, if you enable TLSv1.3, the NGFW may drop some mobile application traffic unless you create a no-decryption policy rule for that traffic.
      If you know the mobile applications you use for business, consider creating a separate decryption policy rule and profile for those applications so that you can enable TLSv1.3 for all other application traffic.
    Key Exchange Algorithms
    RSA, DHE, and ECDHE key exchange algorithms are enabled by default. Only DHE and ECDHE support Perfect Forward Secrecy.
    Only ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is supported for TLSv1.3 connections.
    To support HTTP/2 traffic, leave the ECDHE box checked.
    (PAN-OS 12.1.2 and TLSv1.3 only) You can configure post-quantum cryptography (PQC) key exchange algorithms in addition to RSA, DHE, and ECDHE. Select the Post-quantum Cryptography (PQC) tab:
    • Classical—Select RSA, DHE, and ECDHE. Leave all three boxes checked to support all classical key exchange algorithms unless the minimum protocol version you support is TLSv1.3, which only supports ECDHE.
    • Post-quantum Cryptography (PQC)—Select PQC-Standard or PQC-Experimental:
      • PQC-Standard enables key exchange algorithms that have been standardized by the National Institute of Standards and Technology (NIST): ML-KEM
      • PQC-Experimental enables the following nonstandardized PQC algorithms: HQC, Bike, and Frodo-KEM
      Preferred Session Settings—Select the proxy sessions that prioritize PQC:
      The NGFW negotiates a PQ KEM for the selected sessions when possible. The NGFW translates between PQC and classical encryption, so it can secure one proxy session with PQC even if the other side only supports classical algorithms.
      If a client or server doesn't support PQC, the NGFW attempts to negotiate an existing cipher supported by these endpoints as a fallback mechanism.
      • Post-Quantum SSL preferred for Client-side session—The NGFW (acting as a server) negotiates PQC algorithms if included in client's cipher suite list
      • Post-Quantum SSL preferred for Server-side session—The NGFW (acting as a client) places PQC algorithms first in its cipher suite list
    Encryption Algorithms
    • If you set the minimum protocol version to TLSv1.2, the older, weaker 3DES and RC4 algorithms are automatically unchecked (blocked).
    • If you set the minimum protocol version to TLSv1.3, the 3DES, RC4, AES128-CBC, and AES256-CBC algorithms are automatically blocked.
    • For any traffic for which you must allow a weaker TLS protocol, create a separate decryption profile and apply it only to traffic for that site, and deselect the appropriate boxes to allow the algorithm. Allowing traffic that uses the 3DES or RC4 algorithms exposes your network to excessive risk. If blocking 3DES or RC4 prevents you from accessing a site that you must use for business, create a separate decryption profile and decryption policy rule for that site.
    Authentication Algorithms
    The NGFW automatically blocks the older, weaker MD5 algorithm. When TLSv1.3 is the minimum protocol version, the NGFW also blocks SHA1. Don’t allow MD5 authenticated traffic on your network; SHA1 is the weakest authentication algorithm you should allow. If no necessary sites use SHA1, block SHA1 traffic to further reduce the attack surface.

    Decryption Profile: No Decryption

    No-decryption profiles enable server certificate verification for traffic you choose not to decrypt for legal, compliance, or other non-technical reasons. You can block sessions with expired certificates or untrusted certificate issuers. Apply this profile only to decryption policy rules with a Do Not Decrypt action (see Exclude Traffic from Decryption for Business, Legal, or Regulatory Reasons.)
    To exclude traffic that can't be decrypted for technical reasons (for example, certificate pinning), add the hostnames of the websites or applications to the decryption exclusions list.
    The following figure shows the general best practice recommendations for no-decryption profiles.
    Don’t attach a no-decryption profile to decryption policy rules for TLSv1.3 traffic that you don’t decrypt. Unlike previous versions, TLSv1.3 encrypts certificate information, so the NGFW has no visibility into certificate data and therefore can't block sessions with expired certificates or untrusted issuers, so the profile has no effect. (The NGFW can perform certificate checks with TLSv1.2 and earlier because those protocols don’t encrypt certificate information and you should apply a no-decryption profile to their traffic.)
    However, you should create a decryption policy rule for TLSv1.3 traffic that you don’t decrypt because the NGFW does not log undecrypted traffic unless a decryption policy rule controls that traffic.
    (Applies to TLSv1.2 and earlier) If you choose to allow sessions with untrusted issuers (not recommended) and only Block sessions with expired certificates, there is a scenario in which a session with a trusted, expired issuer may be blocked inadvertently. When the NGFW certificate store contains a valid, self-signed trusted CA and the server sends an expired CA in the certificate chain, the NGFW does not check its certificate store. Instead, it blocks the session based on the expired CA when it should find the trusted, valid alternative trust anchor and allow the session based on that trusted self-signed certificate.
    To avoid this scenario, select Block sessions with untrusted issuers in addition to Block sessions with expired certificates. This forces the NGFW to check its certificate store, find the self-signed trusted CA, and allow the session.

    Decryption Profile: SSH Proxy

    The SSH Proxy decryption profile controls the session mode checks and failure checks for SSH traffic defined in the SSH Proxy decryption policy rules to which you attach the profile. The following figure shows the general best practice recommendations for SSH Proxy decryption profiles, but the settings you use also depend on your company’s security compliance rules and local laws and regulations.
    NGFWs don’t perform content and threat inspection on SSH tunnels (port forwarding). However, they distinguish between the SSH application and the SSH-tunnel application. If the NGFW identifies SSH tunnels, it blocks the tunneled traffic and restricts the traffic according to configured Security policy rules.

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