How to enable OCSP stapling when default server is self-signed?

[Maxim Dounin]

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/