Validating certificates

Working With Encrypted Data > Validating certificates

Validating certificates

Help | Content Gateway | Version 7.7.3

Related topics:

Bypassing verification

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 SSL Manager, and the origin server verify that each is who it says it is.

In SSL Manager, this task is performed by the certificate verification engine.

Use the tabs on Configure > My Proxy > SSL > Validation to enable and configure the Certificate Verification Engine (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 Manager Certificate Verification Engine v7.7.

Configuring validation settings

1.	Navigate to the page Configure > SSL > Validation > General.

2.	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 taken by surprise by the effects of certificate verification when HTTPS is initially enabled (on the Configuration > My Proxy > Basics page).

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

Important

If you disable the certificate verification engine, you need to provide information on only the following pages:

Configure > SSL > Decryption / Encryption > Inbound

Configure > SSL > Decryption / Encryption > Outbound

Configure > SSL > Logging pages

Configure > SSL > Customization > Connection Error

3.	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 Web site by IP address.

4.	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.

6.	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.

7.	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.

9.	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 Web HTTPS site access.

12.	Run external program on incidents: For troubleshooting purposes, you can run an external program on incidents. An incident is logged whenever a client receives an access denied message. See Managing Web HTTPS site access for more information on incidents. Enter the path to the script in this field.

The minimum permissions for running this script should be as follows:

chmod 700 /opt/WCG/sxsuite/bin/script.sh

chown root /opt/WCG/sxsuite/bin/script.sh

chgrp root /opt/WCG/sxsuite/bin/script.sh

The account that created the incident

The client IP or the IP address of the previous proxy if the client IP address is not forwarded

The ID of the incident as shown in the incident list

A detailed message on what caused the incident

The profile within the account that caused the incident

The host section of the URL that precipitated the incident

#!/bin/sh

OUTFILE=/root/WCG/incidents.log

date >> $OUTFILE

echo "Account: $SCIP_INCIDENT_ACCOUNT" >> $OUTFILE

echo "Client-IP: $SCIP_INCIDENT_CLIENTIP" >> $OUTFILE

echo "Incident-ID: $SCIP_INCIDENT_ID" >> $OUTFILE

echo "Detailed Message: $SCIP_INCIDENT_MESSAGE" >> $OUTFILE

echo "Profile: $SCIP_INCIDENT_PROFILE" >> $OUTFILE

echo "Destination Host URL: $SCIP_INCIDENT_REMOTEHOST" >> $OUTFILE

echo "User: $SCIP_INCIDENT_USER" >> $OUTFILE

echo >> $OUTFILE


	Important It is recommended that you do not enter any of the other commands in the /opt/WCG/sxsuite/bin/ directory in this field, and that you exercise caution if you enter a script other than the one provided above.

Working With Encrypted Data > Validating certificates

Support

Search

Article Rating:

Related Articles

Quick Links

Service Requests

How are we doing?