[Nut-upsdev] TLS support in NUT

Manuel Wolfshant wolfy at nobugconsulting.ro
Sun Jun 13 19:53:43 BST 2021

On June 13, 2021 9:02:46 PM GMT+03:00, Tim Dawson <tadawson at tpcsvc.com> wrote:
>Let's not overlook the simple fact that a lot of deployments are behind
>secure firewalls, on secure networks, and on servers and lans that no
>users have access to (physical ormotherwise), and thus have negligible
>security requirements beyond what the environment already provides.
>Yes, the more advanced stuff may have validity and use some places, but
>the ability to stand up nut without that added layer of complexity has
>a lot of value as well . . . 
Absolutely correct. 

>(I run one of those environments, and frankly, would likely instantly
>cease to upgrade of all this was rammed down my throat and not a

Same here

>The idiotic deliberate breakage of Java in that many older
>systems can no longer have a functional network console, even on a
>secure network, is the perfect example of what *NOT* to do!)
Incidentally I fight for 2 weeks trying to obtain again control over an IBM chassis which requires an old Java

> The end
>user should *ALWAYS* have the choice - never a mandate!
My thoughts exactly ! Thank you for phrasing it out loud, Tim.

>On June 13, 2021 11:06:35 AM CDT, Manuel Wolfshant
><wolfy at nobugconsulting.ro> wrote:
>>On 6/13/21 3:36 PM, Jim Klimov via Nut-upsdev wrote:
>>> Haven't got many ideas on this today, preoccupied with other 
>>> house-work, but can share a couple :)
>>> Regarding two implementations - I believe NSS and OpenSSL are
>>> differently and/or are (initially were?) available non-overlapping
>>> different OSes. A quick googling now showed that they both were 
>>> actually provided under different licenses over different releases
>>> years.
>>> As long as NUT consumes "some way to secure the packets" and does
>>> really care what that way is, leaching onto one or another library
>>> a decent choice (and better than using just one and offering nothing
>>> on platforms that do not support it).
>>> I *think* the different ways of configuration apply to some features
>>> only supported by (integration with?) one of those libraries, but 
>>> can't vouch for that OTOH :)
>>> Regarding self-signed certs vs. private (corporate) CA vs.
>>> - technically they are all the same, politics and setup policies and
>>> responsibilities differ. Back in my sys-admining days, we had a 
>>> private CA with in-house scripting for openssl for engineering gear 
>>> (UPSes, PDUs, IPMIs and equivalents) which gave some measure of 
>>> security (encrypted comms) for many devices with some ease of setup 
>>> (one cert - engCA - to add trust for in a browser or similar
>>> Having an easy self-signed secure setup for small deployments (e.g. 
>>> home LAN) is certainly a welcome bonus - when several computers are 
>>> protected by one UPS and one upsd, but I'd expect (maybe biased)
>>> any sort of small office or larger deployment with more than a
>>> of NUT clients and/or servers would go for a centralized cert setup.
>>> It is not too hard to conjure up, with many free and commercial
>>> available to orchestrate depending on the scale they would need.
>>> As for listening on several interfaces and/or ports from a single
>>> instance, can't quickly check, so would fathom a guess that NUT 
>>> codebase did not have a reason to bother yet to support that. 
>>> Otherwise, your points (4) and (5) make sense and are "doable" 
>>> generally, after some effort :)
>>1. There are miriad of scripts written on top of openssl and certutil 
>>that allow implementing a CA and issuance of certificates, with
>>probably leading the lot (and usage basically consists of running 
>>./build-ca followed by ./build-key ( for v2 ) and equivalent
>>passed to the only script that easy-rsa v3 consists of ). Even f-droid
>>provides one for android, if I am not mistaken. I really do not see
>>need for yet another set of scripts that reimplement the wheel, 
>>especially as the existing programs provide a full stack of tools 
>>implementing all the stages a certificate can have, from creating a CA
>>to revoking a certificate.
>>2. nut can be very nicely wrapped behind stunnel if a point to point 
>>connection between master and slaves is needed. Other tools also
>>are reliable and well known, tested and vetted. Therefore, from my
>>of view, even if the python shim approach is smart and nice, I do not 
>>see it as being really needed. A link to stunnel and an example
>>in the docs would do just as well. With all due respect, the shim idea
>>looks to me like a "not invented here" approach. To be clear: I am not
>>opposed to it but I would certainly not use it when "yum install
>>/ apt install stunnel" are available.
>>3. Last but not least, for anyone with low to moderate knowledge, 
>>letsencrypt takes minutes to setup and use and has the advantage of
>>requiring anything but running their script every 3 months.

More information about the Nut-upsdev mailing list