On Fri, Jun 02, 2023 at 09:55:25PM +0200, Willy Tarreau wrote:
> On Fri, Jun 02, 2023 at 01:29:31PM +0300, Matthias Fechner wrote:
> > Am 02.06.2023 um 04:13 schrieb Shawn Heisey:
> > > @Matthias I have no idea whether crt-list can load all certs in a
> > > directory like crt can.  If it can't, then you will probably need a
> > > script for starting/restarting haproxy that generates the cert list
> > > file.  If you wantthat script to be automatically run whenever someone
> > > does `systemctl restart haproxy`, you could use the ExecStartPre and
> > > ExecReloadPre options in a systemd service file to run your script.
> > > 
> > > My certificate files contain the server cert, the issuer cert, the
> > > private key, and DH PARAMETERS that are unique to that cert.
> > 
> > maybe adding a global configuration parameter to enable ocsp retrieval for
> > all certificates?
> 
> Initially during the design phase we thought about having 3 states:
> "off", "on", "auto", with the last one only enabling updates for certs
> that already had a .ocsp file. But along discussions with some users
> we were told that it was not going to be that convenient (I don't
> remember why, but I think that Rémi and/or William probably remember
> the reason), and it ended up dropping "auto".
>

Because at the time it was an option not to activate the ocsp-update,
but to activate the ocsp, so it could be activated by letting a .ocsp
file, or by doing it automatically by retrieving it, but that was super
confusing so we decided to just have an on/off option to activate it.

> Alternately maybe instead of enabling for all certs, what would be
> useful would be to just change the default, because if you have 100k
> certs, it's likely that 99.9k work one way and the other ones the other
> way, and what you want is to indicate the default and only mention the
> exception for those concerned.

Indeed that could be a way to do it.

-- 
William Lallemand

Reply via email to