# Client TLS handshake failed - Operation canceled

**URL:** <https://community.icinga.com/t/client-tls-handshake-failed-operation-canceled/13154>\
**Category:** Icinga 2\
**Tags:** tls, satellite, api\
**Created:** [January 22, 2024, 1:19pm UTC](https://community.icinga.com/t/client-tls-handshake-failed-operation-canceled/13154 "2024-01-22T13:19:36Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![HExSM](https://community.icinga.com/letter_avatar_proxy/v4/letter/h/bbce88/32.png) [@HExSM](https://community.icinga.com/u/HExSM)\
**Post date:** [January 22, 2024, 1:19pm UTC](https://community.icinga.com/t/client-tls-handshake-failed-operation-canceled/13154/1 "2024-01-22T13:19:37Z")

</div>

I want to connect an icinga satellite to an icinga master. The icinga satellite is running on-prem and the icinga master on a vps. The on-prem network and the vps network are connected by a Site-to-Site IPSec tunnel.

I use the icinga2 node wizard to connect the satellite to the master. When I enter the request ticket, I this error messages:

```auto
critical/cli: Could not fetch valid response. Please check the master log.
critical/cli: Failed to fetch signed certificate from master 'icingam01.subnet.vcn.oraclevcn.com, 5665'. Please try again.

```

This is the log from the master:

```auto
[2024-01-22 13:50:22 +0100] information/ApiListener: New client connection from [::ffff:xxx.xxx.xxx.83]:42136 (no client certificate)
[2024-01-22 13:50:22 +0100] information/ApiListener: No data received on new API connection from [::ffff:xxx.xxx.xxx.83]:42136. Ensure that the remote endpoints are properly configured in a cluster setup.
[2024-01-22 13:50:41 +0100] critical/ApiListener: Client TLS handshake failed (from [::ffff:xxx.xxx.xxx.83]:51632): Operation canceled

```

I saw that there are other posts in this forum about this problem. So I already checked the time on the satellite with `TZ=UTC date`, which is the same on both systems.

I also tried to do a connection with `openssl s_client`. There I get

```auto
...

---
SSL handshake has read 3443 bytes and written 447 bytes
Verification error: self-signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self-signed certificate in certificate chain)

...

```

Does anybody has an idea how to solve the issue?

- Version used: `r2.14.2-1` (master and satellite)
- Operating System and version: `Ubuntu 22.04.3 LTS (Jammy Jellyfish)` (master and satellite)
- Enabled features: `api checker debuglog icingadb mainlog notification` (master)

---

<div class="post-metadata">

**Author:** ![HExSM](https://community.icinga.com/letter_avatar_proxy/v4/letter/h/bbce88/32.png) [@HExSM](https://community.icinga.com/u/HExSM)\
**Post date:** [January 29, 2024, 3:58pm UTC](https://community.icinga.com/t/client-tls-handshake-failed-operation-canceled/13154/3 "2024-01-29T15:58:18Z")

</div>

I installed another icinga master instance on the same network as the satellite. When I connect the satellite through the node wizard it’s working fine.

I compared the `openssl s_client` output and there indeed is a difference:

vps master:  
`Verify return code: 19 (self-signed certificate in certificate chain)`

on-prem master:  
`Verify return code: 18 (self-signed certificate)`

I guess that’s why the handshake is not working.  
But what is causing this error?

Edit: Nevermind… I guess that’s because the on-prem master was a “test satellite” before. So it’s certificate was was not signed by the ca.crt and this means there is no certificate chain.

So, I still have no idea why it’s not working as it should 😕

---

<div class="post-metadata">

**Author:** ![HExSM](https://community.icinga.com/letter_avatar_proxy/v4/letter/h/bbce88/32.png) [@HExSM](https://community.icinga.com/u/HExSM)\
**Post date:** [January 31, 2024, 8:01am UTC](https://community.icinga.com/t/client-tls-handshake-failed-operation-canceled/13154/4 "2024-01-31T08:01:47Z")

</div>

I found the issue. There was a routing problem with the Site-to-Site tunnel.