OCSP stapling limitations (was Re: [PATCH 0 of 4] OCSP stapling)
mdounin at mdounin.ru
Mon Oct 7 12:37:28 UTC 2013
On Mon, Oct 07, 2013 at 11:29:00AM +0100, Rob Stradling wrote:
> On 06/10/13 11:14, Maxim Dounin wrote:
> >>2. The CA/Browser Forum are defining a "must staple" certificate
> >>extension , which we anticipate that browsers (e.g. ) will
> >>recognize and enforce, by aborting the TLS handshake if a stapled
> >>OCSP response was not sent.
> >I believe it was said more than once that this changes OCSP
> >stapling quite significantly. As of now it's an optimization
> Yes, but it's an optimization technology that seems to work reliably
> in httpd and IIS. ;-)
The "seems" is a key word here, it seems. :)
> >>What work needs to be done to enable Nginx to send a stapled OCSP
> >>response every time (without having to use the "ssl_stapling_file"
> >I tend to think that ssl_stapling_file is a good way to provide an
> >OCSP response if it's required for some reason.
> It works, but doesn't it require the user to regularly download a
> newer OCSP Response for each certificate, update the contents of
> their stapling file(s), and reload Nginx?
> IMHO, this needs to be fully automated, just as it is in httpd and IIS.
> Are you saying that there's zero chance of this ever happening?
Automatic download doesn't make OCSP responses magically available
in all cases. But if an OCSP response is required for a server to
work - a server should refuse to start if it's missing and can't
be downloaded. And this is not something httpd and/or IIS do now,
On the other hand, ssl_stapling_file allows this to be done if
needed. If it is actually needed.
More information about the nginx-devel