We have OCSP enabled. Why do we get this reported in our tests? Monosnap
Any help would be very much appreciated.
What you’re seeing normally occurs as an artifact from using NGINX + many other proxies/CDNs.
If you look closely, you’ll see the OCSP probe has no effect on your site speed.
Not really a problem. You can safely ignore this.
If you must fix this, use straight up Apache, as Apache handles this differently than other proxies I’ve tested.
WebPageTest - Running web page performance and optimization tests... shows a simple static site, with straight up Apache, no proxy or CDN or any other tech.
I wonder if OCSP stapling isn’y configured correctly somewhere…
SSL Test says it’s enabled - SSL Server Test: rainvac.com (Powered by Qualys SSL Labs) - so you shouldn’t see the OCSP check in the waterfall.
The status check WILL be having a small speed impact - in the waterfall you linked to it’s 89ms or ~16% of TTFB.
If you can get OCSP stapling working correctly then the TLS negotiation time for the root request will reduce as it’s part of that step
I can comment on the OCSP stapling with respect to CDN. (responding back to Andy’s comment earlier)
Even when OCSP stapling is enabled, a CDN may not always respond back with the staple. Typically, the work flow occurs as follows:
- very first user makes a request. CDN responds without the staple.
- CDN asynchronously makes a request and pulls down the cert verification status
- for subsequent requests, the staple is included.
Browsers are supposed to work regardless of a CDN. So the optimization is to ensure that the request for staple verification does not break / slow down a website.
Refer to my comments above.
This appears to be an NGINX artifact which can be ignored.
Fix seems to be… simply removing NGINX, which solve other problems too, like 502 errors.
no this is not NGINX because we actually use “straight up apache” as you said, however the CDN MIGHT use NGINX however obviously we have no control over what they do or dont do.