Zertifikatsdesaster aus heiterem Himmel

[markus0815 10]

Hallo allerseits.

 

Ich ersuche um Hilfe zu meiner Testumgebung-/Familiennetzwerk. Konstellation: Windows Server 2012 R2 physischer Host, 6 virtuelle Maschinen in Hyper-V mit insg. ~15 Serverrollen (AD, DNS, DHCP, RRAS, WSUS, IIS, SQL, WSS, NLB, Exchange, CA,...). Das ganze lauft seit vielen Jahren, abgesehen von den üblichen kleinen Bug-Unterbrechungen 1, 2mal pro Jahr, problemlos.

 

Seit kurzem ist der Exchange nur noch teilfunktionell. Es gab keine Änderung am System. Das Problem trat spontan auf, und ist, grob beschrieben: Emails können empfangen, jedoch nicht gesendet werden.

 

Die Exchange-Warteschlangenanzeige gibt als Fehler bekannt: "451 4.4.0 Primary target IP address responded with: "454 4.7.5 Certificate validation failure."" Zur Info, ich nutze ein Forwarding-Service, zu dem ich den Sendeconnector via TLS verbinden / authentifizieren lasse. Ich nehme an, die haben sich einfach vor kurzem dazu entschlossen, mein selbstsigniertes Zertifikat nicht mehr zu akzeptieren. Das werde ich natürlich mit diesem Dienstleister abklären.

 

Bei der Fehlersuche sind leider jedoch weitere interne Problemchen aufgetaucht. Insb. scheint der Fehler 12014 in der Ereignisanzeige auf: "Microsoft Exchange konnte ein Zertifikat nicht finden, das den Domänennamen "(FQDN der Exchange/CA-VM)" im persönlichen Informationsspeicher auf dem lokalen Computer enthält. Daher kann die STARTTLS-SMTP-Aktionsart für den Connector "x" mit einem FQDN-Parameter von "(FQDN der Exchange/CA-VM)" nicht  unterstützt werden. Überprüfen Sie die Connectorkonfiguration sowie die installierten Zertifikate, damit sichergestellt wird, dass ein Zertifikat mit einem Domänennamen für jeden Connector-FQDN vorhanden ist. Wenn das Zertifikat vorhanden ist, führen Sie "Enable-ExchangeCertificate -Services SMTP" aus, damit sichergestellt ist, dass der Microsoft Exchange-Transportdienst auf den Zertifikatschlüssel zugreifen kann."

 

Das Computerzertifikat der CA / des Exchange Servers ist jedoch gültig, 2021 ausgestellt und erst 2026 ablaufend, und enthält die richtigen Informationen; Get-ExchangeCertificate meldet dieses auch als "Valid". Wenn ich via dem Befehl in der letzten Zeile des letzten Absatzes dieses nochmal manuell via Thumbprint als zu verwendendes Zertifikat eintrage, ändert das nichts an den Fehlermeldungen.

 

Fehler 11005 scheint auch auf: "Das TLS-Zertifikat (Transport Layer Security) des Smarthosts für den Connector 'x' konnte nicht überprüft werden. Der Zertifikatüberprüfungsfehler für das Zertifikat ist UntrustedRoot. Wenn das Problem weiterhin besteht, wenden Sie sich an den Administrator des Smarthosts, um das Problem zu beheben."

 

Das nochmal deutlich interessantere: etwas in der Ereignisanzeige zurück recherchiert tauchen die beiden eben genannten Fehler seit 22. 3. 2022 auf, also schon Monate, bevor sich irgendwelche Symptome gezeigt haben. Und, das noch bessere: auch damals bzw. seit damals keine Änderungen am Server! Keine Updates installiert, keine Konfiguration verändert, keine Zertifikate abgelaufen oder neu ausgestellt. Die eben genannten Fehler tauchten aus blankem Himmel auf!

 

Aber nochmal: alle Zertifikate sind gültig. Sie sind noch nicht abgelaufen, und sie enthalten die richtigen Informationen. Alle anderen auf sie zugreifenden Dienste / Rollen, wie zB die VPN-Einwahl mit EAP-Authentifizierung, funktionieren weiterhin einwandfrei.

Ebenfalls nochmal betont: mit exakt dem gleichen Zertifikat, ausgestellt 2021, funktionierte alles einwandfrei - bis wie gesagt März 2022, wann, ohne jegliche Änderungen am System, auf einmal die beschriebenen Fehlermeldungen zu auftauchen begannen.

Nun ja. Vll. fällt ja wem mit mehr Erfahrung als ich was hilfreiches ein.

Beste Grüße
Markus

bearbeitet 23. November 2022 von markus0815

[NorbertFe 2.016]

Eigentlich meckert er ja auch nicht das Zertifikat an, sondern es fehlt eines mit dem Namen der im receive oder sendeconnnector unter helo String steht. Das musst du vergleichen und dann geht auch die Meldung weg. ;)

[markus0815 10]

So. Aus den SMTP Logs ging hervor, dass das versenden von Emails am 7. 11. noch funktionierte. Am 8. 11. nicht mehr. Als Unterschied konnte ein geänderter Thumbprint des für TLS bereitgestellten Zertifikats des angesprochenen Forwarding-Services ausgemacht werden. Die haben also heimlich still und leise Zertifikat gewechselt, auf eines das bei mir nicht vertrauenswürdig war. Support kontaktiert, von dort das entsprechende Zertifizierungsstellenzertifikat erhalten, und nun funktioniert die TLS-Authentifizierung auf den Forwarder wieder, und dementsprechend auch das versenden von Mails.

 

Zu den Fehlermeldungen (12014 & 11005) im Eventlog: die sind weiterhin vorhanden, haben aber keine Symptome. Trotzdem natürlich nicht wünschenswert. Die entsprechende FQDN ist auf jeden Fall bei den Konnektoren eingetragen; und wie gesagt, es hat ja vorher (vor März 2022) diese Fehlermeldungen nicht gegeben, und seitdem fand keine Änderung der Konfiguration statt.

 

Wenn jemand noch was einfällt, sehr gerne. Ansonsten ist zmd. das bis dato akute Problem gelöst.

[NorbertFe 2.016]

Die Fehlermeldung sagt eigentlich genau aus, was das Problem ist. Da wirst du genauer schauen müssen.