[Nut-upsdev] Common NUT client auth setup

Mon Mar 16 20:02:31 GMT 2026

I would also hope that this burden will not become mandatory, and some coders implement. 

For many, it's just one more thing to break, and serves little purpose . . . (Our UPS gear is on a private, non routed network, for instance so this would simply introduce the opportunity for cert expirations and such . . . )

Options are great . . . . mandates are *NOT*!

- Tim

On March 16, 2026 2:56:21 PM EDT, Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> wrote:
>Well, regarding features I propose to pass via some `nutauth.conf` files,
>this is about using settings that are already available in (mostly)
>`upsmon.conf` for the client side, varying based on whether the build uses
>an NSS or OpenSSL backend.
>This partially mirrors the server side settings for `upsd.conf`.
>
>Ability for client auth via certs is in the tree (for NSS at least) for a
>long time, but only upsmon had the endpoints attached to configuration
>options and calls made into `libupsclient`.
>
>I believe it originated from the fact that NUT reads like those with `upsc`
>are inherently anonymous (maybe something can/should be done about that
>too/instead), so sites that want to use SSL to protect their engineering
>network from any sort of revealing their hardware and its state to
>unpermitted clients, would use CERTVERIFY to only allow the channel for
>whatever use (including auth/anon in the layer above that, before it comes
>to that) to programs that have the correct client cert. Probably this
>implies some sort of private/corporate CA.
>
>Program-specific setup of crypto stuff is common in the web server world I
>had a lot of experience with, whether it is Apache, or Nginx, or one of
>many Java web-app servers. These typically configure the trusted credential
>locations (cert with public key and CA chain, private key, possibly the
>generally-trusted corporate CA to issue requests to nearby servers) and do
>not use a system-wide location (or at best fall back to using it if the
>dedicated store lacks some info). It is similar with CI systems that can
>store such credentials and let them be used per remote system they use (and
>trust) for a particular job; a neighboring job or a different run of this
>one should not necessarily have access to that system if it is not allowed
>to use the credential (e.g. to avoid tests aimed at one SUT to bombard an
>unrelated system by mistake).
>
>I think the NUT approach is somewhat modeled after those examples, like a
>web server and potentially trusted/trusting clients constrained to a small
>population with access given on a need-to-know basis (perhaps NOT trusting
>servers/clients from corporate-wide or world-wide public CA is the point of
>an engineering network setup with its own CA for equipment like networked
>UPSes, NMCs, ILOMs and stuff like that). I'm not a regular sysadmin
>anymore, but back in the days I did set up eng networks like that for
>dayjob and its customers, so would have been a prime user for this feature.
>
>I agree that building a binary with multiple SSL backend support is not
>likely to find real users, other than CI runners that can test all those
>code paths in one build... which in itself is not too bad a reason, would
>probably shave a few hours off the build matrix :)
>
>Jim
>
>
>On Mon, Mar 16, 2026 at 4:06 PM Kelly Byrd <kbyrd at memcpy.com> wrote:
>
>> Another vote for "don't need client certs as auth"
>> In my experience, it's rarely used. It's one of these "neat in theory, but
>> nobody uses it and when they do they hate the specifics" things.
>>
>> I've run into more than one working for different company that offered
>> some API service. In all cases, the customers that wanted it had an
>> internal requirement to use client certs. In all cases, the folks on the
>> ground on the client side hated it, didn't really understand client certs
>> and what they needed to do, and got mad at our (the service provider's)
>> folks for various things. Reading between the lines, the whole interaction
>> felt like they just wanted a shared secret. They wanted us to generate a
>> thing, then give it to them and be done and never change it. Or the more
>> clued in ones understood good password management practices, but setting up
>> their own cert process was never easy. Every time there was a certificate
>> expiration, we were expected to warn them (we did, the ignored the 3mo,
>> 1mo, 2wk emails) and then the customer had to find the "one person" who
>> knew how certs worked, with the customer getting mad we couldn't magically
>> extend the expiration date of the certificate they handed us a year ago.
>>
>> At one place, we figured out customer A's requirement was: If a vendor
>> offers client cert for auth, customer A must use that. So in a regular
>> sync, someone on our side hinted we could disable client cert auth for
>> their account so it wasn't available to them. They jumped at it.
>>
>>
>>
>> On Mon, Mar 16, 2026 at 6:33 AM Greg Troxel via Nut-upsdev <
>> nut-upsdev at alioth-lists.debian.net> wrote:
>>
>>> Jim Klimov via Nut-upsdev <nut-upsdev at alioth-lists.debian.net> writes:
>>>
>>> >   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.
>>>
>>> This is not really about nut.  Having client certificates and using them
>>> for authentication is very unusual.  Existing practice is almost
>>> entirely to have a server have a certificate, and to have that
>>> verifiable via pkix norms, either because it's part of the normal public
>>> PKI (mozilla rootcerts, ish) or because a private CA has been
>>> configured.
>>>
>>> The normal path is to use username/password, openidconnect, or some
>>> other auth scheme within the TLS session after the client is sure they
>>> are talking to the real server.  Or maybe even Kerberos.
>>>
>>> Extending this to certificates for client use crosses into rare
>>> practice.  LE in particular is no longer issuing certs usable for this,
>>> as I understand it, so you're likely in private PKI territory.
>>>
>>> I would say the first question is who actually trying to use client
>>> certs, and does this make any sense to put time into.  My reaction is
>>> that it's work and complexity for no practical usage.
>>>
>>> >   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:
>>> > https://github.com/networkupstools/nut/issues/3331
>>>
>>> Do you really believe that there are actual nut users that are wanting
>>> to restrict pkix validation to only certain CAs, or engage in pinning
>>> for nut, while not wanting to have the same kind of restricted CA set
>>> system-wide?  I find that surprising.
>>>
>>> But, adding ability to configure that as a client does not seem harmful,
>>> other than the general costs of more lines of code for zero users.  Is
>>> there existing practice for other programs that connect via TLS, in
>>> terms of common interfaces and config options?  It would be good to do
>>> it the conventional way.
>>>
>>> >   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)?
>>> > https://github.com/networkupstools/nut/issues/3332
>>>
>>> I hold that
>>>
>>>   - almost all uses [of any widely-used program] will be via a packaging
>>>     system
>>>
>>>   - when packaging
>>>
>>>     + one wants to include dependencies that result in the program
>>>       working better or doing more things.
>>>
>>>     + one wishes to avoid dependencies that take up space, require more
>>>       building, or cause cognitive load from their presence, when they
>>>       do not materially improve how the program works for the user
>>>
>>>   - I have no memory of encountering a program that links with more than
>>>     one of openssl, nss, gnutls, etc.  Yes, there are programs that can
>>>     choose at build time, and sometimes pkgsrc has a build option to
>>>     choose, for people that care, but the default is usually openssl.  I
>>>     have never found a package that links with both.
>>>
>>>
>>> I don't think this makes sense.  It's a lot of complexity, and packaging
>>> systems aren't going to build with multiple ssl libs at the same time.
>>> People that want to choose something else can build -- it's not that
>>> hard, and if it is, fixing that is more important -- either by hand or
>>> via a packaging option.
>>>
>>> Before proceeding, I think we should be hearing from other packagers,
>>> and specifically whether, if nut could be built with both openssl and
>>> nss, they would configure their package to *by default so it is the
>>> standard distributed binary* to depend on both.
>>>
>>> My prediction is that nobody will say that, but I hope there is a
>>> packager on this list Debian, FC, suse, arch?, gentoo, FreeBSD, OpenBSD,
>>> homebrew, macports, and probably something else.  (I'm unclear on
>>> packaging for a large number of GNU/Linux systems that don't derive from
>>> Debian, Fedora, or suse).
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Nut-upsdev mailing list
>>> Nut-upsdev at alioth-lists.debian.net
>>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>>
>> _______________________________________________
>> Nut-upsdev mailing list
>> Nut-upsdev at alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20260316/692aa400/attachment.htm>