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?
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.
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?
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
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.
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.
# 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 192.35.177.195
2 http://isrg.trustid....IAAAFThXNqC4Xspwg%3D application/ocsp-response 0.662 s - 185 ms 4693 ms 2.8 KB 200 192.35.177.195
@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 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.
@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).