A CRL is a signed list of revoked certificate serial numbers published periodically by a CA. Clients download CRLs to check if a presented certificate has been revoked. CRLs are large (megabytes), updated infrequently (hours to days), and rarely checked by browsers. OCSP and short-lived certificates are the modern replacements.
Certificate Revocation Lists are the original mechanism for distributing revocation information. A CA signs a list of all revoked certificate serial numbers and publishes it at a CRL Distribution Point URL embedded in each certificate. Clients download the full list and check whether the presented certificate's serial appears. CRLs have fundamental scaling problems: popular CAs revoke thousands of certificates, making CRLs megabytes in size. Downloading a full CRL for each TLS connection is impractical. Update frequency (typically 1-24 hours) means recently revoked certificates remain trusted until the next CRL publication. Most browsers abandoned CRL checking in favor of OCSP stapling and CRLSets (compact, proprietary subsets of revoked certs maintained by browser vendors). Let's Encrypt's 90-day certificate lifetime reduces the revocation window, making CRLs and OCSP less critical.
Certificate Authority (CA)
A Certificate Authority issues and signs TLS certificates that browsers and operating systems trust. CAs verify domain ownership (DV), organization identity (OV), or extended validation (EV) before signing. The CA system relies on ~150 root certificates pre-installed in trust stores. Let's Encrypt automated DV issuance, issuing 400M+ active certificates.
OCSP (Online Certificate Status Protocol)
OCSP is a protocol for checking whether a TLS certificate has been revoked in real-time. Instead of downloading entire CRL lists, clients query the CA's OCSP responder for a single certificate's status (good/revoked/unknown). OCSP stapling lets the server fetch and cache the response, avoiding client-side privacy leaks and latency.