Configuring validation settings

Steps

  1. In the Content Gateway manager, go to the Configure > SSL > Validation > General tab.
  2. If it is not already selected, mark the Enable the certificate verification engine check box.
    • Certificate verification is enabled by default.
    • If this option is not selected, certificate validation does not occur.
  3. Indicate whether or not to Deny certificates where the common name does not match the URL. When this option is selected, 2 checks are made:
    • 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” to access “https://www.cia.gov” may result in a block. Additionally, a block may occur when users attempt to access a site by IP address.

  4. If you have enabled the Deny certificates option, indicate whether or not to Allow wildcard certificates. When selected, 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” could cover “email.example.com” and “stream.example.com”, among others.

    • 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.
  5. Select the No expired or not yet valid certificates option to deny 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.
  6. Indicate whether or not to Deny self-signed certificates. By default, the option is enabled, and self-signed certificates (certificates without an official certificate authority) are considered invalid.
  7. Indicate whether or not to Verify entire certificate chain. By default, this option is enabled, and Content Gateway 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.
  8. Indicate whether or not to 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, verify that the daily CRL update feature is enabled on the Revocation Settings tab under CRL Settings.
    • If this option is not used, disable the daily CRL update feature on the Revocation Settings tab under CRL Settings.
  9. Indicate whether or not to 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 about CRLs and OCSP.
  10. If you are using OCSP revocation checking, use the Block certificates with Unknown OCSP state option to determine whether to block certificates that return the “Unknown” status.
  11. If both CRL and OCSP revocation checking are enabled, indicate your Preferred method for revocation check. The selected method (CRL, by default), is applied first.
  12. If you have enabled CRL or OCSP checking (or both), use the Block certificates with no CRL URI and with no OCSP URI 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 Managing certificates 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.