Currently the C libupsclient (and C++ libnutclient by virtue of massive copy-paste with adaptations) seem to only support one SSL context, which is linked to client identity, trusted certificate stores, etc. - meaning a single NUT client process written in C or C++ even with multiple-connection support (upsmon, upslog, nut-scanner, CGI upsstats, wmNut...) can currently connect only to NUT data servers under the same management domain (same root CA, one client identity for all servers, etc.)
During work on PR #3435 for issue #3329 it was found that the constraint may be somewhat artificial, a shortcut taken by original SSL/TLS implementation by using one global variable (and not a list/array thereof) for the context. Other (OpenSSL-backed) clients like Perl and Python bindings, and Java jNut, wrap context specifics into OOP classes and many instances can co-exist.
This issue is about investigating whether it is possible to compartmentalize work with SSL contexts with both OpenSSL and Mozilla NSS backends, and extend the code (ideally backwards-compatibly) to allow registration of multiple unique contexts. As a new feature, this may be limited to methods which deal with authconf data types to (extensibly) pass the trust stores and identification credentials involved, added in PR #3435.
Currently the C libupsclient (and C++ libnutclient by virtue of massive copy-paste with adaptations) seem to only support one SSL context, which is linked to client identity, trusted certificate stores, etc. - meaning a single NUT client process written in C or C++ even with multiple-connection support (
upsmon,upslog,nut-scanner, CGIupsstats, wmNut...) can currently connect only to NUT data servers under the same management domain (same root CA, one client identity for all servers, etc.)During work on PR #3435 for issue #3329 it was found that the constraint may be somewhat artificial, a shortcut taken by original SSL/TLS implementation by using one global variable (and not a list/array thereof) for the context. Other (OpenSSL-backed) clients like Perl and Python bindings, and Java jNut, wrap context specifics into OOP classes and many instances can co-exist.
This issue is about investigating whether it is possible to compartmentalize work with SSL contexts with both OpenSSL and Mozilla NSS backends, and extend the code (ideally backwards-compatibly) to allow registration of multiple unique contexts. As a new feature, this may be limited to methods which deal with authconf data types to (extensibly) pass the trust stores and identification credentials involved, added in PR #3435.