> On 2023-06-02 (Fr.) 22:42, Lukas Tribus wrote: > > I suggest we make it configurable on the bind line like other ssl > > options, so it will work for the common use cases that don't involve > > crt-lists, like a simple crt statement pointing to a certificate or a > > directory. > >
That's what we've done in the first place, but I decided to remove it because I was not happy with the architecture. And once you have something like this, you have to keep the configuration compatibility for the next versions and then you are stuck with something awful. My concern here, is that the ocsp-update option was never a "bind" option, it's a feature which applies on the internal storage part, which is not directly exposed in the configuration. So for example if you use the same certificate on multiple bind lines, setting "ocsp-update on" on one line and "ocsp-update off" on the other doesn't make sense. It is the same problem we have with the "key" option, which applies on the storage. We are well aware on the current limitations of this model, and we are working on it, that's why it landed in the crt-list for now, but that will evolve! > > It could also be a global option *as well*, but imho it does need to > > be a bind line configuration option, just like strict-sni, alpn and > > ciphers, so we can enable it specifically (per frontend, per bind > > line) without requiring crt-list. Sure, that what considered for the evolution of the feature ! -- William Lallemand
