sfw/fix
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

  1. 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'.)
  2. 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.
  3. 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.
  4. 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