On Sat, 3 Jun 2023 at 14:30, William Lallemand <[email protected]> wrote: > 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.
I understand, I just think that those are tradeoffs that need to be made. We could document it well, and trigger configuration warnings or alerts (depending on severity) for conflicts. Not providing bind lines configuration support to avoid conflicting configurations in a small number of cases, while not supporting the most commonly used configuration does not seem like a good tradeoff. Note that I'm not saying conflicting configuration warnings for this are trivial to implement or anything like that. I don't actually know; I'm just saying this sounds like in this case the cure may be worse than the disease. > 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! Great, thank you! Lukas
