OCSP does not work with $ssl_server_name

[leon.mailhardener.com@…]

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.

[Maxim Dounin]

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.

[leon.mailhardener.com@…]

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

[Maxim Dounin]

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.

[leon.mailhardener.com@…]

Hello mdounin, thank you for the clarification! I hope this ticket may help others who encounter this situation :-)