ERR_SSL_KEY_USAGE_INCOMPATIBLE high
ERR_SSL_KEY_USAGE_INCOMPATIBLE
The cert's Key Usage or Extended Key Usage extensions don't permit TLS server authentication, so the browser refuses to use it.
What you see
This site can’t provide a secure connection example.com sent an invalid response. ERR_SSL_KEY_USAGE_INCOMPATIBLE
What’s actually happening
Chrome (and Chromium-based browsers) refuse the connection because the certificate's usage extensions forbid what it's being asked to do. The cert may be in-date, trusted, and match the hostname — none of that matters if Key Usage is missing digitalSignature or Extended Key Usage is missing serverAuth. This is almost always a hand-rolled self-signed or internal-CA cert generated without the right flags, not a commercial cert.
Common causes
- Key Usage lists only keyEncipherment and omits digitalSignature, which TLS 1.2/1.3 ECDHE and RSA suites require
- Extended Key Usage is present but doesn't include serverAuth (1.3.6.1.5.5.7.3.1) — e.g. only clientAuth or codeSigning was set
- A self-signed cert created with a bare openssl req and no -addext for keyUsage/extendedKeyUsage, so usage is wrong or under-specified
- An internal/enterprise CA issued the cert from a template intended for client auth or code signing rather than server auth
- An intermediate CA cert was mistakenly installed and served as the leaf — CA certs carry keyCertSign, not the server-auth usages
How to fix it
- Read the usage extensions off the live certecho | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -ext keyUsage,extendedKeyUsage. A healthy TLS leaf shows Key Usage with Digital Signature and Extended Key Usage with TLS Web Server Authentication. Missing either is the fault. (Older OpenSSL: pipe -text and grep for 'Key Usage'.)
- Reissue the cert with the correct usage flagsWith OpenSSL, add the extensions at signing: -addext "keyUsage=critical,digitalSignature,keyEncipherment" -addext "extendedKeyUsage=serverAuth". Or put them in an openssl.cnf v3_req section and pass -extensions v3_req. Regenerate, install the new cert, reload the server.
- Use a real CA instead of hand-rollingThis error basically never comes from Let's Encrypt or a commercial CA — they always set serverAuth. Switch the origin to a Let's Encrypt cert (certbot) or a Cloudflare Origin CA cert and the usage extensions are correct by construction.
- Make sure you didn't install the intermediate as the leafIf the served cert's subject equals its issuer or it carries keyCertSign, you've pointed the server at a CA cert by mistake. Repoint ssl_certificate at the actual leaf (fullchain.pem, leaf first), reload, and re-check with the -ext command above.
Stop it recurring
Generate TLS certs from a real CA (Let's Encrypt or Cloudflare Origin CA) rather than bare self-signed commands, so keyUsage=digitalSignature and extendedKeyUsage=serverAuth are always set.
Related errors