oven-sh/bun · error · TypeError

APPLICATION_VERIFICATION

APPLICATION_VERIFICATION

Error message

APPLICATION_VERIFICATION

What it means

CertError::APPLICATION_VERIFICATION maps BoringSSL X509_V_ERR_APPLICATION_VERIFICATION (verify code 50). It is the catch-all set when verification fails at the application layer: the app-supplied verify callback rejected the chain, or the verification context was invoked with parameters that let no more specific code apply. Message: "application verification failure". Treat it as 'the verifier said no for a reason it did not classify'.

Source

Thrown at src/http/error.rs:221

    #[error("INVALID_EXTENSION")]
    INVALID_EXTENSION,
    #[error("INVALID_POLICY_EXTENSION")]
    INVALID_POLICY_EXTENSION,
    #[error("NO_EXPLICIT_POLICY")]
    NO_EXPLICIT_POLICY,
    #[error("DIFFERENT_CRL_SCOPE")]
    DIFFERENT_CRL_SCOPE,
    #[error("UNSUPPORTED_EXTENSION_FEATURE")]
    UNSUPPORTED_EXTENSION_FEATURE,
    #[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")]

View on GitHub (pinned to 8c5296ac45)

Solutions

  1. Get the real verdict out-of-band: openssl s_client -connect host:443 -verify_return_error -servername host
  2. Check hostname vs SAN first - app-level hostname rejection commonly lands here
  3. Review any custom verify-callback/proxy logic between your code and the server; this code often means that layer rejected, not the raw chain
  4. Reproduce with a fresh trust store (SSL_CERT_FILE / NODE_EXTRA_CA_CERTS) to rule out store problems

Example fix

// before: app callback rejects without detail
function verifyCb(ok) { return ok && allowedHosts.has(url.host); }

// after: classify failures so the error you see is actionable
function verifyCb(ok, ctx) {
  if (!ok) console.error('verify failed:', ctx.error, ctx.errorString);
  return ok;
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Get the real verify verdict before the app-level call, so a generic failure becomes specific
import { execFileSync } from "node:child_process";
export function strictVerify(host, port = 443, ca = "/etc/ssl/cert.pem") {
  execFileSync("openssl", ["s_client", "-connect", `${host}:${port}`, "-servername", host, "-verify_return_error", "-CAfile", ca], { input: "", stdio: "pipe" });
  return true; // throws with the underlying X509 code
}

Type guard

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

Try / catch

try {
  await fetch(url);
} catch (e) {
  if (e?.code === "APPLICATION_VERIFICATION") {
    // catch-all: run openssl s_client -verify_return_error to get the specific cause, check proxy callbacks
    const detail = await diagnoseWithOpenssl(url);
    log({ url, detail });
  } else throw e;
}

Prevention

When it happens

Trigger: An application verify callback returns 0 without a preceding specific X509 error; verification requested with mismatched parameters (e.g. purpose/hostname handling done app-side and failing); intermediaries that terminate and re-verify TLS with their own callback rejecting the upstream chain.

Common situations: Corporate proxies or AV middleware re-verifying upstream and passing the verdict down as a generic failure; hostname checks performed by a callback rather than built-in SAN matching; runtime/library upgrades changing callback semantics; containers missing their CA bundle causing callbacks to fail open-or-closed differently.

Related errors


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