How to Fix the ERR_SSL_PROTOCOL_ERROR

You open a site in Google Chrome and get a blank error page instead: “This site can’t provide a secure connection”, followed by the code ERR_SSL_PROTOCOL_ERROR. Microsoft Edge and the other Chromium browsers show the same message, because they share the same networking code.

Most of the advice written about this code points in the wrong direction, because the code itself is misleading: it looks like a precise diagnosis and it is not one. These failures usually originate on the server, or on something sitting between you and the server, rather than in a setting inside your browser. That is why the order in which you check things matters more than any individual fix.

Quick answer: ERR_SSL_PROTOCOL_ERROR is Chromium’s generic code (network error -107) for a TLS handshake that failed for a reason the browser could not identify more precisely. Before changing anything, test the same URL on a second device, on a second network, and in an incognito window. If it fails everywhere, the problem is on the server: confirm it offers TLS 1.2 or TLS 1.3, that a TLS service rather than plain HTTP answers on port 443, that the certificate chain is complete, and that the server and any inline security appliance can handle Chrome’s larger post-quantum ClientHello. If it fails only on your machine, the usual causes are antivirus HTTPS scanning, a corporate TLS-inspection proxy, a browser extension, or a stale hosts file entry.

Table of Contents

1. What Is the ERR_SSL_PROTOCOL_ERROR?
2. First, Find Out Where the Failure Is
3. Server-Side Causes and Fixes
4. Client-Side and Network Causes and Fixes
5. Advice That Does Not Fix This Error
6. Frequently Asked Questions

What Is the ERR_SSL_PROTOCOL_ERROR?

ERR_SSL_PROTOCOL_ERROR is Chromium’s network error -107, described in the source code simply as “an SSL protocol error occurred”. It appears when the TLS handshake, the short negotiation that has to succeed before any page content can move over HTTPS, breaks down.

The important detail is how Chrome chooses this code. Chromium translates the failure reasons it recognizes into specific errors, and anything it does not recognize falls through to -107. In other words, ERR_SSL_PROTOCOL_ERROR is the bucket of last resort. If Chrome had been able to name the problem, you would have seen a more precise code instead:

• ERR_SSL_VERSION_OR_CIPHER_MISMATCH (-113) when the server refuses politely with a protocol version or cipher alert.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT (-159) when the server does not recognize the hostname you asked for.
• ERR_CERT_DATE_INVALID (-201) when the certificate has expired or is not yet valid.
• ERR_QUIC_PROTOCOL_ERROR (-356) when the failure happened inside a QUIC or HTTP/3 connection.
• ERR_CONNECTION_REFUSED (-102) and ERR_CONNECTION_TIMED_OUT (-118) when the connection never got far enough to attempt TLS at all.

So -107 usually means the handshake ended messily rather than cleanly: the connection was torn down halfway through, a reply arrived that was not a valid TLS record, a security appliance interrupted it, or the server produced a failure Chrome has no specific name for.

Other browsers report the same class of failure under their own names. In Firefox you are likely to see PR_END_OF_FILE_ERROR or SSL_ERROR_RX_RECORD_TOO_LONG, and Safari says it cannot establish a secure connection. If a site fails in every browser, that agreement is itself a diagnosis: the problem is not Chrome.

First, Find Out Where the Failure Is

Because the code covers so many causes, guessing at fixes wastes time. Spend a minute working out which side is broken, then read only the section that applies.

Two ten-second prechecks

Reload the page once. A handshake can fail on a dropped packet and succeed on the next attempt, and there is no point investigating an error that does not come back.

Then glance at your system clock. If the date or time on your device is badly wrong, certificate validity checks fail. This is worth ruling out because it costs nothing, but keep your expectations low: a wrong clock normally produces ERR_CERT_DATE_INVALID, not this error. On Windows, open Settings, go to Time & language, select Date & time, turn on Set time automatically and click Sync now. On macOS, open System Settings, click General and then Date & Time, and turn on Set date and time automatically.

Four isolation tests

Run these in order and note which ones load the site:

1. An incognito window. Press Ctrl + Shift + N on Windows or Cmd + Shift + N on macOS. Extensions are disabled there by default, so this tests your extensions in one step. A Guest profile is stricter still, since it carries no profile data at all.
2. A different browser. Firefox and Safari use different TLS libraries from Chrome. If the site loads in one of them, the fault is narrow and probably local.
3. A different device on the same network. If a second computer or tablet fails identically, the problem is not your machine’s software.
4. A different network. Turn Wi-Fi off on your phone and load the site over mobile data. This is the single most informative test, because it takes your router, your office firewall, and any inspection appliance out of the path.

Take the browser out of the picture

If you have a terminal available, you can attempt the handshake directly and read the raw result. Replace example.com with the affected domain:

openssl s_client -connect example.com:443 -servername example.com

Read the top of the output, not the bottom. A healthy server returns a certificate, so the output contains a subject= line naming the site and a real cipher on the New, line. A failed handshake shows no peer certificate available and Cipher is (NONE) instead, with an error line above it.

Ignore the last line of the summary. Verify return code: 0 (ok) is printed even when the handshake failed and no certificate was ever received, because it reports the result of a certificate check that never ran. Current OpenSSL gives you no protocol line to fall back on either: the session block that carries one is printed only for TLS 1.2 and below, or when a TLS 1.3 session ticket arrives. The certificate line is the one to look at.

The error text above the summary tells you what went wrong. An error about the record layer, the packet length, or an unexpected protocol version usually means the service on that port is not speaking TLS at all. An alert naming the protocol version points to a version mismatch. A connection reset with no reply points to a firewall or an inspection appliance. The exact wording varies between OpenSSL releases, so match on the idea rather than the phrase.

The same request through curl gives a shorter, more readable verdict:

curl -sSv https://example.com -o /dev/null 2>&1 | head -25

For a second opinion from outside your own network entirely, scan the domain with our free SSL Checker. It reports the certificate, the chain, and the protocol versions the server offers, all from a machine that has nothing to do with your computer or your office network.

Read the result

• It fails everywhere, on every device and network. The server is misconfigured. Go to Server-Side Causes and Fixes. If you do not own the site, report it to the site owner: there is nothing you can change locally.
• It works elsewhere but fails on your machine. Something local is interfering. Go to Client-Side and Network Causes and Fixes.
• It works on mobile data but fails for everyone on one network. A device on that network is breaking the handshake, typically a firewall doing TLS inspection. The antivirus and TLS-inspection section covers it.
• Only one site fails and everything else is fine. Almost always the server. Only one site failing for you while it loads for everybody else points at a hosts file entry or a cached connection.

Server-Side Causes and Fixes

These are the causes that make a site fail for every visitor. You need access to the web server, the load balancer, or the CDN configuration to apply them. Work down the list in order: the early entries are the quickest to test and rule out, while the later ones are the causes that most reliably produce this particular code rather than a more specific one.

1. The server only offers TLS 1.0 or TLS 1.1

Chrome removed support for TLS 1.0 and TLS 1.1 in Chrome 84, released in July 2020, and every other major browser did the same that year. A server still restricted to those versions, or to SSL 3.0, has nothing left to agree on with a current browser.

Set your expectations before you start, though. When a server refuses cleanly on version grounds, Chromium maps that alert to ERR_SSL_VERSION_OR_CIPHER_MISMATCH, not to this error. A version problem reaches you as -107 only when the server drops the connection instead of sending a proper alert, which is exactly what neglected or half-configured stacks tend to do. It is worth checking first because it takes two commands, not because it is the likeliest answer.

Test which versions the server accepts by asking for one at a time. The first command should succeed on any modern server, the second should succeed on most:

openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

If both fail while an older version succeeds, enable the modern protocols. In Apache, set the following in your TLS virtual host, then reload:

SSLProtocol -all +TLSv1.2 +TLSv1.3

sudo apachectl configtest && sudo systemctl reload apache2

In Nginx, the equivalent directive goes in the server or http block:

ssl_protocols TLSv1.2 TLSv1.3;

sudo nginx -t && sudo systemctl reload nginx

Always run the configuration test before reloading. A syntax error in a TLS block can leave the site down entirely rather than merely broken for some visitors. If you are unsure which versions to allow, our comparison of TLS 1.2 and TLS 1.3 explains what each one gives you.

2. The cipher suites do not overlap

Even when both sides agree on a TLS version, they still have to agree on a cipher suite, the set of algorithms that will actually encrypt the traffic. If the server’s list contains nothing the browser is still willing to use, the handshake ends there.

This happens on two kinds of server: old ones that were never updated past legacy suites, and hardened ones where the allowed list was trimmed so aggressively that ordinary browsers no longer match it. Scan the host with Qualys SSL Labs’ server test and read the Cipher Suites section, or enumerate them locally:

nmap --script ssl-enum-ciphers -p 443 example.com

Replace anything flagged as weak or insecure with current TLS 1.2 and TLS 1.3 suites. A clean refusal on cipher grounds is more likely to surface as ERR_SSL_VERSION_OR_CIPHER_MISMATCH, so treat this as a check to rule out rather than the expected answer.

3. Something that is not TLS is answering on port 443

This one produces ERR_SSL_PROTOCOL_ERROR reliably, and it is easy to create by accident. The browser sends a TLS handshake to port 443, and what comes back is plain HTTP, an application banner, or nothing that resembles a TLS record. Common ways to end up here:

• A virtual host is listening on 443 but TLS was never enabled on it, so it serves plain HTTP on the secure port.
• An application server or container was published on 443 without a TLS terminator in front of it.
• A redirect or a hard-coded link sends visitors to an https:// address on a port that only speaks HTTP.
• The web server failed to start after a configuration change and something else claimed the port.

Check what is actually bound to the port on the server:

sudo ss -tlnp | grep :443

Then confirm from outside that the thing answering speaks TLS, using the s_client command from the previous section. When plain HTTP is answering, the command returns no certificate at all: you get an error about the record layer or the packet length, followed by no peer certificate available. The wording differs between OpenSSL releases, so treat the missing certificate as the signal rather than any particular error string. Firefox names this exact situation SSL_ERROR_RX_RECORD_TOO_LONG, which is a useful cross-check if you can reproduce it there.

4. The certificate chain is broken or unnecessarily large

A server has to send its own certificate plus the intermediate certificates that link it to a trusted root. Inspect what yours is sending:

openssl s_client -connect example.com:443 -servername example.com -showcerts

A simply missing intermediate normally shows up as a certificate warning such as ERR_CERT_AUTHORITY_INVALID rather than a protocol error, and an expired intermediate certificate has its own symptoms. The chain lands on -107 when the server abandons the connection instead of completing the handshake, which is most likely when the chain is malformed, when certificates are concatenated in the wrong order, or when it is padded out with extra certificates.

Keep the chain minimal and correctly ordered: leaf certificate first, then each intermediate, and leave the root out, since clients already have it. An oversized chain makes the server’s reply span more network packets than necessary, which is exactly the condition that older inline security devices mishandle. Our explanation of the chain of trust covers how the pieces fit together.

5. SNI or CDN virtual host misconfiguration

SNI (Server Name Indication) is the TLS extension that tells the server which hostname you are asking for, so that one IP address can serve certificates for many sites. If the server ignores it, or if a CDN has no entry for the hostname, the connection either gets the wrong certificate or is dropped mid-handshake.

Compare the two cases. Note the -noservername flag in the first command: since OpenSSL 1.1.1, s_client fills the SNI extension automatically from the hostname given to -connect, so without that flag both commands would send SNI and the comparison would prove nothing. The flag is specific to OpenSSL, and LibreSSL, including the openssl command built into macOS, rejects it as an unknown option.

openssl s_client -connect example.com:443 -noservername
openssl s_client -connect example.com:443 -servername example.com

If the second command returns your certificate and the first returns a different one, the server depends on SNI and is behaving correctly. If neither returns your certificate, the server is answering with the wrong virtual host. Fix the virtual host configuration, add the hostname to the CDN or load balancer, or move the site to a dedicated IP address. When the server rejects the name outright you will usually see ERR_SSL_UNRECOGNIZED_NAME_ALERT instead, so treat that code as the same family of problem.

6. The server or a middlebox cannot handle post-quantum key agreement

This is the cause most troubleshooting guides still do not mention, and it is the one that most specifically produces this code rather than a more precise one. Chrome turned on a hybrid post-quantum key agreement called X25519MLKEM768 by default in Chrome 131 in November 2024, on desktop first, and on every platform from Chrome 133 in February 2025. Firefox 132 and Edge 131 shipped it inside the same two-week window. The breakage this caused peaked during the rollout through 2025 and most vendors have since released fixes, so treat it today as the thing to check when a site fails only from one network, or only from behind one appliance, rather than as the first thing to suspect.

The change is meant to be backwards compatible: a server that does not support it is supposed to ignore the option and pick a classical one. The problem is what the option does to the size of the message. The post-quantum key share makes the browser’s opening ClientHello larger than a single network packet, so it arrives split across several. Equipment that assumes the ClientHello always fits in one packet, or that rejects unfamiliar options instead of ignoring them, drops the connection. Google’s own enterprise documentation describes the failure mode plainly: devices that do not implement TLS correctly may disconnect in response to unrecognized options or to the resulting larger messages.

The result reaches the visitor as ERR_SSL_PROTOCOL_ERROR. Fortinet documented this error by name in November 2024 as a known issue affecting flow-based deep inspection on FortiGate firewalls, and has since shipped IPS engine updates for its supported branches, with hybrid post-quantum support in flow-mode inspection arriving in FortiOS 7.6.5. Older load balancers, TLS-terminating proxies, and WAF appliances hit the same wall. That is the shape of the problem today: for most products a fix exists, and what is left is the equipment nobody has updated.

What changed in 2026 is that the escape hatch is gone. The PostQuantumKeyAgreementEnabled enterprise policy that let administrators turn the feature off was always described as temporary. It was supported on Chrome 116 through 146 and removed in Chrome 147. The chrome://flags toggle went earlier still, in Chrome 138. Neither one exists now, so on current Chrome there is no client-side setting that avoids this. The server or the appliance has to be fixed.

To test whether a host copes with the post-quantum key share, request it explicitly. ML-KEM arrived in OpenSSL 3.5, so check what you actually have before you rely on the result:

openssl version

This step matters more than it looks. If the answer names LibreSSL, which is what the built-in openssl command on macOS is, or names an OpenSSL older than 3.5, the test below cannot run and tells you nothing about the server: LibreSSL stops with Failed to set groups, and an OpenSSL older than 3.5 stops with Call to SSL_CONF_cmd(-groups, X25519MLKEM768) failed. Install a current OpenSSL first, through Homebrew’s openssl@3 package or your distribution’s packages, and run that binary instead. Run openssl version once more after installing: /usr/bin comes first on the default macOS PATH, so a plain openssl often still reaches LibreSSL, and you may need the full path /opt/homebrew/bin/openssl.

openssl s_client -connect example.com:443 -servername example.com -groups X25519MLKEM768

If that fails while the plain command from earlier succeeds, you have found the cause. The fixes, in order of preference: update the TLS stack, firmware, or inspection engine on the device that breaks; add an inspection exemption for the affected hostname as a temporary measure; and plan proper ML-KEM support, since the direction of travel is not going to reverse. Our overview of the post-quantum transition covers what it means for certificates more broadly.

Client-Side and Network Causes and Fixes

Work through these when the isolation tests showed the site loading somewhere else. They are ordered by how often they turn out to be the answer.

1. Antivirus HTTPS scanning or a TLS-inspection proxy

This is the most likely local cause, and it is the one the older advice about firewalls was reaching for and missing. A firewall that simply blocks a site gives you ERR_CONNECTION_TIMED_OUT or ERR_CONNECTION_REFUSED, because the connection never reaches the TLS stage. What produces a protocol error is TLS inspection.

Antivirus suites with an HTTPS scanning feature, and corporate proxies and firewalls doing deep inspection, do not pass your encrypted traffic through untouched. They intercept it, terminate the TLS connection themselves, decrypt and inspect the content, then re-encrypt it with a certificate signed by their own root, which they installed in your trust store. Every HTTPS connection you make is really being negotiated by that product’s TLS library rather than by Chrome. When that library is out of date, or cannot cope with Chrome’s larger post-quantum ClientHello, the handshake fails and Chrome reports what it sees: a protocol error.

Chromium even accounts for one specific version of this. The TLS access denied alert officially belongs to client-certificate access control, but some firewalls send it to block a page. So when Chromium gets that alert from a server that never asked for a client certificate, it overrides its normal handling and reports ERR_SSL_PROTOCOL_ERROR instead of a client certificate error, on the grounds that a client certificate error would only mislead you.

To find out whether your traffic is being inspected, open any site that does work, click the padlock in the address bar, and look at the certificate’s issuer. If it names your antivirus vendor or your employer instead of a public certificate authority, everything you browse is being intercepted. The same mechanism is behind many ERR_CERT_AUTHORITY_INVALID reports.

On a personal machine, turn the scanning feature off temporarily and reload the site. The wording differs between products and versions, but look for a setting along these lines:

• Avast and AVG: Core Shields, then Web Shield, then the HTTPS scanning option.
• ESET: Advanced setup, then Web and email, then SSL/TLS protocol filtering.
• Kaspersky: Settings, then Network settings, then encrypted connection scanning.
• Bitdefender: Protection, then Online Threat Prevention, then Encrypted web scan.

If turning it off fixes the site, turn it back on and update the product rather than leaving it disabled. An out-of-date scanning module is the actual defect. On a work machine you will not be able to disable inspection, and you should not try: send the hostname and the error to your IT team so they can update the appliance or exempt the site.

2. Extensions, VPN clients, and proxies

If the site loaded in the incognito window, an extension is responsible. The ones that matter here are the ones that sit in the connection path: VPN and proxy extensions, ad blockers, and anything marketed as a security or privacy add-on that rewrites requests.

Open chrome://extensions/, disable the candidates, and reload the page after each one rather than switching everything off at once, so you learn which extension is at fault. Disconnect any standalone VPN client and any system-wide proxy as well, then test again.

3. Chrome’s cached connections and DNS entries

Chrome keeps pooled connections and its own DNS cache, and either can hold on to a broken result after the underlying problem has been fixed. Clearing them is the modern replacement for the old “Clear SSL state” advice, which routed through Chrome settings into the Windows Internet Properties dialog. Chrome removed that route years ago, and these two pages do the job properly:

1. Go to chrome://net-internals/#sockets and click Flush socket pools.
2. Go to chrome://net-internals/#dns and click Clear host cache.
3. Reload the site.

If that is not enough, clear the browsing data too. Press Ctrl + Shift + Delete on Windows or Cmd + Shift + Delete on macOS to open Delete browsing data. Pick All time from the row of range buttons across the top, where you may need More to reach it, then tick Cookies and other site data and Cached images and files. Finish with the delete button, which reads Delete data when you are signed in to Chrome and Delete from this device when you are not.

Flush the operating system’s resolver cache as well, since Chrome’s cache is not the only one:

ipconfig /flushdns

On macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

On Linux with systemd-resolved:

sudo resolvectl flush-caches

While you are in net-internals, the chrome://net-internals/#hsts page (labeled Domain Security Policy) lets you query and delete a stored HSTS entry for a single domain. An HSTS entry does not cause this error, so do not go looking for one, but it is worth knowing about when you are testing an internal host that has switched away from HTTPS. We cover it in detail in our guide to disabling HSTS in Chrome and Firefox.

4. A stale entry in the hosts file

The hosts file overrides DNS for individual domains. If it points a domain at an address that no longer serves that site, your browser will faithfully open a TLS connection to the wrong machine, and the handshake fails. Old entries left over from development work, and entries added by ad-blocking or parental-control tools that redirect domains to 0.0.0.0 or 127.0.0.1, are the usual sources.

Inspect the file and remove the offending line. Do not delete the file itself: that is not a fix, and on some systems it breaks other software that relies on entries in it. On Windows, the file is at C:\Windows\System32\drivers\etc\hosts. Open a Command Prompt or PowerShell as administrator, which you need in order to save changes, and run:

notepad C:\Windows\System32\drivers\etc\hosts

On macOS and Linux the file is at /etc/hosts:

sudo nano /etc/hosts

Look for any line mentioning the affected domain. Rather than deleting it, put a hash in front so you can restore it later if it turns out to be needed:

# 192.0.2.10    example.com

Save the file, flush the DNS caches as described above, and reload the site.

5. Rule out HTTP/3 with the QUIC flag

Be clear about what this step is. QUIC is the transport protocol behind HTTP/3, standardized as RFC 9000 in 2021. When a QUIC connection fails, Chrome reports ERR_QUIC_PROTOCOL_ERROR and normally falls back to TCP with TLS on its own, so disabling QUIC is rarely the cure for a protocol error. It is still a fast way to take HTTP/3 out of the picture on networks that filter or throttle UDP, and it takes half a minute.

1. Type chrome://flags/#enable-quic in the address bar and press Enter.
2. Set Experimental QUIC protocol from Default to Disabled.
3. Relaunch Chrome and load the site again.

If the error is still there, set the flag back to Default. Leaving QUIC disabled costs you performance on every other site for no benefit.

Advice That Does Not Fix This Error

Several suggestions circulate widely for this error. They are worth naming, because two of them make things worse.

• Lowering the Internet Options security level to Medium. The Internet Options dialog configures the zone security model used by legacy Windows internet components. Chrome performs its own TLS handshake through its built-in library and does not consult those zone levels when doing it. Moving the slider cannot affect this error, and it does weaken the settings for the components that still use them. Leave it alone.
• Deleting the hosts file. Inspect it and comment out the offending line instead, as described above. Deleting the file removes entries other software may depend on and fixes nothing that commenting out one line would not.
• Turning the firewall off completely. A firewall that blocks a site produces a connection timeout or a refused connection, not a protocol error. Inspection is the part that breaks handshakes, and that is a setting to adjust, not a reason to disable your firewall.
• Reinstalling Chrome. A Guest profile tests the same hypothesis in ten seconds without losing your bookmarks, passwords, or history.
• Ignoring the error on a site you own. If it fails for you on more than one network, it fails for your visitors too, and unlike a certificate warning there is no button that lets them continue.

Frequently Asked Questions

For more SSL error troubleshooting, check our detailed tutorials about fixing different SSL errors.