DIS

OK, Danke - werde ich bei Gelegenheit probieren. Danke für die Hilfe, das Wichtigste ist klar. lg

wacx.exe - A simple Windows ACMEv2 client

Beim Erstellen des Zertifikates mit LetsEncrypt legt er es bequem im Windows Zertifikatspeicher unter "Eigene Zertifikate->Zertifikate" ab, da wo auch das Exchange Zertifikat drinnen ist.- Exchange zeigt es dann automatisch unter "Server->Zertifikate" an. Also ich hab hier nichts manuell importiert oder so....

Ja, klar, aber Standardmäßig eingerichtet... Ja, alles grün Sonst würde ich mir ja sorgen machen. Mir missfällt nur, dass ich mein LetsEncrypt ZErtifikat nicht für SMTP aktivieren kann. Ansonsten geht eh alles und ich frag mich eben ob ich mich dann zurücklehnen kann...

OK, danke - für SMTP enabled ist einzig und alleine das Standard "WMSVC-SHA2" Zertifikat. Wenn ich versuche mein LetsEncrypt Zetifikat (welches für IMAP, POP, IIS enabled ist) auch für SMTP zu enablen werde ich zwar gefragt: "Soll das vorhandene SMTP-Standardzertifikat überschrieben werden? Aktuelles Zertifikat: 'XXXXX' (läuft am 24.02.2028 15:32:01 ab) Ersetzen durch Zertifikat: 'YYYYY' (läuft am 06.02.2023 12:58:18 ab)" Wenn ich das mit ja beantworte ändert sich leider nichts daran. Beim LetsEncrypt bleibt "nur" IMAP, POP, IIS stehen. Von SMTP ist nichts zu sehen und beim "WMSVC-SHA2" bleibt SMTP stehen und ist auch ausgegraut, sprich kann nicht deaktiviert werden. Irgendwie seltsam. Stellt das ein Problem dar dem ich nachgehen sollte oder kann man das so belassen?

Nachdem ich mich jetzt mal ein wenig mit dem Thema Exchange 2016 und TLS 1.2 beschäftigen musste ist mir aufgefallen, dass Standardmäßig keinem meiner Receive Connectoren ein TLSCertificate zugeordnet ist. Bei Ausführung des CMDs "Get-ReceiveConnector |fl Name, TlsCertificatename, Bindings" bleibt die Spalte TlsCertificateName bei allen Konnektoren leer. Der Exchange funktioniert soweit perfekt und unterstützt nach den gängigen Tests auch TLS 1.2. Muss dann einem Connector ein Zertifikat zugeordnet werden bzw. was bringt sich das wenn es offensichtlich auch ohne geht?

Ok, danke für die Inputs. Ich kann wirklich nirgendwo ein Problem mit dem Zertifikat finden. Soweit funktioniert ja alles (bis auf RCA). Dann lasse ich das jetzt einfach mal so stehen...

Habe beim Zertifikat nun auch SMTP aktiviert - leider keine Änderung. Aktuell nur eine Cisco RV345. Hab die Firewall dort mal kurz deaktiviert, leider auch keine Änderung :(

Hi, mein Exchange 2016 verwendet ein LetsEncrypt Zertifikat. Dem Zertifikat sind im AdminCenter die Dienste "IMAP, POP, IIS" hinterlegt. Alle Outlook und Smartphone Clients funktionieren sowohl von intern als auch extern problemlos. OWA funktioniert problemlos und der Browser zeigt beim Verwenden von OWA das korrekte Zertifikat an. Wenn ich mit dem Microsoft Remote Connectivity Analyzer einen Outlook Connectivity Test mache schlägt er an der folgenden Stelle fehl: The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server xxx.tld on port 443.The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate. Additional Details: The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation. Ich habe keine Ahnung warum bzw. seit wann das so ist. Kann wer helfen?

Ok - dann kenn ich mich jetzt aus.

Keine Ahnung. Mir stellt sich nur die Frage, dass wenn RPC/HTTP ohnehin besser ist warum dann Exchange/Outlook nicht ohnehin standardmäßig RPC/HTTP verwendet.

​Ich habe die Einstellung ServerExclusiveConnect für EXPR jetzt wie du gesagt hast aktiviert. Es wird jetzt auch unter <Type>EXPR</Type> <ServerExclusiveConnect>on​</ServerExclusiveConnect> angezeigt. Die Folge ist jetzt, dass alle Clients, also egal ob sie sich in der Domäne befinden oder sich nicht in der Domäne befinden und per hosted Exchange zugreifen von Anfang an ausschließlich RPC/HTTP verwenden. Wäre es nicht besser bzw. möglich dass die internen Clients weiterhin RPC/TCP nutzen?

Da interne Domains immer öfter nichtmehr in ein Zertifikat aufgenommen werden können habe ich an einem Exchange Server 2010 Split-DNS eingerichtet und: - Alle Dienste (ECP, EAS, OABD, OWA, Autodiscover, WebServicesVirtualDirectory) - Den Service Connection Point (SCP) im Active Directory - Den RPCClientAccessServer Parameter der Datenbank so umkonfiguriert, dass sowohl intern als auch extern nur mehr die von extern erreichbare Clientzugriffsdomäne mail.sss.at verwendet wird. Folglich muss der interne FQDN "Server01.sss.local" nichtmehr im Zertifikat stehen. Diese Konfiguration funktioniert mittlerweile auch und alle neu eingerichteten Clients werden per Autodiscover richtig konfiguriert und können auf ihre Exchangekonten zugreifen. Mir ist allerdings aufgefallen, dass der Clientzugriff von Extern dadurch wesentlich langsamer geworden ist. Der Grund dafür ist, dass vorher die Verbindung über RPC/TCP aufgebaut wurde. Jetzt probiert Outlook beim Start immer zuerst RPC/TCP bekommt aber keine Verbindung und dann nach ca. 30 Sekunden wird RPC/HTTPS versucht, was auch funktioniert. Wenn ich den Server jetzt in die DMZ stelle ist das Problem weg und der externe Zugriff funktioniert ohne Verzögerung und Wartezeiten wieder über RPC/TCP. In der Verbindungsübersicht tauchen immer die Ports 6010 sowie 10872 auf. Wenn der Server jedoch nicht in der DMZ steht und man Portweiterleitungen für die beiden Ports anlegt ist das Problem jedoch wieder da. Folglich müssen hier noch andere Ports im Spiel sein. Bei diversen Recherchen habe ich jedoch nichts gefunden und ich möchte den Server nicht unbedingt in der DMZ stehen haben..... Vielleicht hat hier jemand eine Lösung - ansonsten muss ich mir mal eine Nacht mit Wireshark um die Ohren schlagen....

Vielen Dank für die professionelle Hilfe. Jetzt funktioniert es so wie ich mir das vorgestellt habe!

Ok, aber um es mal zu testen: Müsste ich dann "autodiscover.uuu.at" als SRV-Record anlegen mit dem Zielhost sss.at und einem Port z.B. 999. Und im IIS dann eine https-Bindung mit ebenfalls dem Port 999?