Icinga Update 2.11 - TLS 1.0 & checks failures

Icinga 2
1

Hello,

When I tried to upgrade my master node to 2.11, it fails because of tls_protocolmin = “TLSv1” is defined in object ApiListener “api” {}

I get this error:
critical/config: Error: Validation failed for object ‘api’ of type ‘ApiListener’; Attribute ‘tls_protocolmin’: Invalid TLS version. Must be ‘TLSv1.2’

Why keeping a configuration option that cannot be configured ?
Will it be enforced ? I have some nodes that cannot do TLS 1.2 due to old openssl version. Must I keep the 2.10 forever ?

With some nodes upgrade to 2.11 and master kept at 2.10, some of my custom checks fails with “Check command ‘blah’ does not exist.”, although they are defined in /var/lib/icinga2/api/zones-stage/director-global//director/commands.conf, and no error shows in icinga2.log

2

Oh, that shouldn’t break. And yeah, TLS v1.2 is enforced as can be read in the upgrading docs. TLS 1.0 is old and weak, many vendors have dropped their support for it. 2.11 hardens this as well.

If you want to stick with older TLS versions, do not upgrade or yet better, upgrade your clients. Which distribution are we talking about here?

Cheers,
Michael

3

those are multiple problems.

the first one with the TLS Version, I’m not too sure about how to fix it.

The second one command does not exist is a known one to me.
check with icinga2 object list --name <command> if the agent knows the check.
Also check the post michi wrote. Check your config deployment via the director, I would guess there are some problems drin as they are not leaving the staging area. Also check my old post about the same issue Icinga Update 2.11; Director Commands not available

1 Like
4

Which distribution are we talking about here?

Debian wheezy.
It’s way too old, I know, but “the Client” wants to stick with some version of its software :confused:

5

icinga2 object list --name check-licences-expiration returns nothing

grep -r check-licences-expiration /var/lib/icinga2/api/zones/director-global/director/ returns 3 lines, in commands.conf and services_templates.conf

I’ve read your post, but it does not apply (I think) : my zones are defined on clients’ /etc/icinga2/zones.conf

6

Which OpenSSL version is installed on Debian Wheezy? Mirrors are dead, so I cannot try it. If it is 1.0.1, TLS 1.2 should already be implemented there and with a 2.10 agent, 2.11 will work fine. Still, if you are planning to keep this for years like this, I can only recommend to convince the customer to upgrade the software.

7

wheezy have 1.0.1, but the icinga2 repository only have icinga 2.9

8

Did you try such a connection already? How does it look like in the logs?

9

It fails. I had to relax debian’s openssl.cnf config to let it talk to 2.10 under buster, that’s why I had to put the tls_protocolmin = "TLSv1" statement in api.conf

10

How exactly? Please add all the details from the logs or a manual openssl sl_client call to get a better idea.

11

Well, my bad, it does not fails with wheezy, I guess it’s the squeeze boxes that cannot connect, but these was upgraded since (finally). So I don’t need TLS1.0 after all, sorry :S

Actually, there is one squeeze box around :

[2019-09-24 17:31:35 +0200] information/JsonRpcConnection: Reconnecting to API endpoint 'icinga.*' via host 'icinga.*' and port '5665'
[2019-09-24 17:31:35 +0200] warning/TlsStream: OpenSSL error: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version
[2019-09-24 17:31:35 +0200] critical/ApiListener: Client TLS handshake failed
Context:
        (0) Handling new API client connection

Icinga is version 2.4 and openssl 0.9.8 … I will try to upgrade it

1 Like
12

Squeeze upgraded, TLS problem solved :slight_smile: