Exchange 2010 SP2 Certificate Issue

[DJNova 10]

Mahlzeit,

 

ich komme her mit einem alten Thema, bei dem aber leider keiner der Lösungsvorschläge hilft, die ich im Internet finde.

 

Aktuelle Situation:

 

1x Terminalserver mit Outlook 2010

1x Exchange Server 2010 SP2 mit CAS und Transport Hub-Rolle

 

Ich habe Outlook Anywhere konfiguriert und auch die internen sowie die externen Adressen am Exchange angepasst die im Bereich Client Access für OWA, ECP usw. zu finden sind.

Am IIS ist ein Zertifikat von GoDaddy installiert und auch die Services im Exchange passend zugewiesen. Das selbstsignierte Zertifikat ist allen anderen Services zugewiesen. Am IIS habe ich auch die Bindings so konfiguriert, dass für http und https mit der IP 127.0.0.1 das selbstsignierte Zertifikat verwendet wird und für alle anderen IPs das von GoDaddy.

 

Ich habe nun das Phänomen, dass beim Start von Outlook die Zertifikatswarnung kommt, ABER mit der Meldung, dass der Servername nicht passt... Wenn ich mir das Zertifikat ansehe, dann verwendet dieser das von GoDaddy und nicht das interne. Wieso? Bei anderen Kunden in der gleichen Konstalltion funktioniert das einwandfrei.

Was habe ich hier falsch gemacht oder nicht bedacht? Hat jemand einen kleinen Tipp für mich, wo ich noch nachsehen kann? Wieso greift Outlook auf die Schnittstelle zu, die mit dem offiziellen Zertifikat konfiguriert ist?

 

Am Client bzw Terminalserver ist auch die Verbindung via HTTP nicht konfiguriert und deaktiviert...

 

Wäre sehr dankbar wenn mir da jemand weiterhelfen könnte.

 

Danke, Michael

bearbeitet 3. April 2013 von DJNova

[NeMiX 76]

Wie sieht den die Dienstebindung im Exchange aus?

Seit Exchange 2010 muss man relativ selten im IIS Bindings anpassen, vieles geht über die Exchange Konsole.

[DJNova 10]

Die Bindings im Exchange sehen so aus: siehe Anhang1

 

und am IIS: siehe Anhang2

 

Kann es vielleicht mit diesem Thema zu tun haben: http://www.howexchangeworks.com/2011/07/service-connection-point-scp-in.html

bearbeitet 3. April 2013 von DJNova

[NorbertFe 2.041]

Steht doch in deinem 1. Screenshot, dass das externe Zertifikat an den IIS gebunden ist. Kannst du in der EMC umkonfigurieren. Bitte nicht im IIS Manager.

[RobertWi 81]

ich komme her mit einem alten Thema, bei dem aber leider keiner der Lösungsvorschläge hilft, die ich im Internet finde.

 

Und das liegt daran, dass es keine Pauschallösung gibt. Man muss ich das Netzwerk, DNS, die Geräte, Anforderungen, Geld, usw. anschauen und dann individuelle Lösungen finden.

 

Und man braucht Infos, die Du hier auch nicht wirklich lieferst.

 

Ich habe Outlook Anywhere konfiguriert und auch die internen sowie die externen Adressen am Exchange angepasst die im Bereich Client Access für OWA, ECP usw. zu finden sind.

 

Hast Du auch die EWS-URL mit der Shell angepasst?

 

Am IIS ist ein Zertifikat von GoDaddy installiert und auch die Services im Exchange passend zugewiesen. Das selbstsignierte Zertifikat ist allen anderen Services zugewiesen. Am IIS habe ich auch die Bindings so konfiguriert, dass für http und https mit der IP 127.0.0.1 das selbstsignierte Zertifikat verwendet wird und für alle anderen IPs das von GoDaddy.

 

Ah ja.

 

Ich habe nun das Phänomen, dass beim Start von Outlook die Zertifikatswarnung kommt, ABER mit der Meldung, dass der Servername nicht passt... Wenn ich mir das Zertifikat ansehe, dann verwendet dieser das von GoDaddy und nicht das interne. Wieso?

 

Weil Du es so im Exchange und IIS zugeordnet hast!? Du schreibst Du selbst: Am IIS habe ich auch die Bindings so konfiguriert, dass für http und https mit der IP 127.0.0.1 das selbstsignierte Zertifikat verwendet wird und für alle anderen IPs das von GoDaddy.

 

Bei anderen Kunden in der gleichen Konstalltion funktioniert das einwandfrei.

 

Ach, und warum geht es dann bei Dir nicht? Muss wohl doch was anders sein, oder? ;)

 

Was habe ich hier falsch gemacht oder nicht bedacht? Hat jemand einen kleinen Tipp für mich, wo ich noch nachsehen kann? Wieso greift Outlook auf die Schnittstelle zu, die mit dem offiziellen Zertifikat konfiguriert ist?

 

Auf welche sollte er denn sonst zugreifen?

[DJNova 10]

Ich habe mir jetzt nochmal alles durchgesehen, und auch die EWS Config nochmal überarbeitet. Jetzt kommt aber noch immer die Zertifikatswarnung, weil der Servername nicht mit dem im Zertifikat übereinstimmt. Es hilft mir nicht viel, wenn man meine Aussagen unf Fragen kommentiert. Ich wollte die Situation schildern, und wenn zu wenig Infos sind, reiche ich die mit Vergnügen nach. Ich zweifle auch nicht an der Kompetenz der Leute, die mir hier Hilfe anbieten... Ich bräuchte nur einen kleinen Hinweis, oder irgendwas, das mich wieder auf die richtige Bahn bringt. Vielleicht habe ich einen kleinen Denkfehler gemacht und/oder in der Konfiguration etwas nicht bedacht, nicht konfiguriert oder aber auch verkonfiggt...

Beim Test der Autokonfiguration via Outlook zeigt er mir alle Pfade korrekt an... :-(

[RobertWi 81]

Wenn Du die Bindungen im IIS wie oben beschrieben hast, funktioniert alles korrekt.

 

Du hast das Godaddy-Zertifikat an die externen IP-Adressen gebunden, also meldet es sich dort.

 

Je nach Geräten und Netzwerk sind Lösungen mit einem Zertifikat, mit mehreren oder mit SAN-Zertifikaten möglich.

 

Wenn ich beim Kunden bin, dauert das einen halben Tag: Analyse, Erklärung, Festlegung.

 

Was meinst Du, wie lange das in einem Forum dauert? Wie gesagt: Es gibt keine Pauschallösung.

[DJNova 10]

So, jetzt habe ich alles nochmal durch. Ich habe zwar die interne Adresse für EWS angepasst, aber auf den Autodiscover vergessen. Anscheinend dauernd in der falschen Zeile geschaut... Man wird bilnd, wenn man sich dauernd mit einem Thema beschäftigt.

 

Ich habe es nun gelöst als ich folgende zwei Verzeichnisse geändert habe:

Set-ClientAccessServer -Identity CASSRV -AutodiscoverServiceInternalUri https://EXTERNE-URL/autodiscover/autodiscover.xml

Set-WebServicesVirtualDirectory -Identity "CASSRV\EWS (Default Web Site)" -InternalUrl https://EXTERNE-URL/ews/exchange.asmx

Set-OABVirtualDirectory -Identity "CASSRV\OAB (Default Web Site)" -InternalUrl https://EXTERNE-URL/oab

Danke für den Denkanstoß :jau:

[RobertWi 81]

Das, was Du gemacht hast, nennt sich SplitDNS.

 

Das passt zwar nicht zu Deiner Beschreibung eingangs, ist aber auch eine Lösung.

[DJNova 10]

Ich habe mich zu früh gefreut... Nach dem Start von Outlook dauert es ca. 15-30 Sekunden, und es kommt wieder ein Warnhinweis, dass der Servername im Zertifikat nicht mit dem eigentlichen Servernamen übereinstimmt... :angry:

[RobertWi 81]

Dann prüfe mit der Outlook-Funktion "E-Mail-Autokonfiguration testen..." mal, welche URLs da wirklich kommen.

 

Und Hinweis: Änderungen (bis auf die Autodiscover-URL, die kommt ja aus AD) werden gecacht, es kann einige Zeit dauern, bis geänderte URL wirksam werden.

[DJNova 10]

Autodiscover kann ich jetzt gar keinen mehr machen... Ich habe die interne URL des Autodiscovers auf die externe URL gesetzt und jetzt sagt er, dass die Einstellungen nicht bestimmt werden konnten. Setze ich wieder auf die interne zurück für den Autodiscover, dann kommt die Zertifikatsmeldung sofort bzw kommt 2mal.

bearbeitet 3. April 2013 von DJNova

[RobertWi 81]

Namensauflösung ist fehlerfrei?

[DJNova 10]

Namensauflösung ist fehlerfrei?

Jap, die funktioniert.

[RobertWi 81]

Welche Fehlermeldung gibt es denn im Assistenten für "E-Mail-Autokonfiguration testen..." in Outlook?