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

Maxim Dounin mdounin at
Wed Apr 8 15:27:52 UTC 2015


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:
> > > 
> > >
> > 
> > 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
> "" in the command):
> # openssl s_client -servername -connect -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, and 
  tcpdump to see what happens on the wire between nginx and OCSP 

Maxim Dounin

More information about the nginx mailing list