9

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 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 at 17:29
  • Try to start Chrome with the parameter -ignore-certificate-errors. – harrymc Oct 14 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 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 at 23:50
18

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.
  • 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 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 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 at 7:53
2

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

  • 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 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 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 at 13:52
  • I was actually referring to charles proxy – Thomas Williams Oct 29 at 20:49
  • lol, re-reading that was quite likely @CharlesDuffy, I didn't notice your A+ name. – Karl von Randow Nov 3 at 0:02
2

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.
  • This worked for me. – TomNash Nov 1 at 13:40

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.