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
- Get the real verdict out-of-band: openssl s_client -connect host:443 -verify_return_error -servername host
- Check hostname vs SAN first - app-level hostname rejection commonly lands here
- Review any custom verify-callback/proxy logic between your code and the server; this code often means that layer rejected, not the raw chain
- 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
- Treat APPLICATION_VERIFICATION as 'unknown cause' - always follow up with -verify_return_error before changing anything
- Make custom verify callbacks emit the underlying ctx.error so this code stops swallowing detail
- Watch for TLS-terminating middleboxes: their verdict arrives as this generic code
- Keep the trust store pinned and versioned in images to rule out store drift
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
- INVALID_EXTENSION
- INVALID_POLICY_EXTENSION
- NO_EXPLICIT_POLICY
- DIFFERENT_CRL_SCOPE
- UNSUPPORTED_EXTENSION_FEATURE
AI-assisted analysis of oven-sh/bun@8c5296ac45 (2026-08-16).
Data as JSON: /api/errors/b93057b9578a37d0.
Report an issue: GitHub.