On Fri, Jul 07, 2023 at 03:06:52PM +0000, Tristan wrote: > > The ocsp-update option should be between brackets > > /etc/haproxy/ssl/mangadex.dev.pem [ocsp-update on] mangadex.dev > > *.mangadex.dev > > Oh that makes more sense indeed; should have guessed so since other crt-list > bind params used those indeed...
I think that we should at least emit a warning when domain names not containing any dot are found, because IIRC these are not valid for SNI anyway thus there should be no valid reason that an option name is accepted as a server name. > > > - if not, what happens if upon restart/reload of HAProxy the .ocsp > > > file is outdated? will HAProxy aggressively try to get an up-to-date > > > response before starting its listeners or will I be risking ssl > > > issues by enabling OCSP must-staple with it? > > > > The OCSP update mechanism will not block anything, it runs alongside all > > the "regular" HAProxy tasks. > > If I remember correctly, you cannot load outdated OCSP responses so you > > should not face this particular problem. But if you have many > > certificates for which OCSP update was activated and no OCSP response > > was provided, fetching all the missing responses will indeed take some > > time and OCSP stapling will temporarily fail for the given server > > certificates. > > Hmm, I understand why it was decided to go that route, and indeed that is > probably not too too hard to do... Though I can't help wonder if an opt-in > mechanism similar to the server state file would make sense for it? I seem to remember that it's possible to issue a "show ocsp" on the CLI and direct it to a file, but I could be wrong. That's the same way the server-state works by the way. > Either way, it all worked flawlessly within these constraints after putting > the brackets, so that's great. Thanks. Great, thanks for the feedback! Willy
