OCSP Requests To identrust.com Slow

I just installed my first Let’s Encrypt certificates and appreciate that it was all free.

Unfortunately, I’m running across a substantial performance bottleneck with initial page load time when using browsers that check for certificate revocation (e.g. IE). All day today at least, I’ve seen IE11 wait 4-6 seconds after issuing OCSP requests to isrg.trustid.ocsp.identrust.com (the root CA) for a response. You can see the results on WebPageTest.org for my website http://www.webpagetest.org/result/160613_08_1CKW/1/details/ .

I enabled OCSP Stapling for my website but that only keeps the browser from querying the Let’s Encrypt CA (ocsp.int-x3.letsencrypt.org). I don’t know if this is possible, but could the Let’s Encrypt CA likewise enable OCSP stapling so that the client wouldn’t have to query the root CA? Eliminating that single request by the browser would be a HUGE improvement in performance.

And just in case the answer is no, I may consider looking for a certificate issued through a chain with a faster root CA. Does anyone know if there is a site that tracks performance of OCSP requests to root CAs so I can compare?

Thank you!

@jsha, do you know if people have had problems with the speed of IdenTrust OCSP services before?

Stapling more than one OCSP response requires additional technology on top of the existing OCSP stapling tech, RFC 6961 “OCSP Multi stapling”, it’s not clear to me how many browsers and servers would grok that today.

Here for example is an open Bugzilla ticket for work on this in Mozilla

1 Like

I haven’t heard complaints that IdenTrust’s OCSP responder is slow, but it’s also not something we monitor. We should start doing so.

As @tialaramex says, OCSP Multi Stapling is available but I’m not sure what the browser support is like. You could choose to have your web server staple the slow IdenTrust instead of the fast response from ocsp.int-x3.letsencrypt.org.

For end users their browsers should cache the IdenTrust response for a long time, so the 3-4 second pause should only happen the first time (though I acknowledge that first-time slowness is still bad). Are you getting end-user complaints about this too, or is it mainly that the results in WebPageTest are bad?

1 Like

Besides experiencing the problem first hand and on WebPageTest.org, I am not aware of visitors to my site having problems. But since I run a business that involves improving website performance, I don’t want to leave a bad first impression :slight_smile:

I agree with you that caching will probably take care of most users if they have recently visited sites that use Let’s Encrypt certificates. I just wouldn’t want to be the first cache miss.

Thanks for your help.

Definitely appreciate that! I used to work on web performance in a past job, and I've tried to make design choices in Let's Encrypt to make it as performant as possible. I've filed Test IdenTrust OCSP responder response time · Issue #1929 · letsencrypt/boulder · GitHub to see if we can reproduce the slowness, and if so we'll file an issue upstream for IdenTrust to work on it.


1 Like

@jsha old but relevant thread at Letsencrypt OCSP response times measured? :slight_smile:

A post was merged into an existing topic: Letsencrypt OCSP response times measured?

try other webpagetest.org locations/test servers as sometimes they're overloaded and play a factor as they are the client so to speak

Thanks for the suggestion. I had and the performance problem was always with identrust.com.

I experience exactly the same problem as the thread opener (IE11 only, recurring).


#  Resource                                     Content Type               ReqStrt  DNSLkp  InitlCx  TT1stByte  DL/Bytes   SC  IP

1  http://isrg.trustid....IAAAFThXNqC4Xspwg%3D  application/ocsp-response  0.661 s  176 ms  185 ms   4688 ms    1.7 KB    200
2  http://isrg.trustid....IAAAFThXNqC4Xspwg%3D  application/ocsp-response  0.662 s  -       185 ms   4693 ms    2.8 KB    200

5 secs, this will kill my site in production.

@jsha suggested earlier that it would be possible to ask the web server to staple the IdenTrust response, (not the Let’s Encrypt one which is much faster) and so browsers won’t need to talk to IdenTrust at all.

But I don’t see any way to tell Apache to do that :confused: so I don’t think this can help everyone. The only good news is that IE11 shouldn’t do this on every visit (OCSP is cached), but depending on the type of site your startup time on first visit may be critical.

I can verify that responses for this OCSP responder are annoyingly slow here too (slow enough they’ll always be aborted in Firefox for example) which makes the responder largely worthless. I don’t know how much influence ISRG has to get that fixed by Identrust.

AFAIK all mayor browsers support it. So as a server admin you should certainly use it.

@rugk – I am not aware of any browsers or web servers implementing Multi
Stapling (RFC 6961) in their general availability releases. If you have a
list showing otherwise, please share.

Basic OCSP stapling (RFC 6066) doesn’t work in this case because the Let’s
Encrypt CA that issued my SSL certificate, and whose certificate status
response is stapled to my own cert, is not the one having problems. It’s
their CA (identrust.com) that is having performance problems and isn’t
something addressed with RFC 6066 (to my knowledge).

Daniel Granville
Website Performance & Availability Consultant
Robexent Solutions, LLC

Ah it’s about multi-stapling…
So no, my comment was only about “usual” OCSP Stapling.