The Policy Server can sign OCSP requests when using a 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:
Use the smkeytool utility to create the database.
When you add a key/certificate pair, specify an alias so the Policy Server can identify the certificate entry in the key database. 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 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 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 © 2012 CA.
All rights reserved.
|
|