Other browsers implement persistent OCSP caches, but we do not (for various reasons).

In an ideal world, the browser would perform an online status check (such as OCSP) whenever it verifies a certificate, and reject the certificate if the check failed. However, these checks can be slow and unreliable. They time out about 15% of the time, and take about 350ms even when they succeed. Browsers generally soft-fail on revocation in an attempt to balance these concerns.

Chrome performs online checking for Extended Validation certificates if it does not already have a non-expired CRLSet entry covering the domain. If Chrome does not get a response, it simply downgrades the security indicator to Domain Validated.

原因 : Windows Vista にパフォーマンス強化および OCSP プロトコルのサポートが追加されたことで、WININET では既定で失効状態のチェックが有効になり、セキュリティが強化されます。

The state of the world for OCSP code is bad. Real bad. Unless you're running IIS, or running a home-grown OCSP daemon, you're going to staple bad responses. That is, if you turn on stapling in Apache or nginx, you're going to serve junk to a portion of your users. When you serve junk, in a must-staple world, everything goes badly.

Further, the world assumes clients are well-behaved - they have good clocks, good caching logic, and good OCSP implementations. Unfortunately, those assumptions can all be wrong - and when something's wrong on the client, it could brick sites. We already see this with HSTS and a variety of otherwise fixable errors (such as clock skew) contributing significantly to warning fatigue or user frustration - and it's actually rather surprisingly hard to quantify, on the client, the ways in which the client could have screwed up.

To that end, our focus has been on quantifying the OCSP ecosystem - both in terms of what the CAs are sending (... frequently, horribly bloated responses that often fail basic DER encoding rules), and what servers are doing. We're also exploring how to allow server operators to participate in that virtuous feedback cycle, by providing something akin to 'expect-staple' - that is, a signifier that the server *should* always be sending valid stapled responses, and a means of getting feedback when this is not the case. This will allow sites to further debug and investigate, both client errors and the fact that, again, most of the OCSP fetching code on servers is bad.