# OCSP server returns unauthorized status **URL:** \ **Category:** Issuance Tech\ **Created:** [October 31, 2016, 4:10pm UTC](https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965 "2016-10-31T16:10:08Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![bjacke](https://avatars.discourse-cdn.com/v4/letter/b/a88e57/32.png) [@bjacke](https://community.letsencrypt.org/u/bjacke)\ **Post date:** [October 31, 2016, 4:10pm UTC](https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965/1 "2016-10-31T16:10:08Z")
Here I reported a “unauthorized” ocsp issue that is not cause by temorary overload or so. It is 100 percent reproducable. Along with must-staple enabled this issue is really bad: > ---
**Author:** ![Biker](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/biker/32/49_2.png) [@Biker](https://community.letsencrypt.org/u/Biker)\ **Post date:** [October 31, 2016, 4:20pm UTC](https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965/2 "2016-10-31T16:20:23Z")
I consistently get the unauthorized error on [https://www.schaffter.com](https://www.schaffter.com) whereas I’ve never (so far?) got the same error on for instance [https://www.boozefighters.fr](https://www.boozefighters.fr) ---
**Author:** ![Biker](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/biker/32/49_2.png) [@Biker](https://community.letsencrypt.org/u/Biker)\ **Post date:** [October 31, 2016, 4:48pm UTC](https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965/3 "2016-10-31T16:48:13Z")
Reply to self: Service seems to be re-established. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [October 31, 2016, 5:58pm UTC](https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965/4 "2016-10-31T17:58:20Z")
Thanks for the report! This was related to a recent outage: [https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5816da347170c62119001f43](https://letsencrypt.status.io/pages/incident/55957a99e800baa4470002da/5816da347170c62119001f43). We’ll be writing up a full report soon, but the short version is that our database was overloaded, and we use the same database to serve OCSP queries. We’ll work to improve reliability in the future. You may be interested to read these gists about the ways in which OCSP stapling is implemented suboptimally in Apache and Nginx: [https://gist.github.com/AGWA/1de6c26be5396f7cbce7ee016302d684](https://gist.github.com/AGWA/1de6c26be5396f7cbce7ee016302d684) and [https://gist.github.com/sleevi/5efe9ef98961ecfb4da8](https://gist.github.com/sleevi/5efe9ef98961ecfb4da8). Ideally your web server (looks like Apache) would keep the latest OCSP response around until it could be replaced by a fresher one. If that were the case, any outage shorter than ~3.5 days could be weathered safely, even with a Must-Staple cert. Unfortunately, Apache drops its cached OCSP response after an hour, which means that any OCSP responder outage can cause an outage in your site. My apologies for the downtime! ---
**Author:** ![Biker](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/biker/32/49_2.png) [@Biker](https://community.letsencrypt.org/u/Biker)\ **Post date:** [October 31, 2016, 7:11pm UTC](https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965/5 "2016-10-31T19:11:11Z")
Thanks for the links to some very interesting and educational reading. We all learn from our experiences. I have no doubt you follow the “What can we learn from that outage?” line of thinking. I’ve (we’ve) already seen a lot of signs of that. You’re providing a very professional service with a fantastic support level and you’re labelling all this as “Free Beer”. You’ve got nothing to apologize for. Hats off for your hard and intense work. Biker P.S. I don’t remember when I got a truly free beer last time. 🙂 ---
**Author:** ![bjacke](https://avatars.discourse-cdn.com/v4/letter/b/a88e57/32.png) [@bjacke](https://community.letsencrypt.org/u/bjacke)\ **Post date:** [October 31, 2016, 9:18pm UTC](https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965/6 "2016-10-31T21:18:31Z")
jsha: I agree with biker, you do a great job, no reason to apologise! About the suboptimal ocsp handling of mod\_ssl I also filed a apache bug report a while ago: [https://bz.apache.org/bugzilla/show\_bug.cgi?id=57121](https://bz.apache.org/bugzilla/show_bug.cgi?id=57121) Better values to set for Apache’s mod\_ssl to mitigate the suboptimal handling of ocsp replies: ``` SSLStaplingReturnResponderErrors off SSLStaplingResponderTimeout 4 SSLStaplingStandardCacheTimeout 172800 SSLStaplingErrorCacheTimeout 60 ``` This updates valid ocsp resonses only every 48 hours and retries faster in case of erroneous ocsp replies. This helps for short outages but does not help in case the ocsp server is in a generic bad condition after the 48 hours are over though. In any case I currently would recommend those settings for every Apache setup with ocsp. ---
**Author:** ![jsha](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jsha/32/12_2.png) [@jsha](https://community.letsencrypt.org/u/jsha)\ **Post date:** [November 2, 2016, 12:11am UTC](https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965/7 "2016-11-02T00:11:35Z")
This is a very helpful example configuration, thanks for posting it. I’ll make sure to reference it if I add a page about OCSP stapling to our documentation. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [December 2, 2016, 12:11am UTC](https://community.letsencrypt.org/t/ocsp-server-returns-unauthorized-status/21965/8 "2016-12-02T00:11:39Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.