Hello!

On Wed, Apr 08, 2015 at 02:30:12AM -0400, bughunter wrote:

> Maxim Dounin Wrote:
> -------------------------------------------------------
> > Hello!
> >
> > On Tue, Apr 07, 2015 at 12:26:23AM -0400, bughunter wrote:
> >
> > [...]
> >
> > > > > So how do I enable OCSP stapling for my vhosts when the default
> > > > server cert
> > > > > is self-signed? This seems like a potential bug in the nginx
> > SSL
> > > > module.
> > > >
> > > > Just enable ssl_stapling in appropriate server{} blocks.
> > >
> > > As far as I can tell, I'm already doing that:
> > >
> > > http://pastebin.com/Ymb5hxDP
> >
> > The configuration you are testing with seems to be
> > overcomplicated. Nevertheless, it should work assuming correct
> > certificates are supplied and OCSP responder works fine. What
> > makes you think that it doesn't work?
>
> Running the 'openssl s_client' command only returns "OCSP response: no
> response sent" as evidenced here (I've replaced the actual domain with
> "mydomain.org" in the command):
>
> # openssl s_client -servername mydomain.org -connect mydomain.org:443 -tls1
> -tlsextdebug -status
> CONNECTED(00000003)
> TLS server extension "server name" (id=0), len=0
> TLS server extension "renegotiation info" (id=65281), len=1
> 0001 - <SPACES/NULS>
> TLS server extension "EC point formats" (id=11), len=4
> 0000 - 03 00 01 02 ....
> TLS server extension "session ticket" (id=35), len=0
> TLS server extension "heartbeat" (id=15), len=1
> 0000 - 01 .
> OCSP response: no response sent
> ...

Note that a connection with a Sertificate Status Request will only
return a status if it is already loaded. If there is no OCSP
status available in the worker process, nginx will return no OCSP
status, but will initiate a request to OCSP responder. That is,
it may take a while before OCSP status will be available - even if
everything works fine.

[...]

> And the OCSP responder itself is working fine because Firefox is working
> fine (for the moment) and I can also ping the OCSP responder and access the
> OCSP responder directly using the URL in the certificate from the server

Note that this isn't really indicate anything: there are two forms of
OCSP requests, POST and GET. And Firefox uses POST, while nginx
uses GET. Given the fact that the responder was completely broken
just a few days ago - it's quite possible that it's still broken
for GETs in some cases.

> that nginx sits on. The CA's OCSP responder went down for a few hours a
> couple of days ago, which caused my browser (Firefox) to freak out and deny
> access to my own website. At that point I went about figuring out setting
> up OCSP stapling to prevent the issue from reoccurring in the future. The
> certificate has the v3 OCSP extension in it and it points at a valid
> location. There aren't any errors in the nginx logs about attempts to
> retrieve OCSP responses and failing. There are no errors, warnings, or
> notices during startup of nginx. I've reloaded and restarted nginx many
> times, rebooted the whole system one time, and run the "openssl s_client"
> command a bunch of times after each "long-shot" configuration adjustment
> (and reverted shortly after back to the config you saw in the pastebin).

I would recommend the following:

- test a trivial config with a single server{} block with the
certificate and "ssl_stapling on", nothing more; this should
rule out problems related to OCSP response verification, as well
as well as problems related to default vs. non-default server
you've claimed.

- try using debugging log to see what happens on low level in
nginx (see http://nginx.org/en/docs/debugging_log.html), and
tcpdump to see what happens on the wire between nginx and OCSP
responder.

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

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx