[Nut-upsdev] Common NUT client auth setup

Mon Mar 16 18:56:21 GMT 2026

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20260316/24e565e2/attachment-0001.htm>