4
Problem nach Erneuerung eines offiziellen Zertifikats für MS Exchange 2010
Nur FQDN-Zertifikate werden akzeptiert, MS Outlook 2010 bemängelt ein fehlendes Zertifikat für den internen Servernamen
Seit Jahren erstelle ich mit Hilfe des Assistenten von MS Exchange 2010 die Zertifikatsanforderungen nach folgendem Prinzip, inkl. der internen Domänen.
http://support.godaddy.com/help/article/6086/generating-a-certificate-s ...
Nun entstand durch die Änderung der Richtlinien bei GD zum ersten Mal ein Problem, dass möglicherweise demnächst viele von Euch betreffen wird und für das ich nun eine Lösung suche.
Die Erstellung eines UNC-Zertifikats mit internen Domänen-Namen ist bei GD nicht mehr möglich:
http://support.godaddy.com/help/article/6935/phasing-out-intranet-names ...
Ich nutzte bisher die einfache Möglichkeit, alle Domänen in einem Rutsch zu sichern, nun geht es nicht mehr.
In meinem Fall wurden bei einer Neuerstellung eines 3-Jahre-Zertifikats die internen Bezeichnungen einfach entfernt (z.B. 2s-srv03.2s.local) und es blieben nur die offiziellen owa.2systems.de oder autodiscovery.2systems.de aktiviert. (Domänennamen sind nur beispielhaft, es geht im vorliegenden Fall um eine andere Kundendomäne.)
Das Aktivieren des Zertifikats für IIS auf einem MS Exchange 2010 SP2 verlief wie immer ohne Probleme, OWA läuft wie gewohnt, alle "externen" Clients ausserhalb des Netzwerks ebenfalls.
Es existiert noch ein gültiges internes Zertifikat von der Grundinstalltion für 2s-srv03.
Das Problem:
Die wenigen MS Outlook 2010 Clients innerhalb der internen Domäne bemängeln nun beim Starten und später in unregelmässigen Abständen (0,5-1 Stunde) das fehlende Zertifikat für 2s-srv03.2s.local.
Die Konfiguration ist identisch mit den externen Clients.
Auch die folgende Anleitung für die Anpassung der Konfiguration der internen URL brachte keine Änderung.
http://support.godaddy.com/help/article/6281/reconfiguring-microsoft-ex ...
Der Aufruf von outlook /rpcdiag zeigt ebenfalls nichts auffälliges.
Bevor ich nun weitere Schritte unternehme, hat einer von Euch vielleicht bereits einen Lösungsansatz oder einen Rat, die Konfiguration anders zu gestalten?
Besten Dank im Voraus
Seit Jahren erstelle ich mit Hilfe des Assistenten von MS Exchange 2010 die Zertifikatsanforderungen nach folgendem Prinzip, inkl. der internen Domänen.
http://support.godaddy.com/help/article/6086/generating-a-certificate-s ...
Nun entstand durch die Änderung der Richtlinien bei GD zum ersten Mal ein Problem, dass möglicherweise demnächst viele von Euch betreffen wird und für das ich nun eine Lösung suche.
Die Erstellung eines UNC-Zertifikats mit internen Domänen-Namen ist bei GD nicht mehr möglich:
http://support.godaddy.com/help/article/6935/phasing-out-intranet-names ...
Ich nutzte bisher die einfache Möglichkeit, alle Domänen in einem Rutsch zu sichern, nun geht es nicht mehr.
In meinem Fall wurden bei einer Neuerstellung eines 3-Jahre-Zertifikats die internen Bezeichnungen einfach entfernt (z.B. 2s-srv03.2s.local) und es blieben nur die offiziellen owa.2systems.de oder autodiscovery.2systems.de aktiviert. (Domänennamen sind nur beispielhaft, es geht im vorliegenden Fall um eine andere Kundendomäne.)
Das Aktivieren des Zertifikats für IIS auf einem MS Exchange 2010 SP2 verlief wie immer ohne Probleme, OWA läuft wie gewohnt, alle "externen" Clients ausserhalb des Netzwerks ebenfalls.
Es existiert noch ein gültiges internes Zertifikat von der Grundinstalltion für 2s-srv03.
Das Problem:
Die wenigen MS Outlook 2010 Clients innerhalb der internen Domäne bemängeln nun beim Starten und später in unregelmässigen Abständen (0,5-1 Stunde) das fehlende Zertifikat für 2s-srv03.2s.local.
Die Konfiguration ist identisch mit den externen Clients.
Auch die folgende Anleitung für die Anpassung der Konfiguration der internen URL brachte keine Änderung.
http://support.godaddy.com/help/article/6281/reconfiguring-microsoft-ex ...
Der Aufruf von outlook /rpcdiag zeigt ebenfalls nichts auffälliges.
Bevor ich nun weitere Schritte unternehme, hat einer von Euch vielleicht bereits einen Lösungsansatz oder einen Rat, die Konfiguration anders zu gestalten?
Besten Dank im Voraus
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 234295
Url: https://administrator.de/forum/problem-nach-erneuerung-eines-offiziellen-zertifikats-fuer-ms-exchange-2010-234295.html
Ausgedruckt am: 27.12.2024 um 21:12 Uhr
4 Kommentare
Neuester Kommentar
Moin,
der Trick im letzten Link funktioniert natürlich nur, wenn du auch intern owa.2systems.de aufrufen kannst. Geht das?
Funktioniert Autodiscover intern problemlos wie in dem Link beschrieben?
Grüße,
Dani
P.S: Das Problem stellt sich eigentlich nicht, da eigentlich ein ReverseProxy vor solchen Dienste stehen sollte.
der Trick im letzten Link funktioniert natürlich nur, wenn du auch intern owa.2systems.de aufrufen kannst. Geht das?
Funktioniert Autodiscover intern problemlos wie in dem Link beschrieben?
Grüße,
Dani
P.S: Das Problem stellt sich eigentlich nicht, da eigentlich ein ReverseProxy vor solchen Dienste stehen sollte.
Danke Dani
zu P.S.
vielleicht sollte ich nachsitzen und dann meine Strategie für die Mini-Exchange-Installation überdenken
Wie würde ein ReverseProxy nun der Meldung zum Zertifikatsfehler innerhalb der internen Domäne abhelfen?
der Trick im letzten Link funktioniert natürlich nur, wenn du auch intern owa.2systems.de aufrufen kannst. Geht das?
Ja, einwandfrei, die Firewall sorgt für den Direktzugriff.Funktioniert Autodiscover intern problemlos wie in dem Link beschrieben?
Ebenfalls.zu P.S.
vielleicht sollte ich nachsitzen und dann meine Strategie für die Mini-Exchange-Installation überdenken
Wie würde ein ReverseProxy nun der Meldung zum Zertifikatsfehler innerhalb der internen Domäne abhelfen?
Geh bitte an einen Client. Starte Outlook ganz normal. Danach hältst du STRG gedrückt und machst einen Rechtslick auf das Outlooksymbol rechts unten (neben der Uhr). Dort wählst du Verbindungsstatus aus. Was steht dor drin?
Ist natürlich ein gewisser Aufwand. Aber du hast sicher firma.local als FQDN. Anders würde es aussehen, wenn du firma.com hättest.
Grüße,
Dani
Wie würde ein ReverseProxy nun der Meldung zum Zertifikatsfehler innerhalb der internen Domäne abhelfen
Der Reverse Proxy hält das öffentliche Zertifikat. Für den Exchange nimmst du ein Zertifikat von deiner internen CA Authority (falls du eine hast). Ist natürlich ein gewisser Aufwand. Aber du hast sicher firma.local als FQDN. Anders würde es aussehen, wenn du firma.com hättest.Grüße,
Dani
Hallo,
sollte das Problem noch bestehen, das hier hat mir geholfen.
http://www.hosting-hilfe.eu/index.php?title=SSL_Fehler_Exchange
Es löst zwar nicht das Problem aber die nervige meldung ist weg.
sollte das Problem noch bestehen, das hier hat mir geholfen.
http://www.hosting-hilfe.eu/index.php?title=SSL_Fehler_Exchange
Es löst zwar nicht das Problem aber die nervige meldung ist weg.
