Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
>
> On Sun, Apr 12, 2015 at 12:21:19PM -0400, numroo wrote:
>
> > >> Yes, I ran the s_client command multiple times to account for the
> nginx
> > >> responder delay. I was testing OCSP stapling on just one of my
> domains.
> > >> Then I read that the 'default_server' SSL server also has to have
> OCSP
> > >> stapling enabled for vhost OCSP stapling to work:
> > >>
> > >> https://gist.github.com/konklone/6532544
> > >
> > >There is no such a requirement.
> >
> > I have the same problem here.
> >
> > openssl s_client -servername ${WEBSITE} -connect ${WEBSITE}:443
> -tls1
> > -tlsextdebug -status|grep OCSP
> >
> > Always returns the following on all virtual hosts no matter on how
> many
> > times I try:
> > OCSP response: no response sent
> >
> > But as soon that I disable my self-signed default host and restart
> Nginx, I
> > get a successfull repsonse on the second request on all CA signed
> hosts:
> > OCSP Response Status: successful (0x0)
>
> As previously suggested, tests with trivial config and debugging
> log may help to find out what goes wrong.
>
I wanted to mention that I've run into this issue as well when trying to enable OCSP stapling, where I have a default_deny SSL server that has a self-signed certificate where I don't want to use OCSP stapling, and other actual server entries for actual sites where I want OCSP stapling enabled. If I enable stapling for only the real sites, it appears to be silently disabled. If I enable it for all server instances, it notices that the default server uses a self-signed certificate and disables stapling. If I remove the default server, OCSP stapling works for the remaining sites, but then accessing the site using a means other than the correct server name provides the SSL certificate for one of the servers.
I tried enabling the debug log but there are no [debug] entries containing anything about OCSP in any of the above instances (only a [warn] entry is added when the self-signed certificate is configured for the default server with OCSP stapling enabled).
It would seem to me that for a parameter in the server {} block to be affected by the parameter's value in other server {} blocks is a bug.
I apologize for coming to the show late; I hadn't cared about optimizing SSL as much until more recently, and I haven't been able to find anyone discussing this issue aside from here (and on various how-to's generally describing the behavior I have confirmed through testing).