net::ERR_SSL_PROTOCOL_ERROR

https://localhost:3000/   ❌ ERR_SSL_PROTOCOL_ERROR
http://localhost:3000/    ✅ loads fine — the server was never running TLS at all

What you're seeing

This site can't provide a secure connection
localhost sent an invalid response.
ERR_SSL_PROTOCOL_ERROR

// in a background request, the browser console instead shows:
Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR

Unlike a certificate-trust error, there is usually no "Advanced → Proceed anyway" option here at all — because the failure happens before a certificate was ever presented for the browser to evaluate. That absence of a click-through option is itself a diagnostic clue: it tells you the problem is at the handshake/protocol layer, not the certificate-trust layer covered by ERR_CERT_AUTHORITY_INVALID.

Fix 1 — HTTP vs HTTPS confusion (the overwhelming majority of cases)

When: a local dev server, an internal tool, or any address you're not 100% sure is actually running TLS.

# confirm which protocol the server is actually speaking on that port:
curl -v http://localhost:3000/    # if this succeeds, there's no TLS here at all
curl -v https://localhost:3000/   # this is the one that should fail identically to the browser

# a typical Express dev server only ever does this — plain HTTP:
const app = require("express")();
app.listen(3000);   // http.createServer under the hood — no TLS involved

Most local development servers (Express, Django's runserver, Vite's default dev server, and dozens of others) bind plain, unencrypted HTTP by default — TLS is opt-in, extra configuration most tutorials skip entirely for local work. A bookmark, browser autocomplete, or muscle memory that adds https:// out of habit will send a TLS handshake to a socket that only ever speaks plain HTTP. The server has no idea what to do with the encrypted handshake bytes it receives and responds with something that isn't a valid TLS response at all, which the browser reports as this generic protocol error rather than anything more specific, because from the browser's perspective the "server" simply isn't speaking TLS.

Fix 2 — your own Node/Express server: check which constructor actually got the cert

When: you wrote the server yourself, configured a certificate, and it still fails.

const fs = require("fs");
const https = require("https");
const http = require("http");   // ⚠️ easy to import both and mix them up
const app = require("express")();

const options = {
  key: fs.readFileSync("key.pem"),
  cert: fs.readFileSync("cert.pem"),
};

// ❌ the certificate options are created but never actually used —
//    this line creates a plain, unencrypted HTTP server regardless:
http.createServer(app).listen(3000);

// ✅ pass the options to the HTTPS constructor specifically:
https.createServer(options, app).listen(3000);

This is a surprisingly common and easy-to-miss local-dev bug: having both http and https imported, building a valid-looking options object with your key and certificate, and then passing your Express app to http.createServer(app) instead of https.createServer(options, app) out of habit or a copy-paste from an older, HTTP-only version of the file. The certificate files are read from disk successfully and no error is thrown at startup — the mistake only surfaces when a browser tries to speak TLS to a socket that's quietly serving plain HTTP underneath, producing exactly this handshake failure.

Fix 3 — the server only supports an obsolete TLS version

When: the target is an older embedded device, an industrial/IoT appliance, or a legacy internal system with a frozen software stack.

# check which protocol versions the server actually offers:
openssl s_client -connect device.local:443 -tls1
openssl s_client -connect device.local:443 -tls1_1
openssl s_client -connect device.local:443 -tls1_2
# if only the -tls1 / -tls1_1 attempts succeed, the device is stuck on
# a protocol version every modern browser has deliberately removed

All major browsers formally deprecated and removed TLS 1.0 and TLS 1.1 support starting around 2020, following an industry-wide push (led by the same browser vendors, the IETF, and PCI compliance standards) to retire protocol versions with known cryptographic weaknesses. A server that has never been updated — common on network hardware, printers, older enterprise software, and industrial control systems with multi-year (or multi-decade) refresh cycles — may only be capable of the versions browsers now refuse outright, producing this handshake failure with no possible client-side workaround; the device's own TLS configuration has to be upgraded, or you fall back to a tool that still permits legacy TLS (accepting the real security trade-off that implies) for that connection specifically.

Fix 4 — a corporate proxy or antivirus with a broken TLS implementation

When: the failure is reproducible against many otherwise-healthy public sites, but only from one specific network or VPN.

# reproduce off that network (mobile hotspot, home connection) to
# rule out the site itself:
curl -v https://example.com/   # succeeds elsewhere, fails only on the suspect network

# on Windows, a common culprit is HTTPS-scanning antivirus —
# temporarily disabling it (if policy allows) isolates the cause quickly

This is rarer than the certificate-trust variant of network interception (most modern inspection proxies handle the handshake correctly and only substitute their own certificate afterward, which produces ERR_CERT_AUTHORITY_INVALID instead), but a poorly implemented or outdated TLS-inspection layer can fail the handshake itself. If disabling the suspect software or switching networks entirely resolves it, the fix belongs to whoever administers that network or security product, not to the site you were trying to reach.

Why this happens: handshake failures vs certificate failures

It's worth being precise about where in the TLS connection process this error occurs, because it changes what's worth investigating. A TLS connection has (roughly) two phases: first, the handshake — the client and server negotiate a shared protocol version and cipher suite, and exchange the cryptographic material needed to establish an encrypted channel; only after that succeeds does the server present its certificate for the client to validate against its trust store. ERR_SSL_PROTOCOL_ERROR is specifically a phase-one failure: the two sides couldn't even agree on how to talk, so there was never a certificate for the browser to evaluate in the first place. That's structurally different from ERR_CERT_AUTHORITY_INVALID, which is a phase-two failure — the handshake completed fine, a certificate was presented, and the trust chain on that certificate is what failed. Recognizing which phase you're in immediately rules out an entire category of fixes: if you're getting this protocol-level error, reinstalling a root CA or adjusting certificate trust settings will do nothing, because the browser never got far enough to look at a certificate at all.

Common causes at a glance

Debugging checklist

• ✓ Try the exact same address with http:// instead of https:// first
• ✓ Your own server? Confirm the TLS options actually reached https.createServer, not http.createServer
• ✓ Old device? Test with openssl s_client -tls1_2 to see which versions it actually offers
• ✓ Reproduce off the suspect network (mobile hotspot) to rule in/out a local proxy or antivirus
• ✓ Remember: no certificate was even evaluated here — don't waste time on trust-store fixes