<div dir="auto">Hello all,<div dir="auto"><br></div><div dir="auto">  While finalizing the NUT v2.8.5 release, I've stumbled on some issues and delayed them for the next release cycle(s). One of these is the realization that very few NUT clients are fully SSL capable (as in saying who they are and what servers they trust). Due to this most users probably can not enable CERTVERIFY on servers, as only upsmon of all stock NUT clients would be able to talk to them.</div><div dir="auto"><br></div><div dir="auto">  I have a vague idea to define a configuration file format (with default locations that clients running with sufficient permissions could read out of the box) which could convey SSL-related nuances as well as user/pass for SETVAR/INSTCMD, all potentially per-server. Feedback welcome at <a href="https://github.com/networkupstools/nut/issues/3329">https://github.com/networkupstools/nut/issues/3329</a></div><div dir="auto"><br></div><div dir="auto">  Similarly, further ideas include somehow equalizing the abilities of OpenSSL and Mozilla NSS backends, so the choice is more of licensing philosophy than technical constraints: <a href="https://github.com/networkupstools/nut/issues/3331">https://github.com/networkupstools/nut/issues/3331</a></div><div dir="auto"><br></div><div dir="auto">  And taking it a bit further (licensing preferences permitting), why not build-in both backend supports and let the run-time choose which to use (at least useful while features differ)? <a href="https://github.com/networkupstools/nut/issues/3332">https://github.com/networkupstools/nut/issues/3332</a></div><div dir="auto"><br></div><div dir="auto">WDYT?</div><div dir="auto"><br></div><div dir="auto">Jim Klimov</div><div dir="auto"><br></div></div>