Chrome v124 - ERR_SSL_KEY_USAGE_INCOMPATIBLE

[BOOT]

Since Chrome version 124.0.6367.61 any certificates generated by filtering solutions or antivirus software generate the error ERR_SSL_KEY_USAGE_INCOMPATIBLE and cannot be bypassed.

How is everyone handling this?

[tom_newton]

We are investigating some reports of this

[jthompson]

Not seeing this problem here. Have a look at the solution posited in this thread if you haven't already - https://support.google.com/chrome/thread/239508594/err-ssl-key-usage-incompatible-error-in-chrome-but-not-edge-for-all-google-sites-and-some-others?hl=en

[PaddyNewman]

When you load your specific cert (self signed I assume) under Details > Key Usage what parameters do you have in there.

 

It should be stating something along the lines of "Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing (86)" - maybe the self signed generator in your product is not adding the key usage params correctly. We aren't seeing problems currently using this certificate across our estate.

[BOOT]

From what I can see, the failing certificates don't have Signing listed for key usage... but the original certificates don't have that either. On an unfiltered connection the site works fine.

[PaddyNewman]

That is what i would expect with a self signed CA that hasn't had the right details passed when generating the cert. Obviously changing it will affect everyone but can you recreate a cert using OpenSSL?

 

Something like

 

[font=var(--ff-mono)]openssl req -x509 -nodes -newkey rsa:2048 -keyout private.key -out ca.crt -days 3650 -addext "keyUsage = digitalSignature, keyEncipherment, dataEncipherment, cRLSign, keyCertSign" -addext "extendedKeyUsage = serverAuth, clientAuth"[/font]

 

Thats a 10 year valid self signed that would work in newer browsers, I imagine its not including the keyUsage part by default, the extended is optional I think...

[mattjones]

We are experiencing this too - @tom_newton is looking into this for us.

 

The certificate is showing signing under keyusage. The now deprecated rsaKeyUsageForLocalAnchorsEnabled was working fine up until v124. We first saw this back in November 23.

 

We have rolled users back to a previous version as a temporary fix until we've had an update from Smoothie.

[ibpalle]

Just a thought - some installs have avoided replacing their CA so they are still using a CA that have expiry in 20232 or similar. I think replacing their CA with a newly created one, which is only valid for the correct 3 years may solve it but haven't tested.

[mattjones]

Our CA was renewed in Feb 24 and has an expiry date of Feb 26, so unfortunately this doesn't appear to be the issue in our case.

 

As mentioned above and in a post on a Google community thread: https://support.google.com/chrome/a/thread/269732161/version-124-0-6367-61-back-to-giving-err-ssl-key-usage-incompatible-and-prior-workaround-not-working?msgid=270044340#, the key usage appears to be set correctly on the Smoothwall generated cert - it shows Digital Signature.

[PaddyNewman]

Indeed, our CA is 10y expiring 2032 and I haven't seen a single report of this on our estate.

[BOOT]

All the failing certificates are using ECDHE_RSA which requires digitalSignature key usage option. The auto-generated certificates do not have this.

[0x9h3]

Hello all,

 

This also starting to affecting our estate (Google Chrome and MS Edge) does anyone have a fix for this yet?

 

Our Smoothwall Root CA expires in June 11, 2024

[mattjones]

It looks like the issue actually lies with Sophos - do you have web control enabled or a different endpoint security product?

[0x9h3]

Yes, we use Sophos Endpoint protection with web control. Do I need to turn this off?

[mattjones]

We have just tested this by temporarily disabling real time scanning for 'internet' and web control under Controls on Users. Close and lose the load browser.

 

For the time being we have disabled Chrome updates and rolled users back to a previous version. I've just opened a ticket with Sophos to investigate further so will keep you posted.

[0x9h3]

Hi,

 

Thank you for this. Did you have these enabled in the Base Policy - Threat Protection, or in another policy or is it a policy you've created.

 

Would you mind sending me screenshots of the policies you've disabled, please

 

Thanks,

[mattjones]

I have only temporarily disabled the policy on a client for testing. Sophos client > admin sign-in > enter tamper protection password and then override policies and turn off realtime scanning for internet and then 'web control' under 'controls on users'.

 

For clients that have updated to v124 we have rolled them back to a previous version:

 

taskkill /F /IM chrome.exe /T

msiexec /i "googlechromestandaloneenterprise64.msi" /quiet (version 124 MSI)

timeout /t 120

msiexec /x "googlechromestandaloneenterprise64.msi" /quiet (version 124 MSI)

timeout /t 20

msiexec /i "googlechromestandaloneenterprise64-v123.msi" /quiet (version 123 MSI - or whatever you have available)

 

Set the reg key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Update\UpdateDefault to 0

 

The client will then be on an earlier version and can't update.

 

Ive opened a case with Sophos for their thoughts.

[0x9h3]

Have you had the same issues with Microsoft Edge?

[mattjones]

Yes, exactly the same issue as Edge, as it is built on Chromium. The Sophos options above resolves the problem in Edge too.

[BOOT]

Disabling antivirus is never the solution.

[mattjones]

@BOOT3988, it is not, hence for testing purposes only.

[PaddyNewman]

I've started seeing stuff relating to v124 however not via HTTPS inspection/proxies, just an older instance.

 

Chrome v124 has re-added the previously experimental quantum jiggery pokery.

 

X25519Kyber768 key encapsulation for TLSProtects current Chrome TLS traffic against future quantum cryptanalysis by deploying the Kyber768 quantum-resistant key agreement algorithm.

 

That is in the release notes and changing this for a machine resolved our issues...

 

A quick fix/test is to add this to registry.

 

Path: SOFTWARE\Policies\Google\Chrome\PostQuantumKeyAgreementEnabled Type: DWORD Value: 0
Path: SOFTWARE\Policies\Microsoft\Edge\PostQuantumKeyAgreementEnabled Type: DWORD Value: 0

 

See if that helps your browsing I guess...

[BOOT]

That policy change didn't work for me.

Starting to suspect this is a malicious change intended as a precursor to a large-scale cyber attack...

[BOOT]

I can't believe more people aren't having this issue.

[mattjones]

BOOT3988 - what is your environment? Smoothwall? Sophos?

 

I've gone back to Smoothwall on this, as when we tested off-network with Sophos enabled it worked fine and when we set an exception for a device on the smoothwall appliance (keeping sophos web control enabled) we didn't receive the ssl errors.