setCertificateVerifyProc Error Code Coverage Gap

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?