Neues Zertifikat von anderem Aussteller, Agent Updater auf Windows hat Probleme damit

Oliverr · July 9, 2026, 3:41pm

Hallo,

wir mussten das Web-Zertifikat für den Apache austauschen, was jetzt von einem anderen Aussteller (sectigo) kommt.

Ich habe in der Agent Updater Config, dass neue CA Zertifikat hinzugefügt und das neue Agent Paket verteilt.

Linux Hosts haben keine Probleme, funktioniert nach dem umstellen des Apache auf das neue Zertifikat.
Windows Hosts bemängeln aber die Verbindung mit “certificate verify failed: unable to get local issuer certificate (_ssl.c:1032)”

Ich habe schon verschiedene Versuche getestet, die Zertificate zu Bündeln und nicht zu bündeln, aber Windows will nicht.

Hat jemand schonmal das Problem gehabt und es gefixt bekommen?

Grüße,
Oliver

mschlenker · July 9, 2026, 4:47pm

Wir arbeiten gerade an dem Themenkomplex (sowohl Entwicklung als auch Dokumentation). Falls Du irgendwelche Fehlermeldungen aus dem manuellen Aufruf rüberreichen kannst/darfst, bitte per PM an mich oder die anderen üblichen Verdächtigen aus der Firma.

Oliverr · July 14, 2026, 7:05am

Hi Mattias,
ich hatte Dir per PM geschrieben gehabt.
Ich habe immer noch keine Lösung des Problems.

mschlenker · July 14, 2026, 7:26am

Hi Oliver, ich habe es intern in die entsprechenden Slack-Kanäle gegeben. Da hatte bislang niemand eine Idee. Hast Du mir noch die verwendeten Versionen der Agenten auf Windows und Linux? Wir bündeln das Python Certifi-Modul (Mozillas Zertifikate-Sammlung) mit der Python-Runtime. Wenn nun ein Intermediate-Zertifikat der einen Certifi-Version bekannt ist, der anderen aber nicht, kann das eine eine Kette validieren, das andere nicht.

Im Zweifel also bitte die gesamte Zertifikatskette dem Updater bekannt machen.

Oliverr · July 16, 2026, 7:29am

Hi Mattias,
wir sind aktuell auf Checkmk Pro (formerly Enterprise) 2.4.0p31.
So wie es aussieht hat das Python Modul auf Windows ein Problem mit den Sectigo Zertifikat (Chain) (Auf Linux gibt es den Fehler nicht).
Ich habe auf dem Apache es mit einem full_chain.pem aus den drei Zertifikaten:
server.crt
CorporationServiceCompanyRSADVSSLCA2.crt
SectigoPublicServerAuthenticationRootR46_USERTrust.crt

und auch mit einem full_chain.pem aus den vier Zertifikaten:
server.crt
CorporationServiceCompanyRSADVSSLCA2.crt
SectigoPublicServerAuthenticationRootR46_USERTrust.crt
USERTrustRSACertificationAuthority.crt

versucht, aber der Fehler bleibt der gleiche.
In der Updater Agent Config gebe ich die beiden Zertifikate:
SectigoPublicServerAuthenticationRootR46_USERTrust.crt
USERTrustRSACertificationAuthority.crt
mit.
Kann es sein, dass das Python Certifi-Modul des Windows Agent mit Sectigo Zertifikaten ein Problem hat?

Oliverr · July 16, 2026, 9:58am

Ich bin jetzt dabei auf 2.4.0p34 zu aktualisieren, da in einer Version dazwischen openssl und python aktualisiert wurde und vielleicht das hilft. Mal sehen wie es heute Nachmittag aussieht.

Oliverr · July 16, 2026, 12:13pm

Mit 2.4.0p34, verhält es sich leider immer noch genauso.

Oliverr · July 16, 2026, 2:23pm

Wenn ich von dem Windows Server die Abfrage openssl s_client -connect domain.de:443 mache um mir die Zertifikat Chain anzeigen zu lassen, gibt es diese Auflistung:

Certificate chain
0 s:CN=``xxxxxxxxx.de
i:C=US, O=Corporation Service Company, CN=Corporation Service Company RSA DV SSL CA 2
a:PKEY: RSA, 2048 (bit); sigalg: sha256WithRSAEncryption
v:NotBefore: Jul 7 00:00:00 2026 GMT; NotAfter: Jan 21 23:59:59 2027 GMT

1 s:C=US, O=Corporation Service Company, CN=Corporation Service Company RSA DV SSL CA 2
i:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
a:PKEY: RSA, 3072 (bit); sigalg: sha384WithRSAEncryption
v:NotBefore: May 14 00:00:00 2025 GMT; NotAfter: May 13 23:59:59 2035 GMT

2 s:C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication Root R46
i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
a:PKEY: RSA, 4096 (bit); sigalg: sha384WithRSAEncryption
v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Jan 18 23:59:59 2038 GMT

3 s:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network, CN=USERTrust RSA Certification Authority
a:PKEY: RSA, 4096 (bit); sigalg: sha384WithRSAEncryption
v:NotBefore: Feb 1 00:00:00 2010 GMT; NotAfter: Jan 18 23:59:59 2038 GMT

Mit der Agent Updater Regel, habe ich schon alle Konstellationen ausprobiert, aber es klappt keine davon:
Nur Nr.2
Nur Nr.3
Beide Nr.2 und Nr.3

mimimi · July 16, 2026, 7:38pm

Ich denke, dass der checkmk webserver das RootCA cert #3 ausliefert ist unnötig.
Schlimm ist es aber auch nicht, nur unnötig.

Ist Dir klar, dass wenn du das RootCA #3 in der Agent updater rule als trusted hinterlegst, Du zunächst:

die changes aktivieren must ?
einen neuen agent mit dem #3 RootCA cert backen und signieren musst ?
denn agent zunächst irgenwie auf dem Windows Endpoint installieren musst?
Denn erst dann wird der agent updater das RooCA #3 kennen und ihm vertrauen.

Beim Austausch des Server/Leaf Zertifikat plus Intermediate CA(s) wird oft übersehen, dass man erst das neue RootCA Zertifikat ZUSÄTZLICH zum alten RootCA Zertifikat auf den Endpunkten ausrollen muss.

Erst wenn sich alle Endpoints geupdated haben und
das alte und das neue RootCA kennen darf man das Server/Leaf Zertifikat und die/das Intermedia CA Zertifikat vom Checkmk Server austauschen

Und in einem finalen Schritt kann man das alte RootCA aus der Agent Updater Rule entfernen.

Oliverr · July 16, 2026, 8:44pm

So mache ich das die ganze Zeit, in verschiedensten Zusammensetzungen, da zum Glück das alte Zertifikat erst morgen abläuft.

mimimi · July 17, 2026, 7:17am

Ich würde mal prüfen, ob das richtige Zertifikat auf der Windows Kiste ankommt:
Hier bin ich per ssh auf einer Windows Kiste:

mydomain\administrator@WINDOWS2016 C:\>type C:\ProgramData\checkmk\agent\config\cmk-update-agent.cfg

# Created by Check_MK Agent Bakery.
# This file is managed via WATO, do not edit manually or you
# lose your changes next time when you update the agent.

{'activated': True,
 'certificates': ['-----BEGIN CERTIFICATE-----\n'
                  'MIIGJzCCBA+gAwIBAgIUNaaQJU7rI2nVQUFIHngJXYjS0bEwDQYJKoZIhvcNAQEL\n'   
...   
                  '7XFz3YwhEzoZRmLkuWbIklgeZDuRI6yXRml36XrvPO5J/lDzeGPEIvpweQ==\n'       
                  '-----END CERTIFICATE-----\n'],
 'ignore_update_url': False,
 'interval': 300,
 'signature_keys': ['-----BEGIN CERTIFICATE-----\n'
                    'MIIFZzCCA0+gAwIBAgIUbWnepTkhpQvRTZWpDm0BVJizHvcwDQYJKoZIhvcNAQEN\n' 
 ..
                    'o0tJZqWf2B5MHu3R+y6EhpHrNatItpgS9+YZcAMTDjwGCqdGlS/VN/lxBg==\n'
                    '-----END CERTIFICATE-----\n'],
 'use_proxy_env': False}

Das ist natürlich alles etwas unhandlich, weil wer kann schon gut base64 encodierte
PEM Zertifikate lesen und dann noch mit newlines drin.

So prüfe ich das daher von meinem Linux Laptop aus:

ssh auf einen windows server,
dann cmk-update-agent.cfg mit type ausgeben,
an pyton pipen um das 1. hinterlegte Zertifikat
an openssl zu pipen um es Menschen lesbar zu machen.

Statt …[“certificates”][0] brauchst Du …[“certificates”][1], je nach dem wieviele RootCAs Du dem Agent Update untergejubelt hast.

$ ssh Administrator@windows2016.mycompany.tld "type C:\ProgramData\checkmk\agent\config\cmk-update-agent.cfg" \
| python3 -c 'import sys ; print( (eval(sys.stdin.read())["certificates"][0] ))' \
| openssl x509 -noout -subject -issuer -dates -ext basicConstraints 

subject=C = Universe, ST = Atlantis, L = Lummerland, O = Railways, OU = Workers, CN = Lab RootCA, emailAddress = "me.surname+ca@mycompany.tld"
issuer=C = Universe, ST = Atlantis, L = Lummerland, O = Railways, OU = Workers, CN = Lab RootCA, emailAddress = "me.surname+ca@mycompany.tld"
notBefore=Jun  3 14:41:18 2025 GMT
notAfter=Jun 18 14:41:18 2037 GMT
X509v3 Basic Constraints: critical
    CA:TRUE

Overlord · July 17, 2026, 1:04pm

Ich hatte vor kurzem ein sehr ähnliches Problem.

Nach der Erneuerung meines Let’s-Encrypt-Zertifikats auf die neue Gen-Y-Chain konnte sich der Checkmk Agent Updater nicht mehr verbinden (unable to get local issuer certificate).

Nach einiger Analyse stellte sich heraus, dass das Zertifikat selbst völlig in Ordnung war. Das Problem war, dass das pfSense-ACME-Paket beim Export der fullchain offenbar das letzte Zertifikat der Zertifikatskette entfernt hat. Dadurch wurden nur zwei statt drei Zertifikate ausgeliefert und OpenSSL/Linux konnte die Kette nicht mehr vollständig validieren.

Als Workaround habe ich nach der Zertifikatserstellung die originale fullchain.cer aus dem ACME-Verzeichnis über die exportierte *.fullchain kopiert. Danach funktionierten openssl, curl und der Checkmk Agent Updater sofort wieder.

Für mich sah das nach einem Bug im ACME-Paket von pfSense aus und nicht nach einem Problem von Checkmk selbst.

Oliverr · July 20, 2026, 6:54am

Hi zusammen,
ich bin bei der Apache Config, wie auf die alte Config umgestiegen und nutze nicht mehr die fullchain.

Somit benutze ich wieder:
SSLCertificateFile server.crt
SSLCertificateKeyFile server.key
SSLCertificateChainFile CorporationServiceCompanyRSADVSSLCA2.crt

Ich muss jetzt nur noch die Agent Updater Regel wieder aufräumen, da ich in der aktuell zu viele Zertifikate habe. Das mache ich, wenn der Montag Stress vorbei ist.