Hey,
i installed a new Proxmox Server and want to monitor it. I couldnt find the older icinga2 version i was using before for this server. I configured it like all my Endpoints who are all connected to satelites.
As far as I’m concerned this is causing the problem:
warning/ApiListener: Certificate validation failed for endpoint ‘porkpie.example.lan’: code 68: CA signature digest algorithm too weak
I cant make a new CA cert since I don’t have the time to roll it out on every server which is using this CA. Is there any way i can make icinga accept this ca cert?
If you use check_pve you can enable the --insecure switch.
usage: check_pve.py [-h] -e API_ENDPOINT -u API_USER -p API_PASSWORD [-k] -m
{cluster,cpu,memory,storage,io_wait,updates,services,subscription,vm,replication}
[-n NODE] [--name NAME] [--vmid VMID]
[--ignore-service NAME] [-w TRESHOLD_WARNING]
[-c TRESHOLD_CRITICAL] [-M]
Check command for PVE hosts via API
optional arguments:
-h, --help show this help message and exit
API Options:
-e API_ENDPOINT, --api-endpoint API_ENDPOINT
PVE api endpoint hostname
-u API_USER, --username API_USER
PVE api user (e.g. icinga2@pve or icinga2@pam,
depending on which backend you have chosen in proxmox)
-p API_PASSWORD, --password API_PASSWORD
PVE api user password
-k, --insecure Don't verify HTTPS certificate
Check Options:
-m {cluster,cpu,memory,storage,io_wait,updates,services,subscription,vm,replication}, --mode {cluster,cpu,memory,storage,io_wait,updates,services,subscription,vm,replication}
Mode to use.
-n NODE, --node NODE Node to check (necessary for all modes except cluster)
--name NAME Name of storage or vm
--vmid VMID ID of virtual machine or container
--ignore-service NAME
Ignore service NAME in checks
-w TRESHOLD_WARNING, --warning TRESHOLD_WARNING
Warning treshold for check value
-c TRESHOLD_CRITICAL, --critical TRESHOLD_CRITICAL
Critical treshold for check value
-M Values are shown in MB (if available). Tresholds are
also treated as MB values
is the culprit, modern systems deny to use this old algorithm and suggested something like Signature Algorithm: sha256WithRSAEncryption or harder instead.
This has nothing to do with the plugin check_pve, but is a problem with the cluster communication. Also, having 2.6 on the master and satellite comes with problems with using a newer agent. 2.6 is out of support, not sure why they are that old. Upgrading them should be on your list.
Hence I am not sure if an upgrade solves this, since the CA won’t be touched with that. Also, the CA doesn’t look like as if it was created by Icinga itself but instead, created with xinux.de.
There’s the possibility to re-new the public CA certificate with generating a CA CSR and signing it again with the private CA key, inspired by this blog post and question.
This of course requires a modern openssl which uses SHA256 by default. Older openssl binaries do not support this, RHEL5 and SLES11 come to mind with OpenSSL 0.9.8.
The new ca.crt file needs to be deployed to all Icinga nodes then.
Unfortunately I don’t see any other way than replacing the public CA certificate, the TLS handshake is something controlled by OpenSSL itself without configurable user settings. Also, SHA1 is deprecated and has been removed from many public applications as well.
The same message can also show up when not the CA, but the server certificate uses a cipher that is considered too weak. In my case, the CA was fine, however, the server’s certificate was indeed a sha1WithRSAEncryption.
Leaving my original post here below, because yes, it took me a while to figure out where to look. In the Debian bug report, someone mentioned this, which made me realize my mistake:
Thank you for your feedback. You are right. I do not know why I was
checking the CA certificate only and not the server one. The CA one is
signed with SHA256 while the server one is signed with SHA1.
Original reply:
I’m seeing the same thing with a CA that uses sha256WithRSAEncryption between a Debian Stretch master and a Debian Buster client.
I’ve looked at some related threads (e.g. https://github.com/openssl/openssl/issues/3558), and I’ve seen that MD and SHA1 have been deprecated, but I don’t see SHA256 having received the same treatment.