Old VMWare, old SSL

How-to Articles
1

Hello everyone,

This is purely informational, in case it helps somebody.

I recently had to set up Checkmk 2.1 on a Rocky 8.x Linux host. Among the targets
to be monitored, I have machines that are running vSphere/ESXi 5.1. The SSL
version they provide, is too old, and when I initially tried, I ran into the same issue described
here:

In order to “fix” this on Rocky 8.x (probably also works for CentOS/RHEL/Alma 8.x), I had
to run the command

upate-crypto-policies --set LEGACY

and reboot. After that, the check works normally.

HTH,
Thomas

1 Like
2

Hello everyone,

After updating to 2.2.0p5 this little “trick” no longer works, although
on the “OS” level, connecting with e.g. openssl s_client -connect <IP>:<port>
does.

Apparently the latest Checkmk version, ships with the python module requests 2.31.0.
As a result, none of my VMWare checks was working anymore. The only “solution” I found
to “fix” this, was to downgrade the requests module to 2.20.0.

Not sure what I “broke” in Checkmk by downgrading this module, but the VMWare checks
work again.

Perhaps someone has a better idea to “solve” this issue.

HTH,
Thomas

3

Perhaps I do not fully understand your setup, but:

Using the openssl binary from the OS (i.e. /usr/bin/openssl) should work independently from any python module shipped with Checkmk. You probably just need to call it with the absolute path, otherwise ~/bin/openssl will take precedence.

4

Hi Martin,

Yes, that is clear. I noticed that when I was trying to use a check for SSL
certificates which wouldn’t work with the openssl binary shipped
with Checkmk, but it did work with the one on the system.

The problem is the vSphere special agent. In 2.2.0p5 the requests module
is in version 2.31.0. With this module, although the “legacy” crypto policy
is in effect, every VMWare check returned “UNSUPPORTED PROTOCOL”.

Again, those are quite old ESXi hosts, but up to 2.1.0p29, the VMWare checks
were working fine, just by changing the crypto policy on my Rocky 8.x host.

As soon as I upgraded to 2.2.0p5, the checks stopped working. Once I installed
requests 2.20.0 with pip in the $OMD_ROOT, the checks worked again.

Thomas

5

understood, sorry.
No idea how to really solve this in a clean way. I guess upgrading the hosts is not feasable.
Perhaps set up some reverse-proxy in between monitoring and the legacy hosts to intercept/upgrade the tls connection?

1 Like