A certificate revocation list (CRL) is a digitally signed list of revoked certificates that are published by a Certificate Authority (CA) that issued the corresponding certificates. Comparing certificates against CRLs is one method of determining whether a certificate is valid.
You can use one CRL for each Issuer DN that you configure in a Policy Server certificate mapping.
The Policy Server retrieves a CRL in one of the following ways:
The Policy Server can establish a connection to an LDAP directory that you specify in the CRL configuration. From that directory, the Policy Server retrieves a CRL.
Multiple CRLs can exist in an LDAP directory; however, each certificate mapping can refer to only one CRL identified by its entry point. Therefore, each entry point for each CRL must be different.
Note: The Policy Server only accepts a CRL that contains all reason codes, and rejects a CRL with only specific reason codes.
A user certificate can contain a distribution point extension. A CDP extension points to a location from where a CRL can be obtained. The Policy Server supports a distribution point extension with a single entry to a CRL or multiple pointers to different CRLs.
The distribution points can use different sources, such as HTTP, HTTPS, and LDAP. If the CDP extension contains entries that use distribution point names with multiple values, these values must all point to the same CRL.
After the Policy Server retrieves a CRL, it can make the necessary checks. If you enable CRL caching in the Administrative UI, the Policy Server can store the CRL in memory. If you do not enable caching, the Policy Server has to retrieve a CRL for every authentication request.
The Policy Server only supports CRLs that include revocation information for all possible reason codes. If a CRL contains certificates that are revoked for only some reason codes, the Policy Server generates an error and treats the CRL as invalid. The Policy Server ignores invalid CRLs and continues looking for an available CRL until it finds a valid one.
The Policy Server treats delta CRLs as invalid CRLs. A delta CRL lists only those certificates whose revocation status changed after the CA issued the complete CRL. The Policy Server ignores delta CRLs and continues looking for an available CRL until it finds a valid one.
If the Policy Server searches through all available CRLs and cannot find a valid one, it does not authenticate the user.
The Policy Server caches CRLs. The Policy Server default cache size is up to 2 MB. If your CRLs exceed the default cache size, increase the cache size up to a maximum of 1 GB. To increase the cache size, add the MaxCRLBufferMB registry key.
Follow these steps:
Windows: Open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\Software\Wow6432Node\Netegrity\SiteMinder\CurrentVersion\PolicyServer.
UNIX: Open the sm.registry file. The default location of this file is siteminder_home/registry.
Specifies the Policy Server installation path.
Unit of measurement: Megabytes
Base: Decimal
Default value: 2
Minimum value: 1
Maximum value: 1023
Windows: Exit the Registry Editor.
UNIX: Save the sm.registry file.
CRL signature verification is an optional feature of CRL checking.
Before the Policy Server compares certificates against a CRL, it verifies the signature of the CRL with a CA certificate stored in an LDAP directory. The Policy Server retrieves the CA certificate from a specific entry in an LDAP user directory, which is identified based on the Issuer DN in the certificate or the DN in the CRL directory that you configure for the certificate mapping in the Administrative UI.
Store the CA certificates in an LDAP directory that the Policy Server can access. In the LDAP directory, configure the specific directory entry with an attribute named cacertificate. The cacertificate attribute is a multivalued attribute where you can store more than one CA certificate. Multiple CA certificates can be necessary if CRLs are partitioned and a different CA key signs each partition. The Policy Server can only verify the signature of a partition if it can access the associated CA signing certificate for a given partition.
For signature verification, the Policy Server can use the following hash algorithms:
Note: The signature algorithm in use is specified in the CRL.
If a CA certificate is not available or your CRL is signed with an unsupported algorithm, you can disable signature checking during the CRL verification process.
Important! If signature checking is turned off, confirm that the repository where CRLs are stored is protected appropriately.
A CRL Distribution Point (CDP) is a certificate extension that points to a location of a CRL. From the specified location, the Policy Server can retrieve the CRL and can confirm which certificates are revoked.
A CDP extension can specify several sources to locate a CRL. Each source contains all the information to locate a CRL. The different options for retrieval ensure that the Policy Server obtains a CRL. The sources in a CDP extension include:
For an HTTPS distribution point, the Policy Server makes a secure connection. To make this secure connection, a valid CA certificate file or certificate bundle (a file of concatenated certificates that form a chain) must exist in the directory policy_server_home/config. If there is no valid certificate, the connection to the HTTPS server fails.
The CA certificate file for the HTTPS connection must be in PEM format (base64 encoded) and named cert.pem. If the certificate is not in the PEM format, convert it using the OpenSSL command–line utility. The cert.pem file must contain the issuer certificate for the SSL web server that is configured in the CDP extension, and it must contain the trusted CA certificate for each distribution point.
Note: For more information about the OpenSSL utility, see the OpenSSL documentation.
If a CDP extension has multiple entries, the Policy Server uses the first successfully retrieved CRL with all reason codes to validate certificates. The order in which it retrieves the CRLs is the same order that the entries are listed in the certificate itself. If the Policy Server cannot retrieve the first CRL in the CDP list, it tries to retrieve the second CRL, and so on. The Policy Server continues in this manner until it is successful.
If the Policy Server cannot retrieve a valid CRL from any source, authentication fails and the user is denied access. Enabling failover between CRLs and OCSP is the only exception to this behavior. If CRL checking is the primary validation method and it fails, the Policy Server fails over to OCSP as the secondary method.
Note: Enable failover in the configuration file for OCSP.
Configure CRL Distribution Points as part of the CRL Checking settings in the Certificate Mapping dialog.
Verifying Signatures of Partitioned CRLs
Different CA keys can sign different partitions of CRLs. The Policy Server can verify the signature of any CRL partition as long as it can access the associated CA signing certificate for each partition.
The use of partitioned CRLs is relevant when using certificate distribution points to locate CRLs. The extension can have multiple links to different CRLs, all whose signatures need verifying.
The Policy Server verifies the signature of the CRL with the CA certificate stored in an LDAP directory. In this LDAP directory, configure a specific entry with the attribute named cacertificate, which is a multivalued attribute. Multiple CA certificates are required to verify partitioned CRLs signed by different CA keys.
Configure CRL checking to verify whether a user certificate has been revoked. This verification ensures 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 that a CDP specifies. If the Policy Server is going to obtain CRLs from a specific LDAP directory, configure a connection to that directory. 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.
Follow these steps:
The Certificate Mappings page appears.
The View Certificate Mapping page appears.
The settings and controls become active.
CRL-specific fields and controls display.
The directory name is the name that 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, 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 value that is specified in DN in CRL Directory is the DN where the Policy Server looks in the CRL directory to locate the CRL. This value is valid only when an LDAP directory is selected as the CRL 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.
The Policy Server can use a CRL distribution point to locate a CRL. If that distribution point is an LDAP URI, the Policy Server can verify the CRL signature. If the distribution point is an HTTP URI, do not select the Verify Signature option because no LDAP host is available from which to retrieve the certificate.
If you select Use Distribution Points and you enter a directory in CRL Directory, the Policy Server uses only the distribution points to locate the CRL. Distribution points take precedence over the CRL directory.
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, CA 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.
|
Copyright © 2014 CA.
All rights reserved.
|
|