This will not impact Chrome in any meaningful way because - in typical Google fashion - they invented their own bullshit called CRLSets that does not perform OCSP or CRL checks in any way, rather periodically downloads a preened blacklist from Google which it then uses to screen certificates.

Most people don't realize this.

It's quite insane given that Chrome will by default not check CRLs *at all* for internal, enterprise CAs.

▲

stusmall 2 days ago | parent | next [-]

What in the Sam Hill? This is a new one on me. Does anyone have any reading for their logic of why?

	▲	TheDong 2 days ago \| parent \| next [-]
		They can be enabled by policy. An enterprise will usually have a policy installing it's custom ca https://www.chromium.org/Home/chromium-security/crlsets/ See here for some of the why: https://www.imperialviolet.org/2012/02/05/crlsets.html
	▲	na4ma4 2 days ago \| parent \| prev [-]
		I vaguely remember there was similar reasoning as why golang doesn't support them, they're "antiquated and useless". I hit that road-block a lot when trying to do mTLS in the browser, that and dropping support for the [KeyGen](https://www.w3docs.com/learn-html/html-keygen-tag.html) tag.

▲

creatonez 2 days ago | parent | prev [-]

What are you on about? Literally all browsers have adopted the same strategy. It's not some secret they're trying to hide from you. It's a good thing.

	▲	ekr____ 2 days ago \| parent [-]
		Sort of. Firefox doesn't filter the list of revoked certificates the way Chrome does.