markus0815

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.

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

Hi. Mein internes Netzwerk ist im Subnetz 192.168.10.x. Mein W2k8 Rechner der Routing & RAS macht hat die IP 192.168.10.23. Er leitet zum Modem weiter, und darum ist er bei allen anderen Rechnern im Subnetz als Standardgateway eingetragen. Nun habe ich auf ihm eine VPN Verbindung zu einer Remote Location erstellt. Er wählt sich dort ein (dortiges Subnetz ist 192.168.8.x) und bekommt die IP 192.168.8.40 zugewiesen. Auf dem Rechner selbst kann ich auch IPs in diesem Subnetz erreichen, von überall anders hier kann ich aber nur 192.168.8.40 erreichen, mehr nicht. Hab schon ein paar Routen erstellt etc, es hat nichts zu Erfolg geführt. Es muss doch eine Möglichkeit geben die eine Einwahlverbindung auf meinen Server für alle anderen Rechner im Netz zugänglich zu machen. - Markus