#1813 closed defect (invalid)
OCSP does not work with $ssl_server_name
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | nginx-core | Version: | 1.17.x |
Keywords: | OCSP, $ssl_server_name | Cc: | |
uname -a: | Linux 5.0.0-15-generic #16-Ubuntu SMP Mon May 6 17:41:33 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux | ||
nginx -V: |
nginx version: nginx/1.17.0
built by gcc 8.3.0 (Ubuntu 8.3.0-6ubuntu1) built with OpenSSL 1.1.1c 28 May 2019 TLS SNI support enabled configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/run/nginx.pid --lock-path=/var/lock/nginx.lock --user=www-data --group=www-data --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-openssl=../openssl-1.1.1c --with-openssl-opt=enable-ec_nistp_64_gcc_128 --with-openssl-opt=no-nextprotoneg --with-openssl-opt=no-weak-ssl-ciphers --with-openssl-opt=no-ssl3 --with-pcre=../pcre-8.43 --with-pcre-jit --with-zlib=../zlib-1.2.11 --with-file-aio --with-threads --with-http_gunzip_module --with-http_gzip_static_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_v2_module --with-cc-opt='-g -O3 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' |
Description
We have a multi-tenant setup with TLS enabled. We use the $ssl_server_name
variable file name feature introduced in 1.15.9 to load the certificates at runtime based on SNI:
server { ssl_certificate /path/$ssl_server_name/fullchain.pem; ssl_certificate_key /path/$ssl_server_name/privkey.pem; ssl_stapling on; ssl_stapling_verify on; # note: $ssl_server_name substitution not supported here? ssl_trusted_certificate /path/le-chain.pem; }
Variable substitution doesn't seem to work for ssl_trusted_certificate
, this isn't a problem for us since all our certificates are from letsencrypt, so we just use a fixed path to a LE trust chain. But we believe the documentation should clarify this, the config file validation should catch this, or support for variable ssl_trusted_certificate
name should be added.
We also noticed that OCSP stapling does not work at all when using $ssl_server_name
for the certificate filename. We observed that Nginx does not serve the OCSP reponse. We did try 'priming' the cache by requesting the page a couple of times, but there was no change. We did not observe any log entries related to OCSP.
To rule out any other configuration mistakes, we copied the configuration and used a fixed path for ssl_certificate
and ssl_certificate_key
, with that config OCSP works just fine.
We are not sure if OCSP stapling is even supposed to work with variable certificate filenames. So this is either a bug or a request to clarify the documentation.
Change History (4)
comment:1 by , 5 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:2 by , 5 years ago
Hello mdounin, thank you for your quick reply. However, this was not a support question, but a bug report.
Again, using this scenario:
server { ssl_certificate /path/$ssl_server_name/fullchain.pem; ssl_certificate_key /path/$ssl_server_name/privkey.pem; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /path/le-chain.pem; }
In this scenario we expect OCSP stapling to work, because all our certificates use the same trust chain (let's encrypt). But it does not.
So, whether this is a bug or not depends on the question: is OCSP stapling supposed to work with variable certificate paths?
If OCSP stapling is supposed to work in this scenario
Then this is clearly a bug
Expected behaviour: nginx sends the OCSP data during TLS handshake
Observed behaviour: nginx does not send the OCSP data during TLS handshake
If OCSP stapling is not supposed to work in this scenario
This is not a bug, but a request to improve the documentation, logging and configuration validator
Expected: Configuration validator should warn/error if trying to enable ssl_stapling
in combination with $ssl_server_name
Observed: Configuration validator passes this scenario
Expected: Log file should warn/error when ssl_stapling
is enabled, but not supported due to $ssl_server_name
Observed: Log file contains no entries related to OCSP stapling
Expected: Documentation should clarify that OCSP is not supported when using $ssl_server_name
Observed: Documentation does not mention lack of OCSP support when using $ssl_server_name
comment:3 by , 5 years ago
OCSP stapling is not supposed to work in this scenario, as certificates are loaded from disk for each SSL handshake, and no stapling information is available for these freshly loaded certificates. If you want OCSP stapling to work, avoid using dynamic certificate loading.
comment:4 by , 5 years ago
Hello mdounin, thank you for the clarification! I hope this ticket may help others who encounter this situation :-)
By default, variables are not supported. As long as variables are supported in a particular parameter of a particular directive, this is explicitly documented. Variables are not supported in the
ssl_trusted_certificate
directive - you can, however, configure multiple trusted root certificates in the file pointed by the directive.If you have further questions on how to configure nginx and what is supported, consider using support options available.