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\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 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.
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 Mappings page appears.
The View Certificate Mapping page appears.
The settings and controls become active.
CRL-specific fields and controls display.
Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.
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, 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 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 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.
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 CA 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.
Set up the following components to use OCSP for certificate validation:
You obtain these certificates in a communication that is separate from an OCSP transaction.
To store the trusted certificate or collection of certificates, configure the LDAP directory in the User Directory section of the Administrative UI. The presence of the user directory enables the Policy Server to connect to it and locate the certificate or collection of certificates to verify the response signature. If you are storing a collection of certificates, be sure to use a multi–valued binary attribute for the directory entry to store all the certificates.
The OCSP responder can include the signature verification certificate with the response. In this case, the Policy Server validates the certificate and the response signature with the trusted certificate in the LDAP directory.
If the signature verification certificate is not in the response, the Policy Server verifies the signature of the response with the certificate or collection of certificates in the LDAP directory.
When you configure OCSP, specify the location of the certificate or the collection of certificates in the ResponderCertEP setting of the SMocsp.conf file.
The Policy Server can work with any OCSP response that is signed using SHA-1 and the SHA-2 family of algorithms (SHA224, SHA256, SHA384, SHA512).
For UNIX operating platforms, the file name must maintain the case-sensitivity.
The Policy Server uses a file named SMocsp.conf to implement OCSP checking. This file is an ASCII file with one or more OCSPResponder records.
The SMocsp.conf file must reside in the directory siteminder_home/config. For ease of configuration, a sample file (SMocsp.Sample.conf) is installed with the Policy Server in the config folder. To configure OCSP for your environment, copy the sample file and rename it SMocsp.conf.
Note: For UNIX platforms, maintain the case–sensitivity of the file name.
The following excerpt is an example of an SMocsp.conf file with a single OCSPResponder entry.
Note: The sample file shows all available settings. Not all settings are required.
[ OCSPResponder IssuerDN C=US,ST=Massachusetts,L=Boston,O=,OU=QA,CN=Issuer,E=user@domain.com AlternateIssuerDN C=US,ST=New York,L=Islandia,O=,OU=QA,CN=Issuer,E=user@domain.com CACertDir 10.1.22.2:389 CACertEP uid=caroot,dc=systest,dc=com ResponderCertDir 10.2.11.1:389 ResponderCertEP cn=OCSP,ou=PKI,ou=Engineering,o=ExampleInc,c=US ResponderCertAttr cacertificate ResponderLocation http://10.12.2.4:389 AIAExtension NO HttpProxyEnabled YES HttpProxyLocation http://10.11.2.5:80 HttpProxyUserName proxyuser1 HttpProxyPassword letmein SignRequestEnabled YES SignDigest SHA256 Alias defaultenterpriseprivatekey IgnoreNonceExtension NO PrimaryValidationMethod OCSP EnableFailover YES ResponderCertAlias cert1 ResponderGracePeriod 0 ]
Guidelines for modifying the SMocsp.conf file are as follows:
The settings in the file are as follows:
Required. Indicates that the entry is an OCSP responder record. Each OCSP Responder record must start with the name OCSPResponder.
Required. Specifies the DN of the certificate issuer. This value labels each OCSP Responder record in the file.
Entry: The Issuer DN value in the certificate.
Optional. Specifies a secondary IssuerDN or reversed DN.
Required. Specifies the name of the CA certificate directory that holds the CA certificate that issues the user certificate.
Be sure to configure this directory as a CA SiteMinder® user directory in the Administrative UI so the Policy Server can connect to it.
Enter a valid IP address and port number of the user directory.
Required. Specifies the entry point in the CA certificate directory where the CA certificate resides.
Enter a string representing an entry point in the certificate directory.
Required. Specifies the LDAP directory where the responder certificates is stored.
Be sure to configure this directory as a CA SiteMinder® user directory in the Administrative UI so the Policy Server can connect to it.
Enter a valid IP address and port number of the directory.
Required. Specifies the entry point in the LDAP directory where the responder certificate resides. The responder certificate directory is specified in the ResponderCertDir setting.
The signature verification certificate is the certificate that directly verifies the response signature or the collection of intermediate certificates.
The OCSP responder can include the signature verification certificate with the response. In this case, the Policy Server verifies the response signature and the certificate using the trusted certificate in the LDAP directory. If the signature verification certificate is not in the response, the Policy Server verifies only the response signature with the certificate or collection of certificates in the LDAP directory.
Enter a string representing an entry point in the directory where the certificate or the collection of certificates resides.
Required. Indicates the LDAP directory attribute that the Policy Server uses to look up the responder certificate in the responder certificate directory, which is specified in the ResponderCertDir setting.
Optional. Indicates the location of the OCSP responder server.
You can use the ResponderLocation setting or the AIAExtension setting, but note the following conditions:
If you enter a location, enter the value in the form responder_server_url:port_number.
Enter a URL and port number of the responder server.
Optional. Specifies whether the Policy Server uses the Authority Information Access extension (AIA) in the certificate to locate validation information.
You can use the AIAExtension or ResponderLocation settings, but note the following items:
Enter YES or NO.
Default: NO
Optional. Tells the Policy Server to send the OCSP request to the proxy server, not to the web server.
Enter YES or NO.
Default: NO
Optional. Specifies the URL of the proxy server. This value is only required if HttpProxyEnabled is set to YES.
Enter a URL beginning with http://.
Note: Do not enter a URL beginning with https://.
Optional. Specifies the user name for the login credentials to the proxy server. This user name must be the name of a valid user of the proxy server. This value is only required if HttpProxyEnabled is set to YES.
Enter an alphanumeric string.
Optional. Specifies the password for the proxy server user name. This value is displayed in clear text. This value is only required if HttpProxyEnabled is set to YES.
Enter an alphanumeric string.
Optional. Instructs the Policy Server to sign the generated OCSP request. Set this value to Yes to use the signing feature.
This value is independent of any user certificate signatures and is only relevant for the OCSP request.
Note: This setting is required only if the OCSP responder requires signed requests.
Enter YES or NO.
Default: NO
Optional. Designates the algorithm the Policy Server uses when signing the OCSP request. This setting is not case-sensitive. This setting is required only if the SignRequestEnabled setting is set to YES.
Enter one of the following options: SHA1, SHA224, SHA256, SHA384, SHA512
Default: SHA1
Optional. Specifies the alias for the key/certificate pair that signs the OCSP request that is sent to an OCSP responder. This key/certificate pair must be in the CA SiteMinder® certificate data store.
Note: The alias is required only if the SignRequestEnabled setting is set to YES.
Enter an alias using lower-case ASCII alphanumeric characters.
Optional. Tells the Policy Server not to include the nonce in the OCSP request. The nonce (number that is used once) is a unique number sometimes included in authentication requests to prevent the reuse of a response. Setting this parameter to Yes instructs the Policy Server not to include the nonce in the OCSP request.
Enter YES or NO.
Default: NO
Optional. Indicates whether OCSP or CRL is the primary method the Policy Server uses to validate certificates. This setting is only required if the EnableFailover setting is set to Yes.
Enter OCSP or CRL.
Default: OCSP
Tells the Policy Server to failover between OCSP and CRL certificate validation methods.
Enter YES or NO.
Default: NO
(Required for federation only). Names the alias of the certificate that verifies the signature of the OCSP response. For the Policy Server to perform response signature verification, specify an alias for this setting. Otherwise, the CA issuer has no available OCSP configuration.
Note: The Policy Server does not use this setting for X.509 certificate authentication.
Enter a string that names the alias.
You can see whether each issuer has an OCSP configuration after the SMocsp.conf file is loaded. The following message is a sample status message:
The SMocsp.conf file was loaded. OCSP configuration was added for the following issuer aliases: ocspcacert ocspcacert1 ocspcacert2
The issuer alias in the status message refers to the alias you specified in the Administrative UI when adding a CA certificate to the data store. If an issuer alias is not in the list, check the SMocsp.conf and the cds.log file. The log file is located in siteminder_home\log.
(Optional) Specifies the period (in days) to delay the invalidation of a certificate after it is revoked. The OCSP grace period gives you time to update certificates so that the configuration does not suddenly stop working. A value of 0 indicates that when a certificate is revoked it becomes invalid immediately.
If you do not specify a value for this field, the Policy Server uses the default revocation grace period setting in the Administrative UI. You can find the default setting by navigating to Infrastructure> X509 Certificate Management > Certificate Management.
Default: 0
Configure OCSP checking so that a user with an invalid client certificate cannot access a protected resource.
Note: Before you can enable OCSP checking, set up your environment for certificate authentication.
The Policy Server can work with any OCSP response that is signed using SHA-1 and the SHA-2 family of algorithms (SHA224, SHA256, SHA384, SHA512).
To configure OCSP checking (without failover enabled)
A sample file, named SMocsp.Sample.conf is installed with the Policy Server in the config directory.
For UNIX platforms the file name is case-sensitive; for Windows platforms it is not.
Important! If you do not configure a responder record for each Issuer DN, the Policy Server authenticates users without confirming the validity of the certificate.
The Certificate Mappings dialog opens.
If the issuer of the user certificate matches a certificate mapping and CRL Checking is enabled, the Policy Server uses CRL checking and not OCSP. Enabling failover is an exception to CRL checking taking precedence over OCSP. If you enable failover, the Policy Server uses the configured primary validation method.
OCSP is now enabled. To disable OCSP, change the name of the SMocsp.conf file.
OCSP requests are made over an HTTP connection, requiring an HTTP GET for the request to the OCSP responder for certificate validation.
In many enterprise environments, HTTP traffic goes through an HTTP proxy. For the Policy Server to send an OCSP request through an HTTP proxy, configure the proxy settings in the SMocsp.conf file.
To configure access to an OCSP Responder through a proxy
Learn how to set each value by reviewing how to create an OCSP configuration file.
The Policy Server can sign OCSP requests when using a CA SiteMinder® certificate authentication scheme. Signing requests is only necessary if an OCSP responder requires signed requests.
Prerequisites for Signing OCSP Requests
Before you configure OCSP signing, complete the following prerequisite tasks:
When you add a key/certificate pair, specify an alias. The Policy Server uses the alias to identify the certificate entry in the certificate data store. When you specify an alias, note the following restrictions:
Note: Private keys must be RSA keys.
The Policy Server can sign requests and verify responses when using a CA SiteMinder® certificate authentication scheme.
To configure OCSP request signing
Instructs the Policy Server to sign an OCSP request.
Limits: Yes or No
Set this value to Yes to use the signing feature.
Accept the default, No, to disable signing.
Default: No. If the SignRequestEnabled entry is not present in a responder record, the Policy Server cannot sign OCSP requests.
Indicates the algorithm to use to sign an OCSP request.
Options:
SignDigest is not case-sensitive.
Default: SHA1
Indicates the alias under which the Policy Server looks to retrieve the signing key/certificate pair. Aliases are restricted to lower-case USA ASCII alphanumeric characters.
Signing of OCSP requests is now enabled.
The Policy Server can use OCSP and CRLs as certificate validation mechanisms. If you configure both mechanisms, you can configure the Policy Server to failover between the two. Enabling failover is preferable to failing the authentication when one or the other certificate validation mechanisms is not available.
You implement failover for certificate checking by designating a primary verification method in the OCSP configuration file (SMocsp.conf). If the primary validation method is unavailable, the Policy Server uses the secondary validation to complete the request. For the next request, the Policy Server reverts to the primary method and uses that method unless a failure occurs.
OCSP as the Primary Validation Method
If the primary method is OCSP and an OCSP responder is not available, the Policy Server uses a CRL to perform the certificate validation instead.
Failover does not override OCSP functionality as long as the OCSP responder returns a response indicator of good or revoked. If the response indicator is "unknown," failover to CRL checking occurs.
If you configure OCSP as the primary validation method, the Policy Server behaves as follows:
|
OCSP Certificate Validation |
Failover Disabled |
Failover Enabled |
|---|---|---|
|
Valid |
User authenticated |
User authentication based on OCSP results only. No CRL checking required. |
|
Revoked |
User not authenticated |
User is not authenticated. No CRL checking required. |
|
Unknown or No response |
User not authenticated |
Perform CRL checking |
CRL Checking as the Primary Validation Method
If the primary method is CRL checking and the Policy Server cannot retrieve a CRL, the Policy Server fails over to the OCSP responder. In this case, the Policy Server only relies on OCSP when a connection to the CRL directory server is not available. If the CRL returns a valid response, the Policy Server does not use OCSP.
Note: If failover is not enabled, and CRL checking and OCSP are both configured, the Policy Server uses only CRL checking for certificate validation.
If you configure CRL as the primary validation method, the Policy Server behaves as follows:
|
CRL Certificate Validation |
Failover Disabled |
Failover Enabled |
|---|---|---|
|
Valid |
User authenticated |
Checking is based on the first valid CRL results. No further CRL checking required. |
|
Revoked |
User not authenticated |
No further CRL or OCSP checking required. |
|
No response/retrieval failed |
If a CDP extension is available, the Policy Server tries each distribution point in consecutive order until it successfully retrieves a CRL. If the status for the certificate is valid or revoked, refer to the descriptions for those states. If a CRL with all reason codes is not retrieved, the Policy Server defaults to Not Authenticated. |
If a CDP extension is available, the Policy Server tries each distribution point in consecutive order until it successfully retrieves a CRL. If the status for a certificate is valid or revoked refer to the descriptions for those states. If a CRL with all reason codes is not retrieved, use OCSP. |
The Policy Server can use OCSP and CRLs as certificate validation mechanisms, enabling failover between the two. Before enabling failover, configure CRL checking in the Administrative UI and configure OCSP by creating the SMocsp.conf file. CRL checking and OCSP checking must be enabled for failover to work.
To enable OCSP Failover to a CRL
Enables CA SiteMinder® to fail over from the primary validation method to the secondary method.
Set this value to Yes to enable failover.
Accept the default, No, if you do not want to configure failover. If you do not configure failover and the OCSP responder cannot perform validation, the transaction fails.
Limits: YES or NO
Default: No
Indicates which certificate validation method the Policy Server uses first before trying the other method.
If EnableFailover is set to YES and the value for this setting is OCSP, the Policy Server uses OCSP validation first. If there is no response from the OCSP responder or the response indicator is "unknown," then the Policy Server fails over to a CRL.
If the value for this setting is CRL, the Policy Server ignores OCSP validation, even if it is configured, and uses a CRL. If the Policy Server cannot obtain the CRL or the CRL expires, the Policy Server fails over to OCSP.
Limits: OCSP, CRL
Default: OCSP
Detailed trace logging is available to help you solve your X.509 certificate authentication and validation problems.
In addition to the typical OCSP and CRL messages, if a failover event occurs the Policy Server logs diagnostic messages specific to the certificate validation failure, followed by messages describing the failover. The message can indicate that OCSP could not be contacted and that it is using a CRL or that the CRL fetch failed and that the Policy Server is failing over to OCSP checking.
To view OCSP and CRL log message, enable authentication trace logging using the Profiler in the Policy Server Management Console.
You can determine which components and data fields the Policy Server includes for trace logging by modifying the default template file smtracedefault.txt.
The following smtracedefault.txt file shows some recommended components to include in the file for certificate validation diagnostics in the trace log.
components: Login_Logout/Authentication, Login_Logout/Certificates, Login_Logout/Receive_Request, IsAuthorized/Policy_Evaluation, IsAuthorized/Receive_Request, Directory_Access, LDAP/Ldap_Error_Messages
data: Date, PreciseTime, SrcFile, Function, ReturnValue, Message, User, Directory, SearchKey, ErrorString, ErrorValue, AuthStatus, AuthReason, CertSerial, SubjectDN, IssuerDN, CertDistPt, UserDN, Data, HexadecimalData, CallDetail, Returns, Result
For instructions on enabling authentication trace logging, see the Policy Server Administration Guide.
For OCSP signing only, you can enable trace messages when trying to validate signatures.
To enable tracing for OCSP signing
policy_server_home is the directory where you installed the Policy Server
-DOCSP_PS_TRACE=true
The trace file, named OcspCertKeyRetriever.log is written to the current working directory of the Policy Server, as follows:
Windows: system32
Unix: siteminder or siteminder/bin
|
Copyright © 2013 CA.
All rights reserved.
|
|