Fixing ERR_SSL_KEY_USAGE_INCOMPATIBLE in Chrome: A TLS 1.3 Guide

The ErrorYou try to load a local development site or an internal tool over HTTPS, but Chrome stops you cold. Instead of your page, you see a blank screen with a blunt warning:

This site can’t provide a secure connection
ERR_SSL_KEY_USAGE_INCOMPATIBLE

This failure often hits developers right after a browser update or when deploying a fresh batch of self-signed certificates. It means your certificate claims it can do one thing, but the TLS handshake (usually version 1.3) demands another.

Why Chrome is blocking youWhen Chrome 117 dropped in late 2023, it tightened the screws on X.509 certificate validation. Specifically, it began strictly enforcing the keyUsage extension. In the past, Chrome would look the other way if these settings were missing or messy. That changed with the move toward TLS 1.3.

TLS 1.3 handles security differently than its predecessors. If you use an RSA certificate, the protocol now requires a Digital Signature to prove ownership during the handshake. If your certificate only lists Key Encipherment (the old standard for RSA) or lacks the extension entirely, Chrome rejects it. It’s a security measure designed to prevent "downgrade attacks," where a server is forced to use a weaker, older version of TLS.

Step-by-Step FixYou can't just click "Advanced" and ignore this error. To fix it, you must regenerate your SSL certificate with the correct keyUsage bits. OpenSSL is the best tool for this job.

1. Inspect your current certificateFirst, confirm that the keyUsage field is actually the culprit. Run this command to peek inside your certificate file:

openssl x509 -in your_certificate.crt -text -noout | grep -A 1 "Key Usage"

If the results don't show Digital Signature, you've found the bottleneck. If the "Key Usage" section is missing altogether, Chrome will assume the certificate is too old to trust for TLS 1.3.

2. Build a better configuration fileDon't rely on generic command-line defaults. Instead, create a dedicated file named openssl.cnf. This ensures every necessary extension is baked in correctly from the start.

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no

[req_distinguished_name]
C = US
ST = New York
L = Brooklyn
O = TechCorp
CN = localhost

[v3_req]
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1 = localhost
IP.1 = 127.0.0.1

The essential part: You must include digitalSignature. We also include keyEncipherment so the certificate stays compatible with older TLS 1.2 clients that might still be lurking in your network.

3. Generate the updated certificateUse your new config file to create a 2048-bit RSA key and a fresh certificate. This command does it in one shot:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
  -keyout server.key -out server.crt \
  -config openssl.cnf -extensions v3_req

4. Deploy to your Web ServerSwap out your old files for the new server.crt and server.key. If you are using Nginx, your configuration should look like this snippet:

server {
    listen 443 ssl;
    server_name localhost;

    ssl_certificate /etc/nginx/ssl/server.crt;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    # Enforce modern, secure protocols
    ssl_protocols TLSv1.2 TLSv1.3;
}

After saving, restart your service with sudo systemctl restart nginx. You may need to restart Chrome or clear your "HSTS cache" to see the change take effect.

Verify the Results### Check with OpenSSLRun the inspection command again to verify the bits are in place:

openssl x509 -in server.crt -text -noout | grep -A 1 "Key Usage"

You should now see a clear success message:

X509v3 Key Usage: critical
    Digital Signature, Key Encipherment

Check in Chrome DevTools

- Navigate to your site and press `F12`.
- Open the **Security** tab.
- Click **View Certificate**.
- In the **Details** list, find **Key Usage**. It must explicitly list "Digital Signature."

Expert Advice

- **Automate with mkcert:** If you manage multiple local domains, `mkcert` is a lifesaver. It automatically creates locally-trusted certificates that already meet these strict TLS 1.3 requirements.
- **Corporate CA Templates:** If your company uses an internal CA (like Active Directory Certificate Services), the issue might be in the certificate template. Ensure the "Server Authentication" template includes the Digital Signature bit.
- **ECDSA Advantage:** While RSA is common, switching to ECDSA certificates (using P-256 or P-384 curves) is often better. They are faster, smaller, and inherently require `digitalSignature` for handshakes.