When the ADSS Server OCSP responder is not the authoritative source for revocation status, it can relay the OCSP request to a peer OCSP responder. The OCSP relay feature can be enabled:


Proxy Settings


For relayed OCSP transactions, generally the OCSP service will re-sign the OCSP response before sending the response to the calling client. Use these settings to ensure relayed OCSP requests for the configured OCSP Responder URLs are NOT re-signed before responding to the calling client:



To add an OCSP Responder URL in the list, simply enter the peer OCSP responder URL and press the ADD button.

T​he above proxy configurations works only when the OCSP request is forwarded to a peer OCSP responder using the Service Locator extension found in the incoming OCSP request. If Manual routing is also enabled then Proxy Settings will be ignored.



Manual Routing


It may be necessary to check revocation of such certificates which contain no AIA extension. For example, imagine a CA, which has issued many thousands of certificates without an AIA extension because it was previously using only CRL as revocation checking method. It has now set-up an OCSP responder and any new certificates issued by the CA contain the address of the OCSP responder in the AIA extension. The OCSP responder will be required to respond for all the certificates issued by the CA, those including the AIA extension and those not containing this extension i.e. the PKI continues to use the old certificate until they expire.

When a client receives a certificate which does not contain an AIA extension, it cannot inform its own OCSP responder of where the authoritative OCSP responder is (using the Service Locator extension to an OCSP request). This means the OCSP responder will respond with "unknown" thus impacting interoperability, unless the certificate being checked, was local (i.e. issued by a locally registered CA) in the first place.

The OCSP Service enables a manual routing table to be created for certificates, that do not contain a Service locator extension in the OCSP request. This is done by identifying the CA and manually configuring an address for its OCSP responder. When an OCSP request is seen for a certificate issued by this CA, the OCSP service will forward the request to the identified peer OCSP responder.

Enable manual routing by selecting the option Enable Manual Routing. Manual routing can be configured:

  • To retain the peer OCSP response i.e. the OCSP Service will not re-sign the response received from peer OCSP responder and the response will be sent back to the requester as received. 
    Note: When the multi-cert request will be received at OCSP service, then the functionality of this checkbox will be ignored. 
  • To use only when incoming request has no service locator extension or  
  • It can be configured to override the service locator address in the incoming request.

Add a CA or multiple CAs in the manual routing table by selecting relevant CA certificate(s) using the Browse button and then specifying the OCSP Responder URL for the selected CA. Click the Add button to add the CA(s) in the manual routing table.

Operator is allowed to upload multiple CA certificates which can be linked with a single OCSP responder URL in single attempt.


After a CA has been added in the manual routing table click on the Save button so that the list for the manual routing table is updated with the newly added CA. The address of the OCSP responder can be tested using the Test button. Any CA can be deleted later by selecting a particular CA and then clicking on the Remove button.


See also

Support for Multiple Trust Models

Multiple CA and Unique Certificate Validation Policies
Configuring the OCSP Service
Advanced Settings
Access Control
Transactions Log Viewer
Logs Archiving
Alerts
Management Reporting
Optimising ADSS OCSP Server Performance
Operating OCSP Service in FIPS 201 Compliant Mode
OCSP Service Interface URLs