ERR_INSECURE_RESPONSE website error explained

What it means

net::ERR_INSECURE_RESPONSE is a Chrome network error shown when a server returns an HTTPS response that fails the browser's security checks, usually around the TLS handshake or the certificate presented. It frequently appears in the DevTools console as net::ERR_INSECURE_RESPONSE beside a failed resource, or as an SSL warning on the "your connection is not private" page. The message is generic: it fires when the response does not live up to the connection's security expectations, so the underlying cause has to be identified rather than assumed.

A key trait is that the error is usually connected to a certificate or TLS configuration problem on the server side, not a local browser fault. A visitor who reloads on a different network or clears cache often sees the same failure, which is a strong sign the certificate itself is at fault.

The common causes

• A certificate that does not match the host. The certificate name (via its Subject Alternative Name or SAN entries) does not cover the domain being visited, often because the site moved to a new hostname or an old certificate was left in place. The SAN multi-domain reference explains how certificates list the domains they cover.
• A self-signed or untrusted certificate. A test certificate not signed by a public CA forces the browser to reject it. This is expected on a development box but must never reach visitors.
• An expired certificate. The certificate is past its validity window. The certificate renewal checklist covers checking and fixing validity dates.
• A weak signature algorithm. A certificate signed with an algorithm the browser no longer trusts, such as an old SHA-1 signature, fails the security checks.
• A missing intermediate. The server sends the leaf certificate but not the intermediates that connect it to a trusted root, so the browser cannot build a complete chain. The certificate authority invalid error covers this exact chain-building failure.
• A client-side interference. Antivirus or web-filtering software injects its own certificate for HTTPS scanning, and when that certificate is not trusted the browser flags the response as insecure. This is visitor-side, not the site's fault.

How to diagnose it

The fastest way to separate a site-side certificate fault from a client-side one is to test the site outside the affected machine.

1. Test from a clean context. Load the page normally, then in a private or incognito window and on a phone or different device. If the error follows across devices and browsers, it is the site's certificate chain, not a local browser cache.
2. Inspect the certificate directly. Click the padlock or use the browser's certificate viewer and check the issuer, the validity dates, the hostname coverage, and the signature algorithm. Run an external TLS checker (for example the SSL Labs test) which reports the chain, expiry and algorithm in one view.
3. Confirm the chain is served. For a Certbot or Let's Encrypt edge case, point the server at fullchain.pem rather than a leaf-only cert.pem, so the intermediates are presented alongside the leaf. The TLS certificate hierarchy explains how the trust path is meant to be built.
4. Confirm hostname coverage. Verify the certificate's SAN entries include the exact host in the bar, including www if the site uses it, because a missing SAN domain produces exactly this security failure.

If the certificate looks right, re-test with a second real-world server by loading a different secure site over the same connection. If that site loads while yours fails, the fault is in your server's certificate or TLS configuration rather than the network. When the error only appears on one machine behind corporate filtering or a security suite, the connection is likely intercepted, and the fix is on the client side, not the origin. In all cases, renew or reissue the certificate to a SAN-covering, chain-complete, current-algorithm certificate and verify with a certificate renewal check before declaring the site healthy.