Revocation checking for EV server certificates in Chrome

Skip to first unread message

Ryan Dickson

Aug 24, 2022, 8:14:26 AM8/24/22

OCSP requests reveal details of individuals' browsing history to the operator of the OCSP responder. These can be exposed accidentally (e.g., via data breach of logs) or intentionally (e.g., via subpoena). This is part of why Chrome doesn't do OCSP checks for Domain Validated (DV) or Organization Validated (OV) certificates by default, and starting in version 106, Chrome won't do them for Extended Validation (EV) certificates either, to better protect users' privacy. 

Select revocation checking support will continue to be available through CRLSets, and OCSP stapling will still be supported. Chrome also supports an enterprise policy to enable online revocation checking, though this may be removed in the future. 

For any other questions or concerns, please email us at



[Sent on behalf of the Chrome Root Program]

Buschart, Rufus

Aug 29, 2022, 2:44:58 PM8/29/22
to Ryan Dickson,

Dear Ryan!


Thank you for sharing this information with us. Will this also have influence on Google’s concept of individual crls per certificate (e.g. for | 7340166965)? I like this concept of extremely sharded CRLs a lot since it effectively keeps the CRL size under control but at the end it seems to me to have the same privacy issues as the OCSP responder.





Freyeslebenstr. 1
91058 Erlangen, Germany
Mobile: +49 (1522) 2894134

Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.
Siemens Corporation: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Roland Busch, Chairman, President and Chief Executive Officer; Klaus Helmrich, Cedrik Neike, Matthias Rebellius, Ralf P. Thomas, Judith Wiese;
Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin-Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322



You received this message because you are subscribed to the Google Groups "" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To view this discussion on the web visit

Ryan Hurst

Aug 29, 2022, 5:35:32 PM8/29/22

Google Trust Services does do CRL sharding but we DO NOT do individual CRLs per certificate. 

As an example, in the CRL you linked to in your post I count 329 entries (openssl crl -in fVJxbV-Ktmk.crl -inform DER -text|grep -c "Revocation Date").

I have not checked with the developers of the CA system on specifics for my response here so I am not sure there are not edge cases are but it seems likely that if there is only one revoked certificate from a CA you will sometimes see one entry CRLs. With that said our objective is to chunk entries them into useful, bite sized CRLs, not produce single CRLs per certificate.

With that background I would argue that modern day browser behavior of using delegated CRLs served by the browsers addresses the privacy concern in question. Specifically the concern as I understand it is that as a user visits a site with OCSP (which BTW can technically contain multiple CertIDs also) the URL (in the case of a GET request) of the revocation response leaks the site being browsed to. The reliance on these delegated CRLs served by browsers addresses this by removing the CA from the runtime interaction all together.

Ryan Hurst
Google Trust Services

Buschart, Rufus

Aug 30, 2022, 4:12:30 AM8/30/22
to Ryan Hurst,,

Hi Ryan!


Thank you for your email explaining the way how Google works with sharded CRLs. I only did some sample checks on and it seemed that every leaf certificate has its own CRL (which I found an extremely interesting concept). But this was obviously not correct. With this information it is clear to me that the situation for OCSP is different to the CRLs.


Thank you!




Reply all
Reply to author
0 new messages