Cmk-update-agent register mit sha1 zertifikat

Global Community Deutsch
,
1

Hallo,
ich versuche einen Agenten aus der Bakery (CEE 1.6.0p25) zu registrieren. Dabei erhalte ich folgende Fehlermeldung:
ERROR HTTPSConnectionPool(host=‘kn01p3sy500.zka.bfinv.de’, port=443): Max retries exceeded with url: /MONITOR/check_mk/login.py (Caused by SSLError(SSLError(“bad handshake: Error([(‘SSL routines’, ‘tls_process_server_certificate’, ‘certificate verify failed’)],)”,),))
Die Ursache liegt im Zertifikat, welches noch sah1 verwendet.
Bevor die Sicherheitsschelte kommt…es geht nicht anders.
wie kann ich den updater dazu bringen, die Überprüfung zu ignorieren.
Danke für “gutgeneinte Schelte” und wertvolle Tipps
Sven

2

Sicher, dass ein “bad handshake” nur von einem SHA1 Zertifikat kommt?
Was sagt ein “openssl s_client -showcerts -connect monitoringhost:443”?
Also als Fehlermeldung, der ganze restliche Textoutput ist ja eher dann unwichtig :wink:

3

also eine richtige Fehlermeldung wirft der Befehl nict . von der Ausgabe her würde ich schon sagen, dass es passt :thinking:
CONNECTED(00000003)
depth=2 CN = VV
verify return:1
depth=1 DC = de, DC = XX, DC = XX, DC = XX, CN = VV
verify return:1
depth=0 C = DE, O = XX, CN = XX.XX.XX.de
verify return:1

Certificate chain
0 s:C = DE, O = XX, CN = XX.XX.XX.de
i:DC = de, DC = XX, DC = XX, DC = XX, CN = YY
-----BEGIN CERTIFICATE-----

Server certificate
subject=C = DE, O = XX, CN = XX.XX.XX.de

issuer=DC = de, DC = XX, DC = XX, DC = XX, CN = XX

No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits

SSL handshake has read 2368 bytes and written 402 bytes
Verification: OK

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)

Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 5A4BD24ABD589393A5270B29168020363A31313B11AB27D24D3C6329180F3D25
Session-ID-ctx:
Resumption PSK: F842DFB0CA485EF84A231E98B4348676E36B171242FB3293C744E6FC203B7E13302DE7A95B52A80CEEB0DF5520A9ACAC
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:

Start Time: 1632748449
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0

read R BLOCK

Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 0AB7ADB8BC35634004AA0080E21DB917BDBDDCFFE194D52A2AE0F32FC0488229
Session-ID-ctx:
Resumption PSK: 271CE459336D74321C4A0CBCA5E8D3C38E93157D27A316D051DE98FDAC1B2F1BF771910A5EB18D115385702947202DFA
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:

Start Time: 1632748449
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0

read R BLOCK

HTTP/1.1 400 Bad Request
Date: Mon, 27 Sep 2021 13:14:12 GMT
Server: Apache/2.4.38 (Debian)
Content-Length: 317
Connection: close
Content-Type: text/html; charset=iso-8859-1

closed

4

Ich sehe auch nicht das hier irgendwo ein SHA1 Zertifikat involviert ist.
Sieht für mich auch erstmal ok aus.

5

Wenn ich die URL mit lynx aufrufe, sagt lynx "SSL-Fehler: The certifikate is NOT Trusted. The certificate chain uses insecure algorithm. "
Ich weis, das unsere Zertifizierungsstelle noch SHA1 Zertifikate vergibt. In der opnessl.cnf mussten wir dies auch konfigurieren ==>> “DEFAULT@SECLEVEL=1”.
Die Rootzertifikate sind auf dem Server auch bekannt. IE und andere Browser können damit umgehen.
Im check_mk kann ich auch konfigurieren, dass beim verteilten Monitorring unsichere Zertifikate nicht geprüft werden. Daher die Aussage, daß es am Zertifikat liegt.

6

hab ich gerade noch gesehen (cmk-update-agent register -vvv)
========snip===========
pdating the certificate store “/var/lib/check_mk_agent/cas/all_certs.pem”…
Updated the certificate store “/var/lib/check_mk_agent/cas/all_certs.pem” with 1 certificate(s)
========snap===========
Darauf hin hab ich mir das Zert mal angeschaut:
========snip===========
openssl x509 -in all_certs.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
3b:6a:6b:2a:00:01:00:00:01:39
Signature Algorithm: sha1WithRSAEncryption
.
.
.

        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        1.3.6.1.4.1.311.21.7:
            0..&+.....7.....T...Y.......#...,.#......E..f...
        X509v3 Extended Key Usage:
            TLS Web Server Authentication
        1.3.6.1.4.1.311.21.10:
            0.0

.+…
Signature Algorithm: sha1WithRSAEncryption
========snap===========
Vielleicht hilft uns das weiter?

7

Hi,

kann das sein, dass der Hostname, der in deinem Zertifikat steht, nicht der gleiche in der Bakery ist?
Prüf das doch mal nach. Es kommt immer mal wieder vor, dass in den Zertifikaten z.B. der FQDN angegeben ist, aber in der Bakery nur der Hostname.

Viele Grüße, Christian

8

In der Bakery ist der FQDN, wie auch im Zertifikat angegeben.Schau ich in die cmk-update-agent.cfg lauter der Eintrag ‘server’ : ‘FQDN’

Gruß
Sven

9

Was mir auffällt:
spreche ich den Updater mit http an, und der Server machet einen Rewrite auf Https

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule (.*) https://%{HTTP_HOST}/$1 [L]

Dann funktioniert die Registrierung. Nur wollen wir Port 80 nicht DMZ-Übergreifend öffnen… :thinking:

10

Hallo,
@andreas-doehler
Danke für die Tipps und Hinweise… Der Fehler lag nicht im " SHA1 Zertifikat" (Asche auf mein Haupt…)
im der Zertifikatskette hatt tatsächlich eine CA gefehlt.Man sollte genau hinschauen. jetzt klappt das Agenten-Update.

Zumindest für die Hosts, die vom Zentalen Server aus gemonitort werden.

11

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.