netxml-ups will fail on https with UPS selfsigned certificates (Eaton at least)

[pablomarquesmendez]

config: [UPS-test123] driver = netxml-ups port = https://admin:password@10.20.30.40 desc = "UPS-test123"

[nut@nut ~]$ usr/sbin/netxml-ups -D -a UPS-test123 Network UPS Tools - network XML UPS 0.44 (2.8.0) Warning: This is an experimental driver. Some features may not function correctly.

0.000000 [D1] debug level is '1' 0.000367 [D1] using https://10.20.30.40 port 443

0.633268 Connectivity test: Server certificate verification failed: certificate issued for a different hostname, issuer is not trusted

[jimklimov]

Is that self-signed for a particular host name? Is it in DNS (or /etc/hosts)? Can you check if using that name instead of IP address helps?

Otherwise, I would assume your system key trust store (OS-dependent detail) used by OpenSSL or NSS (depending on your NUT build) would need to trust that certificate (or corporate CA that issued it) and then NUT would. I don't remember there being any provisions for emergency trusts, other than normal systemic setup.

[pablomarquesmendez]

It is just a selfsigned cert created when the UPS is first configured. Can NUT be configured to trust (of rather ignore) the cert?

[jimklimov]

CC @aquette @dzomaya

[akelleher]

I am also encountering an issue with the factory self-signed certs on my Eaton 9PX with Network-M2. (sorry to bump ancient issue, but it's still open...)

[xxxxxx@xxxxxxxxx ~]$ sudo upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - network XML UPS 0.44 (2.8.0)
Warning: This is an experimental driver.
Some features may not function correctly.

Connectivity test: Server certificate verification failed: issuer is not trusted
Driver failed to start (exit status=1)

Is there any way to disable cert validation in this case?

[jimklimov]

Thanks for reminding about this. Not sure quickly about options for this, but can you try adding that cert to system trust store (very much OS-dependent, but likely you put a PEM file into a special directory and run a script/service to compile many such files into one big trust store), so the underlying libcurl would just trust it properly?

[aquette]

NM2 are not compatible with XML/HTTP. Only older NMC. NM2 and later can use snmp-ups. The other driver, for REST+MQTT, is proprietary :(

[akelleher]

Thanks.

I made partial progress with adding the UPS cert to the system trust store. However, sounds like if NM2 is only compatible with snmp-ups then that isn't a thread worth pursuing. (It wasn't clear to me on the compatibility page that 9PX network card only refers to the old network card - maybe that is worth clarifying.)

When you say "The other driver, for REST+MQTT, is proprietary" - is that something that exists, but just can't be distributed and we have to go to Eaton to get? Or is the proprietary-ness blocking development entirely?

I did previously try snmp-ups but saw these errors. My network card is on 3.0.5. Unsure if this is a difference between the expected MIB and what's being reported by the recent UPS firmware, or something else.

[root@deployment_controller ~]# upsdrvctl start
Network UPS Tools - UPS driver controller 2.8.0
Network UPS Tools - Generic SNMP UPS driver 1.21 (2.8.0)
Detected Eaton 9PX 6000 on host xx.xx.xx.xx (mib: pw 0.104)
[eatonups] unhandled ASN 0x81 received from 1.3.6.1.4.1.534.1.4.4.1.4.1.0
[eatonups] unhandled ASN 0x80 received from 1.3.6.1.4.1.534.1.7.3
[eatonups] unhandled ASN 0x80 received from 1.3.6.1.4.1.534.1.7.4
[eatonups] unhandled ASN 0x80 received from 1.3.6.1.4.1.534.1.6.2.0
[eatonups] unhandled ASN 0x81 received from 1.3.6.1.4.1.534.1.6.3.0
[eatonups] unhandled ASN 0x81 received from 1.3.6.1.4.1.534.1.4.4.1.2.1.0
[eatonups] unhandled ASN 0x81 received from .1.3.6.1.4.1.534.1.10.6.0
[eatonups] unhandled ASN 0x81 received from .1.3.6.1.4.1.534.1.10.7.0
[eatonups] unhandled ASN 0x81 received from 1.3.6.1.4.1.534.1.4.4.1.3.1.0
[eatonups] unhandled ASN 0x81 received from 1.3.6.1.4.1.534.1.4.4.1.4.1.0
[eatonups] unhandled ASN 0x80 received from 1.3.6.1.4.1.534.1.3.4.1.2.0
[eatonups] unhandled ASN 0x80 received from 1.3.6.1.4.1.534.1.3.4.1.3.0
[eatonups] unhandled ASN 0x81 received from 1.3.6.1.4.1.534.1.3.2.0
[eatonups] unhandled ASN 0x80 received from 1.3.6.1.4.1.534.1.5.3.1.2.0
[eatonups] unhandled ASN 0x81 received from 1.3.6.1.4.1.534.1.5.3.1.2.1.0
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.1.12.2.1.1.0
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.1.12.2.1.1.0
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.1.12.2.1.2.0
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.1.2.1.4.0
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.2.3.1.3.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.2.3.1.1.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.2.2.1.6.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.2.2.1.5.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.2.2.1.7.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.2.2.1.8.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.3.3.1.3.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.3.3.1.1.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.3.2.1.6.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.3.2.1.5.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.3.2.1.7.0.1
[eatonups] unhandled ASN 0x80 received from .1.3.6.1.4.1.534.6.8.1.3.2.1.8.0.1

I am on network-m2 firmware 3.0.5.

[aquette]

These snmp-ups errors are not, just non existing oids not well caught, and that I should have fixed a decade ago. Still, no issue.

As for the proprietary driver, just political decisions. You may ask through customer support, to help me once I restart that topic...