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)?

  • Possible duplicate of superuser.com/questions/1152291/… – garethTheRed Oct 14 '19 at 17:13
  • 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. – Charles Duffy Oct 14 '19 at 17:29
  • Try to start Chrome with the parameter -ignore-certificate-errors. – harrymc Oct 14 '19 at 17:33
  • @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?). – Charles Duffy Oct 14 '19 at 17:40
  • 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. – Mohamed El Mahallawy Oct 16 '19 at 23:50

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.
| improve this answer | |
  • 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. – Charles Duffy Oct 15 '19 at 19:28
  • 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. – EOhm Oct 15 '19 at 20:45
  • 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. – gabel Oct 28 '19 at 7:53
  • 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! – Vinny Mar 3 at 23:06

A quick workaround (ensure you trust the site)

In the chrome browser whilst on the page, type:

| improve this answer | |
  • 1
    Neat! Thank you for the hint. – Charles Duffy Jan 14 at 13:02
  • This is awesome, works for Brave Browser too! – damd Jan 16 at 20:24
  • Thanks! This solution works! :) – rzaaeeff Feb 26 at 13:41
  • @rzaaeeff I would not consider this as a solution, but a damn workaround 😉 – Jossef Harush Feb 26 at 17:14

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.
| improve this answer | |
  • 1
    This worked for me. – TomNash Nov 1 '19 at 13:40
  • 2
    This did not work for me (MacOS 10.15.2). – Davi Lima Jan 2 at 19:11

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


| improve this answer | |
  • 1
    This would be a much better answer if the specifics of the new requirements in question were described without needing to follow a link. – Charles Duffy Oct 16 '19 at 3:29
  • 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! – Karl von Randow Oct 29 '19 at 9:01
  • @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. – Charles Duffy Oct 29 '19 at 13:52
  • I was actually referring to charles proxy – Thomas Williams Oct 29 '19 at 20:49
  • lol, re-reading that was quite likely @CharlesDuffy, I didn't notice your A+ name. – Karl von Randow Nov 3 '19 at 0:02

Yes...it's correct that on MacOS Catalina Chrome and Safari give "NET::ERR_CERT_REVOKED" error on self-signed certificate, due to various reasons. But to quick start your work you can use Mozilla Firefox. I installed the Mozilla browser and it worked for me.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.