github.com/letsencrypt/boulder@v0.20251208.0/docs/CRLS.md (about)

     1  # CRLs
     2  
     3  For each issuer certificate, Boulder generates several sharded CRLs.
     4  The responsibility is shared across these components:
     5  
     6  - crl-updater
     7  - sa
     8  - ca
     9  - crl-storer
    10  
    11  The crl-updater starts the process: for each shard of each issuer,
    12  it requests revoked certificate information from the SA. It sends
    13  that information to the CA for signing, and receives back a signed
    14  CRL. It sends the signed CRL to the crl-storer for upload to an
    15  S3-compatible data store.
    16  
    17  The crl-storer uploads the CRLs to the filename `<issuerID>/<shard>.crl`,
    18  where `issuerID` is an integer that uniquely identifies the Subject of
    19  the issuer certificate (based on hashing the Subject's encoded bytes).
    20  
    21  There's one more component that's not in this repository: an HTTP server
    22  to serve objects from the S3-compatible data store. For Let's Encrypt, this
    23  role is served by a CDN. Note that the CA must be carefully configured so
    24  that the CRLBaseURL for each issuer matches the publicly accessible URL
    25  where that issuer's CRLs will be served.
    26  
    27  ## Shard assignment
    28  
    29  Certificates are assigned to shards explicitly at issuance time, with the
    30  selected shard baked into the certificate as part of its CRLDistributionPoints
    31  extension. The shard is selected based on taking the (random) low bytes of the
    32  serial number modulo the number of shards produced by that certificate's issuer.
    33  
    34  ## Storage
    35  
    36  When a certificate is revoked, the new status is written to both the
    37  `certificateStatus` table and the `revokedCertificates` table. The former
    38  contains an entry for every certificate, explicitly recording that newly-issued
    39  certificates are not revoked. The latter is less explicit but more scalable,
    40  containing rows only for certificates which have been revoked.
    41  
    42  The SA only exposes the latter of these two mechanisms via the
    43  `GetRevokedCertsByShard` method, which returns revoked certificates whose
    44  `shardIdx` matches the requested shard. The `certificateStatus` table will be
    45  removed in the near future.