Why did this cert work for years and then suddenly fail in Chrome?

Because the cert didn't change — Chrome's tolerance did. Chrome tightened enforcement of certificate key-usage constraints around version 119 (late 2023), and certificates that had always been technically non-compliant started getting rejected instead of quietly accepted. An X.509 certificate can carry two extensions that declare what its key is allowed to do: Key Usage (RFC 5280 §4.2.1.3) and Extended Key Usage (§4.2.1.12). For years browsers were lenient about whether those declarations actually matched a TLS server handshake. Chrome now checks: if the certificate says it's for the wrong purpose, it refuses the connection with ERR_SSL_KEY_USAGE_INCOMPATIBLE. The classic victims are internal appliances, IIS boxes, and anything using a self-signed certificate generated with default settings that never set digitalSignature or serverAuth. Nothing about your cert or server broke — the browser stopped overlooking a mismatch it used to ignore.

How is this different from ERR_CERT_AUTHORITY_INVALID or a name mismatch?

Those three errors object to three different things about the same certificate, and the distinction tells you what to fix. ERR_CERT_AUTHORITY_INVALID is about trust — the chain doesn't lead to a root the browser trusts (self-signed, missing intermediate). ERR_CERT_COMMON_NAME_INVALID is about identity — the name in the cert doesn't match the hostname. ERR_SSL_KEY_USAGE_INCOMPATIBLE is about permission — the cert may be trusted and the name may be perfect, but the cert declares it is not allowed to be used as a TLS server. It's the difference between 'I don't know you,' 'you're not who this is for,' and 'this key isn't licensed for this job.' You can't fix a key-usage problem by installing a root or adding a SAN; the declared purpose lives inside the certificate and the only fix is to reissue it correctly.

Why does the site load fine in Firefox or with curl but fail in Chrome?

Because Chrome (via BoringSSL) enforces key-usage and EKU consistency more strictly than Firefox or OpenSSL do, so a cert that other clients wave through gets stopped at Chrome. This is the single most useful clue you have: it localizes the problem to the certificate's declared purpose rather than the chain, the name, or the network. An `openssl s_client` handshake succeeding does NOT clear the certificate here — OpenSSL doesn't reject on the same mismatch, so a green result from it is a false all-clear. To actually see the problem, inspect the certificate's Key Usage and Extended Key Usage fields directly and confirm whether serverAuth (OID 1.3.6.1.5.5.7.3.1) is present and whether the keyUsage bits permit the cipher the server negotiates. That's what tells you the cert is scoped wrong, and Chrome is the only common client honest enough to say so out loud.

Views: 33

ERR_SSL_KEY_USAGE_INCOMPATIBLE: Wrong Cert Purpose

ERR_SSL_KEY_USAGE_INCOMPATIBLE means the cert's keyUsage or EKU forbids TLS server use. Isolate it in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

A site loads in Firefox and answers openssl s_client cleanly, but Chrome and Edge refuse it with ERR_SSL_KEY_USAGE_INCOMPATIBLE. The certificate isn’t expired. The hostname matches. The chain builds to a trusted root. Chrome isn’t objecting to who signed the certificate or whose name is on it — it’s objecting to what the certificate says its key is allowed to do.

Symptoms

The failure is Chrome/Edge-only; Firefox, Safari, or curl may connect without complaint.
It started after a Chrome update, with no change to the server or certificate.
The target is often an internal appliance, an IIS server, a NAS, a printer, a router admin page, or anything using a self-signed or internal-CA certificate.
openssl s_client -connect host:443 completes the handshake and prints the chain — yet Chrome still blocks.
Other Chrome cert errors (ERR_CERT_AUTHORITY_INVALID, ERR_CERT_COMMON_NAME_INVALID) are not what you see; the message is specifically about key usage.

What This Error Actually Means

An X.509 certificate can constrain its own key with two extensions. Key Usage (RFC 5280 §4.2.1.3) is a bitfield naming the cryptographic operations the key may perform — digitalSignature, keyEncipherment, and so on. Extended Key Usage (§4.2.1.12) names the higher-level purposes, each an OID: TLS server authentication is id-kp-serverAuth, OID 1.3.6.1.5.5.7.3.1.

ERR_SSL_KEY_USAGE_INCOMPATIBLE is Chrome saying: one of those extensions is present and inconsistent with using this certificate as a TLS server. Two shapes of the same problem:

The EKU is present but doesn’t include serverAuth. A certificate minted for client authentication, code signing, or email — or from a CA template scoped to the wrong purpose — carries an Extended Key Usage that simply doesn’t list 1.3.6.1.5.5.7.3.1. Chrome reads that as “this key is not for TLS servers” and stops.
The Key Usage bits don’t match the handshake. The server’s key-exchange method decides which bit it needs. ECDHE cipher suites — and all of TLS 1.3 — have the server sign the key exchange, which requires digitalSignature. Legacy RSA key-transport suites have the client encrypt to the server’s public key, which requires keyEncipherment. If the certificate lists only keyEncipherment but the connection negotiates ECDHE (needing digitalSignature), the declared usage and the actual operation disagree, and Chrome rejects.

The nuance that makes this diagnosable: absence of the extension is permissive, presence-but-wrong is fatal. RFC 5280 says a certificate with no Key Usage extension may be used for anything; the trouble comes specifically when the extension exists and forbids what TLS needs. That’s why this is not a trust or naming problem and can’t be fixed from the client — the certificate is announcing the wrong job for itself, and only reissuing it changes that announcement.

Top 3 Causes

A self-signed certificate generated with default settings. Windows New-SelfSignedCertificate, older IIS self-signed certs, and appliance-generated certs frequently omit digitalSignature or serverAuth. They worked until Chrome started enforcing; now every ECDHE/TLS 1.3 handshake — i.e. all modern ones — trips the key-usage check.
The wrong certificate template from an internal CA. On an enterprise PKI, a cert issued from a “Computer,” “Code Signing,” or client-auth template carries an EKU that doesn’t include serverAuth. It installs fine, chains to the trusted internal root, matches the hostname — and Chrome still refuses because the declared purpose is wrong.
A cert reused outside its intended purpose. Someone points a TLS server at a certificate that was issued for client authentication or another role. The key math is valid and the chain is trusted, but the EKU says “not a server,” so Chrome won’t use it for one.

Diagnose with DechoNet

SSL Check reads the certificate the server actually presents and shows its fields from outside your browser. Look at Extended Key Usage — if serverAuth (or TLS Web Server Authentication) isn’t listed, that’s your answer regardless of what any other client says.
The same check shows each certificate in the chain, so you can confirm the problem is on the leaf (the server cert) and not something you’re misreading further up. Key-usage rejection here is about the end-entity certificate’s declared purpose.
Because Chrome, Firefox, and OpenSSL disagree on strictness, an external inspection of the raw certificate fields beats “it works in curl.” Confirm the declared usage against what a TLS 1.3 / ECDHE handshake needs (digitalSignature, and serverAuth in the EKU) — that comparison is the whole diagnosis.

Resolution Checklist

Inspect the leaf certificate’s Key Usage and Extended Key Usage. Confirm the EKU includes serverAuth (OID 1.3.6.1.5.5.7.3.1) and the Key Usage includes digitalSignature. Missing either is the bug.
Reissue the certificate with the correct usage. For a TLS server, request keyUsage = digitalSignature (add keyEncipherment only if you still serve legacy RSA key-transport ciphers) and an EKU containing serverAuth. This is the actual fix — nothing on the client side substitutes for it.
On an internal CA, pick a TLS-server template. Reissue from a “Web Server” template (or your CA’s equivalent) rather than a Computer, code-signing, or client-auth template, so the emitted EKU is right.
Regenerate self-signed certs with explicit usage. When using New-SelfSignedCertificate or openssl req, set the key usage and serverAuth EKU explicitly instead of relying on defaults that may omit them.
Verify from outside, not just with curl. Re-run an external SSL Check and confirm serverAuth now appears and the Key Usage permits the negotiated exchange. A passing openssl s_client alone doesn’t prove Chrome will accept it.
Don’t try to “trust” your way past it. Adding the cert to a trust store fixes authority errors, not key-usage errors — the purpose is baked into the certificate and only reissuance changes it.

When to Escalate

If the certificate belongs to an appliance, printer, or vendor device you can’t reissue, escalate to the vendor: the fix is firmware or a device-side certificate regeneration that emits serverAuth and digitalSignature.
If it comes from an enterprise CA, hand it to whoever owns the PKI templates — the correction is a new issuance from a web-server template, not anything an individual server admin can patch locally.