ERR_SSL_KEY_USAGE_INCOMPATIBLE: How to Fix the Certificate Key Usage

ERR_SSL_KEY_USAGE_INCOMPATIBLE is Chromium net error -181. The Chromium source describes it as: "The server's certificate has a keyUsage extension incompatible with the negotiated TLS key exchange method." The failure happens inside the TLS handshake, after the browser has received the certificate. The X.509 keyUsage extension lists what the key may do, and the handshake needs one specific bit:

• digitalSignature when the server signs the handshake: every TLS 1.3 connection and every TLS 1.2 ECDHE_RSA or ECDHE_ECDSA cipher suite.
• keyEncipherment for the legacy TLS 1.2 RSA key exchange (TLS_RSA_WITH_* suites), where the client encrypts the premaster secret with the server key.

It is not a trust error: the chain can be valid, unexpired and issued for the right name. It is also not about extendedKeyUsage (serverAuth), which is a separate check. A certificate with no keyUsage extension at all is not restricted and does not trigger this error. The classic offender is an RSA certificate whose keyUsage contains only keyEncipherment while the server negotiates ECDHE or TLS 1.3.

The error became common with Chrome 124. Chrome 116 to 123 had the enterprise policy RSAKeyUsageForLocalAnchorsEnabled; when it was disabled, Chrome skipped the check for TLS 1.2 connections that use an RSA certificate chaining to a local trust anchor (a policy-provided or user-installed root). Google's policy documentation states that starting in Chrome 124 the check is always enabled, so that policy no longer has any effect.

Certificates from public CAs normally carry digitalSignature, and connections to public trust anchors were already checked before 124. That is why the error usually appears on internal sites: router and firewall admin pages, printers, hypervisor consoles, intranet apps signed by a private CA, and HTTPS pages re-signed by a TLS-inspection proxy whose generated certificates lack the right bit. Firefox often opens the same page, which makes it look like a Chrome bug; it is not, the certificate really is mislabeled.

The browser checks the certificate of whatever terminates TLS for it, so on a Cloudflare-proxied hostname your origin certificate cannot cause this error. The checks that apply: on a load balancer or appliance (HAProxy, F5, a firewall portal) inspect the certificate uploaded there, not the backend copy, and on a corporate TLS-inspection proxy the certificate template must include digitalSignature.

1. Read the extensions the server actually sends.

   openssl s_client -connect intranet.example.com:443 -servername intranet.example.com </dev/null 2>/dev/null \
     | openssl x509 -noout -ext keyUsage,extendedKeyUsage

   If the output shows X509v3 Key Usage: critical followed only by Key Encipherment, you have found the cause. The -ext option needs OpenSSL 1.1.1 or later; on older builds use -text and look for the same lines.
2. Reissue from your private CA with both bits. A certificate is signed, so extensions cannot be edited in place. Sign a new one with an extension section like this:

   # server_ext.cnf
   [ server_ext ]
   basicConstraints = critical, CA:FALSE
   keyUsage = critical, digitalSignature, keyEncipherment
   extendedKeyUsage = serverAuth
   subjectAltName = DNS:intranet.example.com
   
   openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial \
     -days 365 -sha256 -extfile server_ext.cnf -extensions server_ext -out server.pem

   Including both bits is what Google's own policy text recommends for RSA certificates meant for HTTPS.
3. Microsoft AD CS: edit the certificate template's Key Usage extension so that digital signature is allowed, publish the template, and re-enroll the affected servers. Existing certificates keep the old bits until they are replaced.
4. Appliances with a built-in self-signed certificate: regenerate it from the vendor's admin UI or upload one issued as above instead of keeping the factory certificate.
5. Deploy and reload. Install the new certificate with its chain and reload the service, for example nginx -t && systemctl reload nginx.

Do not try to "fix" this by forcing legacy RSA key-exchange cipher suites. It cannot work with TLS 1.3, removes forward secrecy and leaves the certificate wrong for every client that negotiates ECDHE.

• Work or school network: if the error appears only there and on many sites, an inspection proxy is generating bad certificates. Send IT the error code; only they can fix the template.
• Antivirus with HTTPS scanning: update it or switch off encrypted-traffic scanning, then reload. The scanner re-signs every site with its own certificates.
• Internal device you manage (router, NAS, printer): use the owner steps above to replace its certificate.
• Public website: if it fails for you on every network and browser, the site owner has to reissue the certificate. There is no browser setting, flag or still-working policy that disables the check.

Clearing the browser cache, cookies or DNS will not help: the certificate is fetched fresh in every new handshake. The system clock is also irrelevant to this error.

Run the same openssl command against the live host and confirm the key usage line now reads:

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment

Then open the page in a current Chrome or Edge: that is the reliable reproduction, because command-line clients do not all apply the same key usage rule. To review the full chain, SANs and expiry from the outside, run the host through the enterno.io SSL checker.

• SEC_ERROR_INADEQUATE_KEY_USAGE: the Firefox key usage error
• ERR_CERT_INVALID: other malformed certificate problems
• ERR_SSL_PROTOCOL_ERROR: generic handshake failure
• ERR_CERT_AUTHORITY_INVALID: private CA not trusted
• Self-signed certificates explained
• How to debug a TLS handshake