Browser errors
ERR_SSL_KEY_USAGE_INCOMPATIBLE: RSA key usage error in Chrome
ERR_SSL_KEY_USAGE_INCOMPATIBLEERR_SSL_KEY_USAGE_INCOMPATIBLE means the server's RSA certificate says its key may not be used for what the TLS handshake asks it to do. Chrome began enforcing this for certificates from locally trusted (private) CAs in 2024, so internal tools, admin panels and appliances that worked for years started failing.
Is it the site or your device?
It is almost always an internal certificate from a private CA; public certificates already comply. Check the certificate with the SSL checker if the host is reachable from the internet:
curl ssl.sh/example.com
- Internal system with a company CA: the certificate must be reissued by whoever runs the CA. As a user, report it to IT.
- Public website: public certificates are compliant, so look for HTTPS interception on your device or network (antivirus or corporate proxy using its own root). See corporate SSL inspection.
Causes
1. Key usage lists only keyEncipherment
Old certificate templates for RSA often set only keyEncipherment, which was enough for the obsolete RSA key-exchange suites. Modern handshakes (ECDHE, and all of TLS 1.3) require the server to sign, which needs digitalSignature. Inspect it:
echo | openssl s_client -connect intranet.example.com:443 -servername intranet.example.com 2>/dev/null \
| openssl x509 -noout -ext keyUsage
2. Key usage lists only digitalSignature with RSA key exchange
The reverse case: the server negotiates a legacy TLS_RSA_* suite while the certificate omits keyEncipherment. Disable RSA key exchange on the server; it lacks forward secrecy anyway.
3. Appliance firmware with outdated certificate generation
Firewalls, storage arrays and remote management cards may generate their own certificates with old templates. Update the firmware or upload a properly issued certificate.
4. Interception product
Security software that re-signs traffic with an RSA key and outdated key usage triggers the error on every site. Update the product.
What it looks like in each browser
| Browser | What you see |
|---|---|
| Chrome / Edge | "This site can't provide a secure connection" with ERR_SSL_KEY_USAGE_INCOMPATIBLE |
| Firefox | SEC_ERROR_INADEQUATE_KEY_USAGE in some configurations, or loads normally |
| Safari | Depends on the certificate; often loads |
How site owners fix it
Reissuing the certificate with digitalSignature in its key usage fixes it.
1. Reissue with the right key usage. For OpenSSL-based CAs:
printf "basicConstraints=CA:FALSE\nkeyUsage=critical,digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth\nsubjectAltName=DNS:intranet.example.com\n" > server.ext
openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
-days 200 -extfile server.ext -out server.crt
On Windows AD CS, duplicate the Web Server template and make sure Digital signature is checked under Extensions > Key Usage, then reissue.
2. Consider ECDSA keys for new internal certificates; they always use digital signatures and avoid this class of problem.
3. Remove legacy RSA key exchange from the server's cipher list.
4. Verify the new certificate with the certificate decoder before deploying, and confirm in Chrome.
FAQ
Why did this start after a Chrome update?
Chrome used to ignore key usage on RSA certificates from locally trusted CAs. Enforcement arrived with Chrome 124, so certificates that had worked for years on internal systems suddenly failed. The certificates were always non-compliant; Chrome stopped tolerating it.
Is there a policy to turn the check off?
Chrome shipped a temporary enterprise policy, RSAKeyUsageForLocalAnchorsEnabled, to give administrators time to reissue certificates. Treat it as a stopgap; check the current Chrome Enterprise policy list for its status, and reissue the certificates.
Does this affect public websites?
Almost never. Public CAs have long issued RSA certificates with digitalSignature. If a public site shows this error, suspect an interception product that re-signs traffic with its own locally installed root.
How can I find all affected internal certificates before users complain?
Scan your internal HTTPS endpoints and list each RSA certificate whose keyUsage lacks digitalSignature. The bulk SSL checker can check many hosts at once for names reachable from the internet; for purely internal hosts, loop openssl s_client over your inventory and grep the keyUsage line. Reissue anything that fails before the next Chrome rollout reaches your users.