If you are using Self-Signed SSL Certificates and recently updated your Google Chrome / Edge browser, you might have come across a new kind of error, i.e: “ERR_SSL_KEY_USAGE_INCOMPATIBLE”. In my case, it happened a few months ago on an Alfresco installation, and more specifically the Apache Solr URL. Since this URL is mostly used/accessible by Administrators, there is not much traffic going on there and no need to use a real signed SSL Certificate. The error on the browser looks like this:

This is, at the moment, specific to Chrome / Edge but it will most probably be coming for other browsers as well. As mentioned on this previous blog, I have been using a pretty standard OpenSSL request file to generate all my Self-Signed SSL Certificates for years. This is an example of configuration I used to use:

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

[dn]
C = CH
ST = JU
L = Delemont
O = dbi services
OU = IT
CN = dms.poc.it.dbi-services.com

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

[alt_names]
DNS.1 = dms.poc.it.dbi-services.com
DNS.2 = alfresco1.it.dbi-services.com
DNS.3 = alfresco2.it.dbi-services.com
DNS.4 = solr1.it.dbi-services.com
DNS.5 = solr2.it.dbi-services.com

This has been sufficient so far and it still works properly on Firefox for example, but not on Chrome anymore. After a bit of research, I found this page from Chrome which explains this change in behavior, for security purposes. As it states:

Connections which fail this check will fail with the error ERR_SSL_KEY_USAGE_INCOMPATIBLE. Sites which fail with this error likely have a misconfigured certificate. Modern ECDHE_RSA cipher suites use the “digitalSignature” key usage option, while legacy RSA decryption cipher suites use the “keyEncipherment” key usage option. If unsure, adminstrators should include both in RSA certificates meant for HTTPS.

Therefore, depending on the cipher suite that will be used, your Self-Signed SSL Certificate with only “keyEncipherment“, might not be sufficient anymore. If you want more details on the “keyUsage“, please see the OpenSSL documentation.

You can, of course, set the registry entry (on Windows clients) to disable this new behavior, but that’s not the way to go in the long term. You should therefore re-generate all your Self-Signed SSL Certificate to add the “digitalSignature” key usage. For that purpose, you just have to edit the line 15 from the above request file from “keyUsage = keyEncipherment, dataEncipherment” to “keyUsage = keyEncipherment, dataEncipherment, digitalSignature“. The result is this one:

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

[dn]
C = CH
ST = JU
L = Delemont
O = dbi services
OU = IT
CN = dms.poc.it.dbi-services.com

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

[alt_names]
DNS.1 = dms.poc.it.dbi-services.com
DNS.2 = alfresco1.it.dbi-services.com
DNS.3 = alfresco2.it.dbi-services.com
DNS.4 = solr1.it.dbi-services.com
DNS.5 = solr2.it.dbi-services.com

Then re-execute the shell script (or just the OpenSSL command) and replace the certificate in your Web Server / Application Server to fix the issue for good. In my case, my Solr URL was reachable again through Chrome: