Change in certificate trust in v7?

szabolcs

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

Alex Kirhenshtein

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

szabolcs

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))

@alk said in Change in certificate trust in v7?:

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

Alex Kirhenshtein

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 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.

KSAIT

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)

Alex Kirhenshtein

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). 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

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.

KSAIT

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.

szabolcs

Thank you for the fix.
Bit offtopic, any way to clean up my business service ?

NetXMS Forum

Change in certificate trust in v7?