11
Bei jedem Outlook-Start Zertifikatsfehler obwohl Zertifikat auf Server nicht existiert
Hallo und guten Abend,
mich treibt seit etwa 8 Stunden folgendes mangels fundiertem Wissen in den Wahnsinn:
Ich wollte mittels einem dyndns host Exchange Active Sync mit dem SBS 2011 zum laufen bekommen und habe dazu für den dyndns hostname ein Zertifikat im Exchange angelegt.
Klappte leider nicht wirklich so wie erwartet, habe daher das Zertifikat wieder gelöscht. Das Standard-Zertifikat dass der SBS erstellt mit remote.domain.name ist natürlich weiterhin vorhanden und auch via Bindungen im IIS den 443er Ports zugeteilt.
Jedoch erhält nun jeder Client beim start von Outlook einen Zertifikatshinweis zu hostname.dyndns.org - und ich weiß einfach nicht an welcher stelle ich das Zertifikat entfernen soll. Ich sehe weder im IIS Zertifikatemanager noch im Exchange das auf dyndns ausgstellte Zertifkat.
Hat da jemand ein bisschen Hilfe für mich?
Danke & Gruß
mich treibt seit etwa 8 Stunden folgendes mangels fundiertem Wissen in den Wahnsinn:
Ich wollte mittels einem dyndns host Exchange Active Sync mit dem SBS 2011 zum laufen bekommen und habe dazu für den dyndns hostname ein Zertifikat im Exchange angelegt.
Klappte leider nicht wirklich so wie erwartet, habe daher das Zertifikat wieder gelöscht. Das Standard-Zertifikat dass der SBS erstellt mit remote.domain.name ist natürlich weiterhin vorhanden und auch via Bindungen im IIS den 443er Ports zugeteilt.
Jedoch erhält nun jeder Client beim start von Outlook einen Zertifikatshinweis zu hostname.dyndns.org - und ich weiß einfach nicht an welcher stelle ich das Zertifikat entfernen soll. Ich sehe weder im IIS Zertifikatemanager noch im Exchange das auf dyndns ausgstellte Zertifkat.
Hat da jemand ein bisschen Hilfe für mich?
Danke & Gruß
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: 248448
Url: https://administrator.de/contentid/248448
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
11 Kommentare
Neuester Kommentar
Ich würde dennoch auf eine falsche Bindung tippen. Diese solltest du sicherheitshalber nochmal alle überprüfen.
Gibt es noch andere Stellen wo eine solche Bindung hinterlegt sein könnte?
Bin im ISS MAnager auf die Default Website -> Bindungen -> 443 für die IP und locahost
Dort ist jeweils das korrekte Zertifikat hinterlegt. Wenn ich dort das Zertifikat in irgendein anderes ändere meldet dies Outlook auch sofort korrekt. Auf die meldung zum dyndns zertifikat hat das keinerlei auswirkung
Bin im ISS MAnager auf die Default Website -> Bindungen -> 443 für die IP und locahost
Dort ist jeweils das korrekte Zertifikat hinterlegt. Wenn ich dort das Zertifikat in irgendein anderes ändere meldet dies Outlook auch sofort korrekt. Auf die meldung zum dyndns zertifikat hat das keinerlei auswirkung
Moin,
BTW: es wird vermutlich auch keinen in den Ruin treiben, sich bei einem deutschen Hoster eine DDNS-aktivierbare domain zu hosten?
Lass den Assi einfach noch mal über den SBS laufen ...
LG, Thomas
Ich wollte mittels einem dyndns host Exchange Active Sync mit dem SBS 2011 zum laufen bekommen und habe dazu für den dyndns hostname ein Zertifikat im Exchange angelegt.
wieso hinterlegst Du das cert im Exchange und nicht by design über den zuständigen Assi des SBS?BTW: es wird vermutlich auch keinen in den Ruin treiben, sich bei einem deutschen Hoster eine DDNS-aktivierbare domain zu hosten?
Lass den Assi einfach noch mal über den SBS laufen ...
LG, Thomas
Hi.
Und wie es mit dem Assistenten für DynDNS funktioniert, steht hie beschrieben - http://blog.sbspraxis.de/sbs2008-sbs2011-und-dyndns-p279/
LG Günther
Und wie es mit dem Assistenten für DynDNS funktioniert, steht hie beschrieben - http://blog.sbspraxis.de/sbs2008-sbs2011-und-dyndns-p279/
LG Günther
Moin,
wenn alles nichts helfen sollte, checke mal die Zertifikatbindungen auf der Konsole mit
Internet Information Server (IIS 7.5) verwendet altes Zertifikat trotz korrekter Einbindung eines neuen Zertifikates
Grüße Uwe
wenn alles nichts helfen sollte, checke mal die Zertifikatbindungen auf der Konsole mit
netsh http show sslcert. Ich hatte hier schon mal den Fall das sich ein verwaistes Zertifikat nur dort entfernen ließ, siehe:Internet Information Server (IIS 7.5) verwendet altes Zertifikat trotz korrekter Einbindung eines neuen Zertifikates
Grüße Uwe
Glaube ich habe mich da nicht deutlich genug ausgedrückt, sorry.
Ich hatte kein gekauftes Zertifikat, die dyndns geschichte soll nur etwas kurzes für die nächsten 30 Tage sein. Daher hatte ich ein Zeritfikat in der Exchange Konsole selbst erstellt und wollte es dann über den Zertifikatsdienst mit https://server/certsrv selbst signieren usw. Da dieser aber nicht verfügbar war (weil offenbar nicht installiert) hab ich das ganze abgebrochen und das zertifikat halt wieder rausgelöscht. Daher habe ich auch den Assistenten nicht verwendet, weils ja noch kein Zertifikat gab für ihn.
Seitdem besteht das Problem.
Habe gestern dann alles mögliche probiert. Mein letzter Arbeitsschritt vor dem Posting hier war, im IIS Manager die Bindungen auf ein anderen Zertifikat zu stellen und dann wieder zurück - in der Hoffnung, dass dies das Problem behebt. Dann natürlich die Webseite neu gestartet. Brachte leider nichts.
Nun war über 14 Stunden Outlook am Client geschlossen - beim ersten Aufruf gerade eben war ich voller freude: KEINE Zertifikatswarnung. Outlook geschlossen, wieder geöffnet, schon ist sie wieder da.
Weiterer Test: Outlook-Profil gelöscht, Oulook neu gestartet und eingerichtet. Beim ersten Öffnen keine Meldung, alle weiteren hingegen schon. Dies lässt sich reproduzieren.
Vielen Dank für diesen Ansatz - leider taucht auch dort das besagte Zertifikat NICHT auf.
Ich hatte kein gekauftes Zertifikat, die dyndns geschichte soll nur etwas kurzes für die nächsten 30 Tage sein. Daher hatte ich ein Zeritfikat in der Exchange Konsole selbst erstellt und wollte es dann über den Zertifikatsdienst mit https://server/certsrv selbst signieren usw. Da dieser aber nicht verfügbar war (weil offenbar nicht installiert) hab ich das ganze abgebrochen und das zertifikat halt wieder rausgelöscht. Daher habe ich auch den Assistenten nicht verwendet, weils ja noch kein Zertifikat gab für ihn.
Seitdem besteht das Problem.
Habe gestern dann alles mögliche probiert. Mein letzter Arbeitsschritt vor dem Posting hier war, im IIS Manager die Bindungen auf ein anderen Zertifikat zu stellen und dann wieder zurück - in der Hoffnung, dass dies das Problem behebt. Dann natürlich die Webseite neu gestartet. Brachte leider nichts.
Nun war über 14 Stunden Outlook am Client geschlossen - beim ersten Aufruf gerade eben war ich voller freude: KEINE Zertifikatswarnung. Outlook geschlossen, wieder geöffnet, schon ist sie wieder da.
Weiterer Test: Outlook-Profil gelöscht, Oulook neu gestartet und eingerichtet. Beim ersten Öffnen keine Meldung, alle weiteren hingegen schon. Dies lässt sich reproduzieren.
Zitat von @colinardo:
Moin,
wenn alles nichts helfen sollte, checke mal die Zertifikatbindungen auf der Konsole mit
Internet Information Server (IIS 7.5) verwendet altes Zertifikat trotz korrekter Einbindung eines neuen Zertifikates
Grüße Uwe
Moin,
wenn alles nichts helfen sollte, checke mal die Zertifikatbindungen auf der Konsole mit
netsh http show sslcert. Ich hatte hier schon mal den Fall das sich ein verwaistes Zertifikat nur dort entfernen ließ, siehe:Internet Information Server (IIS 7.5) verwendet altes Zertifikat trotz korrekter Einbindung eines neuen Zertifikates
Grüße Uwe
Vielen Dank für diesen Ansatz - leider taucht auch dort das besagte Zertifikat NICHT auf.
Daher habe ich auch den Assistenten nicht verwendet, weils ja noch kein Zertifikat gab für ihn.
ja und jetzt ist kein Zertifikat aktiv oder was ? Schlecht... ohne wird das nicht wie gewünscht laufen.- Was gibt Get-ExchangeCertificate in einer EMS aus ?
Zitat von @colinardo:
ja und jetzt ist kein Zertifikat aktiv oder was ? Schlecht... ohne wird das nicht wie gewünscht laufen.
ja und jetzt ist kein Zertifikat aktiv oder was ? Schlecht... ohne wird das nicht wie gewünscht laufen.
- Was gibt Get-ExchangeCertificate in einer EMS aus ?
ne, es ist einfach das selbstzertifizierte aus der installation mit remote.domäne.de aktiv. Die Ganze dyndns geschichte haben wir zugunsten einer festen IP verworfen.
Hier die Rückgabe - so wie sie imo sein sollte. Das problematische Zertifikat ist darin nicht aufgelistet.
[PS] C:\Windows>Get-ExchangeCertificate
Thumbprint Services Subject
-------- -------
D8XX7A58684D9C3B3BE706A10DB958EFC17A2A32 IP.WS. CN=remote.domain.de
E1XX0BDE00F56C3E0115DCF3EA119A0655BB3EC6 ....S. CN=PDC.domain.local
25XX341ED4B210781687361367E39E47D6819709 ....S. CN=Sites
76XXC65BB8D14F0303EF6E2D1F509150E3619916 ...... CN=domain-PDC-CA
02XXC31FE184DF77481670F277E623638B799218 ...... CN=WMSvc-WIN-QQH1BMQSV35
Hab gerade den Outlook Autoconfig Test-Dialog entdeckt.
Dort geistert die dyndns url umher. Siehe Screenshot unter:
http://s14.directupload.net/images/user/140906/dowzxwdf.jpg
In der Exchange-Verwaltungskonsole unter Serverkonfiguration -> Clientzugriff
ist jedoch bei allen Elementen (Outlook Web App, Exchange Systemsteuerung, Exchange ACtiveSync usw.) diese p7.de URL zusammen mit dem Zertifikat von mir wieder entfernt worden und auf remote.domain.de zurückgestellt worden.
Wo kann die URL denn noch herkommen?
Danke
Dort geistert die dyndns url umher. Siehe Screenshot unter:
http://s14.directupload.net/images/user/140906/dowzxwdf.jpg
In der Exchange-Verwaltungskonsole unter Serverkonfiguration -> Clientzugriff
ist jedoch bei allen Elementen (Outlook Web App, Exchange Systemsteuerung, Exchange ACtiveSync usw.) diese p7.de URL zusammen mit dem Zertifikat von mir wieder entfernt worden und auf remote.domain.de zurückgestellt worden.
Wo kann die URL denn noch herkommen?
Danke
Checke alle internen und externen URLs mit der Powershell um sicherzugehen. Auf die GUI verlasse ich mich persönlich ungerne:
Powershell: Konfigurieren der internen und externen URLs von Exchange Server 2013, 2016
Und den Server ab und zu mal neu starten, wenn nicht schon geschehen. Und auch mal einen
Aber besser du hältst sich bei dem SBS-Gedöns an die Assistenten zum Einrichten des Zertifikates, und fummelst nicht hinten an allem rum ohne alle Abhängigkeiten zu kennen.
Wer weis wo der Assi den neuen Hostnamen noch alles hinterlegt hat, deswegen diesen nochmal mit dem vorherigen Domainnamen durchlaufen lassen.
Powershell: Konfigurieren der internen und externen URLs von Exchange Server 2013, 2016
Und den Server ab und zu mal neu starten, wenn nicht schon geschehen. Und auch mal einen
IISRESET durchführen.Aber besser du hältst sich bei dem SBS-Gedöns an die Assistenten zum Einrichten des Zertifikates, und fummelst nicht hinten an allem rum ohne alle Abhängigkeiten zu kennen.
Wer weis wo der Assi den neuen Hostnamen noch alles hinterlegt hat, deswegen diesen nochmal mit dem vorherigen Domainnamen durchlaufen lassen.
Tausend Dank Euch Leute!
Problem konnte nun endlich gelöst werden - in der Tat brachte der gegencheck auf der Exchange-Shell die Lösung.
Der Befehl
[PS] C:\Windows>Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl
Identity : PDC\EWS (Default Web Site)
InternalUrl : https://remote.domain.de/EWS/Exchange.asmx
ExternalUrl : https://domain.p7.de/ews/exchange.asmx
zeigte: da stimmt was noch nicht.
Mittels
[PS] C:\Windows>Set-WebServicesVirtualDirectory -Identity "PDC\EWS (Default Web Site)" -ExternalUrl https://remote.domain.de/EWS/Exchange.asmx -BasicAuthentication:$true
Lies sich das ganze korrigieren.
Als ich von Euch in die Richtige Richtung gewiesen wurde fand ich folgende Seite die exakt dieses Problem, insbesondere im Zusammenhang mit der GUI:
http://www.3ait.co.uk/blog/changing-the-autodiscover-url-in-microsoft-e ...
In Kombination mit dem Outlook Autodiscover-Test lies sich das ganze dann lösen.
Vielen Vielen Dank für die Hilfe!!
Grüße,
DR
Problem konnte nun endlich gelöst werden - in der Tat brachte der gegencheck auf der Exchange-Shell die Lösung.
Der Befehl
[PS] C:\Windows>Get-WebServicesVirtualDirectory |fl identity,internalurl,externalurl
Identity : PDC\EWS (Default Web Site)
InternalUrl : https://remote.domain.de/EWS/Exchange.asmx
ExternalUrl : https://domain.p7.de/ews/exchange.asmx
zeigte: da stimmt was noch nicht.
Mittels
[PS] C:\Windows>Set-WebServicesVirtualDirectory -Identity "PDC\EWS (Default Web Site)" -ExternalUrl https://remote.domain.de/EWS/Exchange.asmx -BasicAuthentication:$true
Lies sich das ganze korrigieren.
Als ich von Euch in die Richtige Richtung gewiesen wurde fand ich folgende Seite die exakt dieses Problem, insbesondere im Zusammenhang mit der GUI:
http://www.3ait.co.uk/blog/changing-the-autodiscover-url-in-microsoft-e ...
In Kombination mit dem Outlook Autodiscover-Test lies sich das ganze dann lösen.
Vielen Vielen Dank für die Hilfe!!
Grüße,
DR
