OCSP certificate revocation checking
When your integration enforces mutual TLS (mTLS), client applications must present a valid certificate issued by a trusted Certificate Authority (CA). This ensures that only authorized clients can access your protected resources.
For enhanced security, Transmit supports real-time certificate revocation checks using [OCSP (Online Certificate Status Protocol)(https://datatracker.ietf.org/doc/html/rfc6960)]. OCSP allows Mosaic to verify whether a client certificate has been revoked by its issuing CA before allowing authentication to proceed.
This adds a critical layer of protection in scenarios where a client certificate may have been compromised or intentionally revoked—ensuring that revocation is respected at runtime, not just at issuance.
How it works
When OCSP checking is enabled, Mosaic validates the revocation status of the client certificate during mTLS authentication. When a client certificate is received, Mosaic sends an OCSP request to the configured responder URI. Mosaic validates the OCSP response using either the configured OCSP responder certificate, or a certificate from the client certificate chain or OCSP response. Based on the response the authentication proceeds (good
) or is blocked (revoked
) (). In case of impossibility to receive a response (unknown
) the behavior depends on the configured fallback mode.
Note
When Mosaic sends an OCSP request to the responder URI:
- if no URI is configured , Mosaic attempts to extract it from the certificate’s AIA (Authority Information Access) extension.
- if multiple URIs are present in AIA , only the first is used.
Response caching
OCSP responses are cached for 30–60 minutes to reduce network traffic and improve performance.
Enable OCSP checking
To enable OCSP revocation checking for client certificates, follow the configuration steps described in the mTLS authentication guide. There you’ll find detailed instructions on how to activate OCSP, configure responder settings, and define fallback behavior.