X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
Embed This Widget
Add the script tag and a data attribute to embed this widget.
Embed via iframe for maximum compatibility.
<iframe src="https://ipfyi.com/iframe/entity//" width="420" height="400" frameborder="0" style="border:0;border-radius:10px;max-width:100%" loading="lazy"></iframe>Paste this URL in WordPress, Medium, or any oEmbed-compatible platform.
https://ipfyi.com/entity//Add a dynamic SVG badge to your README or docs.
[](https://ipfyi.com/entity//)Use the native HTML custom element.
S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams · 2013-06
Abstract
This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFC 2560.
Why This RFC Matters
RFC 6960 defined OCSP as a real-time alternative to Certificate Revocation Lists (CRLs) for checking whether a TLS certificate has been revoked before the end of its validity period. Unlike CRLs that must be downloaded and parsed in their entirety, an OCSP request asks a CA's responder about one specific certificate, returning a signed 'good', 'revoked', or 'unknown' response. OCSP Stapling (RFC 6066) extends this by having the server include a pre-fetched OCSP response in the TLS handshake, improving both performance and privacy, and is now the standard approach for certificate status in modern TLS deployments.