Firefox PR_END_OF_FILE_ERROR: Quick Fix & Why It Works

You're trying to load a site, Firefox hits you with “Secure Connection Failed” and error code PR_END_OF_FILE_ERROR. Annoying, but fixable in under a minute.

What's actually happening here is Firefox opens a TLS handshake, the server sends some data, then abruptly closes the connection before the handshake finishes. The error code literally means “premature end of file”—the SSL/TLS stream ended unexpectedly. Let's fix it.

The Fix

1. Clear the SSL cache. This is the first thing to try because Firefox stores SSL session data that can go stale. Go to about:preferences#privacy → scroll to “Security” → click “Clear SSL cache”. No restart needed—just reload the broken page. Works for maybe 60% of cases.
2. If that doesn't work, disable TLS 1.3. Firefox 90+ uses TLS 1.3 by default. Some older servers or misconfigured reverse proxies can't handle the 0-RTT handshake or the shortened cipher negotiation. Type about:config in the address bar, accept the risk, search for security.tls.version.enable-deprecated and set it to true. Then find security.tls.version.max and change it from 4 (TLS 1.3) to 3 (TLS 1.2). Reload the page.
3. Still broken? Turn off DNS over HTTPS. Go to about:preferences#general → scroll to “Network Settings” → click “Settings” → uncheck “Enable DNS over HTTPS”. Some DNS providers (especially corporate proxies) mangle the DNS response, causing Firefox to connect to the wrong IP. The server then sends a reset.

I've seen this pattern most often on Windows 11 with Firefox 115+, hitting sites behind Cloudflare or AWS load balancers. The server side is fine—it's Firefox's negotiation that chokes.

Why This Works

The reason step 1 works is that Firefox caches SSL session IDs and ticket data to speed up repeat connections. If the server updated its certificate or TLS stack (or you changed networks), the cached session becomes invalid. Firefox tries to reuse it, the server says “I don't know what you're talking about” and drops the connection. Clearing the cache forces a fresh full handshake.

Step 2—disabling TLS 1.3—fixes the remaining cases because TLS 1.3's 0-RTT (zero round trip) mode sends data before the handshake completes. Some middleboxes (corporate firewalls, antivirus scanners) can't parse this and kill the connection. Dropping to TLS 1.2 removes the 0-RTT mode entirely. The tradeoff is slightly slower initial connections, but it's stable.

Step 3—disabling DNS over HTTPS—addresses the edge case where your DNS resolver returns a different IP than what Firefox expects. Firefox does DNSSEC validation internally, and if the resolver's answer doesn't match the server's certificate CN, the connection aborts before any HTTP data flows.

Less Common Variations

• Antivirus SSL scanning. Norton, McAfee, and Bitdefender sometimes inject their own certificates into Firefox's trust store. If the scan fails, they send a TCP RST. Check Firefox's certificate manager (about:certificate) for any cert issued by your AV vendor. If you see one, disable the “SSL scanning” feature in your AV settings.
• IPv6 vs IPv4 mismatch. If your ISP has broken IPv6 (common on older DSL lines), Firefox may try an IPv6 connection, get a SYN-ACK, then the server sends a TLS alert, and Firefox interprets it as PR_END_OF_FILE_ERROR. Type about:config, search for network.dns.disableIPv6, set it to true. Reload.
• Firefox profiles corrupted. Rare, but I've seen it twice. The cert9.db file in your profile folder (%APPDATA%\Mozilla\Firefox\Profiles\ on Windows) gets corrupted. Close Firefox, delete cert9.db and key4.db (they regenerate on next launch). Warning: this wipes all saved passwords and client certificates.

Prevention

You can't prevent servers from misbehaving, but you can keep Firefox from choking on them. I do two things:

• Keep Firefox updated. Old versions have bugs in TLS session handling that Mozilla patches regularly. Firefox 118 fixed a specific bug where the session cache could retain stale entries for 24+ hours.
• If you run a corporate VPN or proxy, use Firefox's “Enterprise Policies” to force TLS 1.2 minimum without the 0-RTT feature. Create a JSON policy file at %PROGRAMFILES%\Mozilla Firefox\distribution\policies.json with:

{
  "policies": {
    "SSLVersionMin": "tls1.2",
    "SSLVersionMax": "tls1.2"
  }
}

This locks TLS to 1.2 globally, preventing any handshake negotiation surprises. You lose TLS 1.3 performance, but you gain reliability on problematic networks. Your call.