[Nut-upsdev] Common NUT client auth setup

[Jim Klimov]

To alleviate the fears and defuse the FUD, none of this is going to
suddenly become mandatory :)

Looking at git, the SSL support generally is in-tree since before 2010 (SVN
import); NSS and certificate validation since 2011 or so. Did not become in
any way mandatory for over 15 years, and adding another way to configure it
(or at all use it in a non-default manner, in some NUT clients) should not
change that.

What I think is, that specifically lack of holistic support for this among
default NUT clients is what could have blocked adoption of such setup,
should anyone have wanted it ("hey, I can uber-protect my upsd-upsmon
comms, but now I can't query with upsc!") So this effort is really about
tying up loose threads that are already there, and finishing incomplete
code.

Specifically in the NUT use-case, for client code dealing with shutdown
during a site-wide outage (e.g. someone's `upssched` script looking via
`upsc` how bad the battery charge is instead of just letting `upsmon` open
the Kingston valves), I think relying on actively networked authentication
is a no-go, everything it needs at least in this situation should be within
the box (maybe cached in some kerberos client, but not relying on
back-and-forth with a powered-off remote server through a powered-off
switch) :)

Jim


On Mon, Mar 16, 2026 at 9:43 PM 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:
>
> > 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.
>
> I think we should step back and ask what the requirement is, and then
> think about how to meet it and how that solution would go over with
> users.
>
> I can see a "want to restrict commands to authorized users".  One can do
> that with
>
>   client certs
>   username/password
>   SASL in general, perhaps openidconnect
>   kerberos/gssapi
>   etc.
>
> If you look at email, I am aware of very little use of client certs.
>
>
> I hink it's a huge and incorrect leap to go from "want to control access
> to upsc" to "we should use client certs".
>
> > 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).
>
> A good argument for credentials of some sort, not for client certs in
> particular.
>
> > 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.
>
> Wanting to use PKI but only trust your own CI is a particular approach
> that some would want.  That's fine.  But it's a leap to think that
> anyone who wants any access control wants to run a private CA.
>
> > 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 :)
>
> except that it wouldn't be testing what users actually build and run.
>
> _______________________________________________
> 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/20260317/a09e2a83/attachment.htm>