Hallo zusammen,
wie der Titel schon sagt habe ich ein Problem mit einer Zertifikatswarnung im Outlook, wenn ich ein Zertifikat verwende, dass den internen Namen des Mailservers nicht enthält. Die Umgebung sieht wie folgt aus: Exchange 2019 (aktuelles CU und SU), Clients Outlook aus Office 365, für Zugriffe von Extern ist eine Sophos UTM mit Mail Protection und Web Server Protection im Einsatz. Die Postfächer sind alle On-Prem, es gibt keine Hybridstellung mit M365, lediglich ein AADConnect zur Synchronisierung der User für die Lizenz von O365.
Bisherige Konfiguration sah so aus, dass die virtuellen Verzeichnisse in den internen URLs auf servername.domäne.com und die externen URLs auf mail.domäne.com lauteten. Der Exchange hat ein Zertifikat aus unserer internen CA, in der servername.domäne.com, mail.domäne.com und autodicover.domäne.com enthalten sind. Auf der Sophos ist ein gekauftes Zertifikat einer öffentlichen CA eingespielt, welches nur mail.domäne.com und autodiscover.domäne.com enthält. Das funktioniert auch alles einwandfrei.
Aufgrund der Anforderung der letzten SU, Extended Protection zu aktivieren und dann auf dem Exchange ja das gleiche Zertifikat verwendet werden muss wie auf der Sophos (SSL Bridging) kann das aber leider so nicht bleiben. Ich habe daher folgende Anpassung der Konfiguration durchgeführt: alle internen URLs der virtuellen Verzeichnisse auf mail.domände.com und das autodiscover auf autodiscover.domäne.com geändert. Entsprechende Einträge im internen DNS sind vorhanden und verweisen auf die IP des Exchange. Der Outlook Verbindungsstatus und auch der "E-Mail Konfigurationstest" von Outlook zeigen mir nun nur noch Verbindungen auf mail.domände.com an. Das Skript von Franky, welches einem die notwendigen Hostnamen für das Zertifikat anzeigt, gibt nun auch aus, dass ich im Zertifikat nur mail.domände.com und autodiscover.domäne.com benötige.
Nun das Problem: Sobald ich das öffentliche Zertifikat einspiele und auf die Dienste binde, bekomme ich am Outlook ca. 10 Sekunden, nachdem die Verbindung bereits steht eine Zertifikatswarnung von servername (ohne Domäne), dass der Name nicht im Zertifikat steht. Ich habe bisher nicht rausfinden können, warum es hier noch eine Kommunikation gibt, die mit dem internen Servernamen erfolgt. Neustart des Servers und des Clients sowie ein flushdns haben nichts gebracht.
Hat irgendeiner von euch noch einen Tipp, wo ich noch suchen kann? Nach allem was ich bisher gelesen hatte war ich davon ausgegangen, das die o.g. Konfiguration reichen sollte, um mein Ziel zu erreichen. Ich habe also entweder irgendwas übersehen, oder das Prinzip doch nicht verstanden. Den internen Namen ins Zertifikat eintragen zu lassen ist aktuell keine Option, da das Zertifikat noch bis April 2023 läuft und ich würde mit der Extended Protection ungern so lange warten.
Danke schon mal im Voraus für jegliche Tipps und Hinweise.
Den internen Namen ins Zertifikat eintragen zu lassen ist aktuell keine Option, da das Zertifikat noch bis April 2023 läuft und ich würde mit der Extended Protection ungern so lange warten.
Der hat da grundsätzlich auch nichts zu suchen. Was gibt dir denn ein get-clientaccessservice |fl *uri* zurück? Funktioniert es, wenn du neue Outlook Profile erstellst? Falls ja, dann solltest du das interne Zertifikat (mit externem Namen) neu binden und warten bis sich die Profile alle auf den neuen Namen per Autodiscover umkonfiguriert haben. Schwund wirst du aber immer haben.
Hallo Norbert,
bei dem Befehl gibt er mir "https://autodiscover.domäne.com/Autodiscover/autodiscover.xml" zurück. Mit neuem Profil hatte ich nicht getestet, ich hatte nur die lokale .ost und die lokale autodiscover.xml mal gelöscht. Verhalten war aber das gleiche, ca. 10 Sekunden nachdem Outlook gestartet ist kommt die Zertifikatsmeldung. Nachdem ich dann das alte Zertifikat wieder eingespielt und gebunden hatte war die Warnung wieder weg, die anderen Änderungen hatte ich natürlich so belassen. Zuerst dachte ich auch "Ok, warst zu ungeduldig", daher hatte ich das einen Tag später noch mal probiert, aber das gleiche. Sobald das öffentliche Zertifikat importiert und gebunden ist tritt das Verhalten auf.
Was mich halt irritiert ist, dass ich außer in dieser Warnung nirgendwo mehr einen Verweis auf "servername.domäne.com" sehe, sondern nur noch auf "mail.domäne.com" und "autodiscover.domäne.com". Einzige Ausnahme sind einige der Default Empfangsconnectoren, die verlangen aber zwingend den echten FQDN des Mailservers oder ein $null weil "Exchange Authentifizierung" in denen aktiviert ist. Aber die sollten ja auf den Outlook Client keine Auswirkungen haben, oder?
Hast du sonst noch Vorschläge?
Was passiert denn, wenn du mal auf "Ja" bei der Zertifikatswarnung klickst. Tritt es danach weiterhin auf?
Wenn ich die Warnung mit "Ja" bestätige ist die Meldung weg und kommt nicht wieder, allerdings nur bis Outlook geschlossen und wieder geöffnet wird. Dann geht das Spiel von vorne los.
Was ist mit einem neuen Outlook Profil? Dauert ja nur ca. 30 Sekunden mal ein paralleles Outlook Profil anzulegen. Tritt der Fehler dort auch auf?
Das werde ich heute Abend einmal ausprobieren, wenn die anderen Mitarbeiter weg sind. Im Moment ist ja das "interne" Zertifikat aktiv und wenn ich das jetzt ändere zum Testen bricht hier bei unseren Nutzern Panik aus (Von wegen Fehlermeldung, die werden bei uns schnell nervös).
Ich poste dann das Ergebnis heute Abend oder morgen früh.
Im Moment ist ja das "interne" Zertifikat aktiv und wenn ich das jetzt ändere zum Testen bricht hier bei unseren Nutzern Panik aus (Von wegen Fehlermeldung, die werden bei uns schnell nervös).
Wie ich oben schon schrieb. Erstell dir ein neues internes Zertifikat, welches die externen und DEN internen Namen beinhaltet. Dann darf ja keine Meldung kommen. Dann mal 24h warten. Ansonsten wirklich nochmal genau prüfen ob du alle URLs wirklich geändert hast.
So ich habe es jetzt mal mit neuem Profil getestet. Bei einem neuen Profil, egal auf welchem Rechner, taucht die Warnung nicht auf, wenn das öffentliche Zertifikat aktiv ist. Somit ist das Problem nicht der Server sondern es scheint irgendwas in dem bestehenden Profil auf den internen Namen zu zeigen. Kann man das irgendwie prüfen bzw. korrigieren, weil für knapp 100 User neue Outlook Profile erstellen zu müssen fände ich ehrlich gesagt nicht ganz so toll.
Ich wiederhole es gern noch mal. Versuch erstmal ein internes Zertifikat mit dem internen (bisherigen) Namen und den externen Namen eine Weile laufen zu lassen. Dann nach ein paar Tagen kannst du mal auf das externe schwenken und schauen ob dann immer noch Meldungen kommen.
Ich wiederhole es gern noch mal. Versuch erstmal ein internes Zertifikat mit dem internen (bisherigen) Namen und den externen Namen eine Weile laufen zu lassen. Dann nach ein paar Tagen kannst du mal auf das externe schwenken und schauen ob dann immer noch Meldungen kommen.
OK, ich gebe zu, ich verstehe den Gedanken dahinter nicht wirklich. Aktuell habe ich 2 Zertifikate zur Verfügung:
Zertifikat 1 (derzeit aktiv): Von interner CA ausgestellt, CN ist mail.domäne.com, SAN enthält servername.domäne.com, mail.domäne.com und autodiscover.domäne.com
Zertifikat 2 (soll aktiv werden): Von öffentlicher CA ausgestellt, CN ist mail.domäne.com, SAN enthält mail.domäne.com und autodiscover.domäne.com
Die Namen mail und autodiscover sind die externen Namen (per Split-DNS aber auch intern erreichbar), servername ist der interne Name des Servers. Die internen URLs sind definitiv alle auf die externen Namen umgestellt (die externen URLs waren es schon vorher).
Du schreibst, ich soll jetzt in unserer internen CA ein neues Zertifikat erstellen, dass die externen und den internen Namen enthält, und dass dann laufen lassen. Genau das steht aber ja auch schon in dem jetzigen Zertifikat 1. Was sollte sich also dadurch ändern, was auf die Verwendung von Zertifikat 2 Auswirkung hat? Zumal ein neues Profil ja funktioniert, wenn ich Zertifikat 2 benutze, sogar auf dem gleichen Rechner, wo schon mein bisheriges Profil drauf ist.
Wäre nett, wenn du mir das etwas näher erklären könntest.
Danke.
Ah ich hab übersehen, dass dein bisheriges Zertifikat schon die externen Namen beinhaltet. Dann kannst du dir meinen Vorschlag tatsächlich sparen. Wenn du also alle URLs geprüft hast, hab ich erstmal keine richtige Idee. Wäre die Frage, ob die Fehlermeldung bei allen outlooks auftritt oder nur bei deinen testkandidaten.
OK, danke, dachte schon ich hätte da irgendwo noch einen Denkfehler. Ich habe das bisher nur mit meinem eigenen User getestet, ich werde das noch mal mit zwei, drei anderen Usern testen auf Rechnern, wo jetzt schon ein Profil existiert. Ich berichte dann.
Es kommt mir halt sehr eigenartig vor, vor allem wegen der knapp 10 Sekunden zwischen "Outlook ist offen" und "Warnung ploppt auf". Als wenn Outlook noch irgendwas nachladen wollte, was dann auf den internen Namen zeigt. Als wir damals den Umzug von Exchange 2013 nach 2019 gemacht hatten und das Zertifikat noch nicht drin war kam die Meldung soweit ich ich erinnere sofort beim Öffnen und nicht erst später.
Falls dir doch noch was einfällt oder sonst noch wer eine Idee hat gerne melden.
Ich habe es jetzt noch einmal mit einigen anderen Usern getestet. Sofern schon ein Profil existiert und ich dieses benutze kommt die Warnmeldung, sobald das öffentliche Zertifikat gebunden ist. Ich habe dann auch in der Ereignisanzeige unter "Sicherheit" einen entsprechenden Logon Eintrag, der meine Anmeldedaten gegen servername.domände.com auf Port 443 prüft (und nicht gegen mail.domäne.com). Der Prozess ist einmal Outlook und noch die svchost.exe (wo sich ja alles mögliche hinter verbergen kann). Somit will da auf jeden Fall noch irgendwas in dem Outlook-Profil mit dem internen Namen sprechen, ich finde aber schlicht nicht wo.
Ich hoffe irgendwer hat noch ne zündende Idee, wenn ich jetzt bei knapp 100 Usern die Outlook-Profile neu machen darf wird's unlustig.
Wenn du ein altes Profil mit dem externen Zertifikat öffnest, und dann mal den Outlook Verbindungstest startest. Was steht dann alles in der Protokolldatei (XML)?
Noch ein interessantes Verhalten: Wenn ich Outlook aufhabe und das externe Zertifikat binde dann passiert erst mal nichts. Die Warnmeldung kam dann nach ca. 20 Minuten. Beim Neustart von Outlook kommt die Meldung nach ca. 10 Sekunden. Hier der Output vom Verbindungstest (habe die personalisierten Daten natürlich anonymisiert):
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>Anzeigename</DisplayName>
<LegacyDN>/o=domäne/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=0b4046a432464f8597b0791d0ee89b19-Nachname, D</LegacyDN>
<AutoDiscoverSMTPAddress>user@domäne.com</AutoDiscoverSMTPAddress>
<DeploymentId>706d23e1-25dd-4513-94be-6a6b231bc553</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<MicrosoftOnline>False</MicrosoftOnline>
<ConsumerMailbox>False</ConsumerMailbox>
<Protocol Type="mapiHttp" Version="1">
<MailStore>
<InternalUrl> https://mail.domäne.com/mapi/emsmdb/?MailboxId=a56d473c-bc9f-43d1-8273-7493ecc75d5a@domäne.com</InternalUrl>
<ExternalUrl> https://mail.domäne.com/mapi/emsmdb/?MailboxId=a56d473c-bc9f-43d1-8273-7493ecc75d5a@domäne.com</ExternalUrl>
</MailStore>
<AddressBook>
<InternalUrl> https://mail.domäne.com/mapi/nspi/?MailboxId=a56d473c-bc9f-43d1-8273-7493ecc75d5a@domäne.com</InternalUrl>
<ExternalUrl> https://mail.domäne.com/mapi/nspi/?MailboxId=a56d473c-bc9f-43d1-8273-7493ecc75d5a@domäne.com</ExternalUrl>
</AddressBook>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba"> https://mail.domäne.com/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl> https://mail.domäne.com/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba"> https://mail.domäne.com/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl> https://mail.domäne.com/EWS/Exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
<Protocol>
<Type>EXHTTP</Type>
<Server>mail.domäne.com</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<ASUrl> https://mail.domäne.com/EWS/Exchange.asmx</ASUrl>
<EwsUrl> https://mail.domäne.com/EWS/Exchange.asmx</EwsUrl>
<EmwsUrl> https://mail.domäne.com/EWS/Exchange.asmx</EmwsUrl>
<EcpUrl> https://mail.domäne.com/owa/</EcpUrl>
<EcpUrl-um>?path=/options/callanswering</EcpUrl-um>
<EcpUrl-aggr>?path=/options/connectedaccounts</EcpUrl-aggr>
<EcpUrl-mt>options/ecp/PersonalSettings/DeliveryReport.aspx?rfr=olk&exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx>&realm=domäne.com</EcpUrl-mt>
<EcpUrl-ret>?path=/options/retentionpolicies</EcpUrl-ret>
<EcpUrl-sms>?path=/options/textmessaging</EcpUrl-sms>
<EcpUrl-publish>?path=/options/calendarpublishing/id/<FldID></EcpUrl-publish>
<EcpUrl-photo>?path=/options/myaccount/action/photo</EcpUrl-photo>
<EcpUrl-tm>options/ecp/?rfr=olk&ftr=TeamMailbox&exsvurl=1&realm=domäne.com</EcpUrl-tm>
<EcpUrl-tmCreating>options/ecp/?rfr=olk&ftr=TeamMailboxCreating&SPUrl=<SPUrl>&Title=<Title>&SPTMAppUrl=<SPTMAppUrl>&exsvurl=1&realm=domäne.com</EcpUrl-tmCreating>
<EcpUrl-tmEditing>options/ecp/?rfr=olk&ftr=TeamMailboxEditing&Id=<Id>&exsvurl=1&realm=domäne.com</EcpUrl-tmEditing>
<EcpUrl-extinstall>?path=/options/manageapps</EcpUrl-extinstall>
<OOFUrl> https://mail.domäne.com/EWS/Exchange.asmx</OOFUrl>
<UMUrl> https://mail.domäne.com/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl> https://mail.domäne.com/oab/27deefaa-e866-464c-a21c-5299b0333db0/</OABUrl>
<ServerExclusiveConnect>On</ServerExclusiveConnect>
</Protocol>
<Protocol>
<Type>EXHTTP</Type>
<Server>mail.domäne.com</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<ASUrl> https://mail.domäne.com/EWS/Exchange.asmx</ASUrl>
<EwsUrl> https://mail.domäne.com/EWS/Exchange.asmx</EwsUrl>
<EmwsUrl> https://mail.domäne.com/EWS/Exchange.asmx</EmwsUrl>
<EcpUrl> https://mail.domäne.com/owa/</EcpUrl>
<EcpUrl-um>?path=/options/callanswering</EcpUrl-um>
<EcpUrl-aggr>?path=/options/connectedaccounts</EcpUrl-aggr>
<EcpUrl-mt>options/ecp/PersonalSettings/DeliveryReport.aspx?rfr=olk&exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx>&realm=domäne.com</EcpUrl-mt>
<EcpUrl-ret>?path=/options/retentionpolicies</EcpUrl-ret>
<EcpUrl-sms>?path=/options/textmessaging</EcpUrl-sms>
<EcpUrl-publish>?path=/options/calendarpublishing/id/<FldID></EcpUrl-publish>
<EcpUrl-photo>?path=/options/myaccount/action/photo</EcpUrl-photo>
<EcpUrl-tm>options/ecp/?rfr=olk&ftr=TeamMailbox&exsvurl=1&realm=domäne.com</EcpUrl-tm>
<EcpUrl-tmCreating>options/ecp/?rfr=olk&ftr=TeamMailboxCreating&SPUrl=<SPUrl>&Title=<Title>&SPTMAppUrl=<SPTMAppUrl>&exsvurl=1&realm=domäne.com</EcpUrl-tmCreating>
<EcpUrl-tmEditing>options/ecp/?rfr=olk&ftr=TeamMailboxEditing&Id=<Id>&exsvurl=1&realm=domäne.com</EcpUrl-tmEditing>
<EcpUrl-extinstall>?path=/options/manageapps</EcpUrl-extinstall>
<OOFUrl> https://mail.domäne.com/EWS/Exchange.asmx</OOFUrl>
<UMUrl> https://mail.domäne.com/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl> https://mail.domäne.com/oab/27deefaa-e866-464c-a21c-5299b0333db0/</OABUrl>
<ServerExclusiveConnect>On</ServerExclusiveConnect>
</Protocol>
<AlternativeMailbox>
<Type>Delegate</Type>
<DisplayName>support@domäne.com</DisplayName>
<SmtpAddress>support@domäne.com</SmtpAddress>
<OwnerSmtpAddress>support@domäne.com</OwnerSmtpAddress>
</AlternativeMailbox>
<AlternativeMailbox>
<Type>Delegate</Type>
<DisplayName>Administrator</DisplayName>
<SmtpAddress>Administrator@domäne.com</SmtpAddress>
<OwnerSmtpAddress>Administrator@domäne.com</OwnerSmtpAddress>
</AlternativeMailbox>
<PublicFolderInformation>
<SmtpAddress>MBX01@domäne.com</SmtpAddress>
</PublicFolderInformation>
</Account>
</Response>
</Autodiscover>
Wieviele zusätzliche Postfächer haben die Leute denn so eingebunden? Wäre es möglich, dass die Meldung quasi für jedes zusätzliche Postfach einmalig aufploppt bei jedem Start eins sozusagen?
Im Zweifel musst du dich ja nur um das löschen der Profile kümmern. Die Erstellung geht ja per gpo automatisch ohne user Interaktion.
Wenn zusätzliche Postfächer angebunden sind, dann sind es in der Regel 1-3, wobei wir auch User haben, die gar keine zusätzliche Postfächer haben. Ich selbst habe wie man sieht 2. Die Idee, dass es daran liegen könnte, hatte ich auch schon und hatte mir mal testweise die zusätzlichen Postfächer weggenommen, hat aber leider am Verhalten nichts geändert. Die Meldung kommt auch nur einmal, nicht mehrmals.
Die Meldung kommt auch nur einmal, nicht mehrmals.
Einmalig oder bei jedem Start einmalig?
Bei jedem Start einmalig, sonst wäre das ja relativ unproblematisch den Usern zu erklären, dass sie da einmal auf "Ja" drücken müssen.