What Causes ERR_SSL_KEY_USAGE_INCOMPATIBLE
Every X.509 certificate can carry a Key Usage extension that lists what its key is allowed to do. Modern TLS with ECDHE_RSA cipher suites needs the digitalSignature bit, because the server signs its part of the key exchange. Legacy RSA key exchange needs keyEncipherment instead. If the extension is present but the needed bit is missing, the connection fails.
Publicly trusted certificates and ECDSA certificates were already checked. Starting with Chrome 117, Google extended the check to RSA certificates that chain to local roots, meaning roots added by a user, an admin policy, or a piece of software. Edge is built on Chromium, so it followed. That is why the error mostly appears on internal tools with self-signed or private CA certificates, like NAS panels, backup consoles, and firewall admin pages.
Why the Registry Fix No Longer Works
Most guides still tell you to set RSAKeyUsageForLocalAnchorsEnabled to 0 in the registry. That policy was a temporary escape hatch. According to Google's RSAKeyUsageForLocalAnchorsEnabled policy page, the check is always on starting in Chrome 124, and even before that the policy only skipped it on TLS 1.2 connections. On any current version, that registry key does nothing.
Why Non-Repudiation Does Not Count
Some vendor guides say Digital Signature or Non-Repudiation will satisfy Chrome. Chrome's documentation names only digitalSignature and keyEncipherment. Non-Repudiation is a separate bit, and a certificate that has it without digitalSignature still fails.
How to Fix It on Your Server
Check the Current Certificate
Run this from any machine that can reach the server:
openssl s_client -connect app.internal:443 -servername app.internal </dev/null 2>/dev/null | openssl x509 -noout -ext keyUsageIf the output shows Key Encipherment without Digital Signature, you found the problem. If the certificate has no Key Usage extension at all, it is not the cause, since the rule only applies when the extension exists.
Reissue the Certificate With OpenSSL
openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
-keyout server.key -out server.crt \
-subj "/CN=app.internal" \
-addext "subjectAltName=DNS:app.internal" \
-addext "keyUsage=critical,digitalSignature,keyEncipherment" \
-addext "extendedKeyUsage=serverAuth"The keyUsage line is the part that matters. Setting both bits covers modern and legacy cipher suites, which lines up with how RFC 5280 defines each bit. Install the new pair on the server and restart the service.
Reissue the Certificate on Windows and IIS
IIS Manager's built-in self-signed option is a common source of this error. Create the certificate in PowerShell instead:
New-SelfSignedCertificate -DnsName "app.internal" -CertStoreLocation "Cert:\LocalMachine\My" -KeyAlgorithm RSA -KeyLength 2048 -KeyUsage DigitalSignature, KeyEnciphermentThen bind it to the site in IIS Manager under Bindings, or with netsh for apps that use HTTP.sys directly. If your certificates come from an internal CA, update the web server template so every future certificate carries digitalSignature.
Also Read: The Full Guide to Proxy Error Codes
Why Every Website Shows This Error
If Google, YouTube, and your bank all fail with this error, the websites are fine. Something on your machine is intercepting HTTPS and re-signing traffic with its own root certificate. Antivirus tools with HTTPS scanning, corporate SSL inspection firewalls, and debugging proxies like Fiddler or mitmproxy all work this way. If their generated certificates lack digitalSignature, Chrome rejects every site.
Open the same page in Firefox and click the padlock. If the issuer is your antivirus or your company firewall rather than a public CA, that is your culprit. Update the tool, turn off its HTTPS scanning, or ask IT to fix the inspection certificate template.
A normal forward proxy does not cause this. Residential proxies and datacenter proxies tunnel HTTPS through a CONNECT request, so the browser still receives the real site's certificate untouched. Only tools that decrypt and re-sign traffic can trigger this error.
Also Read: Fix 'The Proxy Server is Refusing Connections'
FAQ Section
Can I click through ERR_SSL_KEY_USAGE_INCOMPATIBLE like other SSL warnings?
No. Chrome shows it as a "This site can't be reached" page with no option to proceed. The certificate has to be replaced.
Does the RSAKeyUsageForLocalAnchorsEnabled registry fix still work?
No. Chrome 124 and later always enforce the check and ignore the policy. Edge runs on the same Chromium code, so do not count on it there either.
Why does the site open in Firefox but not in Chrome?
Firefox handles these certificates differently, so the page often still loads there. That makes Firefox useful for checking the certificate issuer, but it is not a real fix.
Will clearing the cache or resetting Chrome fix it?
No. Key Usage is a fixed property of the certificate. Nothing you change in the browser will add the missing bit.
Can a proxy cause ERR_SSL_KEY_USAGE_INCOMPATIBLE?
Only a proxy that intercepts TLS and signs its own certificates. A standard HTTP or SOCKS5 proxy passes the original certificate through and has no effect on this check.
Final Thoughts
ERR_SSL_KEY_USAGE_INCOMPATIBLE always comes back to one certificate that is missing the digitalSignature bit. If it hits a single internal site, reissue that site's certificate with digitalSignature and keyEncipherment. If it hits every site, find the software intercepting your HTTPS traffic and fix or disable it. Registry keys and browser resets will not get you past it in 2026. And if you route your traffic through Proxyon, the real certificate passes through untouched, so the proxy stays out of the equation.
