Jump to content

Outlook Anywhere - Zwischenzertifikat abfrage


Direkt zur Lösung Gelöst von NorbertFe,
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Wenn sich die Kollegen hier im Unternehmen von z.B Zuhause am Outlook anmelden kommt zum Anfang die oben zu sehende Abfrage. Wenn man ja klickt startet Outlook und alles ist gut. NUr kommt die Abfrage immer wieder. Auch wenn man das Zertifikat installiert wird man die Abfrage nicht los.

 

Soweit ich weiß ist es ein ZwischenZertfikat in dem das Stammzertfikat nicht enthalten ist. Und ich finde es auch nicht so toll ein "fremdes" Zertfikat über eine GPO in die Stammzertfikate zu schreiben. Wie löse ich das Problem das die Abfrage immer kommt. Ich habe etwas über Zertfikatsketten gelesen, komm aber nicht so ganz auf die Lösung.

post-72100-0-18936700-1489068252_thumb.png

Link zu diesem Kommentar

Nein, ist es nicht. Ich habe auf dem Exchange nur das von mir ausgestellte Zertifikat hinterlegt, das ich dann auch über GPO als Stammzertfikat verteile. Wie gesagt dieses Zwischenzertfikat kommt ja anscheinend vom "Provider" bzw. von Domainfactory. Dort haben wir unsere externe Outlook Adresse für Outlook Anywhere im Nameserver. (also dort liegen unsere Domains, Subdomains etc.)

Link zu diesem Kommentar

ich würde den srv-Eintrag im externen DNS lassen und statt dessen einen A-Record autodiscover.x.de setzen mit dem gleichen Ziel wie Deine OWA Adresse.

 

Funktioniert zuverlässig. Gegebenenfalls im externen DNS die "Autodiscover" Funktion deaktivieren. (So war das bei meiner Strato Webpräsens ... mit aktiven autodiscover und entsprechenden srv Eintrag lief das nicht sauber ... Autodiscoverdienst von Strato für meine Domäne deaktiviert und entsprechenden A-Record angelegt .. alles hübsch ... auch beim Microsoft Connectivity Analyzer)

Link zu diesem Kommentar

Das ist das typische Providerproblem dort. ;) https://domain.tld/autodiscover/autodiscover.xml reagiert "falsch" und damit kommt dieser Fehler zustande. Das hat in dem Fall erstmal nichts mit dem eigenen Exchangezertifikat zu tun. Oftmals kann und sollte der DNS Domain Eintrag beim Provider einfach entfernt werden. Falls der unbedingt benötigt wird, sollte man dann dafür sorgen, dass er nicht auf ssl reagiert (zu bevorzugen), oder ein entsprechendes Zertifikat und Host beim Provider konfigurieren.

 

Die Reihenfolge des Autodiscoverprozesses ist hartcodiert:

1. SCP (bei Domänenmitglieder)

2. https://domain.tld/autodiscover/autodiscover.xml

3. https://autodiscover.domain.tld/autodiscover/autodiscover.xml

4. http://domain.tld/autodiscover/autodiscover.xml

5. http://autodiscover.domain.tld/autodiscover/autodiscover.xml

6. SRV Record im DNS

 

Du siehst also, dass dir der SRV Record nur bedingt hilft in deinem Fall.

 

Bye

Norbert

Link zu diesem Kommentar
  • 1 Jahr später...
Am 10.3.2017 um 15:03 schrieb NorbertFe:

Das ist das typische Providerproblem dort. ;) https://domain.tld/autodiscover/autodiscover.xml reagiert "falsch" und damit kommt dieser Fehler zustande. Das hat in dem Fall erstmal nichts mit dem eigenen Exchangezertifikat zu tun. Oftmals kann und sollte der DNS Domain Eintrag beim Provider einfach entfernt werden. Falls der unbedingt benötigt wird, sollte man dann dafür sorgen, dass er nicht auf ssl reagiert (zu bevorzugen), oder ein entsprechendes Zertifikat und Host beim Provider konfigurieren.

 

Die Reihenfolge des Autodiscoverprozesses ist hartcodiert:

1. SCP (bei Domänenmitglieder)

2. https://domain.tld/autodiscover/autodiscover.xml

3. https://autodiscover.domain.tld/autodiscover/autodiscover.xml

4. http://domain.tld/autodiscover/autodiscover.xml

5. http://autodiscover.domain.tld/autodiscover/autodiscover.xml

6. SRV Record im DNS

 

Du siehst also, dass dir der SRV Record nur bedingt hilft in deinem Fall.

 

Bye

Norbert

 

Kannst du "Oftmals kann und sollte der DNS Domain Eintrag beim Provider einfach entfernt werden" nochmal erläutern. Habe die Änderungen gemacht und den SRV Eintrag beim Provider gelöscht und nur autodiscover.domain.tld hinzugefügt bekomme das Problem aber weiterhin. Thema ist zwar schon ein wenig älter, aber die "Probleme" häufen sich. Bei manchen kommt die Abfrage sehr oft hintereinander und man kann eigtl nicht arbeiten.

Link zu diesem Kommentar

Die Reaktionszeit ist der Hammer =D

 

Problem tritt bei Outlook 2016 und Outlook 2013 auf. Frisch gepatched oder etwas älter ist dabei egal. Problem tritt direkt auf wenn ich z.b. von internem WLAN auf Gast-Wlan wechsel, oder generell mich nicht in der Domäne (Also Domänennetzwerk) befinde.

Reverse Proxy ist nicht vorhanden. Der Exchange hat ein wildcard Zertifikat für *.domain.tld. Im Outlookverbindungssatus sehe ich ja auch das die Verbindung zu der externen Adressse des Exchange hergestellt wird. Was mich wundert ist warum der interne/FQDN des Servers (Siehe erster Post) angezeigt wird.

Auf der Firewall ist ein NAT eingerichtet welches alle Anfragen von https an die externe Exchnageadresse an den Exchange intern weiterleitet.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...