How do you configure CRL-based revocation checking as a deliberate fallback when OCSP is unavailable?

How do you configure CRL-based revocation checking as a deliberate fallback when OCSP is unavailable?

When OCSP responders are down or a client cannot reach them, a CRL (Certificate Revocation List, RFC 5280 section 5) is the older, bulk alternative: a signed, periodically published list of revoked serial numbers. For controlled environments it is a defensible fallback. Configuration playbook.

— Confirm the certificates carry a CRL Distribution Point (CDP) extension pointing to a reachable, signed CRL; without it there is nothing to fetch.
— Decide refresh cadence against the CRL's nextUpdate field. A client caching a stale CRL past nextUpdate is checking against outdated data, the core CRL weakness.
— Size matters: large CAs produce multi-megabyte CRLs. For internal PKI, partition with CRL Distribution Points or use delta CRLs to keep fetches small.
— Set explicit fail behavior: hard-fail in high-security internal contexts where you control connectivity; soft-fail on the public internet to avoid outages from unreachable lists.
— Validate the CRL signature chains to the issuing CA and that the issuer matches the cert's CDP, preventing a substituted list.

Evidence vs. speculation: CRLs give point-in-time-of-publication truth, not real-time status; the freshness gap is structural.

Further reading: RFC 5280 section 5; RFC 5280 section 4.2.1.13 (CDP).

Bottom line: CRLs are a bulk, cacheable fallback whose value is bounded entirely by your refresh discipline.