ERR_SSL_KEY_USAGE_INCOMPATIBLE: How to Fix It on Chrome, Edge, Windows, IIS, NGINX, Apache, and Internal HTTPS Sites

by

ERR_SSL_KEY_USAGE_INCOMPATIBLE means the browser received a certificate whose key usage settings do not fit the way that certificate is being used for HTTPS. In most cases, the certificate is real and the hostname may even be correct, but the certificate extensions are wrong for modern TLS.

This error is especially common on internal websites, self-signed certificates, IIS deployments, local certificate authorities, and environments with SSL inspection. The fix is usually not in the browser. It is usually in the certificate template, the certificate itself, or the software intercepting HTTPS traffic.

Quick Fix

  • Test whether the error happens on one site or many secure sites.
  • Try the same site in another browser and on another device.
  • Disable VPN, proxy, or antivirus HTTPS scanning temporarily.
  • If you own the site, inspect the certificate’s Key Usage and Extended Key Usage.
  • Make sure the certificate includes Server Authentication for HTTPS.
  • For RSA server certificates, include Digital Signature. In many environments, Key Encipherment is also expected.
  • Replace old self-signed or internally issued certificates created from the wrong template.
  • Rebind the corrected certificate in IIS, Apache, NGINX, or the reverse proxy.
  • Clear browser state and restart the browser after certificate changes.
  • Run an external or internal SSL test to verify the live certificate actually changed.

What Is ERR_SSL_KEY_USAGE_INCOMPATIBLE?

ERR_SSL_KEY_USAGE_INCOMPATIBLE is a certificate validation error shown mainly by Chromium-based browsers such as Chrome and Edge. It appears when the browser decides that the certificate’s allowed key usages do not match the way the server is trying to use that certificate during TLS negotiation.

This is not the same as an expired certificate or a hostname mismatch. A site can have:

  • a valid hostname,
  • a valid certificate chain,
  • a working HTTPS listener,
  • and still fail because the certificate extensions are wrong.

In X.509, the Key Usage extension defines what the key may be used for, and the Extended Key Usage extension defines one or more application purposes. RFC 5280 states that if both extensions are present, they must both be processed, and the certificate must only be used for a purpose consistent with both. If there is no purpose consistent with both, the certificate must not be used. That is the core reason this error exists. :contentReference[oaicite:1]{index=1}

For TLS server authentication, RFC 5280 defines id-kp-serverAuth and says the key usage bits that may be consistent are digitalSignature, keyEncipherment, or keyAgreement. That sounds broad, but modern browser and platform behavior is stricter in practice, especially with RSA certificates used in modern ECDHE-based handshakes. :contentReference[oaicite:2]{index=2}

Why ERR_SSL_KEY_USAGE_INCOMPATIBLE Happens

Most real cases come from a short list of problems.

1. The Certificate Was Issued with the Wrong Key Usage

This is the most common cause. The certificate may be missing Digital Signature, or it may have been created for a different purpose entirely.

Typical bad examples:

  • certificate created only for key exchange,
  • certificate intended for signing, not server TLS,
  • certificate template copied from another service,
  • legacy self-signed certificate created by an old tool or wrong wizard.

RFC 5280 explains that digitalSignature is used when the subject public key verifies digital signatures for entity authentication and integrity services, while keyEncipherment is used for enciphering private or secret keys, such as key transport. For TLS server auth, the final certificate usage has to line up with what the TLS stack expects. :contentReference[oaicite:3]{index=3}

2. The Certificate Is Missing Server Authentication EKU

A certificate may have acceptable key usage bits but still fail because the Extended Key Usage does not include server authentication.

This is common with certificates created from:

  • client authentication templates,
  • code-signing templates,
  • smart card templates,
  • custom internal CA templates built for a different purpose.

Microsoft’s certificate guidance for secure LDAP states clearly that a server certificate must be valid for TLS server authentication and configured for digital signatures and key encipherment. The exact product is different, but the certificate design rule is highly relevant for HTTPS server certificates too. :contentReference[oaicite:4]{index=4}

3. The Certificate Works in Some Browsers but Fails in Chrome or Edge

This confuses many admins. The site may appear to work in one browser or one older client, then fail in a newer Chromium build.

The reason is simple: browsers do not all enforce every certificate rule in the same way or on the same schedule. Chrome Enterprise’s policy documentation for local trust anchors reflects this directly. It says modern ECDHE_RSA cipher suites use the digitalSignature key usage option, while older RSA decryption cipher suites use keyEncipherment. If the certificate fails this check, Chrome can show ERR_SSL_KEY_USAGE_INCOMPATIBLE. :contentReference[oaicite:5]{index=5}

4. The Certificate Came from a Local CA or Self-Signed Setup

This error is extremely common on internal company websites, lab servers, intranet dashboards, routers, and dev environments.

Why?

  • Admins often create self-signed certs quickly.
  • The wrong certificate template gets used.
  • The key usage fields are never reviewed.
  • The certificate is installed because it “looks valid,” but the extensions are wrong.

5. Antivirus or SSL Inspection Is Replacing Certificates

If the error appears on many secure sites and not just your own, the browser may not be seeing the real site certificate at all. Mozilla says that when secure-site errors happen across multiple websites, a common cause is software on the device or network intercepting secure connections and replacing certificates. They specifically list antivirus HTTPS scanning, corporate monitoring tools, and malware. :contentReference[oaicite:6]{index=6}

In those cases, the problem certificate may belong to the intercepting software, not the website.

6. The Correct Certificate Exists, but the Server Is Still Serving the Old One

This happens after certificate replacement.

  • IIS still has the old binding.
  • NGINX is still pointing at the old file path.
  • Apache reload never happened.
  • A load balancer or proxy is serving its own stale certificate.

How to Fix ERR_SSL_KEY_USAGE_INCOMPATIBLE Step by Step

Start by figuring out whether this is a site problem or a local machine problem.

1. Check Whether the Error Happens on One Site or Many

This is the fastest diagnostic step.

  • If only one site fails, that site’s certificate is probably wrong.
  • If many secure sites fail, the problem is probably local HTTPS interception.
  • If only one device fails, focus on that device first.

This matters because the fix path is completely different in each case.

2. Test Another Browser and Another Device

Open the same site in:

  • Chrome,
  • Edge,
  • Firefox,
  • another PC,
  • a phone on mobile data if the site is public.

If only Chromium-based browsers fail, that points even more strongly to certificate key usage enforcement. If every device fails, the server certificate itself is probably wrong.

3. Disable VPN, Proxy, and Antivirus HTTPS Scanning

If multiple secure sites fail, test local interception next.

  1. Disconnect the VPN.
  2. Turn off manual proxy settings.
  3. Disable browser proxy extensions.
  4. Temporarily disable antivirus HTTPS or encrypted web scanning.
  5. Restart the browser.
  6. Retest the site.

Mozilla’s guidance makes this a high-priority step when many secure sites are affected. :contentReference[oaicite:7]{index=7}

4. Inspect the Certificate’s Key Usage and EKU

If you own the site, inspect the live certificate now. Do not guess based on what you intended to deploy.

Look for:

  • Key Usage
  • Extended Key Usage
  • Server Authentication EKU
  • Digital Signature
  • Key Encipherment if your platform expects it

RFC 5280 says that for TLS WWW server authentication, consistent key usage bits may include digitalSignature, keyEncipherment, or keyAgreement. It also says that if both KU and EKU are present, both must allow the intended purpose. :contentReference[oaicite:8]{index=8}

5. Replace Certificates Created from the Wrong Template

If the certificate came from an internal CA, the fastest real fix is often to issue a new certificate from the correct server template.

The replacement certificate should have:

  • the correct hostname in SAN,
  • Server Authentication purpose,
  • Digital Signature,
  • and often Key Encipherment for broad compatibility with RSA server cert deployments.

Microsoft’s documentation for secure LDAP setup shows exactly that combination: DigitalSignature, KeyEncipherment, and SSLServerAuthentication. :contentReference[oaicite:9]{index=9}

6. Recreate Bad Self-Signed Certificates Correctly

Old self-signed certificates are one of the biggest sources of this error.

When recreating them, make sure you include:

  • the real DNS name in SAN,
  • server authentication purpose,
  • the correct key usage flags,
  • a modern key size and algorithm.

If the cert is for development only, do not reuse a code-signing or client-auth certificate just because it is easy to generate. That usually causes more problems later.

7. Rebind the New Certificate Correctly

After issuing the right certificate, make sure the live service actually uses it.

Check:

  • IIS site bindings,
  • Apache SSLCertificateFile and key paths,
  • NGINX ssl_certificate and ssl_certificate_key,
  • reverse proxy or load balancer certificate bindings,
  • container or ingress TLS secret references.

This step is where many renewals fail.

8. Restart or Reload the Service

A corrected certificate on disk means nothing if the server never reloads it.

  • Restart IIS site bindings if needed.
  • Reload Apache.
  • Reload NGINX.
  • Restart the reverse proxy.
  • Restart the application only if the TLS layer depends on it.

9. Clear Browser State and Retest

After certificate replacement:

  1. close the browser fully,
  2. reopen it,
  3. test in a private window,
  4. clear cache if needed.

This does not fix the root cause, but it prevents stale results from confusing the test.

10. Verify the Live Certificate with a TLS Test

Do not trust the server file system alone. Verify what the browser actually receives.

Check:

  • the served certificate,
  • the SAN list,
  • the KU and EKU values,
  • the chain,
  • the issuing CA.

This is the point where you confirm the fix really reached production.

Advanced Troubleshooting

Check for Local Trust Anchor Issues

Chrome Enterprise has a policy named RSAKeyUsageForLocalAnchorsEnabled specifically for checking RSA key usage for server certificates issued by local trust anchors. That is a strong clue about where this error usually appears: internally trusted certificates, not just public websites. :contentReference[oaicite:10]{index=10}

If the problem only exists in a managed enterprise environment, inspect:

  • local machine trust store,
  • certificate templates from the internal CA,
  • browser policy settings,
  • security products inserting local CA certificates.

Inspect the Certificate with OpenSSL

Use OpenSSL to inspect the live certificate and verify the extensions directly.

openssl s_client -connect example.com:443 -servername example.com

Then inspect the certificate fields for:

  • Key Usage
  • Extended Key Usage
  • Subject Alternative Name
  • issuer and chain

This helps when the GUI certificate viewer hides too much detail.

Check the Entire Proxy Chain

The wrong certificate may be served by:

  • the edge proxy,
  • the load balancer,
  • the ingress controller,
  • the web server,
  • or local SSL inspection software.

Always verify which layer terminates TLS.

Review Recent Changes

Ask what changed before the error started.

  • Did the browser update?
  • Did the certificate renew?
  • Did the internal CA template change?
  • Did antivirus or VPN software update?
  • Did the proxy or load balancer change certificates?

Most cases become clear immediately after this step.

Prevention Tips

  • Use proper server certificate templates, not generic ones.
  • Document required KU and EKU values for internal HTTPS.
  • For RSA HTTPS server certificates, include Digital Signature and, where appropriate, Key Encipherment.
  • Always include Server Authentication EKU for web servers.
  • Validate the live certificate after every renewal.
  • Keep self-signed and lab certificates out of production.
  • Limit HTTPS interception tools where possible.
  • Monitor for browser policy changes in managed environments.

When to Contact Support

Contact your hosting or infrastructure team if:

  • the site certificate came from a central CA,
  • the wrong certificate is being served by a load balancer or proxy,
  • you cannot inspect the certificate bindings yourself.

Contact your internal PKI or Windows admin if:

  • the problem affects internal HTTPS sites,
  • the certificate came from an enterprise CA,
  • the server template may be wrong.

Focus on the local device if:

  • many secure sites fail,
  • only one machine is affected,
  • turning off HTTPS inspection fixes the issue.

Related SSL Errors

FAQ

What does ERR_SSL_KEY_USAGE_INCOMPATIBLE mean?

It means the certificate’s key usage or extended key usage settings do not match how the certificate is being used for HTTPS. The browser rejects the connection because the certificate extensions are incompatible with the TLS handshake or server-auth purpose.

Why does ERR_SSL_KEY_USAGE_INCOMPATIBLE happen mostly on internal sites?

Because internal sites often use self-signed certificates, locally trusted certificates, or enterprise CA templates. Those are the environments where certificate extension mistakes are most common.

What key usages should an HTTPS server certificate have?

Per RFC 5280, TLS server authentication may be consistent with digitalSignature, keyEncipherment, or keyAgreement, depending on the certificate and handshake design. In practice, Microsoft guidance for TLS server certificates commonly expects Digital Signature, Key Encipherment, and Server Authentication. :contentReference[oaicite:11]{index=11}

Can antivirus or SSL inspection cause ERR_SSL_KEY_USAGE_INCOMPATIBLE?

Yes. If the error appears on many secure sites, Mozilla says local interception by antivirus, corporate monitoring tools, or malware is a common cause of certificate problems across sites. :contentReference[oaicite:12]{index=12}

How do I fix ERR_SSL_KEY_USAGE_INCOMPATIBLE on my website?

Issue a new certificate with the correct SAN, Key Usage, and Extended Key Usage; bind it to the live HTTPS service; reload the service; and verify the live certificate with a TLS test.

Final Thoughts

ERR_SSL_KEY_USAGE_INCOMPATIBLE is not a random browser glitch. It usually means the certificate was created for the wrong purpose or with the wrong key usage settings, especially on internal HTTPS deployments.

Start by checking scope. One site or many. Then inspect the live certificate, confirm Server Authentication, confirm the right key usage flags, replace bad certificates, and retest the live endpoint. That solves the problem much faster than changing browser settings and hoping for the best.

Leave a Comment