Skip to content

ERR_SSL_KEY_USAGE_INCOMPATIBLE: Fix Guide

Key idea:

ERR_SSL_KEY_USAGE_INCOMPATIBLE means the certificate does not include TLS Web Server Authentication (OID 1.3.6.1.5.5.7.3.1) in extKeyUsage. Chrome considers such a cert unfit for HTTPS. Causes: cert issued for S/MIME, code signing, client auth. Fix: request a cert with the correct extKeyUsage from your CA, or reissue via Let's Encrypt.

This error blocks HTTPS access. Below: causes, fixes, working config, FAQ.

Check your site's SSL →

Common Causes

  • Certificate issued for S/MIME (email), not TLS
  • Code-signing cert mistakenly installed on a web server
  • Client-authentication (mTLS) cert deployed instead of a server cert
  • Corporate CA issued only keyEncipherment without extKeyUsage
  • Old cert without extKeyUsage (modern browsers require it explicitly)

Step-by-Step Fix

  1. Check extKeyUsage: openssl x509 -in cert.pem -text | grep -A1 "Extended Key Usage"
  2. It must contain: TLS Web Server Authentication
  3. Let's Encrypt always issues certs with the correct serverAuth — reissue
  4. Commercial CA: order "SSL Server Certificate", not "Code Signing"
  5. Inspect SSL via SSL Checker — you will see every extension

Check SSL Certificate →

Example: Proper nginx TLS config

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;
    ssl_prefer_server_ciphers off;

    ssl_stapling        on;
    ssl_stapling_verify on;
}

Related SSL Errors

TL;DR: Understanding ERR_SSL_KEY_USAGE_INCOMPATIBLE

The ERR_SSL_KEY_USAGE_INCOMPATIBLE error indicates that the SSL certificate being used is not suitable for server authentication due to incorrect key usage attributes. This typically arises when the certificate does not include the necessary key usage extensions, such as 'Digital Signature' or 'Key Encipherment'. To resolve this, ensure that your SSL certificate is correctly issued for server authentication by checking its configuration and key usage settings.

Key Usage and Extended Key Usage in SSL Certificates

SSL certificates contain specific fields that dictate their usage, primarily 'Key Usage' and 'Extended Key Usage'. These fields determine the operations for which the certificate can be used. The 'Key Usage' extension specifies the basic functions of the key, while 'Extended Key Usage' delineates more specific purposes.

For server authentication, the following key usage attributes must be present:

  • Digital Signature: Allows the key to be used to sign data.
  • Key Encipherment: Permits the key to be used for encrypting keys.

If these attributes are missing or incorrectly configured, clients will reject the certificate, leading to the ERR_SSL_KEY_USAGE_INCOMPATIBLE error.

Checking Key Usage Attributes

To verify the key usage attributes of your SSL certificate, you can use the OpenSSL command-line tool. Here’s how to extract the key usage information:

openssl x509 -in your_certificate.crt -text -noout

This command will output various details about the certificate, including its key usage. Look for the 'Key Usage' and 'Extended Key Usage' sections to ensure they include the appropriate values for server authentication.

Practical Example: Configuring SSL Certificates for Server Authentication

When generating an SSL certificate, it is critical to specify the correct attributes to avoid the ERR_SSL_KEY_USAGE_INCOMPATIBLE error. Below is an example of how to create a Certificate Signing Request (CSR) with the appropriate key usage settings using OpenSSL.

Creating a CSR with Key Usage Extensions

First, create a configuration file (e.g., openssl.cnf) with the following content:

[ req ]
default_bits       = 2048
prompt             = no
distinguished_name = req_distinguished_name
req_extensions     = v3_req

[ req_distinguished_name ]
C  = US
ST = California
L  = San Francisco
O  = Example Company
CN = www.example.com

[ v3_req ]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth

Next, generate the CSR using this configuration file:

openssl req -new -key your_private_key.key -out your_csr.csr -config openssl.cnf

This command ensures that your CSR includes the necessary key usage attributes for server authentication. Once the CSR is generated, submit it to a Certificate Authority (CA) for signing.

Verifying the Issued Certificate

After receiving the signed certificate, you can verify that it contains the correct key usage attributes by running the OpenSSL command again:

openssl x509 -in your_signed_certificate.crt -text -noout

Check the output to ensure that the 'Key Usage' and 'Extended Key Usage' fields include the required attributes. If they do not, you will need to reissue the certificate with the correct settings.

CertificateExpiry, issuer, domains (SAN)
ChainIntermediate and root CA validation
TLS ProtocolTLS version and cipher suite
VulnerabilitiesHeartbleed, POODLE, weak ciphers

Why teams trust us

TLS 1.3
supported
Full
CA chain check
<2s
result
30/14/7
days-to-expiry alerts

How it works

1

Enter domain

2

TLS chain verified

3

Expiry date & vulnerabilities

What Does the SSL Check Cover?

SSL/TLS is the encryption protocol that protects data between the browser and server. Our tool analyzes the certificate, chain of trust, TLS version, and knownvulnerabilities.

Certificate Details

Issuer, validity period, signature algorithm, covered domains (SAN), and validation type (DV/OV/EV).

Chain of Trust

Full chain verification: from leaf certificate through intermediates to root CA.

TLS Analysis

Protocol version (TLS 1.2/1.3), cipher suites, Perfect Forward Secrecy (PFS) support.

Expiry Alerts

Set up a monitor — get Telegram and email alerts 30/14/7 days before expiration.

DV vs OV vs EV Certificates

DV (Domain Validation)
  • Confirms domain ownership only
  • Issued in minutes automatically
  • Free via Let's Encrypt
  • Suitable for most websites
  • Most common certificate type
OV / EV
  • Organization (OV) or Extended Validation (EV)
  • Issued in 1-5 business days
  • Costs $50 to $500/year
  • For finance, e-commerce, government sites
  • Increases user trust

Who uses this

DevOps

SSL certificate monitoring

Security

TLS config audit

SEO

HTTPS as ranking factor

E-commerce

customer trust

Common Mistakes

Expired certificateBrowsers block sites with expired SSL. Set up auto-renewal or monitoring.
Incomplete certificate chainWithout intermediate CA, some browsers and bots cannot verify the certificate.
Mixed content on HTTPS siteHTTP resources on an HTTPS page — the browser lock icon disappears, reducing trust.
Using TLS 1.0/1.1Legacy TLS versions have known vulnerabilities. Use TLS 1.2+ or 1.3.
Domain mismatch in certificateThe certificate must cover all site domains, including www and subdomains.

Best Practices

Set up auto-renewalLet's Encrypt + certbot with cron — certificate renews automatically every 60-90 days.
Enable HSTSStrict-Transport-Security header forces browsers to always use HTTPS.
Use TLS 1.3TLS 1.3 is faster (1-RTT handshake) and safer — legacy ciphers removed.
Monitor expiration datesCreate a monitor on Enterno.io — get notified well before expiration.
Verify chain after renewalAfter certificate renewal, confirm that intermediate certificates are installed.

Get more with a free account

SSL certificate monitoring, check history and alerts 30 days before expiry.

Sign up free

Learn more

Sources

Frequently Asked Questions

What is extKeyUsage?

Extended Key Usage — an X.509 extension listing what the cert is for: serverAuth, clientAuth, codeSigning, emailProtection. Browsers require serverAuth for HTTPS.

Why did it work before?

Old browsers did not enforce extKeyUsage strictly. Chrome 82+ requires serverAuth explicitly. A cert that worked 5 years ago is now blocked.

Can I add extKeyUsage to an existing cert?

No — the cert is signed by the CA. Changing its structure invalidates the signature. Only a reissue fixes it.

Is Let's Encrypt always fine?

Yes. All ACME certs are issued with <code>serverAuth,clientAuth</code> in extKeyUsage. Universal format.

Try the live tool that powered this guide

Free plan — 10 monitors, checks every 5 min, no card required. Upgrade for 1-minute interval and multi-region monitoring.