Configure SSL Forward Proxy
SSL Forward Proxy decryption enables the firewall to see potential threats in outbound encrypted traffic and apply security protections against those threats.
To enable the firewall to perform SSL Forward Proxy decryption, you must set up the certificates required to establish the firewall as a trusted third party (proxy) to the session between the client and the server. The firewall can use certificates signed by an enterprise certificate authority (CA) or self-signed certificates generated on the firewall as Forward Trust certificates to authenticate the SSL session with the client.
- (Recommended Best Practice)Enterprise CA-signed Certificates—An enterprise CA can issue a signing certificate that the firewall can use to sign the certificates for sites which require SSL decryption. When the firewall trusts the CA that signed the certificate of the destination server, the firewall can send a copy of the destination server certificate to the client, signed by the enterprise CA. This is a best practice because usually all network devices already trust the Enterprise CA (it is usually already installed in the devices’ CA Trust storage), so you don’t need to deploy the certificate on the endpoints, so the rollout process is smoother.
- Self-signed Certificates—The firewall can act as a CA and generate self-signed certificates that the firewall can use to sign the certificates for sites which require SSL decryption. The firewall can sign a copy of the server certificate to present to the client and establish the SSL session. This method requires that 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.
Additionally, set up a Forward Untrust certificate for the firewall to present to clients when the server certificate is signed by a CA that the firewall does not trust. This ensures that clients are prompted with a certificate warning when attempting to access sites with untrusted certificates.
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.
After setting up the Forward Trust and Forward Untrust certificates required for SSL Forward Proxy decryption, create a Decryption policy rule to define the traffic you want the firewall to decrypt and create a Decryption profile to apply SSL controls and checks to the traffic. The Decryption policy decrypts SSL tunneled traffic that matches the rule into clear text traffic. The firewall blocks and restricts traffic based on the Decryption profile attached to the Decryption policy and on the firewall Security policy. The firewall re-encrypts traffic as it exits the firewall.
When you configure SSL Forward Proxy, the proxied traffic does not support DSCP code points or QoS.
- Ensure that the appropriate interfaces are configured as either virtual wire, Layer 2, or Layer 3 interfaces.View configured interfaces on thetab. TheNetworkInterfacesEthernetInterface Typecolumn displays if an interface is configured to be aVirtual WireorLayer 2, orLayer 3interface. You can select an interface to modify its configuration, including what type of interface it is.
- Configure the Forward Trust certificate for the firewall to present to clients when a trusted CA has signed the server certificate. You can use an enterprise CA-signed certificate or a self-signed certificate as the forward trust certificate.(Recommended Best Practice) Use an enterprise CA-signed certificate as the Forward Trust certificate. Create a uniquely named Forward Trust certificate on each firewall:
Use a self-signed certificate as the Forward Trust certificate:
- Generate a Certificate Signing Request (CSR) for the enterprise CA to sign and validate:
- Selectand clickDeviceCertificate ManagementCertificatesGenerate.
- Enter aCertificate Name. Use a unique name for each firewall.
- In theSigned Bydrop-down, selectExternal Authority (CSR).
- (Optional) If your enterprise CA requires it, addCertificate Attributesto further identify the firewall details, such as Country or Department.
- ClickGenerateto save the CSR. The pending certificate is now displayed on theDevice Certificatestab.
- Export the CSR:
- Select the pending certificate displayed on theDevice Certificatestab.
- ClickExportto download and save the certificate file.LeaveExport private keyunselected in order to ensure that the private key remains securely on the firewall.
- Provide the certificate file to your enterprise CA. When you receive the enterprise CA-signed certificate from your enterprise CA, save the enterprise CA-signed certificate to import onto the firewall.
- Import the enterprise CA-signed certificate onto the firewall:
- Selectand clickDeviceCertificate ManagementCertificatesImport.
- Enter the pendingCertificate Nameexactly. TheCertificate Namethat you enter must exactly match the pending certificate name in order for the pending certificate to be validated.
- Select the signedCertificate Filethat you received from your enterprise CA.
- ClickOK. The certificate is displayed as valid with the Key and CA check boxes selected.
- Select the validated certificate to enable it as aForward Trust Certificateto be used for SSL Forward Proxy decryption.
- ClickOKto save the enterprise CA-signed forward trust certificate.
- Click the self-signed root CA certificate () to openDeviceCertificate ManagementCertificatesDevice CertificatesCertificate informationand then click theTrusted Root CAcheckbox.
- Generate new subordinate CA certificates for each firewall:
- Select.DeviceCertificate ManagementCertificates
- ClickGenerateat the bottom of the window.
- Enter aCertificate Name.
- Enter aCommon Name, such as 192.168.2.1. This should be the IP or FQDN that will appear in the certificate. In this case, we are using the IP of the trust interface. Avoid using spaces in this field.
- In theSigned Byfield, select the self-signed Root CA certificate that you created.
- Click theCertificate Authoritycheck box to enable the firewall to issue the certificate. Selecting this check box creates a certificate authority (CA) on the firewall that is imported to the client browsers, so clients trust the firewall as a CA.
- Generatethe certificate.
- Click the new certificate to modify it and click theForward Trust Certificatecheckbox to configure the certificate as the Forward Trust Certificate.
- ClickOKto save the self-signed forward trust certificate.
- Repeat this procedure to generate a unique subordinate CA certificate on each firewall.
- Distribute the forward trust certificate to client system certificate stores.If you are using an enterprise-CA signed certificate as the forward trust certificate for SSL Forward Proxy decryption, and the client systems already have the enterprise CA installed in the local trusted root CA list, you can skip this step. (The client systems trust the subordinate CA certificates you generate on the firewall because the Enterprise Trusted Root CA has signed them.)If you do not install the forward trust certificate on client systems, users see certificate warnings for each SSL site they visit.On a firewall configured as a GlobalProtect portal:This option is supported with Windows and Mac client OS versions, and requires GlobalProtect agent 3.0.0 or later to be installed on the client systems.
Without GlobalProtect:Export the firewall Trusted Root CA certificate so that you can import it into client systems. Highlight the certificate and clickExportat the bottom of the window. Choose PEM format.Do not select theExport private keycheckbox! The private key should remain on the firewall and should not be exported to client systems.Import the firewall’s Trusted Root CA certificate into the browser Trusted Root CA list on the client systems in order for the clients to trust it. When importing into the client browser, ensure that you add the certificate to the Trusted Root Certification Authorities certificate store. On Windows systems, the default import location is the Personal certificate store. You can also simplify this process by using a centralized deployment option, such as an Active Directory Group Policy Object (GPO).
- Selectand then select an existing portal configuration orNetworkGlobalProtectPortalsAdda new one.
- SelectAgentand then select an existing agent configuration orAdda new one.
- Addthe self-signed firewall Trusted Root CA certificate to the Trusted Root CA section. After GlobalProtect distributes the firewall’s Trusted Root CA certificate to client systems, the client systems trust the firewall’s subordinate CA certificates because the clients trust the firewall’s Root CA certificate.
- Install in Local Root Certificate Storeso that the GlobalProtect portal automatically distributes the certificate and installs it in the certificate store on GlobalProtect client systems.
- Configure the Forward Untrust certificate (use the same Forward Untrust certificate for all firewalls).
- ClickGenerateat the bottom of the certificates page.
- Enter aCertificate Name, such as my-ssl-fwd-untrust.
- Set theCommon Name, for example 192.168.2.1. LeaveSigned Byblank.
- Click theCertificate Authoritycheck box to enable the firewall to issue the certificate.
- ClickGenerateto generate the certificate.
- ClickOKto save.
- Click the new my-ssl-fwd-untrust certificate to modify it and enable theForward Untrust Certificateoption.Do not export the Forward Untrust certificate to the Certificate Trust Lists of your network devices! Do not install the Forward Untrust certificate on client systems. 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.
- ClickOKto save.
- (Optional) Configure the Key Size for SSL Forward Proxy Server Certificates that the firewall presents to clients. By default, the firewall determines the key size to use based on the key size of the destination server certificate.
- Although Decryption profiles are optional, it is a best practice to include a Decryption profile with each Decryption policy rule to prevent weak, vulnerable protocols and algorithms from allowing questionable traffic on your network.
- Select, Add or modify an existing rule, and define traffic to be decrypted.PoliciesDecryption
- Set the ruleActiontoDecryptmatching traffic.
- Set the ruleTypetoSSL Forward Proxy.
- (Optional but a best practice) Configure or select an existingDecryption Profileto block and control various aspects of the decrypted traffic (for example, create a decryption profile to perform certificate checks and enforce strong cipher suites and protocol versions).
- ClickOKto save.
- Enable the firewall to forward decrypted SSL traffic for WildFire analysis.
- Committhe configuration.
Recommended For You
Recommended videos not found.