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

Identify the non-v3 cert: openssl s_client -showcerts then openssl x509 -noout -text on each, checking 'Version: 1'

oven-sh/bun · error · TypeError

SUITE_B_INVALID_VERSION

SUITE_B_INVALID_VERSION

Error message

SUITE_B_INVALID_VERSION

What it means

CertError::SUITE_B_INVALID_VERSION maps BoringSSL X509_V_ERR_SUITE_B_INVALID_VERSION (verify code 56). NSA Suite B profile verification is enabled (X509_V_FLAG_SUITE_B_128_LOS / _192_LOS) and a certificate in the chain is not X.509 v3, which the Suite B profile mandates. Message: "Suite B: certificate version invalid".

Source

Thrown at src/http/error.rs:231

    #[error("UNNESTED_RESOURCE")]
    UNNESTED_RESOURCE,
    #[error("PERMITTED_VIOLATION")]
    PERMITTED_VIOLATION,
    #[error("EXCLUDED_VIOLATION")]
    EXCLUDED_VIOLATION,
    #[error("SUBTREE_MINMAX")]
    SUBTREE_MINMAX,
    #[error("APPLICATION_VERIFICATION")]
    APPLICATION_VERIFICATION,
    #[error("UNSUPPORTED_CONSTRAINT_TYPE")]
    UNSUPPORTED_CONSTRAINT_TYPE,
    #[error("UNSUPPORTED_CONSTRAINT_SYNTAX")]
    UNSUPPORTED_CONSTRAINT_SYNTAX,
    #[error("UNSUPPORTED_NAME_SYNTAX")]
    UNSUPPORTED_NAME_SYNTAX,
    #[error("CRL_PATH_VALIDATION_ERROR")]
    CRL_PATH_VALIDATION_ERROR,
    #[error("SUITE_B_INVALID_VERSION")]
    SUITE_B_INVALID_VERSION,
    #[error("SUITE_B_INVALID_ALGORITHM")]
    SUITE_B_INVALID_ALGORITHM,
    #[error("SUITE_B_INVALID_CURVE")]
    SUITE_B_INVALID_CURVE,
    #[error("SUITE_B_INVALID_SIGNATURE_ALGORITHM")]
    SUITE_B_INVALID_SIGNATURE_ALGORITHM,
    #[error("SUITE_B_LOS_NOT_ALLOWED")]
    SUITE_B_LOS_NOT_ALLOWED,
    #[error("SUITE_B_CANNOT_SIGN_P_384_WITH_P_256")]
    SUITE_B_CANNOT_SIGN_P_384_WITH_P_256,
    #[error("HOSTNAME_MISMATCH")]
    HOSTNAME_MISMATCH,
    #[error("EMAIL_MISMATCH")]
    EMAIL_MISMATCH,
    #[error("IP_ADDRESS_MISMATCH")]
    IP_ADDRESS_MISMATCH,
    #[error("INVALID_CALL")]

View on GitHub (pinned to 8c5296ac45)

Solutions

Identify the non-v3 cert: openssl s_client -showcerts then openssl x509 -noout -text on each, checking 'Version: 1'
Replace the v1 root/intermediate with a v3 certificate
If Suite B compliance is not actually required, disable the Suite B flags on the verifying component
Confirm which hop enables Suite B (client config vs proxy) - the fix belongs there

Example fix

# before: v1 root
openssl req -x509 -newkey rsa:2048 -days 3650 -nodes ...

# after: explicitly v3 with extensions
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -days 3650 -nodes -addext 'basicConstraints=critical,CA:TRUE' ...

Defensive patterns

Strategy: try-catch

Validate before calling

// If a Suite B verifier is in play, assert the whole chain is X.509 v3 first
import tls from "node:tls";
import { X509Certificate } from "node:crypto";
export function chainIsV3(host, port = 443) {
  return new Promise((resolve, reject) => {
    const s = tls.connect({ host, port, servername: host, rejectUnauthorized: false }, () => {
      let c = s.getPeerCertificate(true), ok = true;
      do { ok = ok && new X509Certificate(c.raw).toString().includes("Version: 3"); } while (c.issuerCertificate && (c = c.issuerCertificate) && !Object.is(c, s.getPeerCertificate(true)));
      s.end(); resolve(ok);
    });
    s.on("error", reject);
  });
}

Type guard

export function isSuiteBInvalidVersion(e): e is Error & { code: "SUITE_B_INVALID_VERSION" } {
  return e instanceof Error && (e as any).code === "SUITE_B_INVALID_VERSION";
}

Try / catch

try {
  await fetch(url);
} catch (e) {
  if (e?.code === "SUITE_B_INVALID_VERSION") {
    // Suite B profile is on somewhere and a pre-v3 cert is in the chain - replace it with v3
    escalateToSuiteBOwner(url);
  } else throw e;
}

Prevention

Replace legacy v1 roots with v3 certificates before enabling Suite B anywhere
Know which hop enforces Suite B - clients, gateways, and terminating proxies each need auditing
Check 'Version: 3' in cert linting for every chain element, not just the leaf

When it happens

Trigger: A verifier running with Suite B flags encounters a v1/v2 certificate in the chain (self-signed v1 roots are a classic source). Stock Bun never sets Suite B flags, so seeing this implies a custom verifying stack or a middlebox that does.

Common situations: Defense/compliance environments enabling Suite B on gateways; v1 root certificates grandfathered into trust stores years ago; TLS-terminating appliances with Suite B enabled in front of your service.

Related errors

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