I am trying to get the Prometheus driver working with a Prometheus server that is listening on port 443 using https. Because it is an internal company system the certificate is self signed. The connection is failing with Error : 12030. [ERROR_WINHTTP_CONNECTION_ERROR].
I have been trying to debug the driver and it looks like the http query is being constructed in an object that is returned from a "before" Qaction:
object[] httpCommand = new object[] { "http", new[] { requestType, sIp, credentials[0], credentials[1], httpheaders, timeoutMs }, new[] { httpcommand } };
return httpCommand;
so I can see how it is being built, however I cannot see any code that is sending the request to the prometheus server as I'm not sure how the mechanism that sends the returned object from the Qaction works. I suspect it may be failing due to not ignoring warnings about self signed certificates, but not sure how to debug any further. If this is the case then I am hoping that there will be a flag that can be set in the httpCommand object to ignore the warning. Does anybody know how I can get this information or get more debug info on the failure?
Hi,
Like Tom mentions, this is making use of a multi-threaded timer.
The meaning of the different error codes can be found here .
For "ERROR_WINHTTP_CONNECTION_ERROR" there is described "The connection with the server has been reset or terminated, or an incompatible SSL protocol was encountered. For example, WinHTTP version 5.1 does not support SSL2 unless the client specifically enables it".
If there would be an issue with the certificate, I would be expecting an ERROR_WINHTTP_SECURE_***** error being returned instead, like ERROR_WINHTTP_SECURE_FAILURE or ERROR_WINHTTP_SECURE_INVALID_CERT as those are the errors the are typically pointing to issues with the certificate.
A Wireshark capture would indeed shed some more light on what is going wrong when trying to set up the connection.
Regards,
[Full request URI: http://xxx.xxxx.xxx.xxx:443/grfprom/api/v1/query?%5D
note – I have replaced the ip address with xxx.xxx.xxx.xxx
Can you edit the element and for the HTTP connection specify in the “IP address/host” field the https prefix? E.g. https://127.0.0.1 (with 127.0.0.1 needs to be replaced with the original IP that was present). If that would not work, please also verify that the protocol.xml supports https (e.g. check the version history comments, or check the QAction 1 if the GetIp method contains a case to deal with https) as that was not supported by the connector in the past.
yes, that has worked, thanks for your help.
Thank you for confirming, I’m glad to hear that the problem is fixed.
Hi Mark,
HTTP communication in the connector is implemented using multithreaded timers. How that works is explained here: https://docs.dataminer.services/develop/devguide/Connector/AdvancedMultithreadedTimersHttp.html.
I'm not aware of a way to bypass the certificate check when using HTTPS. That would probably also be very insecure.
You mentioned that you are using self-signed certificates. What you could try to do is importing it on the DataMiner server that is hosting the element, so that it becomes trusted by that system. The following page explains how you can do that: https://techcommunity.microsoft.com/t5/windows-server-essentials-and/installing-a-self-signed-certificate-as-a-trusted-root-ca-in/ba-p/396105.
If it still doesn't work you could try to debug this further using Wireshark to see what the device actually responds and where exactly it fails.
I just did a wireshark capture and the http request shows: [Unencrypted HTTP protocol detected over encrypted port, could indicate a dangerous misconfiguration.]. Is it possible that Dataminer is not requesting https? as when I do a similar request to the endpoint through a browser with https I can see the TLS handshake. How do I configure a multitreaded timer to use https? Thanks