Opened 11 years ago

Closed 9 years ago

#425 closed defect (fixed)

ocsp stapling may send expired response

Reported by: Ryanne Fox Owned by:
Priority: minor Milestone:
Component: nginx-core Version: 1.3.x
Keywords: Cc:
uname -a: Linux hostname 2.6.18-348.16.1.el5 #1 SMP Wed Aug 21 04:00:25 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.4.3
built by gcc 4.1.2 20080704 (Red Hat 4.1.2-54)
TLS SNI support enabled
configure arguments: --user=nginx --group=nginx --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/var/run/ --lock-path=/var/lock/subsys/nginx --with-http_ssl_module --with-http_spdy_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-mail --with-file-aio --with-mail_ssl_module --with-ipv6 --with-openssl=/builddir/build/BUILD/openssl-1.0.1e --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-debug


In some conditions, Nginx when configured with 'ssl_stapling on' may send an expired response to a client. When a client receives this invalid response, it aborts the handshake, per RFC6066.

Clients requesting an OCSP response and receiving an OCSP response in
a "CertificateStatus" message MUST check the OCSP response and abort
the handshake if the response is not satisfactory with
bad_certificate_status_response(113) alert. This alert is always

Better behavior from Nginx would be to continue the handshake without including a CertificateStatus message, so the client may attempt to retrieve a valid response itself.

A suggestion from Kaspar Brand, looking at this issue from Mozilla (, was:

A flaw in the OCSP stapling code in nginx, it seems:

(should check for an expired response first, and not call ngx_ssl_stapling_update only after having handed out the current/old response)

Change History (5)

comment:1 by Maxim Dounin, 11 years ago

Status: newaccepted

The code in question checks if it's time to obtain new OCSP response (which happens in an hour after a OCSP response was obtained), not certificate status response expiration. The fact that an expired OCSP response was served indicate that a site had no requests for a long time to trigger a reload process (or it wasn't able to load new response due to some problems) and the response was expired. Additional check should be added to make sure expired responses are not served to clients in such cases.

comment:2 by Maxim Dounin, 10 years ago

Just a side note. I tend to think that following quoted RFC6066 requirement might not be a good idea in real life. As far as I can tell, this can be easily used to DoS a server if an OCSP response signature isn't checked, and this seems to be the case at least in nginx (by default, as this requires additional root certificates to be configured, at least with previous OpenSSL versions) and in Apache (it looks like there is no OCSP response signature validation in the OCSP stapling code at all).

comment:4 by Maxim Dounin <mdounin@…>, 9 years ago

In 6893a1007a7c7e91e0afeb9c537c5bcecf937faa/nginx:

OCSP stapling: avoid sending expired responses (ticket #425).

comment:5 by Maxim Dounin, 9 years ago

Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.