Hello,
since I've updated to 7.0.1 my Service.Check and NetworkService.Status DCI returns 5 for https sites, which is I believe some cert trust error?
Was there any change that could cause this?
thank you
Hi,
5 is not specifically a certificate error. For http/https checks the agent returns it for any libcurl failure except DNS and connection errors, so a timeout looks the same as a TLS problem. Service.Check and NetworkService.Status run the same code, so both returning 5 is one failure, not two.
There are no changes in the check code between 6.2.6 and 7.0.1. What did change is the Windows agent build - new toolchain and new bundled libraries, libcurl included. Is this a Windows agent, or deb/rpm? And which version did you upgrade from?
To see the real error, set DebugLevel = 6 in nxagentd.conf, restart the agent and post these two lines from the agent log:
cURL initialized (version: ...)
NetworkServiceStatus_HTTP(...): call to curl_easy_perform failed (NN: ...)
Quick test for certificate trust:
NetworkService.Status(https://your.site, verify-peer=false)
If this returns 0, then it's trust. As a workaround you can point the agent to a CA bundle in PEM format:
[netsvc]
CA = /path/to/ca-bundle.pem
Hello,
thank you, updgrade was from 6.2.5, this is a windows agent, this is what i get in the log.
Its an onprem site with cert from a public PKI (DigiCert root, appears valid in a browser)
NetworkServiceStatus_HTTP(https://*fqdn*): call to curl_easy_perform failed (60: SSL certificate OpenSSL verify result: self-signed certificate in certificate chain (19)) Quote from: Alex Kirhenshtein on November 02, 2026, 03:48:39 PMHi,
5 is not specifically a certificate error. For http/https checks the agent returns it for any libcurl failure except DNS and connection errors, so a timeout looks the same as a TLS problem. Service.Check and NetworkService.Status run the same code, so both returning 5 is one failure, not two.
There are no changes in the check code between 6.2.6 and 7.0.1. What did change is the Windows agent build - new toolchain and new bundled libraries, libcurl included. Is this a Windows agent, or deb/rpm? And which version did you upgrade from?
To see the real error, set DebugLevel = 6 in nxagentd.conf, restart the agent and post these two lines from the agent log:
cURL initialized (version: ...)
NetworkServiceStatus_HTTP(...): call to curl_easy_perform failed (NN: ...)
Quick test for certificate trust:
NetworkService.Status(https://your.site, verify-peer=false)
If this returns 0, then it's trust. As a workaround you can point the agent to a CA bundle in PEM format:
[netsvc]
CA = /path/to/ca-bundle.pem
Yes, this comes from a change in the Windows build. The libcurl bundled with the 7.0 agent uses OpenSSL for TLS and doesn't read the Windows certificate store, so unless a CA bundle is configured the agent has no trusted roots at all. Error 19 means your server sends the DigiCert root along with the chain and the agent doesn't trust it. A server that doesn't send the root fails with error 20 instead. The browser checks the same chain against the Windows store, which is why it looks valid there.
7.0.2, released today, doesn't change this.
Workaround is to give the agent a CA bundle. Mozilla's bundle from https://curl.se/docs/caextract.html (https://curl.se/docs/caextract.html) includes the DigiCert roots:
# nxagentd.conf, top level - applies to netsvc and other https requests made by the agent
CACertificates = C:\NetXMS\etc\cacert.pem
Restart the agent after the change.
Can you please post the "cURL initialized (version: ...)" line from the agent log? It's logged on startup with DebugLevel 3 or higher, and it shows the TLS backend, which will confirm this.
Hello - Aye this has caused us issues as well with the notification drivers on our Windows install.
Telegram & our SMTP one both say
curl_easy_perform() failed (60: SSL certificate OpenSSL verify result: self-signed certificate in certificate chain (19))
SMTP one we can bypass this by adding "VerifyPeer=false" to the config as a temp fix (It's Office 365) but Telegram we can't.
If we run "openssl s_client -connect api.telegram.org:443" on the machine it returns with
Verify return code: 19 (self-signed certificate in certificate chain)
Running
openssl s_client -connect api.telegram.org:443 -CAstore org.openssl.winstore:
Forces it to load in the windows certificate store & then passes all ok.
So we've done what is in the post above
Downloaded the Mozilla ca bundle and imported into our NetXMS Server config (netxmsd.conf) & the agent config on the server (nxagentd.conf) , but still fails on both drivers
(It appears to be being loaded in)
2026.11.04 11:34:48.438 *I* [config ] +- CACertificates
2026.11.04 11:34:48.438 *I* [config ] value: C:\NetXMS\etc\cacert.pem
Telegram uses a Godaddy cert if it helps at all
Curl version is
2026.11.04 11:34:48.456 *D* [init.curl ] cURL initialized (version: libcurl/8.21.0 OpenSSL/3.5.9 zlib/1.3.1.1-motley WinLDAP)
Hi,
CACertificates is an agent parameter. netxmsd doesn't read it, the config dump just prints every key in the file. The server has no equivalent: notification drivers rely on libcurl defaults, and in the 7.0.0-7.0.2 Windows builds libcurl has no trusted roots at all.
It's fixed in 7.0.3 (https://github.com/netxms/netxms/issues/3869 (https://github.com/netxms/netxms/issues/3869)). libcurl is now built with Schannel as the default TLS backend, so it uses the Windows certificate store, same as your -CAstore org.openssl.winstore: test. You don't have to wait for the release: libcurl.dll from that build works as a drop-in replacement on 7.0.2, you can get it here: https://cloud.radensolutions.com/s/x3j62JbWPqsNtXJ (https://cloud.radensolutions.com/s/x3j62JbWPqsNtXJ)
Stop the NetXMS server and agent services, keep a copy of the old C:\NetXMS\bin\libcurl.dll, copy the new one over it and start the services again. After that the cURL initialized (version: ...) line in the log should include Schannel, and you can remove VerifyPeer=false from the SMTP channel and CACertificates from both configs.
The next upgrade overwrites the DLL, which is fine because 7.0.3 ships the same one. The same file works for 64-bit Windows agents too: put it in the agent's bin directory instead of setting CACertificates.
Hi there
Ah thank you for such a quick response - Perfect yes that makes sense.
I have copied the new ddl in & tested - All works perfectly now.
Kind regards & thanks again for all your work on this product.