Wieder mal ein SSL-Problem

Global Community Deutsch
1

CMK version:2.3.0p34
Error message:

Version: 2.3.0p34, OS: windows, TLS is not activated on monitored host (see details), Update error: HTTPSConnectionPool(host=SERVER’, port=443): Max retries exceeded with url: /SITE/check_mk/deploy_agent.py (Caused by SSLError(SSLCertVerificationError(1, ‘[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get issuer certificate (_ssl.c:1010)’)))WARN, Last update: 2025-11-20 15:16:04, Agent plug-ins: 2, Local checks: 0

Hallo Forum,

ich muß den CMK-Servern Agenten ein neues Zertifikat einspielen. daher ist für die gebackenen Agenten ein neues ROOT-Zertifikat erforderlich, da sich auch die CA geändert hat.

ich habe in den Regeln für die Agentenupdates das Zertifikat des Ausstellers und des Ausstellers des Ausstellers eingepflegt, also die komplette Kette.

Die Agenten haben sich mit den „bisherigen“ Server-Zertifikaten aktualisiert. und damit die neue CA heruntergeladen.

Nach Aktualisierung der Serverzertifikate und Neustart der Apachen sin 2 Instanzen IO Die Agenten haben die neue CA akzeptiert. In 2 Instanzen bekomme ich allerdings den obigen Fehler.

Ich weiß, das Problem ist ein „fehlerhaftes/fehlendes“ Zertifikat , habe aber keine Idee wo das Problem liegt.

Am Client habe ich geprüft:

openssl s_client -connect FQDN-SERVER:443 -CApath //etc/ssl/certs | grep 'return code'

depth=2 C = GR, O = Hellenic Academic and Research Institutions CA, CN = HARICA TLS RSA Root CA 2021

verify return:1

depth=1 C = GR, O = Hellenic Academic and Research Institutions CA, CN = GEANT TLS RSA 1

verify return:1

depth=0 C = DE, ST = XXXXXXXXX, O = BBBBBBBBBBB, CN = FQDN-Server

verify return:1

Verify return code: 0 (ok)

 

    Verify return code: 0 (ok)

    Verify return code: 0 (ok)

Dem entnehme ich, daß der Client das Zertifikat prinzipiell verifizieren kann

Dann versuche ich herauszufinden, ob der CMK-Agent diese Zertifikate enthält:

openssl crl2pkcs7 -nocrl -certfile <(cat /etc/check_mk/cmk-update-agent.cfg | egrep "\\n'" | cut -f2 -d":" | cut -f2 -d"'" | sed "s/\\\\n//g") | openssl pkcs7 -print_certs -text -noout | grep -e Subject: -e Issuer -e DNS


        Subject: C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021

        Issuer: C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021

        Subject: C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1

                CA Issuers - URI:http://crt.harica.gr/HARICA-TLS-Root-2021-RSA.cer

        Issuer: C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1

        Subject: C=DE, ST= XXXXXXXXX, O= BBBBBBBBBBB, CN=FQDN-SERVER

                CA Issuers - URI:http://crt.harica.gr/HARICA-GEANT-TLS-R1.cer

                DNS:FQDN-SERVER

Das scheint auch zu passen.

Und mir gehen gerade die Ideen aus……

Gruß

Sven

2

Nur aus den Erfahrungen mit meinen Systemen. Dem Agent geb ich nur das CA Zertifikat mit.
Dafür muss ich dann schauen, dass mein System Apache auf dem CMK Server ordentlich die Zertifikat Chain mit ausliefert.

Damit bin ich bisher gut gefahren ohne größere Probleme.

Es gab auch Systeme auf welchen der Agent die Chain mitgeliefert bekommen hat wie in deinem Beispiel. Hier gab es immer wieder mal Probleme mit der Reihenfolge der Zertifikate, deshalb bin am Ende bei nur noch CA Zertifikaten gelandet.

3 Likes
3

wenn ich das richtig verstehe, ist das bei mir der Fall.
Und dem Agenten würde ich in Deiner Variante nur das Zertifikat

Subject: C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1

            CA Issuers - URI:http://crt.harica.gr/HARICA-TLS-Root-2021-RSA.cer

mitgeben?

4

Das folgende

sollte im Agent sich befinden.

Dein Apache liefert dann

und

aus.

5

Hallo,

ich habe nun versucht die Lösung nachzubauen indem ich für beite zu testende Hosts jeweils einen eigenen Agenten gebacken habe. Leider ohne Erfolg, obwohl es eigentlich so passen sollte. Könnte in die Problematik noch irgend eine andere Konfigurationsstelle rein spielen?

Instanz A (SITE-Master und SITE-Instanz liegen auf dem selben Host)

Screenshot 2025-11-27 at 15-35-19 Agent Updater (Linux Windows Solaris)
Screenshot 2025-11-27 at 15-35-19 Agent Updater (Linux Windows Solaris)748×365 9.52 KB

Altes Zertifikat ==> Updater OK

$ openssl s_client -connect CMK-SERVER:443 -showcerts | egrep ‘s:|i:’

depth=0 C = DE, ST = Nordrhein-Westfalen, O = OOOOOOOOOOOO OOO, CN = CMK-SERVER

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 C = DE, ST = Nordrhein-Westfalen, O = OOOOOOOOOOOO OOO, CN = CMK-SERVER

verify error:num=21:unable to verify the first certificate

verify return:1

depth=0 C = DE, ST = Nordrhein-Westfalen, O = OOOOOOOOOOOO OOO, CN = CMK-SERVER

verify return:1

0 s:C = DE, ST = Nordrhein-Westfalen, O = OOOOOOOOOOOO OOO, CN = CMK-SERVER

i:C = NL, O = GEANT Vereniging, CN = GEANT OV RSA CA 4

#$ cmk-update-agent -v

Updated the certificate store “/var/lib/check_mk_agent/cas/all_certs.pem” with 3 certificate(s)

±------------------------------------------------------------------+

| |

| Checkmk Agent Updater v2.3.0-2025.05.26 - Update |

| |

±------------------------------------------------------------------+

Getting target agent configuration for host ‘HOST-A’ from deployment server

Updated the certificate store “/var/lib/check_mk_agent/cas/all_certs.pem” with 3 certificate(s)

Target state (from deployment server):

Agent available: True

Signatures: 1

Target hash: 41935e2408a3cd2b

Agent 41935e2408a3cd2b already installed.

Neues Zertifikat ==> Updater ERROR

openssl s_client -connect CMK-SERVER:443 -showcerts | egrep ‘s:|i:’

depth=2 C = GR, O = Hellenic Academic and Research Institutions CA, CN = HARICA TLS RSA Root CA 2021

verify return:1

depth=1 C = GR, O = Hellenic Academic and Research Institutions CA, CN = GEANT TLS RSA 1

verify return:1

depth=0 C = DE, ST = Nordrhein-Westfalen, O = OOOOOOOOOOOO OOO, CN = CMK-SERVER

verify return:1

0 s:C = DE, ST = Nordrhein-Westfalen, O = OOOOOOOOOOOO OOO, CN = CMK-SERVER

i:C = GR, O = Hellenic Academic and Research Institutions CA, CN = GEANT TLS RSA 1

1 s:C = GR, O = Hellenic Academic and Research Institutions CA, CN = GEANT TLS RSA 1

i:C = GR, O = Hellenic Academic and Research Institutions CA, CN = HARICA TLS RSA Root CA 2021

2 s:C = GR, O = Hellenic Academic and Research Institutions CA, CN = HARICA TLS RSA Root CA 2021

i:C = GR, L = Athens, O = Hellenic Academic and Research Institutions Cert. Authority, CN = Hellenic Academic and Research Institutions RootCA 2015

$ cmk-update-agent -v

Updated the certificate store “/var/lib/check_mk_agent/cas/all_certs.pem” with 3 certificate(s)

±------------------------------------------------------------------+

| |

| Checkmk Agent Updater v2.3.0-2025.05.26 - Update |

| |

±------------------------------------------------------------------+

Getting target agent configuration for host ‘kn01p3ap801’ from deployment server

Failed to connect to Agent Bakery: HTTPSConnectionPool(host= CMK-SERVER ', port=443): Max retries exceeded with url: /SITE-MASTER/check_mk/deploy_agent.py (Caused by SSLError(SSLCertVerificationError(1, ‘[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)’)))

Retrying with fallback URL: https:// CMK-SERVER-A /SITE/check_mk

HTTPSConnectionPool(host= CMK-SERVER ', port=443): Max retries exceeded with url: /SITE-INSTANZ/check_mk/deploy_agent.py (Caused by SSLError(SSLCertVerificationError(1, ‘[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1076)’)))

See syslog or Logfile at /var/lib/check_mk_agent/cmk-update-agent.log for details.

Instanz B

Screenshot 2025-11-27 at 14-11-27 Agent Updater (Linux Windows Solaris)
Screenshot 2025-11-27 at 14-11-27 Agent Updater (Linux Windows Solaris)1187×380 22.4 KB

Altes Zertifikat ==> Updater OK

#$ openssl s_client -connect CMK-SERVER-B:443 -showcerts | egrep ‘s:|i:’

Connecting to 10.188.46.230

depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority

verify return:1

depth=1 C=NL, O=GEANT Vereniging, CN=GEANT OV RSA CA 4

verify return:1

depth=0 C=DE, ST=Nordrhein-Westfalen, O= OOOOOOOOOOOO OOO, CN= CMK-SERVER-B

verify return:1

0 s:C=DE, ST=Nordrhein-Westfalen, O= OOOOOOOOOOOO OOO, CN= CMK-SERVER-B

i:C=NL, O=GEANT Vereniging, CN=GEANT OV RSA CA 4

#$ cmk-update-agent -v

Updated the certificate store “/var/lib/check_mk_agent/cas/all_certs.pem” with 5 certificate(s)

±------------------------------------------------------------------+

| |

| Checkmk Agent Updater v2.3.0-2025.05.26 - Update |

| |

±------------------------------------------------------------------+

Getting target agent configuration for host ‘HOST-B’ from deployment server

Failed to connect to Agent Bakery: HTTPSConnectionPool(host= CMK-SERVER’, port=443): Max retries exceeded with url: /Master-Site/check_mk/deploy_agent.py (Caused by NewConnectionError(‘<urllib3.connection.HTTPSConnection object at 0x7f240ae9d090>: Failed to establish a new connection: [Errno 111] Connection refused’))

Retrying with fallback URL: https:// CMK-SERVER-B /INSTANZ-B/check_mk

Updated the certificate store “/var/lib/check_mk_agent/cas/all_certs.pem” with 5 certificate(s)

Target state (from deployment server):

Agent available: True

Signatures: 1

Target hash: a7cf13368ba1d602

Agent a7cf13368ba1d602 already installed.

Neues Zertifikat ==> Updater OK

openssl s_client -connect CMK-SERVER-B:443 -showcerts | egrep ‘s:|i:’

Connecting to IP-CMKSERVER-A

depth=2 C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021

verify return:1

depth=1 C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1

verify return:1

depth=0 C=DE, ST=Nordrhein-Westfalen, O=OOOOOOOOOO OOO, CN= CMK-SERVER-B

verify return:1

0 s:C=DE, ST=Nordrhein-Westfalen, O= OOOOOOOOOO OOO, CN= CMK-SERVER-A

i:C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1

1 s:C=GR, O=Hellenic Academic and Research Institutions CA, CN=GEANT TLS RSA 1

i:C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021

2 s:C=GR, O=Hellenic Academic and Research Institutions CA, CN=HARICA TLS RSA Root CA 2021

i:C=GR, L=Athens, O=Hellenic Academic and Research Institutions Cert. Authority, CN=Hellenic Academic and Research Institutions RootCA 2015

#$ cmk-update-agent -v

Updated the certificate store “/var/lib/check_mk_agent/cas/all_certs.pem” with 5 certificate(s)

±------------------------------------------------------------------+

| |

| Checkmk Agent Updater v2.3.0-2025.05.26 - Update |

| |

±------------------------------------------------------------------+

Getting target agent configuration for host ‘HOST-B’ from deployment server

Failed to connect to Agent Bakery: HTTPSConnectionPool(host=CMK-Server’, port=443): Max retries exceeded with url: /MASTER-SITE/check_mk/deploy_agent.py (Caused by NewConnectionError(‘<urllib3.connection.HTTPSConnection object at 0x7fb1d62de1d0>: Failed to establish a new connection: [Errno 111] Connection refused’))

Retrying with fallback URL: https://CMK-SERVER-B/INSTANZ-B/check_mk

Updated the certificate store “/var/lib/check_mk_agent/cas/all_certs.pem” with 5 certificate(s)

Target state (from deployment server):

Agent available: True

Signatures: 1

Target hash: a7cf13368ba1d602

Agent a7cf13368ba1d602 already installed.

6

Kann ich dem Agenten eigentlich irgendwo reinkonfigurieren ( so wie “cmk_update-agent -x”), daß er das Zertifikat ignorieren soll (zumindest vorläufig, bis das Problem gelöst ist) Da das CMK-Server-Zertifikat demnächst ungültig wird. Ich hab da nix so richtigiges gefunden.

7

Hallo Sven,

eigentlich kann es nur an irgendeiner Kleinigkeit liegen. Es ließt sich alles OK, was du geschrieben hast. Ich habe das Szenario auch gerade noch einmal durchgespielt - sollte eigentlich funktionieren.

Vielleicht nochmal alles der Reihe nach prüfen. Andreas hat es bereits erwähnt: Der Server muss die Zertifikate korrekt ausliefern.

Der Server muss liefern:

  • das Serverzertifikat
  • die Intermediate-Zertifikate / Chain (falls vorhanden)
  • kein(!) Root-Zertifikat
  • einen DNS-Namen, der exakt mit dem CN/SAN im Serverzertifikat übereinstimmt
  • der Server muss über diesen DNS-Namen (SNI) vom Agent angesprochen werden

Bei Problemen würde ich wie folgt vorgehen:

1) SSL-Test

Zunächst völlig unabhängig von Servern oder Agents lokal testen.

Altes Zertifikat prüfen:

openssl verify -CAfile /certs/alt/root/root_ca.crt -untrusted /certs/alt/intermediate/intermediate_cas.crt -verify_hostname site.internal.dtconnect.de /certs/alt/issued/site.internal.dtconnect.de.crt

Neues Zertifikat prüfen:

openssl verify -CAfile /certs/neu/root/root_ca.crt -untrusted /certs/neu/intermediate/intermediate_cas.crt -verify_hostname site.internal.dtconnect.de /certs/neu/issued/site.internal.dtconnect.de.crt

Wenn das funktioniert, prüfen, ob der Hostname korrekt aufgelöst wird:

$:/home/dtuecks# nslookup site.internal.dtconnect.de

Server:		192.168.0.1
Address:	192.168.0.1#53

Name:	site.internal.dtconnect.de
Address: 192.168.0.2

2) Webserver konfigurieren und testen

Wenn die Zertifikate validieren, Apache wie folgt konfigurieren:

SSLCertificateFile /certs/neu/issued/site.internal.dtconnect.de.crt

SSLCertificateChainFile /certs/neu/intermediate/intermediate_cas.crt

Alternativ kann man die gesamte Kette in das SSLCertificateFile packen; ich finde die getrennte Variante übersichtlicher.

Danach erneut den Weg über das Netzwerk testen:

openssl s_client -connect ``site.internal.dtconnect.de:443`` -CAfile /certs/neu/root/root_ca.crt -verify_hostname ``site.internal.dtconnect.de`` -verify_return_error

curl --cacert /certs/neu/root/root_ca.crt ``https://site.internal.dtconnect.de

3) Checkmk konfigurieren

Wenn alles funktioniert, dann den Inhalt von

/certs/neu/root/root_ca.crt

als neues Root-Zertifikat im Agent Updater hinterlegen. Das alte Root-Zertifikat sollte vorerst ebenfalls eingetragen bleiben (Inhalt von /certs/alt/root/root_ca.crt).

So kennt der Agent am Ende zwei Root CAs (alt und neu).

Intermediates werden nicht im Agent hinterlegt - die liefert der Server per SSLCertificateChainFile.

Zum Schluss prüfen, ob die Agent-Updater-Konfiguration den richtigen Hostnamen nutzt

(Agent updater → DNS name or IP address of update server).

Dort muss der Hostname stehen, der im Zertifikat enthalten ist - nicht nur die reine IP-Adresse.

4) Anmerkungen

  • In Checkmk müssen die Root CAs jeweils als einzelne Einträge hinzugefügt werden (ggf. mehrmals auf “Add” klicken).
  • Wenn die Chain mehrere Intermediates enthält oder ein Bundle verwendet wird, ist die Reihenfolge wichtig: Serverzertifikat - Intermediates - Root (Root wird aber nicht ausgeliefert).

Ablauf bei bereits abgelaufenen Zertifikaten

Falls Root- oder Serverzertifikate bereits abgelaufen sind, würde ich so vorgehen:

- Neue Zertifikate auf dem Webserver ausrollen und in den Agent Updater einpflegen.

  • Auf jedem betroffenen System einmal ausführen: cmk-update-agent -x Dadurch wird die Zertifikatsprüfung 1x ausgesetzt und der Agent kann sich aktualisieren (mit den neuen Root Zertifikaten)

Danach sollte sich die Situation stabilisieren.

-x deaktiviert die Zertifikatsprüfung nur für diesen einen Lauf.
Mit -t ließe sich dem aktuellen Zertifikat dauerhaft vertrauen - inklusive Chain und (vermutlich) Ablaufdatum. Letzteres sollte man aber bewusst nicht tun.

Bis dann

Daniel

P.S.: Soweit ich weiß, kannst du den Agent nicht so konfigurieren, dass er Zertifikate (analog zu -x) einfach ignoriert - ich habe auch nichts entsprechendes gefunden. Das einzige wäre wahrscheinlich wirklich -t beim deployment…

1 Like
8

Danke für die Unterstützung, das Problem ist gelöst. Entscheidend war a) ich hatte zwei Zertifikate verwechselt :face_with_peeking_eye: und zum anderen ist die Reihenfolge der Zertifikate wohl auch nicht unwichtig, wie oben beschrieben.