Validating certificates

Keeping revocation information up to date

SSL certificate verification is an important component of SSL security. It is through certificate exchange and verification that the client, in this case Content Gateway, and the origin server verify that each is who it says it is.

Content Gateway performs this task with the certificate verification engine (CVE).

Use the tabs on Configure > My Proxy > SSL > Validation to enable and configure the CVE.

For information about options when verification fails and you prefer to trust the site, see Bypassing verification.

For a comprehensive discussion of the use and best practices of the CVE, see SSL Certificate Verification Engine v7.8.

Configuring validation settings

Go to Configure > SSL > Validation > General.

Enable the certificate verification engine: This option enables and disables the certificate verification engine.

Certificate verification is disabled by default. This prevents the Content Gateway administrator and network users from being surprised by the effects of certificate verification when HTTPS is initially enabled (on Configuration > My Proxy > Basics > General).

If this option is not selected, certificate validation does not occur.

Important

If you disable the CVE, you need to provide settings on only the following pages:

Configure > SSL > Decryption / Encryption > Inbound

Configure > SSL > Decryption / Encryption > Outbound

Configure > SSL > Customization > Connection Error

Deny certificates where the common name does not match the URL: When enabled, two checks are made:

First, the certificate's Common Name is checked for an exact match of the destination URL.

If the first check fails, the certificate's Subject Alternative Name (SAN) list is checked for an exact match of the destination URL.

Checks are case insensitive.

Because an exact match is required, there may be instances when a legitimate variation in the Common Name, or the absence of a matching variation in the SAN, may result in a block.

For example, using "https://cia.gov" when attempting to access "https://www.cia.gov" may result in a block. Additionally, a block may occur when accessing a site by IP address.

Allow wildcard certificates: This is a sub-option of When Deny Certificates where the common name does not match the URL. When enabled, this option allows matches with Common Names that include the "*" (wildcard) character in the name.

Some HTTPS servers use a wildcard in the Common Name so that a single certificate can cover an entire domain. For example: "*.example.com" to cover "email.example.com" and "stream.example.com", etc.

Use of the wildcard means that individual servers within the domain are not verified; they are included as a result of the wildcard.

Allowing wildcard certificates eases the strict matching burden when a Common Name match is required. It is also helpful for domains that have multiple subdomains like google.com or yahoo.com. It also introduces some risk that a fraudulent or undesirable variation of a domain may go unblocked.

No expired or not yet valid certificates: When enabled, denies access to sites that offer an expired or not yet valid certificate. This is a basic check that is important because many malicious sites operate with expired certificates. If this option is not selected, access to those sites is permitted.


	Note Self-signed certificates (certificates without an official certificate authority) are considered invalid and belong in this category.

Verify entire certificate chain: When enabled, verifies expiration and revocation status of all certificates between the site certificate and the root Certificate Authority as specified in the certification path of the certificate. This is an important check.

Check certificate revocation by CRL: Certificate revocation lists (CRLs) are used to check a certificate's revocation status. CRLs list certificates that have been issued and subsequently revoked by the CA.

Verifying the revocation status is a basic check that is very important because certificates are revoked when they are improperly issued, have been compromised, have a false identity, or violate policies specified by the CA.

If this option is enabled, it is recommended that you verify that the daily CRL update feature is enabled. Go to the Revocation Settings tab and enable the check box in CRL Settings.

If this option is not used, it is recommended that you disable the daily CRL update feature. Go to the Revocation Settings tab and disable the check box in CRL Settings.

Check certificate revocation by OCSP: Online Certificate Status Protocol (OCSP) is an alternate way to check a certificate's revocation status. While OCSP is beneficial, it is not used as widely as CRLs and therefore is not as reliable. Also, it is a real-time, Internet-hosted check that can introduce some request handling latency.


	Note It is recommended that you use OCSP in addition to, rather than instead of, CRLs. See Keeping revocation information up to date for more information on CRLs and OCSP.

Block certificates with Unknown OCSP state: When OCSP revocation checking is enabled, enable this option to block certificates that return the "Unknown" status.

10.

Preferred method for revocation check: When both CRL and OCSP revocation checking are enabled, use this option to indicate which method to apply first. The default is CRL.

11.

Block certificates with no CRL URI and with no OCSP URI: When CRL checking, OCSP checking, or both are enabled, use this option to block certificates that do not have the expected, associated URIs. For example, if only CRL checking is enabled and the certificate doesn't have a CRL URI, if this option is enabled the connection is blocked. When both CRL and OCSP checking are enabled, the block occurs only if both CRL and OCSP lack a URI.

You can view URI information in the certificate when you select to view the certificate in your browser. See View a certificate for details.

Because many certificates do not include CRL or OCSP information, this option can result in a high number of verification failures. Often the failures are reported as "Unknown revocation state" errors.

This can result in a highly restrictive security policy, with many access denials.

As with all verification failures, you can allow for exceptions using the Incident List. See Managing HTTPS website access.