ssl_stapling_file does not work with multiple certificates

[John Cook]

NGINX version 1.11.0 introduced the ability to use multiple certificates (ticket #814).

Changeset 6550:51e1f047d15d did not make any changes to enable multiple ssl_stapling_file directives.

As only one ssl_stapling_file directive can be specified, only one specified ssl_certificate will have a stapled OCSP response that matches the serial number of the certificate.

As no checking appears to be done to make sure the serial number in an ssl_stapling_file OCSP response matches that of a certificate, additional certificates will be served with stapled OCSP responses that are not valid for those certificates.

[Maxim Dounin]

The ssl_stapling_file directive instruct nginx to unconditionally return file provided as an OCSP staple. It is not expected to do any checks, and works exactly as intended. Avoid using it if it doesn't work for you.

[John Cook]

People use ssl_stapling_file because otherwise nginx doesn't always staple OCSP responses (ticket #812).

With dual ECDSA and RSA certificates (described as a feature in version 1.11.0) ssl_stapling_file cannot be used because, if the file contains the OCSP response for the ECDSA certificate, RSA connections will be served an invalid stapled response.

If the directive is working as intended, then the documentation should advise against its use with multiple certificates, especially if OCSP Must-Staple is used in the certificates.

[Scott Helme]

I'd like to open this ticket again to look at updating the ssl_stapling_file directive file so it can be specified multiple times like the ssl_certificate and ssl_certificate_key directives can.

Right now ssl_stapling_file lets you specify one OCSP response but you can have multiple certificates, which results in it breaking a potentially large amount of the time.

[jsha@…]

I'm an engineer from Let's Encrypt, and I'd also like to lend my support to fixing this bug, as it leads to support issues with our customers. Specifically, as watfordjc says, reliable OCSP stapling requires using ssl_stapling_file. However, ssl_stapling_file is incompatible with dual ECDSA and RSA certificates.

OCSP stapling and dual ECDSA/RSA certificates are both important steps forward in the security of the WebPKI, and we'd like people to easily be able to use them both at the same time. Unfortunately, this bug means that people have to choose one or the other.

From a configuration perspective, another way to achieve the goal would be add a property of the ssl_certificate directive that points to an ssl_stapling_file for that specific certificate. That way Nginx can preserve the property that the contents of ssl_stapling_file are passed through without examination.

[Maxim Dounin]

As previously explained, this is not a bug. Everything works as intended and as documented.

Always stapling OCSP responses was never a goal of OCSP stapling implementation, as OCSP stapling by itself is an optimization technique. Trying to use ssl_stapling_file to make stapling "reliable" may not be a good idea in the first place.

If this causes support issues, it might worth adding a warning during configuration parsing / testing, patch below:

# HG changeset patch
# User Maxim Dounin <mdounin@mdounin.ru>
# Date 1494530764 -10800
#      Thu May 11 22:26:04 2017 +0300
# Node ID 1d3e7775bb95367690ff283004671ccd95f38f74
# Parent  e694391dc6ad86b42012b4905f42eb80a26f0452
SSL: warning on stapling file used with multiple certificates.

The ssl_stapling_file directive provides a single response to be used
for OCSP stapling.  In most cases this is not going to work when using
multiple certificates, hence the warning (ticket #990).

diff --git a/src/http/modules/ngx_http_ssl_module.c b/src/http/modules/ngx_http_ssl_module.c
--- a/src/http/modules/ngx_http_ssl_module.c
+++ b/src/http/modules/ngx_http_ssl_module.c
@@ -791,6 +791,11 @@ ngx_http_ssl_merge_srv_conf(ngx_conf_t *
 
     if (conf->stapling) {
 
+        if (conf->stapling_file.len && conf->certificates->nelts > 1) {
+            ngx_log_error(NGX_LOG_WARN, cf->log, 0,
+                          "using ssl_stapling_file for multiple certificates");
+        }
+
         if (ngx_ssl_stapling(cf, &conf->ssl, &conf->stapling_file,
                              &conf->stapling_responder, conf->stapling_verify)
             != NGX_OK)

[Scott Helme]

I know it's currently working as intended which is why I said "I'd like to open this ticket again to look at updating the ssl_stapling_file directive".

Reliable OCSP Stapling is going to become more and more essential, especially with the introduction of features like OCSP Must-Staple to try and address issues with revocation as a whole, this bug will hold that back: ​https://scotthelme.co.uk/tag/ocsp-must-staple/

Why would using ssl_stapling_file to reliably OCSP staple not be a good idea? It seems like the most reliable way to do things given some of the current limitations like nginx not priming the OCSP cache when the process starts. If we can provide the appropriate file on disk it will also survive restarts. This can all be handled with an independent daemon that simply produces the file/s for nginx to use.

All of that aside, it doesn't seem logical that we can provide two certificates but only an OCSP response for one of them, resulting in a large amount of failure.

[jsha@…]

Always stapling OCSP responses was never a goal of OCSP stapling implementation, as OCSP stapling by itself is an optimization technique.

I agree that OCSP stapling has been an optimization technique for most of the time it's existed. However, with the publication of the TLS Feature Extension (aka Must-Staple) in October 2015 (​https://tools.ietf.org/html/rfc7633), OCSP stapling has additionally become a security mechanism, and is part of an overall effort in the Web PKI to make revocation checking more reliable. Also, Certificate Transparency (​https://www.certificate-transparency.org/, RFC 6962) provides a mechanism for additional security information to be provided in a stapled OCSP response.

So, you're right, Nginx is definitely working as designed, but PKI participants are working on making revocation more secure, and improving the reliability of OCSP stapling is a big part of the effort, which is why we're requesting this change.

[Maxim Dounin]

So, from the above I conclude that support issues is not a concern, but rather Must-Staple is. Must-Staple is an attempt to turn OCSP Stapling into something it was never designed to be. It is not a surprise that it requires quite a different approaches in many places, and doesn't work.

I don't really think that adding support for multiple ssl_stapling_file is a good solution for Must-Staple. And it is not clear why there should be many ssl_stapling_file but not many ssl_stapling, ssl_stapling_responder, and so on - so this solution looks inconsistent. On the other hand, introducing additional notion of "certificate properties" looks clearly inconsistent with current nginx configuration approach.

Reclassifying this as a feature request and leaving open for now.

[Scott Helme]

Must-Staple is an attempt to turn OCSP Stapling into something it was never designed to be.

I'm not sure I follow here, Must-Staple is designed to turn OCSP Stapling into what it was always supposed to be, a reliable revocation checking mechanism. What's your view on what OCSP Stapling is supposed to be?

I don't really think that adding support for multiple ssl_stapling_file is a good solution for Must-Staple.

The only other solution is to ensure Nginx has a robust OCSP Stapling implementation and takes care of things like priming the cache, renewing the cached response, validating the response, etc... How else could we implement Must-Staple reliably?

And it is not clear why there should be many ssl_stapling_file but not many ssl_stapling, ssl_stapling_responder, and so on - so this solution looks inconsistent.

If you are providing the OCSP Staples as a file then the ssl_stapling_responder directive shouldn't be needed as the server already has the response. As for ssl_stapling I guess you could enable this on a per certificate basis if you wanted, though I'm not sure why you would!

[Maxim Dounin]

Replying to stackoverflow.com/users/1414715/scott-helme:

Must-Staple is an attempt to turn OCSP Stapling into something it was never designed to be.

I'm not sure I follow here, Must-Staple is designed to turn OCSP Stapling into what it was always supposed to be, a reliable revocation checking mechanism. What's your view on what OCSP Stapling is supposed to be?

As already said in comment:5, OCSP stapling is an optimization technique to save resources and latency for clients. Quoting ​RFC 6066:

This extension allows for such information to be sent in the TLS handshake, saving roundtrips and resources.

Must-Staple tries to turn it into a mandatory mechanism, basically identical to short-lived certificates. This has very different requirements from OCSP stapling though - as it always needs to be able to return something to work properly, while OCSP stapling can fall back to other revocation checking mechanisms on the client at any time if a response is not available for some reason by simply returning no OCSP response.

[plinss@…]

Let me add my support for allowing multiple staple files. Regardless of the opinion of Must-Staple, it's here, CAs support it and browsers support it. Nginx's current behavior of not priming the OCSP cache leaves servers that have Must-Staple certificates broken on first use for supporting browsers after a restart. This issue blocks addressing that with an external OCSP staple management tool.

So long as it won't be arbitrarily rejected due to opinions of the value of Must-Staple, I'd be happy to take a crack at writing a patch to address this.

[plinss@…]

Patch submitted:
​http://mailman.nginx.org/pipermail/nginx-devel/2017-July/010254.html