There is a newer OCSP response but was not provided by the server

[Maxim Dounin]

Hello!

On Wed, Sep 23, 2015 at 09:42:32AM -0400, 173279834462 wrote:

> > Though not providing an OCSP response isn't a problem at all 
> > as OCSP stapling is just an optimization, and
> 
> Well. it *is* a problem. 
> 
> Without stapling, each client that hits our server also hits the ocsp
> server. 
> In our case, the ocsp server is overloaded (StartSSL), and therefore we
> can help by caching the response and delivering it ouselves. 

The problem here is that OCSP server is overloaded.  The fact that
nginx isn't able to provide help in this situation to a few first 
connections is at most lack of optimisation.

> There is another, more general problem: ocsp servers may log the hits.
> Although this may not happen with StartSSL (we do not know for sure), 
> it is still a concern on privacy of clients and profiling of all sorts. 

That's the problem with OCSP, not with nginx.  Clients who 
consider this to be a problem can use other ways to check 
certificate validity, including CRLs and CRLsets.

> > there is no need to care about pre-caching things.
> 
> If it works, yes. 
> If it does not work, then we must update manually. 
> One wants to avoid the latter case. 

Consider switching to a CA which works?

If you OCSP server is overloaded and not able to respond to 
requests, nginx won't be able to load an OCSP response as 
well, and nothing would help.

If your OCSP server is responding - at least to some requests - 
nginx eventually will be able to load a response and will start 
serving it to clients.

> > As long as there are clients who ask your server about an OCSP response 
> >- nginx will load it and will provide it to clients as needed.
> 
> It is *not* working. Please move on with the wishful thinking. It would be
> great if things were as you say. In reality, they are not. 
> 
> I think we agree that the following openssl test would be sufficient
> and good to ask the server about an OCSP response. In practice, 
> nginx is still not delivering as intended. 
> 
> echo QUIT \
>    | openssl s_client \
>    -CAfile /etc/ssl/ca-bundle.pem \
>    -connect $fqdn:443 \
>    -servername $fqdn \
>    -tlsextdebug \
>    -status 2>&1
> 
> where fqdn is the server's address.

I believe I already explained how it works, but let me repeat.  As 
soon nginx sees an connection with Certificate Status Request TLS 
extension, it will start loading an OCSP response from you CA OCSP 
responder.  Once the response is loaded, it will be stapled to 
further connections.  It is not possible to return an OCSP 
response in connection which was first to request it due to 
OpenSSL API limitations and the fact that loading a response can 
take a while.

That is, assuming 1 worker process and just started nginx, an OCSP 
staple is expected to be returned on the second connection with 
"openssl s_client -status ...".

Note though that if your CA OCSP responder is overloaded and not 
responding, it is likely that nginx won't be able to load a 
response, much like your clients.  In this case nginx will retry 
loading a response each 5 minutes.

As far as I understand, what you are asking about is a persistent 
cache of OCSP responses, to mitigate your CA's OCSP responder 
availability issues.  This is not a feature currently available in 
nginx (and you've choosen very wrong way to ask for a feature in 
an open source project).

-- 
Maxim Dounin
http://nginx.org/