HTTPS check fails in Icinga, but not in the plugin directly

Service Monitoring
1

Hello community,

we recently upgraded our Icinga2 server to Debian Buster; Icinga is installed from Debian packages, so that got upgraded as well. Both the Web and Monitoring modules are now version 2.6.2.

Since the upgrade, a TLS certificate check to an older webserver (sadly running on Ubuntu 12.04 - not under our control) fails. The server supports TLS up to version 1.2, according to the ssllabs.com SSL test.

Icinga throws the following error:

CRITICAL - Cannot make SSL connection.

22466919016256:error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type:../ssl/t1_lib.c:1110:

I assumed that was because OpenSSL wouldn’t accept the servers old TLS version / crypto algorithms. However, calling check_http directly with the hostname and the --ssl option exits with “OK”, wget doesn’t complain either.

Now what I would really like is a way to read the check command that Icinga actually runs, with expanded variables etc., so I could further troubleshoot why and where this error occurs. Does anyone have an easy solution to that, or maybe another idea what the problem could be?

Any help is much appreciated.

2

Hi and welcome to the community :slight_smile:

I don’t have a icingaweb2 available right now but if you navigate to the service you should see a link Inspect. It should show you the exact command incl. all parameters.

3

Thanks for your reply, Marcel! :slight_smile: I don’t see an “Inspect” link in the frontend. According to my Google-fu this seems to be a feature of Icinga Director, which I don’t have, is that possible?

1 Like
4

Hi,

In that case you need to enable debug log and look for the full command and parameters in the debug.log that will appear.

Cheers,
George

5

Oh sorry, yes, you are correct. I was just too used to have the director. :sweat_smile:

1 Like
6

Perfect, that did it, thank you! I could simply read the full check_http command from debug.log and figure out that it was --sni that was causing trouble. Now I can build a seperate service specifically for hosts with old TLS versions, which is a super ugly hack, but they can’t go unmonitored, so I have no choice… :confused:

Thanks again!

3 Likes
7

You can define it in your object host definition like this:

vars.http_sni = true

I just didi it (thanks to your post) :slightly_smiling_face: and it works like a charm. I noticed that microsoft IIS 10.X servers do need that.

1 Like