[Nut-upsdev] TLS support in NUT
roger at rogerprice.org
Sun Jun 13 10:42:10 BST 2021
On Sat, 12 Jun 2021, Jim Klimov wrote:
> On a related note, we have got a pull request
> https://github.com/networkupstools/nut/pull/1043 submitted today, to add a way
> of limiting the use of obsoleted ciphers in a NUT deployment. Reviews and
> comments in the PR are welcome :)
I would like to comment more generally on TLS support in NUT. The pull request
is part of a project move to continue supporting up to date encryption of
communications, but it also raises more general questions:
1) The NUT project supports two TLS implementations: OpenSSL and NSS. The
administrative setups in upsd.conf and upsmon.conf for the two differ. In both
cases it is accepted that the NUT system administrator will be using commercial
certificates, with all the administrative complexity that commercial
certificates imply. Should this be the case?
2) For the experimental TLS shims upsdTLS.py and upsmonTLS.py, and for the
experimental client UPSmon.py, I took the position that the NUT project should
help the system administrator as much as possible in the certificate management.
The required certificates are provided by script mkNUTcert.py which produces a
pair of self-signed certificates specifically for use by NUT. These provide
better security, and are simpler to manage: the script knows where the files go.
There is no hashing, no CSR or other complexity. It seems to me that the NUT
project could usefully move to "self-signed certificates preferred".
3) Does the NUT project need two implementations of TLS?
4) I hope that in the long term, if the proposed RFC is accepted, port nut/3493
will remain "TLS on request using command STARTTLS", but port ups/401 will be
5) Is it possible to configure upsd.conf as follows:
LISTEN <interface> 3493
LISTEN <interface> 401
and listen on two ports? I havn't tried it.
More information about the Nut-upsdev