Skip to content

OCSP Responder Performance Needs Improvement

, 2 min read

This post is from 2012. Some details, links, and recommendations may be out of date.

Recently I set up a PingDom monitor to track the overall performance of the various OCSP responders out there, PingDom is limited to doing GETs and cannot parse the responses from the responders but it’s a fair mechanism to look at response time.

These tests run from a number of different global locations and are averaged together, the locations change but the same locations are used for each set of tests so again this seems fair.

I decided to use the Google logo as my control test, as it is about the same size as a larger OCSP response, after about a month of monitoring this is what I saw:

Test Avg. Response time
Google Logo (3972 bytes) 44 ms
GoDaddy OCSP 186 ms
GlobalSign OCSP 228 ms
Digicert OCSP 266 ms
Comodo OCSP 268 ms
TrustCenter OCSP 273 ms
TrustWave OCSP 315 ms
Startcom OCSP 364 ms
Entrust OCSP 371 ms
Geotrust OCSP 432 ms
VeriSign OCSP 510 ms
CyberTrust OCSP 604 ms
Certum OCSP 776 ms

As you can see the fastest responder is over four times slower than the Google logo, far from acceptable.

When looking at the individual responses and their responses this is what I saw:

  • Very few responders are using CDNs, AnyCast or other techniques to globally distribute responses.
  • Only a handful of responders have multiple DNS entries for failover scenarios.
  • Quite a few responders are not following the HTTP caching header requirements in RFC 5019.
  • Most responders are not sending CA signed responses which reduce the response size significantly (down to 471 bytes), in my opinion a OCSP responder should do this for all pre-produced responses.
  • Some responders are returning Unknown for out of scope responses, this really isn’t safe for unauthenticated requests as it exposes the responder to resource consumption denial of service for against the signing keys.
  • Response freshness ranges from 6 hours to 14 days, I am quite sure the six hour responses are failing for a very large % of the internet community due to time skew; 4 days appear to be optimum.

These are all fairly easy things to address and I believe it’s reasonable for responders to get down to response times that are consistent with the control test above.

PKI & CertificatesEngineering & Code#OCSP#REVOCATION#X509

Use and to move through the timeline.

2 comments

Comments are closed. These were left on the original WordPress site.

  1. Hi how would i use PingDom to test my OCSP responders, is it a basic script?

    1. I determined what the GET URIs for each of the CAs OCSP status would be and configured them as HTTP tests; no need for a script. OCSP says that you should get a non-successes should be something other than HTTP 200 so this works.

      I no longer use PingDom and instead use Monitis though I am considering switching to thousandeyes.com.