How to Fix ERR_SSL_KEY_USAGE_INCOMPATIBLE

What the error means

A certificate can carry a key usage extension that lists what its key is allowed to do. Two values matter for HTTPS:

• digitalSignature. Needed by modern connections that use ECDHE key exchange, where the server signs the handshake with its key. This covers practically all connections today.
• keyEncipherment. Needed only by the legacy RSA key exchange, where the browser encrypts a secret with the server's key.

Many older devices create certificates that list only keyEncipherment. When the browser negotiates ECDHE, the certificate forbids the signature the handshake requires, so Chrome stops. Chrome already applied this check to publicly trusted certificates, ECDSA certificates and TLS 1.3. From version 124 it also applies to RSA certificates that chain to a locally installed root, which is where most devices fail.

A certificate with no key usage extension at all is not affected; the error appears only when the extension is present and lacks digitalSignature.

Quick checks: is it you or the device?

Chrome shows the error on a "This site can't be reached" page that suggests the site might be down. It is not down: the connection is refused because of the certificate. Unlike certificate warnings, there is no "Proceed anyway" link.

• Visitors: clearing the cache, changing the clock or turning off the antivirus will not help. Tell the administrator of the device or site; only a new certificate fixes it.
• Administrators: if the page fails for every Chrome and Edge user since spring 2024 and the device uses a self-signed or company-CA certificate, check its key usage (step 3).

Check the certificate's key usage

Because Chrome refuses the connection, read the certificate with OpenSSL instead. It shows the certificate even when the browser will not (replace the host name with your device):

echo | openssl s_client -connect nas.example.lan:443 -servername nas.example.lan | openssl x509 -noout -ext keyUsage

If you have the certificate file, run:

openssl x509 -in device.crt -noout -text

Look for the X509v3 Key Usage line. "Digital Signature, Key Encipherment" is correct. "Key Encipherment" alone, or any list without "Digital Signature", is the cause of the error. The -ext option needs OpenSSL 1.1.1 or newer.

On Windows you can also double-click the certificate file and open the "Details" tab, then the "Key Usage" field. On macOS, open the file in Keychain Access. Our guide on how to check SSL details in the browser shows where the certificate viewer is.

Reissue the certificate with the right key usage

The real fix is a new certificate whose key usage includes digitalSignature. If unsure, Chrome's documentation advises listing both values in RSA certificates meant for HTTPS. With OpenSSL, put the extensions in a small config file and use your device's names:

device.cnf:

[req]
prompt             = no
distinguished_name = dn
x509_extensions    = server_ext
req_extensions     = server_ext

[dn]
CN = nas.example.lan

[server_ext]
basicConstraints = critical, CA:FALSE
keyUsage         = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName   = DNS:nas.example.lan, IP:192.168.1.10

Self-signed certificate:

openssl req -x509 -newkey rsa:2048 -sha256 -days 365 -nodes -keyout device.key -out device.crt -config device.cnf

Certificate signed by your own CA:

openssl req -new -newkey rsa:2048 -nodes -keyout device.key -out device.csr -config device.cnf
openssl x509 -req -in device.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out device.crt -days 365 -sha256 -extfile device.cnf -extensions server_ext

Upload device.crt and device.key to the device, restart its web service and check the key usage again. A self-signed certificate must then be trusted on each computer, otherwise Chrome shows NET::ERR_CERT_AUTHORITY_INVALID instead. If you run a company CA (for example Active Directory Certificate Services), check that the certificate template for web servers includes "Digital Signature" and reissue the affected certificates.

Switching to an ECDSA key is not a shortcut: ECDSA certificates already needed digitalSignature, so the key usage must be right either way. For development machines, see SSL certificate for localhost.

Update the device firmware or software

If the device creates its own certificate, you often cannot set the key usage yourself. Many vendors have released versions that generate certificates with the correct key usage, so install the latest firmware or software version first. An update usually keeps the old certificate, so regenerate the self-signed certificate in the device's admin panel afterwards and check its key usage again. If no update exists, upload a certificate you made in step 4 or step 6, and ask the vendor for a fix.

Or use a publicly trusted certificate

Certificates from public certificate authorities are issued with the correct key usage, and every browser trusts them without installing a root on each computer. If the device is reachable under a host name in a domain you own, for example nas.example.com, a domain-validated certificate such as Sectigo PositiveSSL (from $16.00 per year) solves both problems. DNS validation works even when the device is not reachable from the internet. Public CAs do not issue certificates for private IP addresses or internal names such as .lan or .local, so those devices need a private certificate from step 4.

Create the CSR on the device or with our CSR generator, then verify the installation with the SSL Checker if the host is public. Public certificates must be renewed regularly, so Automated SSL can take care of renewals for you.