Fix ERR_SSL_KEY_USAGE_INCOMPATIBLE

ERR_SSL_KEY_USAGE_INCOMPATIBLE means the server's certificate carries an X.509 Key Usage extension that does not permit the operation the TLS handshake needed. The certificate may be otherwise valid, trusted, in date, and covering the right hostname; Chrome rejects it because the certificate itself declares "this key must not be used that way," and modern Chrome enforces the declaration.

You will almost never see this on a certificate from a public CA. It is overwhelmingly a self-signed or internal-CA problem: a hand-rolled cert generated with the wrong extension flags.

The 30-Second Background#

Two X.509 extensions constrain what a certificate's key may do:

• Key Usage (KU): low-level crypto operations, e.g. digitalSignature, keyEncipherment, certSign
• Extended Key Usage (EKU): high-level purposes, e.g. serverAuth, clientAuth, codeSigning

What a TLS handshake requires depends on the key exchange:

A certificate minted with only keyEncipherment breaks on TLS 1.3, which signs with the key rather than encrypting to it. A certificate minted for the wrong purpose entirely (a CA cert with certSign, a client cert without serverAuth) fails the same way.

Diagnose It#

openssl x509 -in cert.pem -noout -text | grep -A1 "Key Usage"

openssl x509 -in cert.pem -noout -text | grep -A1 "Key Usage"

Healthy output for a server certificate looks like:

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
    TLS Web Server Authentication

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
    TLS Web Server Authentication

If Digital Signature is absent, or EKU lacks TLS Web Server Authentication (serverAuth), you have found it.

Fix: Reissue the Certificate#

The Key Usage extension cannot be edited on an existing certificate; it is part of the signed data. Reissue. For a self-signed dev certificate:

openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -keyout key.pem -out cert.pem \
  -subj "/CN=dev.local" \
  -addext "keyUsage=critical,digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage=serverAuth" \
  -addext "subjectAltName=DNS:dev.local"

openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -keyout key.pem -out cert.pem \
  -subj "/CN=dev.local" \
  -addext "keyUsage=critical,digitalSignature,keyEncipherment" \
  -addext "extendedKeyUsage=serverAuth" \
  -addext "subjectAltName=DNS:dev.local"

For an internal CA (smallstep, Microsoft AD CS, a Vault PKI role), fix the template or role so issued server certs get digitalSignature + keyEncipherment and EKU serverAuth, then reissue affected certs. For local development, mkcert generates correctly-extended certificates by default and saves you the openssl incantations.

Limitations to Know#

• The error is Chrome-specific in name only. Other clients enforce key usage too, just with vaguer messages; fixing the certificate fixes them all.
• Clearing browser state does not help. The constraint lives in the certificate; the only fix is reissuing it.
• Critical flag matters. Marking KU critical with wrong values fails harder than omitting the extension; copy the values above rather than improvising.

Conclusion#

ERR_SSL_KEY_USAGE_INCOMPATIBLE is the certificate forbidding its own use: a Key Usage extension missing digitalSignature (or an EKU missing serverAuth), almost always on a self-signed or internal-CA certificate. Reissue with the right extensions and it is gone.

Internal services with hand-rolled certificates are precisely the ones nobody browses daily, so this class of breakage sits unnoticed until someone needs the tool urgently. Pointing an ObserveOne check at internal HTTPS endpoints surfaces a rejected handshake the day it starts, not the day it matters.