6
Zertifikatprobleme mit selbstsigniertem Zertifikat unter Exchange 2013 bzw IIS unter Server 2012 R2
Hallo zusammen,
ich habe hier eine noch recht frische Installation eines Exchange 2013 SP1 auf einem Windows Server 2012 R2 mit entsprechendem IIS.
Erstellt habe ich dafür ein selbstsigniertes Zertifikat mit Hilfe der AD Zertifikatdienste.
In dem Zertifikat enthalten sind folgende Domains:
- mail.externedomain.xy (externer hostname des exchange-servers)
- hostname.internedomain.local (interner fqdn des exchange-servers)
- autodiscover.externedomain.xy
- autodiscover.internedomain.local
- hostname (interner hostname)
- internedomain.local
- externedomain.xy
Das Problem ist nun, dass es im Firefox gar nicht möglich ist (sowohl im LAN als auch von extern) die OWA-Seite oder die ECP-Seite des Exchange aufzurufen.
Fehlermeldung:
"Fehler: Gesicherte Verbindung fehlgeschlagen.
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.
Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren."
Ich habe dann das Stammzertifikat in den Firefox importiert, was jedoch nicht geholfen hat.
Anschliessend habe ich beim Exchange 2013 SP1, das Update KU 8 installiert, was ebenfalls nicht geholfen hat.
Im InternetExplorer kann ich OWA und ECP, aber es kommt auch dort eine Fehlermeldung:
"Es sind keine Sperrinformationen für das Sicherheitszertifikat dieser Site verfügbar. Möchten Sie den Vorgang fortsetzen?"
Nach Bestätigung mit "Ja" wird dann im IE das OWA-Interface einwandfrei geladen.
Ich vermute, dass der Fehler nicht am Zertifikat selbst liegt, sondern vielmehr an irgendwelchen Einstellungen, vielleicht auch im Bereich TLS beim IIS.
Da ich dort aber (zumindest nicht bewusst) irgendwelche Standardeinstellungen verändert habe, wüsste ich nicht, wo ich nach dem Fehler suchen soll.
Interessanter Aspekt bei der Sache:
Als der Server ganz neu installiert war, hatte ich auch schon ein selbsterstelltes Zertifikat erstellt.
(Dort hatte ich dann aber die externe URL des Servers vergessen einzutragen). Komischerweise ging es damit jedoch im Firefox (nach dem Bestätigen der Warnmeldung, dass der Verbindung nicht vertraut wird), aber seit dem zweiten Zertifikat geht es nun gar nicht mehr. Ich wüsste nicht, dass ich bei der zweiten Erstellung was anders gemacht habe.
Irgendwelche Ideen, woran es liegen könnte?
Vielen Dank vorab!
Gruß,
Colt
ich habe hier eine noch recht frische Installation eines Exchange 2013 SP1 auf einem Windows Server 2012 R2 mit entsprechendem IIS.
Erstellt habe ich dafür ein selbstsigniertes Zertifikat mit Hilfe der AD Zertifikatdienste.
In dem Zertifikat enthalten sind folgende Domains:
- mail.externedomain.xy (externer hostname des exchange-servers)
- hostname.internedomain.local (interner fqdn des exchange-servers)
- autodiscover.externedomain.xy
- autodiscover.internedomain.local
- hostname (interner hostname)
- internedomain.local
- externedomain.xy
Das Problem ist nun, dass es im Firefox gar nicht möglich ist (sowohl im LAN als auch von extern) die OWA-Seite oder die ECP-Seite des Exchange aufzurufen.
Fehlermeldung:
"Fehler: Gesicherte Verbindung fehlgeschlagen.
Die Verbindung zum Server wurde zurückgesetzt, während die Seite geladen wurde.
Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren."
Ich habe dann das Stammzertifikat in den Firefox importiert, was jedoch nicht geholfen hat.
Anschliessend habe ich beim Exchange 2013 SP1, das Update KU 8 installiert, was ebenfalls nicht geholfen hat.
Im InternetExplorer kann ich OWA und ECP, aber es kommt auch dort eine Fehlermeldung:
"Es sind keine Sperrinformationen für das Sicherheitszertifikat dieser Site verfügbar. Möchten Sie den Vorgang fortsetzen?"
Nach Bestätigung mit "Ja" wird dann im IE das OWA-Interface einwandfrei geladen.
Ich vermute, dass der Fehler nicht am Zertifikat selbst liegt, sondern vielmehr an irgendwelchen Einstellungen, vielleicht auch im Bereich TLS beim IIS.
Da ich dort aber (zumindest nicht bewusst) irgendwelche Standardeinstellungen verändert habe, wüsste ich nicht, wo ich nach dem Fehler suchen soll.
Interessanter Aspekt bei der Sache:
Als der Server ganz neu installiert war, hatte ich auch schon ein selbsterstelltes Zertifikat erstellt.
(Dort hatte ich dann aber die externe URL des Servers vergessen einzutragen). Komischerweise ging es damit jedoch im Firefox (nach dem Bestätigen der Warnmeldung, dass der Verbindung nicht vertraut wird), aber seit dem zweiten Zertifikat geht es nun gar nicht mehr. Ich wüsste nicht, dass ich bei der zweiten Erstellung was anders gemacht habe.
Irgendwelche Ideen, woran es liegen könnte?
Vielen Dank vorab!
Gruß,
Colt
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 271499
Url: https://administrator.de/forum/zertifikatprobleme-mit-selbstsigniertem-zertifikat-unter-exchange-2013-bzw-iis-unter-server-2012-r2-271499.html
Ausgedruckt am: 15.04.2025 um 20:04 Uhr
6 Kommentare
Neuester Kommentar
Moin Colt,
öffne mal das Zertifikat und schau nach ob darin Sperrstellen-URLs hinterlegt worden sind. Ist das der Fall müssen diese URLs und die Sperrlisten der Zertifikate auch für den Client abrufbar sein (Für externen Zugriff muss natürlich auch eine extern erreichbare URL hinterlegt sein). Standardmäßig geschieht das über eine HTTP-URL. Wenn du also im IIS für die Site festgelegt hättest das sie nur via SSL abgerufen werden kann, können die Clients keine Sperrstelleninformationen abrufen und meckern deswegen. Also entweder du sagst dem IIS er soll auch normales HTTP zulassen, oder veröffentlichst die Sperrlisten woanders. Prüfe auch ob die Sperrlisten wirklich an der richtigen Stelle generiert worden sind. Prüfen kann man das auch mit dem Kommandozeilentool certutil.
Die Sperrstellen-URLs lassen sich in den Eigenschaften der Zertifizierungsstelle festlegen/ändern.
Gruß jodel32
öffne mal das Zertifikat und schau nach ob darin Sperrstellen-URLs hinterlegt worden sind. Ist das der Fall müssen diese URLs und die Sperrlisten der Zertifikate auch für den Client abrufbar sein (Für externen Zugriff muss natürlich auch eine extern erreichbare URL hinterlegt sein). Standardmäßig geschieht das über eine HTTP-URL. Wenn du also im IIS für die Site festgelegt hättest das sie nur via SSL abgerufen werden kann, können die Clients keine Sperrstelleninformationen abrufen und meckern deswegen. Also entweder du sagst dem IIS er soll auch normales HTTP zulassen, oder veröffentlichst die Sperrlisten woanders. Prüfe auch ob die Sperrlisten wirklich an der richtigen Stelle generiert worden sind. Prüfen kann man das auch mit dem Kommandozeilentool certutil.
Die Sperrstellen-URLs lassen sich in den Eigenschaften der Zertifizierungsstelle festlegen/ändern.
Gruß jodel32
Servus Jodel32,
vielen Dank für die Tips.
Geholfen haben sie leider nicht.
Ich habe noch einen Win SBS 2008, bei dem der Fernzugriff mit einem ebenfalls selbst erstellten Zertifikat funktioniert. Deshalb habe ich die beiden Zertifikate mal anzeigen lassen und verglichen.
Bei dem funktionierenden Zertifikat des SBS 2008 war unter dem Punkt "Sperrlisten-Verteilungspunkte" ein ldap-Pfad und ein HTTP-Pfad angegeben, bei dem mit Win 2012R2 erstelltem, nicht funktionierenden Zertifikat war nur der ldap-Pfad eingetragen. Sah also erstmal nach Lösung aus. Habe dann in den Eigenschaften der CA in der Zertifizierungsstelle ein paar Häkchen gesetzt, sodass nun auch in den 2012R2-Zertifikaten ein HTTP-Pfad auftaucht.
Daran lags aber nicht, denn:
1. Ist der HTTP-Pfad auch bei dem funktionierenden Zertifikat des SBS 2008 nur eine Intranet-URL, die von extern nicht aufgelöst werden kann.
2. Funktioniert dieses Zertifikat dennoch von aussen ohne die Zertifikatsperrlisten-Warnung im IE, und es funktioniert auch mit dem Firefox.
Der Port 80 ist beim SBS2008 von aussen zudem nicht erreichbar, nur der 443. Port 80 kann also nicht erforderlich sein, damit es geht.
Auch im LAN des Win 2012R2 funktioniert der Zugriff auf OWA und ECP nach wie vor per Firefox nicht.
Warum also das eine Zertifikat funktioniert und das andere nicht gut genug ist, ist mir immer noch nicht klar.
Einziger Unterschied bei den Zertifikaten ist der Signaturalgorithmus.
Beim funktionierenden Zertifikat ist es der SHA1RSA, bei dem nicht funktionierenden Zertifikat ist es der SHA512RSA.
Aber ich würde erstmal nicht vermuten, dass das ne Rolle spielt bei diesem Problem, oder?
=> Liegt das Problem vielleicht beim IIS?
Gruß,
Colt
vielen Dank für die Tips.
Geholfen haben sie leider nicht.
Ich habe noch einen Win SBS 2008, bei dem der Fernzugriff mit einem ebenfalls selbst erstellten Zertifikat funktioniert. Deshalb habe ich die beiden Zertifikate mal anzeigen lassen und verglichen.
Bei dem funktionierenden Zertifikat des SBS 2008 war unter dem Punkt "Sperrlisten-Verteilungspunkte" ein ldap-Pfad und ein HTTP-Pfad angegeben, bei dem mit Win 2012R2 erstelltem, nicht funktionierenden Zertifikat war nur der ldap-Pfad eingetragen. Sah also erstmal nach Lösung aus. Habe dann in den Eigenschaften der CA in der Zertifizierungsstelle ein paar Häkchen gesetzt, sodass nun auch in den 2012R2-Zertifikaten ein HTTP-Pfad auftaucht.
Daran lags aber nicht, denn:
1. Ist der HTTP-Pfad auch bei dem funktionierenden Zertifikat des SBS 2008 nur eine Intranet-URL, die von extern nicht aufgelöst werden kann.
2. Funktioniert dieses Zertifikat dennoch von aussen ohne die Zertifikatsperrlisten-Warnung im IE, und es funktioniert auch mit dem Firefox.
Der Port 80 ist beim SBS2008 von aussen zudem nicht erreichbar, nur der 443. Port 80 kann also nicht erforderlich sein, damit es geht.
Auch im LAN des Win 2012R2 funktioniert der Zugriff auf OWA und ECP nach wie vor per Firefox nicht.
Warum also das eine Zertifikat funktioniert und das andere nicht gut genug ist, ist mir immer noch nicht klar.
Einziger Unterschied bei den Zertifikaten ist der Signaturalgorithmus.
Beim funktionierenden Zertifikat ist es der SHA1RSA, bei dem nicht funktionierenden Zertifikat ist es der SHA512RSA.
Aber ich würde erstmal nicht vermuten, dass das ne Rolle spielt bei diesem Problem, oder?
=> Liegt das Problem vielleicht beim IIS?
Gruß,
Colt
Prüf mal ob im IIS in der Verwaltungswebsite (nicht der Default Site) das neue SSL-Zertifikat korrekt hinterlegt wurde (unter Bindungen).
2. Funktioniert dieses Zertifikat dennoch von aussen ohne die Zertifikatsperrlisten-Warnung im IE, und es funktioniert auch mit dem Firefox.
Trotzdem ist das alles andere als die feine Art, wenn man schon eine Zertifizierungsstelle betreibt und Sperrlisten in den Zertifikaten angibt und diese dann nicht erreichbar sind. In Zukunft wenn die Browser in dieser Hinsicht noch restriktiver werden bekommt man dann damit Probleme ...
Ich bin nen kleinen Schritt weiter:
Offenbar scheint es wirklich ein Problem mit dem starken Signaturalgorithmus zu geben:
Laut https://www.ssllabs.com/ssltest/viewMyClient.html unterstützt der aktuelle Firefox (37.0.2) noch gar nicht den SHA512RSA.
Der IE 11 hingegen schon...
Das hab ich glaub ich bei Installation der Zertifikatdienste als Standard festgelegt (Ich dachte mir: wenn schon, denn schon
)
Den Zertifikatsrequest habe ich bisher über den Assistenten im Exchange Admin Center erstellt, und dann über die die certsrv-Webseite eingereicht und dort dann das Zertifikat heruntergeladen.
Weisst Du zufällig, wie ich das händisch so lösen kann, dass ich ein Zertifikat in SHA256RSA-Stärke erstellen kann?
Offenbar scheint es wirklich ein Problem mit dem starken Signaturalgorithmus zu geben:
Laut https://www.ssllabs.com/ssltest/viewMyClient.html unterstützt der aktuelle Firefox (37.0.2) noch gar nicht den SHA512RSA.
Der IE 11 hingegen schon...
Das hab ich glaub ich bei Installation der Zertifikatdienste als Standard festgelegt (Ich dachte mir: wenn schon, denn schon
)Den Zertifikatsrequest habe ich bisher über den Assistenten im Exchange Admin Center erstellt, und dann über die die certsrv-Webseite eingereicht und dort dann das Zertifikat heruntergeladen.
Weisst Du zufällig, wie ich das händisch so lösen kann, dass ich ein Zertifikat in SHA256RSA-Stärke erstellen kann?
Servus!
Ich habe nun ein neues Stammzertifikat mit SHA256 erstellt, und danach ein neues Zertifikat für den Exchange erstellt.
Nun läuft wieder alles - also es lag wirklich an der SHA512RSA-Stärke - wer hätte das gedacht, dass hier der Firefox dem IE hinterherhinkt?!
Auch der IE meckert nun nicht mehr wegen des Sperrlistenpfads, obwohl der Pfad noch immer die Intranet-URL enthält (aber das ist bei dem anderen Server mit SBS 2008 ja nicht anders) - scheint also NOCH nicht betriebsrelevant zu sein.
Aber generell geb ich Dir natürlich recht: Auch bei Zertifikaten aus einer eigenen Zertifizierungsstelle empfiehlt es sich natürlich den Sperrlistenpfad auch für externen Zugriff zu konfigurieren, wenn solche Zertifikate im Internet (wie in diesem Fall für den Outlook Web Access) eingesetzt werden.
Vielen Dank für Deine Hilfe!
Gruß,
Colt
Ich habe nun ein neues Stammzertifikat mit SHA256 erstellt, und danach ein neues Zertifikat für den Exchange erstellt.
Nun läuft wieder alles - also es lag wirklich an der SHA512RSA-Stärke - wer hätte das gedacht, dass hier der Firefox dem IE hinterherhinkt?!
Auch der IE meckert nun nicht mehr wegen des Sperrlistenpfads, obwohl der Pfad noch immer die Intranet-URL enthält (aber das ist bei dem anderen Server mit SBS 2008 ja nicht anders) - scheint also NOCH nicht betriebsrelevant zu sein.
Aber generell geb ich Dir natürlich recht: Auch bei Zertifikaten aus einer eigenen Zertifizierungsstelle empfiehlt es sich natürlich den Sperrlistenpfad auch für externen Zugriff zu konfigurieren, wenn solche Zertifikate im Internet (wie in diesem Fall für den Outlook Web Access) eingesetzt werden.
Vielen Dank für Deine Hilfe!
Gruß,
Colt
