<div dir="ltr">Another vote for "don't need client certs as auth"<br>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.<br><br>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. <br><br>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.<br><br><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Mar 16, 2026 at 6:33 AM Greg Troxel via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net">nut-upsdev@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jim Klimov via Nut-upsdev <<a href="mailto:nut-upsdev@alioth-lists.debian.net" target="_blank">nut-upsdev@alioth-lists.debian.net</a>> writes:<br>
<br>
> While finalizing the NUT v2.8.5 release, I've stumbled on some issues and<br>
> delayed them for the next release cycle(s). One of these is the realization<br>
> that very few NUT clients are fully SSL capable (as in saying who they are<br>
> and what servers they trust). Due to this most users probably can not<br>
> enable CERTVERIFY on servers, as only upsmon of all stock NUT clients would<br>
> be able to talk to them.<br>
<br>
This is not really about nut. Having client certificates and using them<br>
for authentication is very unusual. Existing practice is almost<br>
entirely to have a server have a certificate, and to have that<br>
verifiable via pkix norms, either because it's part of the normal public<br>
PKI (mozilla rootcerts, ish) or because a private CA has been<br>
configured.<br>
<br>
The normal path is to use username/password, openidconnect, or some<br>
other auth scheme within the TLS session after the client is sure they<br>
are talking to the real server. Or maybe even Kerberos.<br>
<br>
Extending this to certificates for client use crosses into rare<br>
practice. LE in particular is no longer issuing certs usable for this,<br>
as I understand it, so you're likely in private PKI territory.<br>
<br>
I would say the first question is who actually trying to use client<br>
certs, and does this make any sense to put time into. My reaction is<br>
that it's work and complexity for no practical usage.<br>
<br>
> Similarly, further ideas include somehow equalizing the abilities of<br>
> OpenSSL and Mozilla NSS backends, so the choice is more of licensing<br>
> philosophy than technical constraints:<br>
> <a href="https://github.com/networkupstools/nut/issues/3331" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/issues/3331</a><br>
<br>
Do you really believe that there are actual nut users that are wanting<br>
to restrict pkix validation to only certain CAs, or engage in pinning<br>
for nut, while not wanting to have the same kind of restricted CA set<br>
system-wide? I find that surprising.<br>
<br>
But, adding ability to configure that as a client does not seem harmful,<br>
other than the general costs of more lines of code for zero users. Is<br>
there existing practice for other programs that connect via TLS, in<br>
terms of common interfaces and config options? It would be good to do<br>
it the conventional way.<br>
<br>
> And taking it a bit further (licensing preferences permitting), why not<br>
> build-in both backend supports and let the run-time choose which to use (at<br>
> least useful while features differ)?<br>
> <a href="https://github.com/networkupstools/nut/issues/3332" rel="noreferrer" target="_blank">https://github.com/networkupstools/nut/issues/3332</a><br>
<br>
I hold that<br>
<br>
- almost all uses [of any widely-used program] will be via a packaging<br>
system<br>
<br>
- when packaging<br>
<br>
+ one wants to include dependencies that result in the program<br>
working better or doing more things.<br>
<br>
+ one wishes to avoid dependencies that take up space, require more<br>
building, or cause cognitive load from their presence, when they<br>
do not materially improve how the program works for the user<br>
<br>
- I have no memory of encountering a program that links with more than<br>
one of openssl, nss, gnutls, etc. Yes, there are programs that can<br>
choose at build time, and sometimes pkgsrc has a build option to<br>
choose, for people that care, but the default is usually openssl. I<br>
have never found a package that links with both.<br>
<br>
<br>
I don't think this makes sense. It's a lot of complexity, and packaging<br>
systems aren't going to build with multiple ssl libs at the same time.<br>
People that want to choose something else can build -- it's not that<br>
hard, and if it is, fixing that is more important -- either by hand or<br>
via a packaging option.<br>
<br>
Before proceeding, I think we should be hearing from other packagers,<br>
and specifically whether, if nut could be built with both openssl and<br>
nss, they would configure their package to *by default so it is the<br>
standard distributed binary* to depend on both.<br>
<br>
My prediction is that nobody will say that, but I hope there is a<br>
packager on this list Debian, FC, suse, arch?, gentoo, FreeBSD, OpenBSD,<br>
homebrew, macports, and probably something else. (I'm unclear on<br>
packaging for a large number of GNU/Linux systems that don't derive from<br>
Debian, Fedora, or suse).<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div>