Opened 5 years ago

Closed 5 years ago

#1830 closed defect (duplicate)

OCSP must staple fails with multi-domain certificates

Reported by: Sam Bull Owned by:
Priority: major Milestone:
Component: nginx-core Version: 1.14.x
Keywords: ocsp, staple Cc:
uname -a: Linux sam-server 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5 (2019-06-19) x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.14.2
built with OpenSSL 1.1.1a 20 Nov 2018 (running with OpenSSL 1.1.1c 28 May 2019)
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-sWHVb6/nginx-1.14.2=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_gzip_static_module --without-http_browser_module --without-http_geo_module --without-http_limit_req_module --without-http_limit_conn_module --without-http_memcached_module --without-http_referer_module --without-http_split_clients_module --without-http_userid_module --add-dynamic-module=/build/nginx-sWHVb6/nginx-1.14.2/debian/modules/http-echo

Description

If using the same certificate across multiple server blocks (e.g. subdomains), and the certificate sets the must staple flag, then several server blocks end up inaccessible for long durations, for example, when using Let's Encrypt.

It seems that the current behaviour is to cache the OCSP responses related to each server block, meaning that these multiple server blocks, which are using the same cert, each manage the OCSP responses separately.

It also seems that Let's Encrypt only allows a request for OCSP staples from the same source once for a given period of time (maybe 1 hour).

Result: After starting/reloading Nginx, the first domain to be visited successfully gets the OCSP staple, but the other domains will be rejected and the browser will get a security error (for maybe 1 hour) until the CA timeout allows a second request to get through. (The long timeout also results in frequent blackouts over time with renewals, not just at startup).

Proposed solution: Cache OCSP staple responses per certificate, not per server block.

This completely destroys the functionality of OCSP must staple for multi-domain sites, making it impossible to use.

Change History (1)

comment:1 by Maxim Dounin, 5 years ago

Resolution: duplicate
Status: newclosed

Each server block uses its own SSL context with independent settings, such as ssl_staple, ssl_staple_verify, ssl_trusted_certificate and so on. As such, sharing a certificate with OCSP stapling information between multiple server blocks is not trivial and not currently implemented.

Note well that nginx supports OCSP stapling - and no OCSP stapling information during an SSL handshake is not a problem for OCSP stapling. But nginx does not support "must staple" - because regardless of configuration it is possible that no OCSP response will be returned during an SSL handshake. Avoid using "must staple" in certificates unless you are going to provide OCSP responses yourself using the ssl_stapling_file directive.

Closing this as a duplicate of #812, which is about improving compatibility with "must staple" without using ssl_stapling_file.

Note: See TracTickets for help on using tickets.