Does PR_END_OF_FILE_ERROR mean my certificate is expired or wrong?

No — and this trips people up, because it appears on the same 'Secure Connection Failed' page as certificate errors. But PR_END_OF_FILE_ERROR happens before Firefox ever sees a certificate. It means the connection was closed mid-handshake: Firefox sent its opening message and got back an end-of-file — zero bytes — where the server's reply should have been. The certificate never entered the picture. If it were expired or misnamed, you'd see a NET::ERR or SEC_ERROR code naming the certificate, not this. So don't spend time reissuing a cert; the handshake is dying earlier than that.

It works in Chrome but fails in Firefox with PR_END_OF_FILE_ERROR. Why only Firefox?

This is the most telling symptom, and since late 2024 it usually points at one thing. Firefox 132 turned on a post-quantum key exchange (X25519MLKEM768) by default, which makes Firefox's opening ClientHello about 1.2 KB larger — big enough that it no longer fits in a single network packet and gets split across two. A lot of older firewalls, DPI appliances, and load balancers were written assuming the whole ClientHello arrives in one read; when the second half shows up separately, they give up and close the connection instead of waiting. Chrome's handshake either fits or is handled differently by that box, so it sails through. Same network, same server, different-sized hello.

How do I tell if the problem is the server or something on my side?

Ask whether it fails for everyone or just for you. Run an external SSL check against the domain from outside your network. If that check completes the handshake and reads the certificate fine, the server is healthy and the failure lives between you and it — antivirus HTTPS scanning, a VPN or proxy, a corporate firewall, or the split-ClientHello middlebox above. If the external check also can't finish the handshake, the fault is at the server or its own load balancer, and every visitor is hitting it, not just you.

Antivirus or a VPN — could that really be it?

Yes, routinely. Security suites that offer 'HTTPS scanning' or 'encrypted connection scanning' (the feature exists in most of them) sit in the middle of your TLS handshakes to inspect them, and a buggy or outdated one closes the connection instead of relaying it — producing exactly this error, often on many sites at once. VPNs and proxies insert another hop that can do the same. The quick test: disable the HTTPS-scanning feature (or the VPN) and reload. If the page loads, you've found your middlebox — update it rather than leaving inspection off permanently.

Views: 52

PR_END_OF_FILE_ERROR Fix Guide (Firefox)

PR_END_OF_FILE_ERROR: connection closed before the TLS handshake finished. Server fault or local middlebox? Find out in 3 checks. Free SSL check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Firefox shows a “Secure Connection Failed” page with the error code PR_END_OF_FILE_ERROR, and the site never loads. Other browsers may open the same site without complaint.

What PR_END_OF_FILE_ERROR Actually Means

PR_END_OF_FILE_ERROR is Firefox’s name for NSPR error -5938, literally “Encountered end of file.” NSPR is the portable runtime underneath NSS, the cryptographic library Firefox uses for TLS — so this code comes from deep in the connection machinery, not from the web page.

Here’s the plain-English version. To open an HTTPS connection, Firefox sends the server an opening message (the ClientHello) and waits for a reply. This error means that instead of a reply, Firefox got an end of file: the other end closed the TCP connection and sent zero more bytes. The handshake stopped mid-sentence. Firefox was waiting for the next word and the line went dead.

The important consequence: this happens before certificates, ciphers, or protocol versions are ever agreed on. It is not a certificate error — no cert was exchanged yet. It’s not really a cipher mismatch either, even though it sometimes gets described that way; a true mismatch produces a specific alert, not silence. PR_END_OF_FILE_ERROR is the sound of the conversation being hung up before it started, and your whole job is to work out who hung up: the server, or something standing between you and it.

The Fork That Decides Everything: You, or Everyone?

Before changing a single setting, answer one question — does this fail for everyone, or just for you? It splits the problem cleanly in half.

If it fails only in your Firefox, or only on your network, the culprit is almost always a middlebox on your side of the wire: antivirus that inspects HTTPS, a VPN or proxy, a corporate firewall, or — the modern default suspect — an appliance that can’t handle Firefox’s larger post-quantum ClientHello. The server is fine; the interception is broken.

If it fails for everyone, including an external check run from outside your network, the server or its load balancer is closing the connection — bad TLS termination config, a listener that resets handshakes it doesn’t like, or a proxy that drops non-matching SNI. Then it’s a server-side fix, and every visitor is seeing it too.

That single distinction saves you from the classic mistake: reinstalling Firefox and clearing certificates for hours when the real problem is a firewall two hops away, or vice versa.

Top 3 Causes

A middlebox chokes on Firefox’s post-quantum ClientHello. Since Firefox 132 (late 2024), Firefox enables the X25519MLKEM768 hybrid key exchange by default. The ML-KEM key share adds roughly 1.2 KB to the ClientHello, pushing it past what fits in one TCP segment, so it arrives split across two packets. Older DPI firewalls, inspection appliances, and load balancers written to expect a whole ClientHello in a single read reset the connection instead of reassembling it. This is why “only Firefox breaks, only on this network” became a common report in 2025. Fortinet, among others, published a known-issue notice for exactly this in flow-based deep inspection and shipped a fix; most affected vendors patched through 2025. So it’s worth ruling out early on a stack that hasn’t been updated recently — and unlikely on one that has.
Local TLS interception is broken. Antivirus and endpoint suites with “HTTPS/SSL scanning” turned on decrypt and re-encrypt your traffic to inspect it; a buggy, expired, or misconfigured one closes the handshake instead of completing it. VPNs and proxies add a hop that can do the same. The tell is breadth: interception problems tend to hit many sites at once, and toggling the scanning feature (or the VPN) off makes the error vanish.
The server or its load balancer is dropping the handshake. If an external check can’t complete the handshake either, look at the origin: TLS terminated at a proxy/CDN with a policy that resets certain connections, a listener misconfigured to close on unsupported protocols or missing SNI, or an overloaded balancer cutting connections early. Here the fix belongs to whoever runs the server, not the visitor.

Diagnose with DechoNet

SSL Check — run it against the domain from outside your own network. If it completes the TLS handshake and returns certificate details, the server is healthy and your problem is local (antivirus, VPN, or the split-ClientHello middlebox above) — stop debugging the site. If the SSL check also fails to handshake, the fault is server-side and affects everyone.
Port Check — confirm 443 is actually open and reachable. If it’s filtered (times out) rather than open, the handshake can’t even start, and you’re looking at a firewall in the path, not a TLS problem.
HTTP Check — if HTTP on 80 works but HTTPS dies, the contrast confirms the failure is specific to the TLS layer, which is consistent with a handshake being cut rather than the server being down.

Resolution Checklist

Decide the scope first: reproduce in a private window, then from another browser, then via an external SSL Check. Only-you means local; everyone means server.
If it’s local and started recently on an un-updated network device, suspect the post-quantum ClientHello. As a test only, you can temporarily turn off Firefox’s post-quantum key share in about:config; if the error disappears, you’ve confirmed a middlebox that can’t handle a split ClientHello — the real fix is updating that appliance, not leaving the setting off.
Toggle off antivirus “HTTPS/SSL scanning” and any VPN or proxy, then reload. If that fixes it, update or reconfigure the tool rather than disabling inspection for good.
Try Firefox on a completely different network (a phone hotspot). Working there points squarely at the original network’s firewall or inspection box.
If the external SSL check also fails, hand this to the server owner: check TLS termination config, the load balancer, and any proxy that might reset handshakes.
Re-run the SSL Check after any server-side change to confirm the handshake now completes end to end.

When to Escalate

If an external SSL check can’t complete the handshake, the problem is the server’s TLS stack or load balancer, and no browser-side change will fix it — escalate to whoever operates the origin or CDN.
If the failure is isolated to a corporate network, the inspection appliance or firewall there owns it. That’s an IT/network-team fix (update the middlebox so it handles split ClientHellos), not something an individual user can reconfigure from the browser.
Related browser-specific variants worth comparing when you’re mapping the failure: ERR_CONNECTION_CLOSED, ERR_SSL_PROTOCOL_ERROR, and ERR_EMPTY_RESPONSE are Chrome’s names for closely related “connection cut” conditions.