Successful OCSP responses from the OCSP service are digitally signed so that Relying Parties (RP) can authenticate the responses and thereby prevent an attacker from spoofing the OCSP service. The OCSP service therefore uses public/private key pairs for signing OCSP responses.


How the public keys of the OCSP service are certified will depend on the particular trust model adopted by your PKI. For example, imagine a scenario where a PKI is established with a Root CA and a Sub CA, and an OCSP responder. Let's assume the purpose of the OCSP responder in this scenario is to provide status information for the certificates issued by the Sub CA.


In this case the options for certifying the OCSP server are as follows:

  • The OCSP responder is certified by the Root CA.
  • The OCSP responder is certified by the Sub CA for which it responds.
  • Some keys of the OCSP responder are certified by the Root CA and some of the keys are certified by the Sub CA.
  • The OCSP responder's keys are self-certified (in this case the OCSP server is directly trusted by the Relying Party).


The OCSP service supports all of these trust models and generally each CA registered on OCSP service can choose the trust model it wishes to follow. The figure below illustrates the first three trust models (the black arrows representing certificates issued by one entity to another):

See also

Support for Multiple Trust Models

Multiple CA and Unique Certificate Validation Policies
Configuring the OCSP Service

General Policy Settings
Forwarding Modes
Access Control
Transactions Logs
Logs Archiving
Alerts
Advanced Settings
Optimising ADSS OCSP Server Performance
Operating OCSP Service in FIPS 201 Compliant Mode

OCSP Service Interface URLs