OCSP Check Logic

The following steps describe the logic of OCSP checking in Sterling B2B Integrator:

If the certificate status is ok, the OCSP check succeeds. Otherwise, it fails.

  1. If an existing response whose time-to-live has not expired is found, than that response is used as the OCSP response.
  2. If no existing response is found in the cache or the time-to-live has expired for a response in the cache, an OCSP request is created.
  3. If the system creates an OCSP request, it launches the business process configured for the OCSP responder to send the request and get the response. Requests will include a nonce value if the responder was configured to have one sent.
  4. If the business process completes successfully, the system attempts to parse its primary document as an OCSP response. The business process used to send OCSP requests and receive OCSP responses strips the HTTP headers from the response.
  5. If the primary document can be parsed as an OCSP response, the system checks the status of the response.
  6. If the response status indicates that the request generated a valid response, the system attempts to verify the signature on the OCSP response using the certificate configured for the OCSP responder.
  7. If the signature is verified and the responder was configured to require nonce, the system attempts to get and check the nonce from the response.
  8. If all other verifications passed, then the system looks for certificate status information for the certificate for which the request was constructed and sent.
  9. If the status information is found, then the system updates the internal cache for an existing OCSP response for the certificate.