Develop a PKI Rollout Plan
Ensure that all of your network devices have valid SSL
Forward Trust certificates before rolling out decryption to avoid
unnecessary certificate warnings and the resulting user calls to
tech support.
Plan how to roll out your
public key infrastructure (PKI). Network
devices need an SSL Forward Trust CA certificate for trusted sites
and an SSL Forward Untrust CA certificate for untrusted sites. Generate
separate Forward Trust and Forward Untrust certificates (do not
sign the Forward Untrust certificate with the Enterprise Root CA
because you want the Untrust certificate to warn users that they
are trying to access potentially unsafe sites). Palo Alto Networks
next-generation firewalls have two methods of generating CA certificates
for SSL decryption:
Generate the SSL CA certificates from your Enterprise
Root CA as subordinate certificates—If you have an existing
Enterprise PKI, this is the best practice. Generating a subordinate
certificate from your Enterprise Root CA makes the rollout easier
and smoother because network devices already trust the Enterprise
Root CA, so you avoid any certificate issues when you begin the
deployment phase. If you don’t have an Enterprise Root CA, consider
getting one.
- Generate a self-signed Root CA certificate on the firewall
and create subordinate CA certificates on that firewall—If you
don’t have an Enterprise Root CA, this method provides a self-signed
Root CA certificate and the subordinate Forward Trust and Untrust
CA certificates. With this method, you need to install the self-signed
certificates on all of your network devices so that those devices
recognize the firewall’s self-signed certificates. Because the certificates
must be deployed to all devices, this method is better for small
deployments and proof-of-concept (POC) trials than for large deployments.
Do not export the Forward Untrust certificate
to the Certificate Trust Lists of your network devices! This is
critical because installing the Untrust certificate in the Trust
List results in devices trusting websites that the firewall does
not trust. In addition, users won’t see certificate warnings for
untrusted sites, so they won’t know the sites are untrusted and
may access those sites, which could expose your network to threats.
Regardless of whether you generate Forward
Trust certificates from your Enterprise Root CA or use a self-signed
certificate generated on the firewall, generate a separate subordinate
Forward Trust CA certificate for each firewall. The flexibility
of using separate subordinate CAs enables you to
revoke one
certificate when you decommission a device (or device pair) without
affecting the rest of the deployment and reduces the impact in any
situation in which you need to revoke a certificate. Separate Forward
Trust CAs on each firewall also helps troubleshoot issues because
the CA error message the user sees includes information about the
firewall the traffic is traversing. If you use the same Forward
Trust CA on every firewall, you lose the granularity of that information.
There is no benefit to using different Forward Untrust certificates
on different firewalls, so you can use the same Forward Untrust
certificate on all firewalls. If you need additional security for
your private keys, consider
storing them on an HSM.
You may need to make special accommodations for guest users.
If guest users don’t need access to your corporate network, don’t
allow access, and then you won’t have to decrypt their traffic or
create infrastructure to support guest access. If you need to support
guest users, discuss with your legal department whether you can
decrypt guest traffic.
If you can decrypt guest traffic, treat guests similarly to the
way you treat BYOD devices. Decrypt guest traffic and subject it
to the same Security policy that you apply to other network traffic.
Do this by redirecting guest users through a captive portal, instruct
them how to download and install the CA certificate, and clearly
notify users that their traffic will be decrypted. Include the process
in your company’s privacy and computer usage policy. In addition,
restrict guest traffic to only the areas guests need to access.
If you can’t decrypt guest traffic for legal reasons, then isolate
guest traffic and prevent it from moving laterally in your network:
All employees, contractors, partners, and other users should
use your normal corporate infrastructure and you should decrypt
and inspect their traffic.
