# Icinga Update 2.11 - TLS 1.0 & checks failures **URL:** \ **Category:** Icinga 2\ **Tags:** director\ **Created:** [September 24, 2019, 10:28am UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314 "2019-09-24T10:28:33Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![bastien](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/51bf81/32.png) [@bastien](https://community.icinga.com/u/bastien)\ **Post date:** [September 24, 2019, 10:28am UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/1 "2019-09-24T10:28:33Z")
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 ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [September 24, 2019, 11:22am UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/2 "2019-09-24T11:22:45Z")
> [@bastien](#): > > 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’ Oh, that shouldn’t break. And yeah, TLS v1.2 is enforced as can be read in the [upgrading docs](https://icinga.com/docs/icinga2/latest/doc/16-upgrading-icinga-2/#tls-12). 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 ---
**Author:** ![KevinHonka](https://community.icinga.com/user_avatar/community.icinga.com/kevinhonka/32/656_2.png) [@KevinHonka](https://community.icinga.com/u/KevinHonka)\ **Post date:** [September 24, 2019, 11:23am UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/3 "2019-09-24T11:23:52Z")
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 ` if the agent knows the check. Also check the [post michi wrote](https://community.icinga.com/t/icinga-2-11-released/2255/2). 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](https://community.icinga.com/t/icinga-update-2-11-director-commands-not-available/2256/5) ---
**Author:** ![bastien](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/51bf81/32.png) [@bastien](https://community.icinga.com/u/bastien)\ **Post date:** [September 24, 2019, 1:00pm UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/4 "2019-09-24T13:00:27Z")
> 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 😕 ---
**Author:** ![bastien](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/51bf81/32.png) [@bastien](https://community.icinga.com/u/bastien)\ **Post date:** [September 24, 2019, 1:11pm UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/5 "2019-09-24T13:11:39Z")
`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` ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [September 24, 2019, 2:55pm UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/6 "2019-09-24T14:55:19Z")
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. ---
**Author:** ![bastien](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/51bf81/32.png) [@bastien](https://community.icinga.com/u/bastien)\ **Post date:** [September 24, 2019, 2:57pm UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/7 "2019-09-24T14:57:59Z")
wheezy have 1.0.1, but the icinga2 repository only have icinga 2.9 ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [September 24, 2019, 3:07pm UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/8 "2019-09-24T15:07:37Z")
Did you try such a connection already? How does it look like in the logs? ---
**Author:** ![bastien](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/51bf81/32.png) [@bastien](https://community.icinga.com/u/bastien)\ **Post date:** [September 24, 2019, 3:10pm UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/9 "2019-09-24T15:10:33Z")
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 ---
**Author:** ![dnsmichi](https://community.icinga.com/user_avatar/community.icinga.com/dnsmichi/32/7721_2.png) [@dnsmichi](https://community.icinga.com/u/dnsmichi)\ **Post date:** [September 24, 2019, 3:14pm UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/10 "2019-09-24T15:14:50Z")
> [@bastien](#): > > It fails. How exactly? Please add all the details from the logs or a manual openssl sl\_client call to get a better idea. ---
**Author:** ![bastien](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/51bf81/32.png) [@bastien](https://community.icinga.com/u/bastien)\ **Post date:** [September 24, 2019, 3:26pm UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/11 "2019-09-24T15:26:43Z")
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 : ```auto [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 ---
**Author:** ![bastien](https://community.icinga.com/letter_avatar_proxy/v4/letter/b/51bf81/32.png) [@bastien](https://community.icinga.com/u/bastien)\ **Post date:** [September 24, 2019, 4:19pm UTC](https://community.icinga.com/t/icinga-update-2-11-tls-1-0-checks-failures/2314/12 "2019-09-24T16:19:56Z")
Squeeze upgraded, TLS problem solved 🙂