Online validation with OCSP

OCSP queries a certificate’s status and returns a signed response. This guide is for an integrator checking what Lamassu publishes and how the consumer must verify it. For complete identity validation, follow Certificate validation.

How the responder works in Lamassu

The responder retrieves the certificate by serial number and locates its issuing CA in the inventory. It translates persisted status as follows:

An absent serial number causes a lookup error; it does not guarantee a signed Unknown response. Lookup or signing errors produce an HTTP failure. Treat that as unavailable evidence according to consumer policy.

The issuing CA itself signs the response through its KMS-associated key. A delegated OCSP signing certificate is not used. An imported CA without a usable key cannot sign responses.

The implementation sets thisUpdate approximately one day before response generation and nextUpdate one day after: the declared window is about 48 hours. Inspect received values and apply your freshness policy. The response reflects stored status when queried; a previously cached copy does not change upon revocation.

Embedding in issued certificates

The signer constructs OCSP URLs from configured VA domains and adds them to AIA. Without domains, there is no URL to add; an imported certificate retains its original extensions. Inspect the actual certificate:

openssl x509 -in device.crt -noout -ocsp_uri

Check that the consumer can reach this URL. DNS, endpoint exposure and domain configuration belong to Deployment. Changing configuration does not modify already signed certificates.

HTTP endpoints

The service accepts:

Use POST to avoid client encoding differences. A successful response has Content-Type: application/ocsp-response and a DER body. The public prefix depends on the Gateway; use the URL published in the certificate and checked by the operator.

Generate and verify a query

You need OpenSSL 3.x, device.crt, its direct issuer’s certificate issuer.pem and the consumer’s trusted roots in roots.pem. For an intermediate issuer, also prepare intermediates.pem containing the intermediate CAs.

Generate the request:

openssl ocsp -issuer issuer.pem -cert device.crt \
  -no_nonce -reqout request.der

This example omits the nonce because the responder does not echo it. Verification relies on signature, response correspondence and timestamps; it does not demonstrate freshness through a nonce.

Replace the example URL with the inspected endpoint:

OCSP_URL='http://pki.example.com/ocsp'

curl --fail --show-error --silent --max-time 15 \
  -H 'Content-Type: application/ocsp-request' \
  --data-binary @request.der "$OCSP_URL" \
  -o response.der

Verify the returned DER:

openssl ocsp -respin response.der \
  -issuer issuer.pem -cert device.crt \
  -CAfile roots.pem -no_nonce -resp_text

For intermediates, add -verify_other intermediates.pem. Require successful response verification and inspect the status corresponding to device.crt, issuer, serial, thisUpdate and nextUpdate. Response verify OK validates the response only: also observe good, revoked or unknown. Do not accept an identity based only on the command’s exit code.

Check from the interface

OCSP Check shows what Lamassu returns for a selected certificate. Complete the check from the consumer’s network and trust store: a console query does not establish its validation configuration.

To check a change, save an earlier response, revoke a test certificate and request another response. The new query should reflect persisted status; compare timestamps to rule out reuse of an earlier response. If it fails, follow PKI troubleshooting.

References

• RFC 6960: OCSP.
• OpenSSL: openssl-ocsp.