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

B
  • 6 Apr '15
My web server is intentionally set up to only support virtual hosts and TLS
SNI.  I know that the latter eliminates some ancient web browsers but I
don't care about those browsers.

I want to enable OCSP stapling and it seems to be configured correctly in my
test vhost (everything else about SSL already works fine - I get an A on the
Qualys SSL Labs test) and there are no errors or warnings but "openssl
s_client" always returns:

"OCSP response: no response sent"

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

This is a huge problem if I want to enable OCSP for my vhosts because my
'default_server' certificate is self-signed (intentional) and running
'configtest' with 'ssl_stapling' options on the default server, of course,
results in a warning:

"nginx: [warn] "ssl_stapling" ignored, issuer certificate not found"

Which indicates that it isn't enabled on the default server and subsequent
s_client tests (after reloading the config, which, of course, issued the
same warning a second time) on the test vhost confirm that there was still
no OCSP stapling.  It was a long-shot in the first place.

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.

Other useful info:  Running nginx 1.6.2 (Stable) built from source.  My
'resolver 127.0.0.1' line in my config points at a local BIND9 server that
'dig myvhostdomain.com @localhost' confirms is working just fine - so it
isn't a DNS resolver issue as far as I can tell.  The error logs are quiet
other than the warning I got when I added the OCSP stapling options to
'default_server'.

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,257833,257833#msg-257833
M
  • 6 Apr '15
Hello!

On Sun, Apr 05, 2015 at 11:26:19PM -0400, bughunter wrote:

> My web server is intentionally set up to only support virtual hosts and TLS
> SNI.  I know that the latter eliminates some ancient web browsers but I
> don't care about those browsers.
> 
> I want to enable OCSP stapling and it seems to be configured correctly in my
> test vhost (everything else about SSL already works fine - I get an A on the
> Qualys SSL Labs test) and there are no errors or warnings but "openssl
> s_client" always returns:
> 
> "OCSP response: no response sent"
> 
> 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.

> This is a huge problem if I want to enable OCSP for my vhosts because my
> 'default_server' certificate is self-signed (intentional) and running
> 'configtest' with 'ssl_stapling' options on the default server, of course,
> results in a warning:
> 
> "nginx: [warn] "ssl_stapling" ignored, issuer certificate not found"
> 
> Which indicates that it isn't enabled on the default server and subsequent
> s_client tests (after reloading the config, which, of course, issued the
> same warning a second time) on the test vhost confirm that there was still
> no OCSP stapling.  It was a long-shot in the first place.

This warning indicates that you've tried to enable OCSP Stapling 
for a server with a certificate whose issuer certificate cannot be 
found, therefore the "ssl_stapling" directive was ignored for the 
server.  To avoid seeing the warning on each start, consider 
switching off ssl_stapling for the server{} block in question.

> 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.

-- 
Maxim Dounin
http://nginx.org/
B
  • 7 Apr '15
Maxim Dounin Wrote:
-------------------------------------------------------
> Hello!
> 
> On Sun, Apr 05, 2015 at 11:26:19PM -0400, bughunter wrote:
> 
> > My web server is intentionally set up to only support virtual hosts
> and TLS
> > SNI.  I know that the latter eliminates some ancient web browsers
> but I
> > don't care about those browsers.
> > 
> > I want to enable OCSP stapling and it seems to be configured
> correctly in my
> > test vhost (everything else about SSL already works fine - I get an
> A on the
> > Qualys SSL Labs test) and there are no errors or warnings but
> "openssl
> > s_client" always returns:
> > 
> > "OCSP response: no response sent"
> > 
> > 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.
> 
> > This is a huge problem if I want to enable OCSP for my vhosts
> because my
> > 'default_server' certificate is self-signed (intentional) and
> running
> > 'configtest' with 'ssl_stapling' options on the default server, of
> course,
> > results in a warning:
> > 
> > "nginx: [warn] "ssl_stapling" ignored, issuer certificate not found"
> > 
> > Which indicates that it isn't enabled on the default server and
> subsequent
> > s_client tests (after reloading the config, which, of course, issued
> the
> > same warning a second time) on the test vhost confirm that there was
> still
> > no OCSP stapling.  It was a long-shot in the first place.
> 
> This warning indicates that you've tried to enable OCSP Stapling 
> for a server with a certificate whose issuer certificate cannot be 
> found, therefore the "ssl_stapling" directive was ignored for the 
> server.  To avoid seeing the warning on each start, consider 
> switching off ssl_stapling for the server{} block in question.

As I explained, I enabled it as a long-shot.  I was expecting to get a
warning and I did.  I have, of course, disabled it for the default server
section.

> > 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

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,257833,257850#msg-257850
M
  • 7 Apr '15
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?

-- 
Maxim Dounin
http://nginx.org/
B
  • 8 Apr '15
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
...

Also, the Qualys SSL labs test indicates OCSP support in the certificate but
no OCSP stapling for the server.

        ssl_certificate       
/var/www/mydomain.org/mydomain.org.chain.pem;

That contains the signed certificate, intermediate CA cert, and root CA cert
(in that order).  PEM format.

        ssl_certificate_key    /var/www/mydomain.org/mydomain.org.key.pem;

That contains the private key.  PEM format.

        ssl_trusted_certificate    /var/www/root.certs.pem;

That contains the intermediate CA cert and root CA cert (in that order). 
PEM format.

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
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).

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,257833,257906#msg-257906
M
  • 8 Apr '15
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/
N
  • 12 Apr '15
>> 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)

Posted at Nginx Forum: http://forum.nginx.org/read.php?2,257833,257974#msg-257974
M
  • 13 Apr '15
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.

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