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>
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>
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.