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
The Certificate Mapping dialog opens.
CRL-specific fields and controls display.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
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.
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.
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:
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.
Certificate revocation list checking is enabled.
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.
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.
Copyright © 2012 CA.
All rights reserved.
|
|