NET::ERR_CERT_REVOKED in Chrome/Chromium, introduced with MacOS Catalina

Question

I'm testing a device which generates a new self-signed certificate after each hard reset.

Immediately after installing MacOS Catalina, recent versions of Chrome (and Brave) have started throwing an NET::ERR_CERT_REVOKED exception, even though there is definitely no published CRL for this device, and the certificates generated on reset have unique serial numbers.

The error message has the following form:

You cannot visit [address redacted] right now because its certificate has been revoked. Network errors and attacks are usually temporary, so this page will probably work later.

Clicking on the "Advanced" button does not present any way to override this error.

What's going on here? How can I work around it, without making my browser unsafe for general-purpose usage (as would be the case by telling it to ignore all certificate errors indiscriminately)?

Solution 1

Apple has introduced a series of new requirements for SSL certificates to be accepted by Catalina, documented at https://support.apple.com/en-us/HT210176. To summarize here:

• Key size must be at least 2048 bits.
• Hash algorithm must be SHA-2 or newer.
• DNS names must be in a SubjectAltName, not in the CN field only.

Moreover, for certificates issued after 2019-07-01:

• The ExtendedKeyUsage extension must be present, with the id-kp-ServerAuth OID.
• The validity period may not be longer than 825 days.

...and, for certificates issued after 2020-08-01 (per HT211025):

• The validity period may not be longer than 398 days

Solution 2

A quick workaround (ensure you trust the site)

In the chrome browser whilst on the page, type:

thisisunsafe

• source https://podtech.com/os/mac-osx/chrome-catalina-certificate-issue/

Solution 3

If you need a workaround to get the site working without replacing the certificate you can do the following.

1. Download the certificate from the server (using another browser or with openssl)
2. Install the certificate into Keychain Access under the login store
3. Set the certificate to "always trust" by double clicking on it once it's been installed.

Solution 4

Looks like Catalina has some new requirements on certificate signatures. Charles probably needs to update their cert generation.

https://forums.developer.apple.com/thread/119877

Solution 5

Additional information for certificates issued after September of 2020:

TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days

https://support.apple.com/en-us/HT211025

https://support.apple.com/en-us/HT210176

View more solutions

Comments

[garethTheRed]

Possible duplicate of superuser.com/questions/1152291/…

[Charles Duffy]

Hmm. It's a possible duplication, but this just started happening -- as in, within the last week -- so there may well be a different root cause than one would see reflected in answers to a question from 2016. Then again, if one just wants a workaround, not a root cause, then the answer there may be adequate.

[harrymc]

Try to start Chrome with the parameter -ignore-certificate-errors.

[Charles Duffy]

@harrymc, yes, that's that's what the existing knowledge-base entries teach -- and that would work if I were using a separate browser instance for nothing but testing. That's nothing remotely like an ideal solution, though; I'd rather know why this is happening (is there a cache of prior serial numbers seen for the same CN?) and how to directly address it (where does that cache live? Can it be cleaned up?).

[Mohamed El Mahallawy]

I have similar problem too. Would be great to find out where the cache is and purge it. In my case, seems like Charles is using an older certificate.

[Charles Duffy]

@MohamedElMahallawy, ...the issue was not "older", but "with a validity period longer than Catalina permits".

[Hefewe1zen]

What version of https / TLS etc is the site running?

[Karl von Randow]

@MohamedElMahallawy Charles does cache the certificates it generates for servers, but it replaces them immediately if the server certificate changes. If it didn't seem to, does restarting Charles address it?

[Mohamed El Mahallawy]

@KarlvonRandow it does not. I do think there is either: 1. caching problem because I see a different expiry date for the certificate when Charles is running vs not. 2. I think Catalina introduced expiry limits on certificates and that might be a problem.

[Karl von Randow]

@MohamedElMahallawy That's odd that there'd be a different expiry on the real certificate. Very strange. Is the certificate in question a self-signed certificate?

[Mohamed El Mahallawy]

@KarlvonRandow it is self-signed

[Charles Duffy]

Thank you for that link -- it's almost certainly a proper answer to my question! I've proposed an edit putting the essential information in the answer itself, as required by rules for most Stack Exchange sites (see meta.stackexchange.com/questions/225370/… for an extended discussion); when that edit is applied, I'll be glad to accept this.

[EOhm]

Yes I think at least the requirement to use SAN for all names (so that in fact cn is more or less ignored), the id-kp-ServerAuth EKU extension will cause many certificates not issued by professional or at least well informed CAs to become suddenly invalid from that perspective. Also quite some self-signed might have a longer validity period then 825 days (or are created as such if not knowing this new limitation).. The first to points are covered by modern OpenSSL versions and such as default, I think.

[Charles Duffy]

This would be a much better answer if the specifics of the new requirements in question were described without needing to follow a link.

[gabel]

Fixed it for me.. The 825 days for the self signed certificate where my root cause. The CA cert ca still be valid for a longer period.

[Karl von Randow]

Charles copies the settings from the server certificate it is replacing, so I think the issue is with the server certificate. Please correct me if I'm wrong so I can correct it!

[Charles Duffy]

@KarlvonRandow, I believe the answer was referring not to the Charles proxy (which my question doesn't relate to in any way), but referring to me, personally, by my name.

[Thomas Williams]

I was actually referring to charles proxy

[TomNash]

This worked for me.

[Karl von Randow]

lol, re-reading that was quite likely @CharlesDuffy, I didn't notice your A+ name.

[Davi Lima]

This did not work for me (MacOS 10.15.2).

[Charles Duffy]

Neat! Thank you for the hint.

[damd]

This is awesome, works for Brave Browser too!

[rzaaeeff]

Thanks! This solution works! :)

[Jossef Harush Kadouri]

@rzaaeeff I would not consider this as a solution, but a damn workaround 😉

[Vinny]

yep the 825 days for me did it. couldn't figure out why my site worked in windows but not mac. thanks for this info, saved the day!

[Charles Duffy]

Thank you -- editing this into the accepted answer to have a single canonical one.