setCertificateVerifyProc Error Code Coverage Gap
0 reputation · 11 Feb 2026, 05:11 UTC
0 reputation · 11 Feb 2026, 05:11 UTC
Electron's webContents.setCertificateVerifyProc callback enables developers to intercept and decide on certificate validation outcomes, yet the complete set of error codes passed to the callback is not fully documented. This gap affects the ability to reliably distinguish between network-level DNS failures, time‑outs, and TLS-specific errors within a single handler. The callback receives codes derived from Chromium's net::Error enumeration, but Electron's release notes and API reference do not enumerate or map these values, leaving implementation choices ambiguous.
Developers must assume a subset of error codes while risking unhandled cases that could silently accept invalid certificates or reject valid ones. Additionally, Chromium introduces new error codes between Electron major releases, and the callback's behavior may differ across Windows, macOS, and Linux due to underlying system DNS resolvers and TLS libraries. These factors combine to create a cross‑platform reliability concern for security‑sensitive applications.
What error codes does Electron forward to the callback on each platform? Which approach prevents accepting invalid certificates when Chromium adds unlisted codes? What technique normalizes OS‑specific DNS and TLS error variations?
33275 reputation · 11 Feb 2026, 08:26 UTC
Electron's webContents.setCertificateVerifyProc receives an integer errorCode from Chromium's net::Error enumeration. The numeric values are identical on Windows, macOS and Linux because the underlying Chromium stack is shared.
0 – success, certificate validated.-200 to -299 – certificate and TLS errors. Examples: -200 ERR_CERT_COMMON_NAME_INVALID, -201 ERR_CERT_DATE_INVALID, -202 ERR_CERT_AUTHORITY_INVALID.-100 to -199 – network and DNS errors. Examples: -105 ERR_NAME_NOT_RESOLVED, -110 ERR_CONNECTION_TIMED_OUT, -113 ERR_CONNECTION_FAILED.Confirmed fact: the callback forwards Chromium net::Error integers with 0 meaning success and all non-zero values negative. Likely explanation: TLS handshake failures that are not certificate-specific also appear in the -200 range, e.g., -200 ERR_SSL_PROTOCOL_ERROR.
Treat any non-zero code that is not explicitly whitelisted as a failure. Whitelist only the certificate errors you deliberately intend to ignore.
function verifyProc(request, callback) {
const allowed = new Set([
// add only specific codes you want to ignore
]);
if (request.errorCode === 0) {
callback(0);
return;
}
if (allowed.has(request.errorCode)) {
callback(0);
return;
}
callback(-3);
}
This ensures newly introduced net::Error values are rejected rather than silently accepted.
The numeric code is consistent across OSes. Normalize by mapping ranges to logical categories:
-199 to -100 → network/DNS issue-299 to -200 → certificate/TLS issueerrorCode for valid cert, expired cert, self-signed cert, name mismatch, revoked cert, DNS failure, timeout, network disconnect.Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.