OCSP

The Online Certificate Status Protocol (OCSP) allows clients to check the revocation status of a certificate in real time, without downloading an entire CRL. Certman provides a public OCSP responder for every CA you create.

How It Works

When a client (browser, application, or TLS library) encounters a certificate issued by your CA, it can query the OCSP responder to verify the certificate hasn't been revoked:

1. The client reads the Authority Information Access (AIA) extension from the certificate to find the OCSP responder URL.
2. The client sends an OCSP request containing the certificate's serial number.
3. The responder replies with a signed response indicating the certificate status: good, revoked, or unknown.

OCSP Responder URL

Each CA's OCSP responder is publicly accessible at:

https://ocsp.certman.app/{ca_id}

This URL is automatically embedded in the AIA extension of all certificates and CAs issued by Certman, so clients can discover it without any manual configuration.

Request Methods

The OCSP responder supports two methods as defined by RFC 6960:

• POST — Send a DER-encoded OCSP request as the request body with Content-Type: application/ocsp-request
• GET — Append the base64url-encoded DER request to the URL path

# POST method
curl -X POST https://ocsp.certman.app/{ca_id} \
  -H "Content-Type: application/ocsp-request" \
  --data-binary @request.der

# GET method
curl https://ocsp.certman.app/{ca_id}/{base64url-encoded-DER}

Response

The OCSP response is returned with Content-Type: application/ocsp-response and includes caching headers (Cache-Control: public, max-age=3600) to reduce load on the responder.

Each response contains the status for the queried certificate serial number:

• Good — The certificate is valid and has not been revoked
• Revoked — The certificate has been revoked, includes the revocation time
• Unknown — The certificate serial number is not recognized by this CA

OCSP vs CRL

Both OCSP and CRLs serve the same purpose (communicating revocation status), but differ in approach:

Certman supports both mechanisms. Use OCSP for real-time checks and CRLs as a fallback or for environments with limited connectivity.

Passphrase-Protected CAs

OCSP continues to work automatically even when a CA is protected with a passphrase. Here's how:

When you create a CA with passphrase protection, Certman generates a separate OCSP signing certificate specifically for signing OCSP responses. This OCSP certificate:

• Is signed by your CA at the time of creation (when you provide the passphrase)
• Has the id-kp-OCSPSigning extended key usage, authorizing it to sign OCSP responses on behalf of the CA
• Is stored server-side with the standard encryption (not passphrase-protected)
• Has the same validity period as the CA itself

This design ensures that OCSP responses can be generated automatically without requiring you to provide the CA passphrase for each status check. The OCSP signing certificate is a standard PKI pattern (RFC 6960) where a CA delegates OCSP response signing to a designated responder.

Security note: While the OCSP signing certificate is stored server-side, it can only sign OCSP responses — it cannot issue new certificates or perform other CA operations. Your CA's private key remains protected by your passphrase for all certificate issuance and revocation operations.

Using OpenSSL to Verify

You can test OCSP status for a certificate using OpenSSL:

openssl ocsp \
  -issuer ca.pem \
  -cert certificate.pem \
  -url https://ocsp.certman.app/{ca_id} \
  -resp_text