If you have an Enterprise
PKI, generate the Forward Trust CA certificate for forward proxy
traffic from your Enterprise Root CA. Otherwise, generate a self-signed
Root CA certificate on the firewall, create a subordinate CA on
that firewall, and then distribute the self-signed certificate to
all client systems. Self-signed certificates are intended for lab
testing, small deployments, and POCs.
Generate a unique subordinate Forward Trust CA for each firewall
(or one Forward Trust CA for all firewall, depending on your planning—one
certificate is easier to deploy, but separate certificates provide
the best security and other benefits). Different PKI platforms have
different features for scaling certificate management.
If you do not use an Enterprise CA, import the Forward Trust
CA certificate into the client systems’ trust CA storage.
Do not import the Forward
CA certificate into
the CA trust storage on client systems or the untrust certificate
won’t act as a trigger for untrusted sites. (However, if the firewall
self-signed Root CA is not installed as a trusted issuer on client systems,
you can use a self-signed Forward Untrust certificate.)
Use an automated method to distribute
the Forward Trust certificates to connected devices, such as the
Palo Alto Networks GlobalProtect Portal, Microsoft AD Certificate
Services (using Group Policy Objects), commercial tools, or open
If you generate the certificate from your Enterprise Root
CA, import the certificate on the firewall.
Back up the private key for the firewall’s Forward Trust
CA certificate (not the firewall’s master key) in a secure repository
so that if an issue occurs, you can still access the Forward Trust
If you generate certificates and private keys from your Enterprise
Root CA, block the export of private keys.
(You can install them on new firewalls and Panoramas from your enterprise
CA, so you don’t need to export them from PAN-OS.)
SSL Forward Proxy Decryption
profiles control server certificate verification, session
modes, and failure checks for outbound traffic. Block sessions with
expired certificates, untrusted issuers, unsupported versions, and
unsupported cipher suites. Block sessions with client authentication
unless an important application requires it, in which case you should
create a separate Decryption profile that allows client authentication
and apply it only to traffic that requires client authentication.
SSL Protocol Settings control
cipher suite elements: protocol versions, key exchange algorithms,
encryption algorithms, and authentication algorithms for SSL Forward
Proxy and SSL Inbound Inspection traffic. Use the strongest ciphers
that you can. For Forward Proxy, set the protocol
to block weak
protocols. For SSL Inbound Inspection, create separate profiles
with protocol settings that match the capabilities of the server(s)
whose inbound traffic you are inspecting.
Use the strongest
cipher suite that you can. Create separate Decryption policies and
profiles to maximize security. If legacy sites that you need for
business purposes only support weaker ciphers, create a separate
Decryption profile to allow the that traffic and apply it in a Decryption
policy only to the necessary sites. Use the same technique to fine
tune security vs. performance for different URL categories.
mobile applications use pinned certificates. Because TLSv1.3 encrypts
certificate information, the firewall can’t automatically add these
mobile applications to the SSL Decryption Exclusion List. For these
applications, ensure that the Decryption profile
set to TLSv1.2 or apply a No Decryption policy to the traffic.
No Decryption profiles control
server certificate verification for traffic you choose not to decrypt.
Block sessions with expired certificates and untrusted issuers.
not apply a No Decryption profile to TLSv1.3 traffic. The certificate
information is encrypted, so the firewall cannot block sessions
based on certificate information.
For SSL Forward Proxy and No Decryption traffic, configure
both Certificate Revocation List (CRL) and Online Certificate Status
Revocation (OCSP) certificate revocation checks
to verify that site certificates have not been revoked.
SSH Proxy profiles control
session modes and failure checks for SSH tunneled traffic. Block
sessions with unsupported versions and unsupported algorithms.
best practice Decryption profile settings for the data center and for the
perimeter (internet gateway) use
cases differ slightly from the general best practice settings.
Create policy rules to
except specific destination IP addresses (for example, finance servers),
source users and groups (for example, executives or HR personnel),
source devices, and application ports that you choose not to decrypt.
Place these rules at the top of the Decryption rulebase, before
rules that decrypt traffic. For all traffic except TLSv1.3 traffic,
attach a No Decryption profile to them to apply SSL server certificate verification
controls to the encrypted traffic. This prevents inadvertently decrypting
traffic that you don’t want to decrypt.
Use URL Categories, Custom URL Categories, and External Dynamic
Lists (EDLs) to specify URLs not to decrypt, such as financial-services,
health-and-medicine, government, and any other categories you don’t
want to decrypt for business, legal, or regulatory reasons. Use
an EDL in environments with dynamically changing IP addresses (for
example, Office 365) or frequent membership changes to update without
having to commit.
Create an EDL or Custom URL Category that
contains all the categories you choose not to decrypt so that you
only need one Decryption policy rule for them.
rules above rules that decrypt traffic in the Decryption rulebase.
If you use Decryption mirroring to
copy and send decrypted traffic to a traffic collection tool, be
aware of local privacy regulations that may prohibit mirroring or
control the traffic you can mirror.
Create policy to decrypt the rest of the traffic by configuring SSL Forward Proxy, SSL Inbound Inspection,
and SSH Proxy rules. Always
decrypt the online-storage-and-backup, web-based-email, web-hosting, personal-sites-and-blogs,
content-delivery-networks, and high-risk URL categories. Limit SSH
Proxy to administrators who manage network devices, log all SSH
traffic, and configure Multi-Factor Authentication to
prevent unauthorized SSH access.
Chrome and some other browsers establish sessions using
QUIC instead of TLS, but QUIC uses proprietary encryption that the
firewall can’t decrypt, so potentially dangerous traffic may enter
the network as encrypted traffic. Create two rules, one to block
the QUIC application on standard ports and one to block UDP ports
80 and 443. Blocking QUIC forces the browser to use TLS.
Decrypt a few URL Categories, review user feedback, and
run reports to ensure that decryption works as expected. Gradually
decrypt more URL Categories until you reach your goal. Start with
the highest priority traffic (URL categories most likely to harbor
malicious traffic, such as gaming), and decrypt more as you learn
from experience and refine the process. A more conservative alternative
is to decrypt URL Categories that don’t affect your business first,
for example, news feeds.