Outlook Anywhere - Zwischenzertifikat abfrage

[Vinc211 1]

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.

[Dukel 454]

Die Zwischenzertifikate werden vom eigentlichen Webserver zusammen mit dem Serverzertifikat ausgeliefert.

Ist auf dem Exchange Server das Zwischenzertifikat installiert?

[Vinc211 1]

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.)

[NilsK 2.937]

Moin,

 

das Zwischenzertifikat muss auch auf den Server.

 

Gruß, Nils

[Vinc211 1]

Reicht es wenn ich das Zwischenzertfikat aus meinem Speicher exportiere und im Exchange 2016 einfüge?

 

Ich habe bei Domainfactory gesucht aber nichts gefunden wo ich das Zertfikat runterladen könnte.

[testperson 1.680]

Hi,

 

ich habe das Gefühl, dass dein Autodiscover nicht korrekt funktioniert bzw. dass es da hakt.

 

Dein Exchange nutzt ein selbstsigniertes Zertifikat?

Gibt es extern den Host autodiscover.<deine-domain>.<tld> der auf deine Firewall bzw. deinen Exchange zeigt?

 

Gruß

Jan

[Vinc211 1]

Nein, nur die OWA Adresse ist von außen erreichbar. Es gibt folgende Einträge

 

owa.x.de - Typ A - ZIEL 123.234.222.255

 

_autodiscover._tcp.x.de - Typ SRV - ZIEL owa.x.de

[testperson 1.680]

Und beim Provider (Domainfactory) gibt es einen Wildcard DNS Eintrag oder eine Autodiscover-Konfiguration sowie einen Webserver der per https erreichbar ist. Da dürfte der Fehler liegen.

 

Ich würde dir zu Split DNS und einem SAN Zertifikat raten.

[Squire 262]

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)

[NorbertFe 2.035]

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

[Vinc211 1]

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.

[NorbertFe 2.035]

Dann liegts meist auch nicht am Server/DNS sondern am Client oder Proxy. Welche Versionen (patchstand) von Outlook setzt du ein? Tritt das Problem intern oder extern auf?

[Vinc211 1]

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.

[NorbertFe 2.035]

Gerade eben schrieb Vinc211:

Reverse Proxy ist nicht vorhanden.

Ich meinte auch Forward Proxies. Welche Exchangeversion nutzt du?

[Vinc211 1]

Forward Proxies nicht vorhanden wenn man nicht im Netz ist.

Exchange 2016 CU7 (Fehlen also 2)