Opened 5 years ago
Closed 5 years ago
#1830 closed defect (duplicate)
OCSP must staple fails with multi-domain certificates
| Reported by: | 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.
Each server block uses its own SSL context with independent settings, such as
ssl_staple,ssl_staple_verify,ssl_trusted_certificateand 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_filedirective.Closing this as a duplicate of #812, which is about improving compatibility with "must staple" without using
ssl_stapling_file.