Configuration directive allow to update it less or _more_ frequently if required. At the moment nobody knows how often are OCSP responses updated until check the source code b/c there is no word in documentation about it.
On Mon, Jan 13, 2014 at 10:25 PM, Maxim Dounin <[email protected]> wrote: > Hello! > > On Mon, Jan 13, 2014 at 08:23:46PM +0400, kyprizel wrote: > > > > This looks like a very-very wrong way to address the problem. > > > Instead of resolving the problem it will hide it on some requests > > > (but not on others), making the problem harder to detect and debug. > > > > Once user can access the resource - he can see the warning about system > > time problem (and other warning). > > If he can't access it at all seeing something like "OCSP response > invalid" > > - he doesn't know what to do. > > So the correct solution will probably be to ask browser vendors > don't follow "abort the handshake" requirement (see > http://trac.nginx.org/nginx/ticket/425 for other reasons why it's > a bad idea anyway) and/or inform users about possible reasons of > the problem. And/or to relax thisUpdate check. And/or to ask CAs > to provide responses with thisUpdate set somewhere in the past. > > Trying to update OCSP responses less frequently doesn't > looks like a solution. There will be periods when a response is > fresh anyway. > > > > > > > > > On Mon, Jan 13, 2014 at 8:12 PM, Maxim Dounin <[email protected]> > wrote: > > > > > Hello! > > > > > > On Mon, Jan 13, 2014 at 07:45:29PM +0400, kyprizel wrote: > > > > > > > The reason is quite easy - most responders _do_ set validity time > equal > > > to > > > > 7 days and there is no reason to update the response every hour and I > > > want > > > > to update it more rarely. > > > > Some do not set nextUpdate at all and 3600 can be too rarely for > them. > > > > > > These reasons suggest that deriving validity times from response > > > validity times, as suggested earlier, would be a better way to go. > > > > > > > > > > > > > > > > > > > On Mon, Jan 13, 2014 at 7:42 PM, Maxim Dounin <[email protected]> > > > wrote: > > > > > > > > > Hello! > > > > > > > > > > On Mon, Jan 13, 2014 at 07:04:11PM +0400, kyprizel wrote: > > > > > > > > > > > So, you going to leave 3600 hardcoded there? > > > > > > > > > > Yes, unless you have some better reasons to make it > > > > > configurable. > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 13, 2014 at 6:51 PM, Maxim Dounin < > [email protected]> > > > > > wrote: > > > > > > > > > > > > > Hello! > > > > > > > > > > > > > > On Mon, Jan 13, 2014 at 06:08:53PM +0400, kyprizel wrote: > > > > > > > > > > > > > > > "some cases", for example = you have a lot of users with > wrong > > > system > > > > > > > time, > > > > > > > > so they can't access the server if OCSP responses updated too > > > > > frequently. > > > > > > > > > > > > > > This looks like a very-very wrong way to address the problem. > > > > > > > Instead of resolving the problem it will hide it on some > requests > > > > > > > (but not on others), making the problem harder to detect and > debug. > > > > > > > > > > > > > > -- > > > > > > > Maxim Dounin > > > > > > > http://nginx.org/ > > > > > > > > > > > > > > _______________________________________________ > > > > > > > nginx-devel mailing list > > > > > > > [email protected] > > > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > nginx-devel mailing list > > > > > > [email protected] > > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > > > > > > > > > > > > -- > > > > > Maxim Dounin > > > > > http://nginx.org/ > > > > > > > > > > _______________________________________________ > > > > > nginx-devel mailing list > > > > > [email protected] > > > > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > > > > > > > > > _______________________________________________ > > > > nginx-devel mailing list > > > > [email protected] > > > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > > > > > > -- > > > Maxim Dounin > > > http://nginx.org/ > > > > > > _______________________________________________ > > > nginx-devel mailing list > > > [email protected] > > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > > > > _______________________________________________ > > nginx-devel mailing list > > [email protected] > > http://mailman.nginx.org/mailman/listinfo/nginx-devel > > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-devel mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-devel >
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
