Previous Topic: Certificate Validity Checking (optional)Next Topic: OCSP Prerequisites


Configure Certificate Revocation List Checking

Configure CRL checking to verify whether a user certificate has been revoked. This verification helps ensure that a user with an invalid client certificate cannot access a protected resource.

You can obtain a CRL from an LDAP directory or from a location specified by a CDP. If the Policy Server is going to obtain CRLs from a specific LDAP directory, be sure to configure a connection to that directory in the User Directory section of the Administrative UI. This LDAP directory can act as a user store and a CRL store. Configure the directory before configuring CRL checking or during the CRL configuration process.

To configure CRL checking

  1. Log on to the Administrative UI.
  2. Select Infrastructure, Directory.
  3. Expand the Certificate Mapping option.
  4. Select Create or Modify a Certificate Mapping.

    The Certificate Mapping dialog opens.

  5. Select Perform CRL Checks in the Certificate Revocation List Checking group box.

    CRL-specific fields and controls display.

    Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.

  6. In the CRL Directory field, select the name of the LDAP directory from where the Policy Server obtains the CRL. The directory name is the name you assigned when configuring the directory in the User Directory section of the Administrative UI. If there is no user directory in the list, click Create to add a directory connection.

    If you do not specify an LDAP directory in the CRL Directory field, select Use Distribution Points as the method by which the Policy Server retrieves a CRL.

    Note: An optional text string value for the CRL Directory field exists and it reads "Take from Certificate Extension." Only select this option if you plan to use distribution points for CRL retrieval.

  7. If you specified a user directory in the CRL Directory field, enter a value for the entry point DN in CRL Directory field.

    The entry in this field is the DN where the Policy Server looks in the CRL directory to locate the CRL. This field is valid only when the CRL Directory field is set to an LDAP directory. If you enable distribution points to locate CRLs, leave this field blank.

  8. (Optional) Select Verify signature to verify the signature of the CRL.

    The Policy Server requires an accessible LDAP host to retrieve the certificate necessary to verify the signature of the CRL. Be sure that you have configured an LDAP host as a user directory connection in the Administrative UI.

    Note the following:

  9. (Optional) Select Use Distribution Points to use the CDP extension to locate CRLs. You can use this option as an alternative to specifying a CRL directory.

    If you select Use Distribution Points and enter a directory in the CRL Directory field, the Policy Server uses only the distribution points to locate the CRL. Distribution points take precedence over the CRL directory and the CRL Directory entry becomes irrelevant.

  10. Complete the remaining settings, as necessary, and click Submit.

Certificate revocation list checking is enabled.

Accessing a CRL through an HTTP Proxy

CRLs requests can be made over an HTTP connection, requiring an HTTP GET request to retrieve the CRL for certificate validation.

In many enterprise environments, HTTP traffic goes through an HTTP proxy. For the Policy Server to retrieve a CRL through an HTTP proxy, set the http_proxy environment variable on the system where the Policy Server resides. For example:

set http_proxy=http://username:password@proxy.example.org:8080
export http_proxy

If you do not specify a port number, SiteMinder defaults to port 1080.

username

The login user name for the proxy server. This name has to be a valid user in the proxy server configuration.

password

The login password for the proxy server. This password has to be a valid entry in the proxy user configuration.

Note: You cannot use this environment variable for accessing an OCSP Responder through a proxy.

Online Certificate Status Protocol Checking (OCSP)

The Online Certificate Status Protocol (OCSP) helps maintain security across your environment by verifying whether user certificates are valid. OCSP uses OCSP responders to determine the revocation status of an X.509 client certificate. The OCSP responder does its verification in real time by aggregating certificate validation data and responding to an OCSP request for a particular certificate.

One benefit of OCSP is that you do not have to keep downloading a CRL at the client side to maintain the most up-to-date certificate status information. Additionally, CRLs can be large.

To implement OCSP checking, the Policy Server uses a text-based configuration file named SMocsp.conf file. This file is located in the directory policy_server_home/config, and it must exist to use the SiteMinder OCSP feature.

The SMocsp.conf file contains settings that define the operation of one or more OCSP responders. When verifying if a user certificate is valid, the Policy Server looks for an Issuer DN in the SMocsp.conf file. If it finds the Issuer DN, a certificate status check is made using the specified OCSP responder associated with the Issuer DN. If the Policy Server does not find the Issuer DN, the Policy Server does not perform OCSP checking and the certificate is considered valid. A certificate is considered valid in the absence of an Issuer DN to satisfy cases where OCSP validation is not required.

You can sign an OCSP request; however, signing requests is an optional feature.

When the OCSP responder returns a response to the Policy Server, the Policy Server default behavior is to validate the signed response. Several settings in the SMocsp.conf file require configuration to enable response verification.

Note: If CRL checking is enabled in the Administrative UI, the Policy Server uses CRL checking by default, regardless of whether an SMocsp.conf file is present. OCSP take precedence over CRL checking only if you enable failover and set OCSP as the primary validation method. Failover is configured in the OCSP configuration file.