Please do not open a public issue for a security vulnerability.

Report it privately through GitHub's private vulnerability reporting — the "Report a vulnerability" button under the Security tab.

Useful things to include: what an attacker can achieve, the configuration and status source in use, and a reproduction if you have one.

This is a small project maintained on a best-effort basis. It is not a funded security programme and there is no bounty — but reports will be read and acted on, and you will be credited in the advisory unless you would rather not be.

Pre-1.0, fixes go to the latest minor only. There are no backports.

Things worth reporting:

• Any path that produces a good response for a revoked certificate
• Any way to make the responder sign a response for an issuer it is not configured for, or that bypasses issuer binding validation
• Anything that discloses the signing key or its material
• Forging or tampering with a response that clients would still accept
• Accepting a CRL that fails issuer or signature verification
• Remote crash or resource exhaustion from a crafted OCSP request

Things that are working as intended:

• OCSP served over plain HTTP. Responses are signed; the transport is not what makes them trustworthy. TLS is available but optional by design.
• Responses are cached in memory. They are signed and carry their own validity window, so a cached response cannot be forged into something else.
• unknown returned when the status source fails. This is the intended fail-closed behaviour, not an availability bug.
• Nonces are not echoed. RFC 6960 §4.4.1 nonces are ignored by design, so responses are cacheable. A captured response can therefore be replayed until its nextUpdate; signer.response_validity bounds that window and should be shortened if replay is part of your threat model. See DESIGN.md for the reasoning.
• Request contents appearing in debug-level logs. Debug logging is opt-in and OCSP requests are not secret.

Two things that are your responsibility rather than the software's, and that cause real incidents:

• Signing key permissions. 600, owned by the service user. The key is never logged, but file permissions are not something this project can enforce.
• Signing certificate expiry. An expired signer does not stop the process: it keeps serving signed responses that every client will reject, while /health reports unhealthy. The practical effect is a total outage that the logs describe only as a warning. ocsp_signer_days_until_expiry is exported for exactly this reason — alert on it.