The TLS handshake succeeds and the certificate is valid, so why does Chrome refuse the connection?

Because HTTP/2 has a stricter TLS floor than TLS itself. The handshake finished and the certificate checked out — that part is fine, and the same connection would happily carry HTTP/1.1. But HTTP/2 layered on top of TLS imposes extra requirements (RFC 9113 §9.2): at minimum TLS 1.2, and a cipher suite that is *not* on the blocklist in Appendix A. Chrome negotiated 'h2' via ALPN during the handshake, then checked whether the connection it actually got meets those requirements. It didn't, so Chrome tears it down with ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY rather than speak HTTP/2 over a connection HTTP/2 forbids.

Why does the same site load fine in another browser or over HTTP/1.1?

Because the restriction is specific to HTTP/2, not to TLS. A client that falls back to HTTP/1.1 has no cipher blocklist — RFC 9113's Appendix A only applies when the protocol is h2 — so the exact same weak cipher that Chrome rejects for HTTP/2 is perfectly acceptable for an HTTP/1.1 request. Some clients and configurations quietly drop to HTTP/1.1 and the page loads; Chrome prefers to negotiate h2 and then enforce its rules. That's why 'it works in curl' or 'it works on my phone' is a red herring here — those requests weren't held to the HTTP/2 cipher rules.

It happens on every HTTPS site at work, not just one. What does that mean?

That pattern points at your network, not any single server. A TLS-inspecting middlebox — a corporate firewall doing SSL decryption, or antivirus that scans HTTPS — sits in the middle, decrypts your traffic, and re-encrypts it to your browser with its own TLS settings. If it re-encrypts using a cipher suite HTTP/2 blocklists, every h2 site behind it fails the same way. Palo Alto's SSL decryption is a documented trigger. When one site fails it's the origin's cipher order; when *all* of them fail it's the box between you and them.

Views: 17

ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY Fix

ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY: TLS too weak for HTTP/2. Fix in 3 checks: TLS version, cipher suite, TLS inspector. Free instant 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

Chrome (or any Chromium browser) refuses to load the site with ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY. The confusing part is that nothing looks broken underneath: the padlock’s cryptography completed, the certificate is valid, and if you force the browser down to HTTP/1.1 the page often loads fine. This error isn’t about a bad certificate or an unreachable server. It’s HTTP/2 refusing to run over a TLS connection it considers too weak.

Symptoms

Chrome/Edge shows net::ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY, usually for the whole page rather than one asset.
The certificate is valid and unexpired — no ERR_CERT_* error, no expiry warning.
The site frequently works in a browser or client that ends up on HTTP/1.1, and in curl from a clean network.
If it appears on every HTTPS site rather than one, that’s a strong tell it’s local.

What This Error Actually Means

HTTP/2 over TLS (the h2 protocol) is fussier about the connection than plain HTTPS is. RFC 9113 §9.2 sets a floor: an h2 connection must use TLS 1.2 or higher, and §9.2.2 forbids a long list of cipher suites — the blocklist in Appendix A. The intent is forward secrecy: HTTP/2 effectively demands an ephemeral key exchange (ECDHE or DHE) paired with an AEAD cipher. Static-RSA key exchange is out, even when it’s carrying AES-GCM, so TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_RSA_WITH_AES_256_GCM_SHA384 are both on the blocklist despite being “AES-256” ciphers people assume are strong.

Here’s the sequence that trips it. During the TLS handshake, the server and browser agree on h2 via ALPN — the server said “yes, I speak HTTP/2.” They also agree on a TLS version and cipher suite. If that negotiated pair violates HTTP/2’s floor — TLS below 1.2, or a blocklisted cipher — the spec says a conformant client should raise an INADEQUATE_SECURITY error (code 0xc) and refuse. Chrome surfaces that as ERR_HTTP2_INADEQUATE_TRANSPORT_SECURITY.

The distinction from ERR_SSL_VERSION_OR_CIPHER_MISMATCH is the whole diagnosis. That error means the two sides shared no usable version or cipher and the handshake failed outright. This one means the handshake succeeded — they found a common cipher — it just happens to be one HTTP/2 won’t allow. The connection is genuinely fine; it’s the protocol running on top that objects. So you’re not looking for a broken TLS stack. You’re looking for a weak-but-working cipher that got chosen, and figuring out whether the server picked it or something in the middle forced it.

Top 3 Causes

The server prefers a blocklisted cipher while still advertising HTTP/2 - This is the classic origin-side cause. The server offers h2 over ALPN but its cipher preference list puts a static-RSA suite (like TLS_RSA_WITH_AES_256_GCM_SHA384) at the top. Browsers negotiate the server’s top choice, get a blocklisted cipher, and bail. The fix is cipher ordering: move ECDHE/DHE AEAD suites to the front and demote or remove the RSA key-exchange suites. Microsoft’s own guidance is explicit that HTTP/2 blocklisted ciphers must sit at the bottom of the order, or HTTP/2 negotiation fails.
A TLS-inspecting middlebox re-encrypts with a weak cipher - A corporate firewall doing SSL decryption, or antivirus “HTTPS scanning,” intercepts the connection and hands your browser a new TLS session using its own cipher settings — which are often older than the real origin’s. If it picks a blocklisted cipher, every h2 site breaks identically. The signature is breadth: it’s not one site, it’s all of them. Palo Alto’s SSL decryption has documented reports of exactly this. The fix is on the appliance (update its decryption profile) or, as a test, on a network without the box.
A legacy TLS terminator negotiating below TLS 1.2 - An old load balancer, reverse proxy, or SSL-offload appliance that still lands connections on TLS 1.1 (or 1.0) while advertising HTTP/2 violates the version floor directly. This is rarer now that TLS 1.2 is near-universal, but embedded appliances and frozen OpenSSL builds still do it. The fix is to raise the terminator’s minimum TLS version to 1.2 and confirm it’s offering modern suites.

Diagnose with DechoNet

SSL Check shows which TLS versions and cipher suites the server actually offers from outside your network. If a static-RSA or otherwise blocklisted suite is preferred, or the top TLS version is below 1.2, that’s your cause — and it proves the problem is the origin, not your browser.
HTTP Check fetches the site from outside your machine entirely; a clean fetch while your browser fails points the finger at a local TLS inspector rather than the server.
Port Check confirms 443 is reachable, separating a genuine connectivity fault from a protocol-level refusal.

Resolution Checklist

Separate origin from network first. Run an external SSL check and an external HTTP check. Clean externally but broken only in your browser → suspect a local TLS-inspecting firewall or antivirus.
Read the offered ciphers. If a TLS_RSA_WITH_* (static RSA key exchange) suite is at the top, or the highest TLS version is 1.1/1.0, that’s the violation.
On the origin, reorder cipher preferences so ECDHE/DHE AEAD suites (e.g. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which HTTP/2 requires you support) come first; demote or drop static-RSA suites. Raise the minimum TLS version to 1.2.
If it’s a middlebox, update or reconfigure the SSL-decryption/HTTPS-scanning profile to offer HTTP/2-compatible ciphers, or exempt the affected sites.
Re-run the SSL check and confirm the preferred suite is an ephemeral-AEAD cipher on TLS 1.2+, then reload in Chrome.

When to Escalate

If the external SSL check shows a blocklisted cipher preferred by the origin, escalate to whoever owns the web server, load balancer, or CDN TLS config — this is a cipher-ordering fix, not an application bug.
If an external HTTP/SSL check is clean but your browser fails across many sites, escalate to whoever runs your network’s TLS inspection: their re-encryption is negotiating a cipher HTTP/2 rejects.
If the terminator is landing connections below TLS 1.2, treat it as an urgent config item regardless of this error — you’re serving a deprecated protocol version to everyone, not just HTTP/2 clients.