oven-sh/bun · error · TypeError

SUITE_B_CANNOT_SIGN_P_384_WITH_P_256

SUITE_B_CANNOT_SIGN_P_384_WITH_P_256

Error message

SUITE_B_CANNOT_SIGN_P_384_WITH_P_256

What it means

CertError::SUITE_B_CANNOT_SIGN_P_384_WITH_P_256 maps BoringSSL X509_V_ERR_SUITE_B_CANNOT_SIGN_P_384_WITH_P_256 (verify code 61). Suite B forbids a P-256 issuer from signing a P-384 certificate: the signer's security level must not be below the signed cert's. Message: "Suite B: cannot sign P-384 with P-256".

Source

Thrown at src/http/error.rs:241

    #[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")]
    INVALID_CALL,
    #[error("STORE_LOOKUP")]
    STORE_LOOKUP,
    #[error("NAME_CONSTRAINTS_WITHOUT_SANS")]
    NAME_CONSTRAINTS_WITHOUT_SANS,
    #[error("UNKNOWN_CERTIFICATE_VERIFICATION_ERROR")]
    UNKNOWN_CERTIFICATE_VERIFICATION_ERROR,
}

impl Error {

View on GitHub (pinned to 8c5296ac45)

Solutions

  1. Re-key the issuing CA on P-384 (or reissue the child on P-256) so signer strength >= signed strength
  2. Rebuild the full chain in one strength and re-verify: openssl verify -CAfile p384-root.pem -untrusted p384-int.pem leaf.pem
  3. If Suite B is not a real requirement, drop the Suite B flags instead

Example fix

# before: P-256 intermediate signs a P-384 leaf
openssl x509 -req -in leaf-p384.csr -CA int-p256.pem ...

# after: match strengths - P-384 signer
openssl ecparam -name secp384r1 -genkey -out int-key.pem
openssl x509 -req -in leaf-p384.csr -CA int-p384.pem ...
Defensive patterns

Strategy: validation

Validate before calling

// Assert signer strength >= signed strength (no P-256 parent over P-384 child)
import { X509Certificate } from "node:crypto";
export function signerStrengthOk(childPem, parentPem) {
  const rank = { "P-256": 1, "P-384": 2 };
  const c = rank[new X509Certificate(childPem).keyObject.export({ format: "jwk" }).crv];
  const p = rank[new X509Certificate(parentPem).keyObject.export({ format: "jwk" }).crv];
  return p >= c;
}

Type guard

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

Try / catch

try {
  await fetch(url);
} catch (e) {
  if (e?.code === "SUITE_B_CANNOT_SIGN_P_384_WITH_P_256") {
    // P-256 issuer signed a P-384 cert - re-key the CA up to P-384 or reissue the child at P-256
    rekeyHierarchy(url);
  } else throw e;
}

Prevention

When it happens

Trigger: A chain where a P-256 CA certificate signs a P-384 leaf (or P-256 intermediate above a P-384 cert) while Suite B verification is enabled - e.g. reissuing a leaf 'stronger' than its parent CA.

Common situations: Operators upgrading leaf keys to P-384 without re-keying the intermediate; mixed hierarchies assembled from multiple CAs; test setups chaining arbitrary EC certs together.

Related errors


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