What causes "CRL_NOT_YET_VALID" in oven-sh/bun?

Sync local time via NTP first — client clock skew is the usual culprit

oven-sh/bun · error · CertError

CRL_NOT_YET_VALID

CRL_NOT_YET_VALID

Error message

CRL_NOT_YET_VALID

What it means

X509 verify result 11 (X509_V_ERR_CRL_NOT_YET_VALID): a CRL consulted during revocation checking has its thisUpdate field in the future relative to the local clock. Mapped via get_cert_error_from_no (src/http/lib.rs:1530) to CertError::CRL_NOT_YET_VALID, message "CRL is not yet valid" (FetchTasklet.rs:1400).

Source

Thrown at src/http/error.rs:143

    #[error("UNABLE_TO_GET_ISSUER_CERT")]
    UNABLE_TO_GET_ISSUER_CERT,
    #[error("UNABLE_TO_GET_CRL")]
    UNABLE_TO_GET_CRL,
    #[error("UNABLE_TO_DECRYPT_CERT_SIGNATURE")]
    UNABLE_TO_DECRYPT_CERT_SIGNATURE,
    #[error("UNABLE_TO_DECRYPT_CRL_SIGNATURE")]
    UNABLE_TO_DECRYPT_CRL_SIGNATURE,
    #[error("UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY")]
    UNABLE_TO_DECODE_ISSUER_PUBLIC_KEY,
    #[error("CERT_SIGNATURE_FAILURE")]
    CERT_SIGNATURE_FAILURE,
    #[error("CRL_SIGNATURE_FAILURE")]
    CRL_SIGNATURE_FAILURE,
    #[error("CERT_NOT_YET_VALID")]
    CERT_NOT_YET_VALID,
    #[error("CERT_HAS_EXPIRED")]
    CERT_HAS_EXPIRED,
    #[error("CRL_NOT_YET_VALID")]
    CRL_NOT_YET_VALID,
    #[error("CRL_HAS_EXPIRED")]
    CRL_HAS_EXPIRED,
    #[error("ERROR_IN_CERT_NOT_BEFORE_FIELD")]
    ERROR_IN_CERT_NOT_BEFORE_FIELD,
    #[error("ERROR_IN_CERT_NOT_AFTER_FIELD")]
    ERROR_IN_CERT_NOT_AFTER_FIELD,
    #[error("ERROR_IN_CRL_LAST_UPDATE_FIELD")]
    ERROR_IN_CRL_LAST_UPDATE_FIELD,
    #[error("ERROR_IN_CRL_NEXT_UPDATE_FIELD")]
    ERROR_IN_CRL_NEXT_UPDATE_FIELD,
    #[error("OUT_OF_MEM")]
    OUT_OF_MEM,
    #[error("DEPTH_ZERO_SELF_SIGNED_CERT")]
    DEPTH_ZERO_SELF_SIGNED_CERT,
    #[error("SELF_SIGNED_CERT_IN_CHAIN")]
    SELF_SIGNED_CERT_IN_CHAIN,
    #[error("UNABLE_TO_GET_ISSUER_CERT_LOCALLY")]

View on GitHub (pinned to 8c5296ac45)

Solutions

Sync local time via NTP first — client clock skew is the usual culprit
If the CA genuinely published a future-dated CRL, report it and wait for a corrected publication
Disable CRL-based revocation checking for the host or switch to OCSP
Check timezone/UTC configuration on the host (date -u should be close to real UTC)

Defensive patterns

Strategy: try-catch

Type guard

function isCertErrorCode(e: unknown, code = "CRL_NOT_YET_VALID"): e is Error & { code: string } {
  return e instanceof Error && (e as any).code === code;
}

Try / catch

try {
  await fetch(url);
} catch (e) {
  if (isCertErrorCode(e, "CRL_NOT_YET_VALID")) {
    throw new Error("CRL dated in the future — check local clock and CA time sources");
  }
  throw e;
}

Prevention

Keep NTP healthy on clients and CA hosts alike
CA signing hosts must sync clocks before signing CRLs
Prefer OCSP to avoid CRL timestamp pitfalls entirely

When it happens

Trigger: TLS handshake with CRL checking where the CRL's thisUpdate timestamp is ahead of local time — clock skew between the client host and the CA, or a mis-issued CRL.

Common situations: Clock-skewed containers (same root cause as CERT_NOT_YET_VALID), CA systems with drifting clocks signing CRLs slightly in the future, timezone misconfiguration on either side.

Related errors

AI-assisted analysis of oven-sh/bun@8c5296ac45 (2026-08-16). Data as JSON: /api/errors/2bb4bea598bc48a8. Report an issue: GitHub.