Certificate validity checking is an optional feature for X.509 client certificate authentication.
The Policy Server can confirm whether a user certificate is valid using the following methods:
The Policy Server can use CRLs to determine whether a certificate is revoked. In the Administrative UI, you can specify a path to a CRL directory or select CRL Distribution Points (CDPs) to locate CRLs.
The Policy Server sends a request to an OCSP responder in reference to a single user. The OCSP responder determines the revocation status of the user certificate and sends back the response.
The Policy Server determines which certificate validation method it uses as follows:
The Policy Server regards the first good or revoked response it obtains to be definitive. The Policy Server does not request subsequent CRLs or OCSP responses after the first valid response. In addition, the Policy Server does not aggregate the results of CRL and OCSP validation to determine the comprehensive status of the user certificate.
For the Policy Server to validate a user certificate, an X.509 client certificate authentication scheme must be configured and be able to authenticate a user when he requests a protected resource.
Review the instructions for setting up an X.509 client certificate authentication scheme.
The instructions for configuring CRLs and OCSP are described in the sections that follow.
A certificate revocation list (CRL) is a digitally signed list of revoked certificates 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 go out and 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 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\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 multi-valued 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 help 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 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.
|
Copyright © 2012 CA.
All rights reserved.
|
|