opnsense
www/nginx: fix ocsp_stapling
Hi
are you sure you want to rename the http.conf file?
I don’t think that now the ssl_trusted_certificate directive is mandatory for the work of the ssl_stapling_verify, and especially for the ssl_stapling to work (there may be certain circumstances (ocsp requestor-responder trust issues?) when such a directive is necessary, but not in the simplest cases).
setting ssl_trusted_certificate to {{ single_servername }}.pem doesn't seem to make sense to me either, sorry.
is it possible to return to the original issue? What does “OCSP stapling not possible” mean and what errors are there in nginx logs?
This would be for example the chain of trust of Let's Encrypt certificates with a depth of minimum two. Usually Nginx will check the first but that's not enough for Let's Encrypt.
I even had to define "TLS: Verify Depth" = 2 to make the reverse proxy setup work with Let's Encrypt certs in place.
The "simplest" setup like self signed certs will not be sufficient enough.
@53c70r Sorry, I'm not sure I'm following this..
TLS: Verify Certificate \ TLS: Verify Depth is from Upstream settings
https://github.com/opnsense/plugins/blob/85e4a256df0936fd4f15dcf23b781c8d078d4994/www/nginx/src/opnsense/service/templates/OPNsense/Nginx/location.conf#L205-L213
and is not relevant to the possible problem at hand?
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_stapling_verify
For verification to work, the certificate of the server certificate issuer, the root certificate, and all intermediate certificates should be configured as trusted using the [ssl_trusted_certificate](http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_trusted_certificate) directive.
Without the commit this will not be true furthermore stapling_verify will not work per definition.
Yeah the option:
Specifies a file with trusted CA certificates in the PEM format used to verify client certificates and OCSP responses if ssl_stapling is enabled.
With Firefox now, and Chrome in April-July 2024 enabling the verification, the TLS handshake will not finish for these browsers unless the option is set when OCSP stapling is enabled.
Without the commit this will not be true furthermore stapling_verify will not work per definition
not quite like that, imo.
As you yourself noted from the docs, the ssl_trusted_certificate directive may be of particular importance for the operation of the ssl_stapling_verify. (and you propose to enable it even if the ssl_staplig directive is enabled without ssl_stapling_verify).
You propose a {{ single_servername }}.pem as the value of the ssl_trusted_certificate directive, which contradicts your quote from the docs: the ssl_trusted_certificate should contain a root certificate. {{ single_servername }}.pem should NOT contain root cert..
And perhaps you are missing the point that the OPNSense contains a trusted roots (at least) certificates bundle for the OpenSSL library (/etc/ssl/cert.pem) and the nginx documentation is valid for all types of installations, including those that do not contain trusted roots bundle (and therefore for (in some cases) ocsp verifying may require a dedicated trust-list) here are, among other things, the author’s comments about the work of verification, his dissatisfaction with the OpenSSL ocsp verify interface ;) and the need for this directive if you are ready to try to understand Russian (https://mailman.nginx.org/pipermail/nginx-ru/2018-September/061447.html)
Sorry, I repeat: I am not saying that this directive is absolutely useless. It just seems to me that you are proposing to implement it incorrectly and that perhaps there is a way to solve the "OCSP stapling not possible without ssl_trusted_certificate" in another way. so it would be great to go back to the original issue and see the errors in the nginx logs.
@DooMMasteR sorry, you mean Chrome planing to stop fetching ocsp on its own in case of an incorrect stapled ocsp?
PS: I tried to enable both ssl_stapling/ssl_stapling_verify directives for sites with an LE certificates on OPN Nginx. and it worked without ssl_trusted_certificate
There is always the option for a nicer fix, true, but at this point, this commit makes it work.
Without it, it just does not work.
Firefox does not seem to care if you also staple the Root certificate and it just ignores it, but if you don't have any configured at all it aborts the handshake and that 100% breaks functionality.
@fichtner what is the best way to get the short chain via acme-client?
I only see the keys and full chains in /usr/local/etc/nginx/key/.
@DooMMasteR I'm still not sure what problem this request should solve, sorry: there is no clear description of the nginx config and errors on the client side and in the nginx logs. maybe we are talking about the problem of "must staple server cert & nginx lazy stapling" @53c70r if we talking about LE cross-signing issues, acme-client plugin not support preferred chain option. but Lets Encrypt is planning to stop providing cross-signed certs (finaly) https://letsencrypt.org/2023/07/10/cross-sign-expiration.html
There are no nginx error logs it's Firefox throwing this error, try to access redmine.ucware.com for example.
Ohh yeah, sorry @fichtner, that must have been lost in comms.
This is not an issue with NGINX complaining.
It is an issue where, if not configured, Firefox is not able to access the sites anymore and soon Chrome won't be either.
Hi. Sorry for delay. Spent a day trying to reproduce the problem - add an Must-Staple wildard LE certificate and tried changing the nginx config and Trust settings to get a similar result. Unsuccessfully. Everything works as expected. A "no resolver defined to resolve r3.o.lencr.org while requesting certificate status" warning appears in the nginx general log (does not affect stapling). If any problems arise (such as a delay in the responder's response), a corresponding error appears in the nginx log. Is there a chance that some special config is being used?
It is no NGinx issue, it is just an issue of Firefox not being able to open the site. @53c70r has posted a hostname that resolves well and works perfectly fine in Chrome but won't work in FIrefox unless the option is set in NginX
hm. if you set (and you are) your server Cert as a OCSP Must-Staple and dont staple ocsp response then Firefox is doing the right thing (https://datatracker.ietf.org/doc/html/rfc7633#section-4.3.3). The questions is: do you realy need Must Staple Cert and why nginx not stapling ocsp response (based on empty nginx error log i would think that stapling is not enabled for this site somehow)
Strange behavior. I checked the nginx traffic for stapling, it really did not staple for the mentioned domains the gui had verify and stapling checkboxes on but the nginx config was not generated correct, i just checked after using "nginx -T". Just deleted the generated configs and let nginx regenerate all by unchecking and checking the staple config check box. After that it generated the correct settings and now it works.
It seams that the addition of trusted_certs actually just causes a regeneration of the config for the one site, i just did this to all broken http server configs now and everything works smoothly.
Some state while config generation seams to be off.
config generation errors are possible, for example, when deleting referenced certificates from System-Trust and there is no server certificate in the nginx/key dir (couse the config references a chain file that cannot be created), but I thought that we added debugging info to the setup script in 1.32 ver so thus some warning\error messages should appear in the nginx general log (besides General and Backend logs)
according to the setting https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_trusted_certificate this should contain the root and the intermediate certificates. This means hat this file is wrong as it also contains the host certificate and most likely not the entire chain (only the certificates known to the OPNsense UI). Not sure if this could also point to the system store?
Also, does that interfere with ssl_client_certificate?
