Mensaje de aviso recurrente "InsecureRequestWarning" en el log del plugin de Z-Wave

[carles]

Buenas tardes…

Recientemente he configurado Apache2 para acceder por https con un certificado SSL. Además cualquier tráfico http es dirigido a https.
Lo que es apache y Jeedom en general funcionan así perfectamente, pero en el log del plugin de Z-Wave (log openzwave) aparece desde entonces un mensaje de aviso cada poco tiempo:

/usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:849: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings InsecureRequestWarning)

Primero intenté seguir las indicaciones que indica el propio mensaje en la url Advanced Usage - urllib3 2.0.0.dev0 documentation pero al poco tiempo vi que no tenía mucho sentido, puesto que como decía, el certificado está bien instalado y el servidor apache responde correctamente.

Al cambiar el nivel de log para que sea más detallado ahora sí se ve cuál es el problema:

[2020-06-06 16:10:52][DEBUG] : Starting new HTTPS connection (1): 127.0.0.1:443
/usr/lib/python2.7/dist-packages/urllib3/connectionpool.py:849: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
InsecureRequestWarning)
[2020-06-06 16:10:52][DEBUG] : https://127.0.0.1:443 "POST /plugins/openzwave/core/php/jeeZwave.php?apikey=5RaupcutUgndpUPgAfV85wXyvqVttmS1 HTTP/1.1" 200 0

Es decir, el plugin está intentando acceder vía https al localhost, con una petición https://127.0.0.1:443.
Evidentemente, el certificado no es válido para 127.0.0.1 si no para el dominio correspondiente.
Por tanto, cualquier petición https://127.0.0.1 devuelve un mensaje de aviso.

Mi pregunta es por qué el pluguin realiza una petición https://127.0.0.1:443… dado que estamos hablando del localhost ¿no es igualmente seguro y bastaría con una petición http://127.0.0.1?

He probado con apache mod_rewrite crear una regla para redirigir el tráfico https://127.0.0.1 a una dirección https://servidor.dominio.com pero no consigo evitar el problema, me imagino que la petición inicial a https://127.0.0.1 ya dispara la verificación del certificado antes de que se tranforme en https://servidor.dominio.com.
Por eso creo que la solución está a nivel del plugin, para que haga las peticiones a http://127.0.0.1.

Agradecería cualquier sugerencia…

[carles]

Bueno… al final parece que he encontrado una solución temporal, por que probablemente en la próxima actualización del plugin habrá que volver a revisar el código y aplicarla.

La solución va en línea de lo que indicaba en mi mensaje incial: hacer que la petición sea a http://127.0.0.1:80 en lugar de a https://127.0.0.1:443
(Que entiendo es segura incluso sin SSL por qué se realiza en el entorno del localhost. ¡Agradecería cualquier comentario en contra de este argumento!)

Para ello hay que modificar el siguiente script PHP de openzwave: html/plugins/openzwave/core/class/openzwave.class.php

Hay que alterar la línea 289 (en la versión que tengo instalada, 2020-05-26 01:01:50), en la función deamon_start().
El problema está en el uso que se hace de la API de Jeedom con el método network::getNetworkAccess. Tal como se usa en el scritp se devuelve el valor « https://127.0.0.1:443/plugins/openzwave/core/php/jeeZwave.php », lo que provoca el mensage de aviso descrito, al intentar acceder via https a una dirección no « cubierta » por el certificado ssl.

Comando original:

$callback = network::getNetworkAccess('internal', 'proto:127.0.0.1:port:comp') . '/plugins/openzwave/core/php/jeeZwave.php';

Comando modificado:

$callback = 'http://127.0.0.1:80' . '/plugins/openzwave/core/php/jeeZwave.php';

Como decía, el comando original devuelve la URL https://127.0.0.1:443/plugins/openzwave/core/php/jeeZwave.php.
Mientras que el comando modificado devuelve http://127.0.0.1:80/plugins/openzwave/core/php/jeeZwave.php

Con ello se consigue que el acceso al localhost no utilice el mecanismo SSL y por tanto no generará ningún aviso en el uso de un certificado SSL.