CVE Best Practices

Certificate verification is essential to HTTPS security. If mismanaged, HTTPS security and the security of your network can be compromised and significantly weakened.

Certificate verification is an investment.

Certificate checks fail in expected and intended ways when browsing to sites with CAs not known to Content Gateway. That's security. Regular, proactive user education helps users recognize and assess legitimate failures. See Frequently Asked Questions for a summary of information for users.

Certificate checks may also fail in unexpected ways that also require user education, as well as administrative effort in the form of investigation and remediation.

When using SSL certificate verification, therefore, you need to know:

Your organization's certificate verification requirements as they pertain to your IT security policy.

Your organization's ability and willingness to manage the administrative burden. When verification fails and there is no remediation in place, the connection request is dropped and users often call HelpDesk. Some failures will require administrator investigation and remediation.

To administer certificate verification, you need to:

Know which failures legitimately protect your network

Know how to investigate failures

Determine which failures are undesirable and can be remediated (certificate replacement, verification bypass, other)

Educate users about SSL connection failures, what they look like, and why they occur

Anticipate more HelpDesk calls


	Important You should not use Content Gateway to proxy internal traffic. However, if you do, before enabling the CVE, audit your internal HTTPS servers to ensure that their certificates are valid and trusted by Content Gateway.

If you plan to use the CVE, be sure to acquaint yourself with these topics:

Troubleshooting Certificate Verification Failures

Certificate Verification Failures and Remediation Options

CVE configurations

This section describes a phased approach to deploying certificate verification.

The starting point assumes that Content Gateway is stable and SSL support is off.

The phases of SSL and CVE deployment include:

Enabling SSL support.

Enabling the CVE with only the certificate revocation (CRL) check enabled.

Adding CVE checks to the configuration as needed.

Enabling SSL support

Before enabling SSL support, verify that Content Gateway:

Is installed in a supported environment that includes a network test segment

Is passing explicit or transparent traffic as expected

Is integrated and tested with TRITON AP-WEB

Policies are configured

Scanning (analytic) options are configured

HTTP requests are handled as expected

Policy is being enforced as expected

Is stable:

Content Gateway performance monitoring graphs show a predictable ramp up in traffic with no unexplained traffic spikes

All mission critical websites and web-hosted applications have been validated to work properly through the proxy, or acceptable bypasses are in place

When the above conditions are met:

Enable SSL support.

Confirm that HTTPS traffic is passing through Content Gateway.

Verify that clients are not receiving certificate errors in the browser. If they are, see these instructions on installing the Internal Root CA.

Test by accessing several sites that are commonly used in your organization.

Test by using HTTPS-based applications that are commonly used in your organization. See these articles for information about common problems.

Dropped HTTPS connections

Websites that have difficulty transiting Content Gateway

Send a representative sample of traffic into the test environment with the objective of uncovering as many HTTPS traffic problems as possible.

When the environment is stable, proceed to Enabling the CVE with only the CRL check enabled.

Enabling the CVE with only the CRL check enabled

Now that SSL support is on and stable, enable the CVE with only CRL checking enabled. The CRL check is an essential certificate verification check that rarely fails in error.

Repeat the testing performed after SSL was enabled.


	Note If a certificate fails because it is on a revocation list, a fast and easy way to confirm the revocation status is to use a web-hosted certificate verification tool. Using a browser and a common Search site, search for "SSL checker". Select a site that you trust and enter the exact URL of the site that failed.

At this stage, to minimize disruption to users, you may also want to enable Verification Bypass. See CVE with Verification Bypass enabled.

Adding CVE checks to the configuration

When you are satisfied with certificate verification using only the CRL check, you can start to enable additional verification options. Enable options one at a time and repeat the same testing procedures.


	Note If you are following the recommended steps, "Check certificate revocation by CRL" is already enabled.

It is recommended that you enable Verify entire certificate chain last.

For each option enabled, when there is a certificate verification failure, an incident is added to the Incident List. Begin troubleshooting by examining the Incident List. See Troubleshooting Certificate Verification Failures.


	Important To reduce administrative overhead, do not enable checks that aren't required by your IT security policy.

For more information on CVE options, see Validating certificates.

CVE with Verification Bypass enabled

In addition to the verification options, SSL support includes an option for Verification Bypass (Configure > SSL > Validation > Verification Bypass). This means that when certificate verification fails, a dialog box warns the user that a failure has occurred and gives the user the option to go to the site anyway.

Advantages include:

Certificate verification is performed and incidents are logged, but users aren't blocked. Users are allowed to make the decision about whether a site is safe.

Administrators can see how the CVE affects the network before allowing it to impact users or require an administrator response.

By monitoring the Incident List, administrators can put remediation measures in place before enforcing certificate verification and impacting users.

Verification bypass provides a response to users that is much like the warning dialogs used by common browsers.

Disadvantages include:

Security is compromised because the choice to drop the connection is given to the user.

In cases where the HTTPS request is for an object embedded in the page or in another page, and its certificate verification fails, the bypass page may not render.