Failed to fetch error in framework7-request when TLS certificate is invalid

The short answer

No — you cannot currently get TLS-specific details out of framework7-request. The wrapper forwards the browser's fetch rejection unchanged, and browsers deliberately collapse certificate failures, DNS failures, and connection resets into the same opaque TypeError: Failed to fetch. This is a browser security decision (preventing pages from probing network internals), not just a Framework7 limitation. So the practical answer is: don't try to classify the error inside framework7-request — detect certificate problems one layer below or one layer above it.

What's confirmed vs. likely

Confirmed behavior: in Chromium- and WebKit-based webviews, a rejected self-signed or expired certificate surfaces to JavaScript as a plain TypeError with no distinguishing name, code, or cause. There is no DOMException with a certificate code hidden inside — the research suggestion that one exists is worth verifying in your target webview, but in current mainstream engines it does not hold. Likely explanation: because the fetch spec intentionally gives no signal, any wrapper around fetch (Framework7's included) inherits that blindness. Extending the library with error codes like certificate-invalid is therefore not feasible in pure JavaScript — the information simply never reaches the page.

Recommended patterns by context

Capacitor / Cordova hybrid apps

Route the request through a native HTTP plugin instead of the webview's fetch. Capacitor's @capacitor/http plugin (or Cordova equivalents) performs the request in native code, where TLS errors are real, typed errors you can inspect and where certificate pinning can be configured explicitly:

import { CapacitorHttp } from '@capacitor/http';

try {
  const res = await CapacitorHttp.get({ url: 'https://api.example.com/data' });
} catch (e) {
  // Native layer surfaces SSL errors distinctly from connectivity errors
  console.error('HTTP failed:', e);
}

On Android, pair this with a network_security_config.xml that declares which domains may use your custom CA or pins, so trust decisions are explicit rather than app-wide.

PWAs and plain browsers

You have no programmatic option — this is by design. The workable patterns are:

• Pre-flight probe: before the real call, hit a lightweight health endpoint. If it fails with TypeError while navigator.onLine is true and other hosts succeed, an untrusted certificate is a strong suspect — but treat this as a heuristic, not detection.
• Server-side check: have your backend (or a monitoring job) validate the certificate chain of your API endpoints and alert on expiry or misconfiguration. Users should never be your TLS monitoring.
• User-facing messaging: show "secure connection could not be established" for unexplained fetch failures rather than a generic network error, and log the failure with URL and timestamp for support triage.

If you still want to extend the library

A backward-compatible enhancement is possible in shape, even if the TLS classification is limited: wrap the internal fetch call, and on rejection attach the original error plus contextual metadata (URL, timestamp, online state) to a custom error object exposed via an optional onError hook, while still throwing the original TypeError for existing callers. What you cannot honestly populate is a certificate-invalid code — mark any such mapping as unreliable across webviews until verified per-platform.

Verify before you build

Test against a server with a self-signed certificate in your actual target webview and log the full rejection object (console.log(JSON.stringify(e, Object.getOwnPropertyNames(e)))). If you see nothing beyond the generic TypeError — which is the expected result — skip the error-classification effort and invest in the native-plugin or server-side patterns above. One detail that would change this recommendation: whether your app targets only Capacitor (native plugin is the clean fix) or must also run as a browser PWA (where heuristics and server-side checks are your only options).