OCSP revocation check despite stapled response


This test is showing an OCSP revocation check (making sure the site’s certificate is still legit), even though the tcpdump shows crutchfield.com responding to the TLS handshake request with a signed OCSP response “stapled” on.

On 3G it’s causing an extra 1s for the TLS handshake (performance killer).

What could be causing the browser to ignore the stapled OCSP response.


Creditkarma.com and overstock.com also have the same problem. They both use extended validation certificates. Is something about the browser configuration forcing a revocation check even though the OCSP response is stapled?

Turns out the OCSP check is on the intermediate certificate. https://www.webpagetest.org/forums/showthread.php?tid=14075

The question now is, why can’t I reproduce this locally? The OCSP check shows up in the tcpdump for the WPT results… but not in a trace generated locally.

have you had any luck making progress on this?

i’ve read a few places that most browsers don’t make revocation checks but i am observing the same behavior with WPT - with OCSP Stapling enabled EV certificates the revocation check is always made.

I’ve wiresharked sessions with chrome/FF and don’t see the OCSP check being made and am wondering if this is specific to WPT and can safely be ignored.

Where did you hear that browsers don’t make revocation checks? Chrome won’t if you don’t have an EV certificate but as long as your site is using EV certficates all browsers will do revocation checks.

The only question at this point is if revocation checks for intermediary certificates get cached or not (leading to how frequently they would get checked).