TLS handshake with IfW API on host 'localhost'

[drapiti]

Receiving this error still on plugin output of a few servers, using both 1.12.3 and 1.13.0 beta.

TLS handshake with IfW API on host 'localhost' (SNI: 'rsmqspus01.xxxxx') port '5668' failed: stream truncated [asio.ssl.stream:1]

[LordHepipud]

Could it be possible that the Icinga Agent certificate is not valid or wasn't signed properly during the initial setup?
This could cause some issues. What happens if you tried to re-create the Icinga Agent certificate?

[drapiti]

Could it be possible that the Icinga Agent certificate is not valid or wasn't signed properly during the initial setup? This could cause some issues. What happens if you tried to re-create the Icinga Agent certificate?

On certain systems we’ve retried to reinstall the agent/certificate and this maybe fixes 30/40% of the cases but not all. Also normal checks/non powershell framework checks work fine on the same systems.

[ispmonsupporto]

I am experiencing the same issues reported by Drapiti in the already open issue.

The error I am encountering is:

TLS handshake with IfW API on host 'localhost' (SNI: 'sbwmop01.xxxxxx') port '5668' failed: stream truncated [asio.ssl.stream:1]
I have tried reinstalling the agent multiple times, but the checks remain in an unknown state. Additionally, I have verified that the certificate is correctly placed in the Trusted Root Certification Authority, and it is present.

I have also noticed some errors in the logs, which I am sharing below:

############################################
_[03/07/2025 11:01:14] Failed to securely establish a communication between this server and the client

A client connection could not be established to this server. This issue is mostly caused by using Self-Signed/Icinga 2 Agent certificates for the server and the client not trusting certificates signed by your trusted CA or setup the client to accept untrusted certificates

Icinga for Windows exception report:

Exception Message:
Exception calling "AuthenticateAsServer" with "4" argument(s): "A call to SSPI failed, see inner exception."

Command Origin:
Internal

Script Line Number:
32933

Exact Position:
At C:\Program Files\WindowsPowerShell\Modules\icinga-powershell-framework\cache\framework_cache.psm1:32933 char:9
$SSLStream.AuthenticateAsServer($Certificate, $false, $TLSPro ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

StackTrace:
at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext funcContext, Exception exception)
at New-IcingaSSLStream(Closure , FunctionContext )

Call Stack:

Command Arguments

---

Get-IcingaExceptionString {ExceptionObject=Exception calling "Authentic...
Write-IcingaEventMessage {EventId=1500, Namespace=Framework, Exception...
New-IcingaSSLStream {Client=System.Net.Sockets.TcpClient, Certifi...
Open-IcingaTCPClientConnection {Client=System.Net.Sockets.TcpClient, Certifi...
New-IcingaForWindowsRESTApi {Port=5668, CertFilter=, Address=, RequireAut...

Object details:

Available :
LocalEndPoint :
RemoteEndPoint :
Handle : 720
Blocking : True
UseOnlyOverlappedIO : False
Connected : False
AddressFamily : InterNetwork
SocketType : Stream
ProtocolType : Tcp
IsBound : True
ExclusiveAddressUse :
ReceiveBufferSize :
SendBufferSize :
ReceiveTimeout :
SendTimeout :
LingerState :
NoDelay :
Ttl :
DontFragment :
MulticastLoopback :
EnableBroadcast :
DualMode :_
############################################

Could you please provide support in resolving this issue?

Thank you in advance.

regards

[drapiti]

@LordHepipud so finally we have a probable cause. It seems that the servers which are not working have a different case in the hostname, so most likely it is not matching with the fqdn which we force lowercase on agent install. Icinga itself comunicates correctly however the icinga powershell framework does not because it may be requiring the actual case which is configured on the specific server. To resolve this issue I would suggest to provide an alias on certificate setup which includes both names in lower and uppercase. Could you please check this?

[LordHepipud]

Thank you for the details. I have tried to reproduce this behavior, but without any success.
The upper/lowercase characters shouldn't count in this scenario.

To test this, I have created an Icinga Agent certificate with a UPPER case hostname and registered that as the Agents name.

Now the certificate does look like this on inspect:

Icinga for Windows Certificate:

Issuer  => CN=Icinga CA
Subject => CN=DEVWIN2022

By checking the hostname, we can see the result:

PS> Get-IcingaHostname
devwin2022

PS> Get-IcingaHostname -ReadConstants
DEVWIN2022

For Icinga for Windows this doesn't matter. The Agent is connecting to the parent node just fine, while the Agent actively calls the Icinga for Windows API directly.

For the moment I have absolutely no clue, on how I can reproduce this issue.

[LordHepipud]

Just out of curiosity - when you re-create the Icinga for Windows certificate by using

Start-IcingaForWindowsCertificateThreadTask;

and restart Icinga for Windows about a minute later - does this issue still persist?

[drapiti]

Start-IcingaForWindowsCertificateThreadTask;

Unfortunately yes, there is no change. What I have noticed is that the majority of servers have OS version < 2016, not all but most with this issue.