https://lesitedefrancois.be/en/tags/x509/Recent content in X509 on Le Site de FrançoisHugo -- gohugo.ioen© 2026 Françoishttps://lesitedefrancois.be/en/security/crl/Mon, 01 Jan 0001 00:00:00 +0000https://lesitedefrancois.be/en/security/crl/<p><strong>A Certificate Revocation List (CRL)</strong> is a signed data structure, published by a <strong>Certificate Authority</strong> as part of its <strong>PKI</strong> operations, that lists the serial numbers of <strong>X.509</strong> certificates the CA has revoked before their scheduled expiry date. A CA revokes a certificate when its private key is compromised, the subject&rsquo;s identity information changes, the certificate was mis-issued, or the subject is no longer authorised. Without revocation, a compromised certificate remains trusted by all verifiers until it expires — which for long-lived CA and infrastructure certificates can be years. The CRL is the oldest revocation mechanism, defined in RFC 5280 alongside the X.509 v3 certificate format, and remains widely deployed for CA certificates, code signing certificates, and client certificates in contexts where <strong>OCSP</strong> is impractical.</p>https://lesitedefrancois.be/en/security/ocsp/Mon, 01 Jan 0001 00:00:00 +0000https://lesitedefrancois.be/en/security/ocsp/<p><strong>OCSP (Online Certificate Status Protocol)</strong>, standardised in RFC 6960, is a request-response protocol that allows a verifier to query an <strong>OCSP responder</strong> — a service operated by the <strong>CA</strong> or a delegated party — for the current revocation status of a specific <strong>X.509</strong> certificate. Where a <strong>CRL</strong> requires downloading an entire list and searching it locally, an OCSP query asks about exactly one certificate and receives a signed response: <code>good</code> (the certificate is currently valid and not revoked), <code>revoked</code> (revoked, with the revocation time and reason), or <code>unknown</code> (the responder does not know this certificate). The OCSP response is signed by the CA&rsquo;s OCSP signing key (or a dedicated OCSP responder key with the <code>id-pkix-ocsp-nocheck</code> extension, exempt from its own revocation checking to prevent circularity) and carries a <code>thisUpdate</code> and <code>nextUpdate</code> timestamp defining its freshness window. Verifiers in strict mode reject responses outside the freshness window; in practice, OCSP responses are valid for 24 hours to 7 days depending on the CA&rsquo;s policy, meaning OCSP shares CRL&rsquo;s staleness problem, albeit with a smaller window.</p>