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 -xDadurch 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…