7
Windows-Domäne und CloudFlare für Webseite
Moin,
ich habe ein kleines Problem.
Der Name der Windows-Domäne lautet: www.meinedomain.com.
Die Domain wird auch für die Webseite verwendet, die allerdings extern gehosted wird. Aufgrund von einigen Anwendungen ist der IIS auf dem Windows Server 2012 R2 installiert. Nun hatten wir intern das Problem, dass innerhalb der Domäne immer auf diesen Server verwiesen wurde wenn www.-Anfragen reinkamen. Dies haben wir dann über den Eintrag im DNS gelöst.
Nun wird die Seite aber über CloudFlare verwaltet, auch was das SSL-Zertifikat angeht. Wenn ich nun die HTTPS-Domain innerhalb der Windows-Domäne aufrufe, zieht er sich aber ein falsches Zertifikat. Das Zertifikat ansich wird nur von CloudFlare gehosted und kann nicht herunter geladen werden.
Jemand eine Idee, wie wir einstellen können, dass die www-Anfragen nur extern verwaltet werden?
Viele Grüße
Toni
ich habe ein kleines Problem.
Der Name der Windows-Domäne lautet: www.meinedomain.com.
Die Domain wird auch für die Webseite verwendet, die allerdings extern gehosted wird. Aufgrund von einigen Anwendungen ist der IIS auf dem Windows Server 2012 R2 installiert. Nun hatten wir intern das Problem, dass innerhalb der Domäne immer auf diesen Server verwiesen wurde wenn www.-Anfragen reinkamen. Dies haben wir dann über den Eintrag im DNS gelöst.
Nun wird die Seite aber über CloudFlare verwaltet, auch was das SSL-Zertifikat angeht. Wenn ich nun die HTTPS-Domain innerhalb der Windows-Domäne aufrufe, zieht er sich aber ein falsches Zertifikat. Das Zertifikat ansich wird nur von CloudFlare gehosted und kann nicht herunter geladen werden.
Jemand eine Idee, wie wir einstellen können, dass die www-Anfragen nur extern verwaltet werden?
Viele Grüße
Toni
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: 320214
Url: https://administrator.de/forum/windows-domaene-und-cloudflare-fuer-webseite-320214.html
Ausgedruckt am: 31.12.2024 um 09:12 Uhr
7 Kommentare
Neuester Kommentar
Hi,
erstmal Licht in Deine Frage bringen.
Das mit intern und extern gleicher DNS-Domänenname kennt man ja.
Aber Du hast ernsthaft die interne Windows Domäne "www.meinedomain.com" genannt?! Sorry, will Dich nicht anmachen. Aber das war entweder sehr dumm oder sehr kurzsichtig oder doch sehr, sehr unwissend. Oder kannst Du uns einen guten Grund dafür nennen?
Du hast also im Internet beim Provider einen Webserver laufen, welcher auf "www.meinedomain.com" reagieren soll? Und wenn Du diesen von intern rufst, dann landest Du auf den internen DC's, ist klar. Wie willst Du das bitte
Oder hast Du intern einen IIS am Laufen, welcher auch von extern über ""www.meinedomain.com" erreichbar ist?
E.
erstmal Licht in Deine Frage bringen.
Das mit intern und extern gleicher DNS-Domänenname kennt man ja.
Aber Du hast ernsthaft die interne Windows Domäne "www.meinedomain.com" genannt?! Sorry, will Dich nicht anmachen. Aber das war entweder sehr dumm oder sehr kurzsichtig oder doch sehr, sehr unwissend. Oder kannst Du uns einen guten Grund dafür nennen?
Du hast also im Internet beim Provider einen Webserver laufen, welcher auf "www.meinedomain.com" reagieren soll? Und wenn Du diesen von intern rufst, dann landest Du auf den internen DC's, ist klar. Wie willst Du das bitte
über den Eintrag im DNS gelöst
haben? Split-DNS fällt hier aus, weil die interne Windows Domäne "www" heißt. Oder wie jetzt?Oder hast Du intern einen IIS am Laufen, welcher auch von extern über ""www.meinedomain.com" erreichbar ist?
E.
Hallo,
Es ist auch nicht das Problem, dass er Intern die Benutzer beim Aufruf der "www-Adresse" auf den Provider leitet, das funktioniert. Problematisch wird es nun, dass für diese Domain beim Provider externe DNS-Server angegeben werden mussten (die von Cloudflare). Auch das war prinzipiell kein Problem. Nun stellt Cloudflare SSL-Zertifikate zur Verfügung, diese können aber nicht herunter geladen werden. Wenn ich nun also die "www-Adresse" intern mit HTTPS aufrufe, zeigt er mir die Seite zwar an, aber mit Sicherheitshinweis dass das Zertifikat nicht gültig ist. Schaue ich mir das Zertifikat an, zieht er sich auch das selbstsignierte aus der Domäne.
Rufe ich die Seite via Smartphone oder von einem anderen externen Standort auf, funktioniert die HTTPS-Verbindung.
Viele Grüße
Aber Du hast ernsthaft die interne Windows Domäne "www.meinedomain.com" genannt?!
ich habe nichts. Die Struktur wurde von einem externen Dienstleister erstellt. Nicht ganz, die Windows-Domäne lautet: meinedomain.com.Du hast also im Internet beim Provider einen Webserver laufen
Genau.welcher auf "www.meinedomain.com" reagieren soll?
Das tut er. Indem ich auf dem Domänen-Controller einen DNS-Eintrag für die "www-Adresse" angelegt und auf den Provider verwiesen habe.Oder hast Du intern einen IIS am Laufen, welcher auch von extern über ""www.meinedomain.com" erreichbar ist?
IIS läuft, allerdings nicht unter der Domain "www.meinedomain.com".Es ist auch nicht das Problem, dass er Intern die Benutzer beim Aufruf der "www-Adresse" auf den Provider leitet, das funktioniert. Problematisch wird es nun, dass für diese Domain beim Provider externe DNS-Server angegeben werden mussten (die von Cloudflare). Auch das war prinzipiell kein Problem. Nun stellt Cloudflare SSL-Zertifikate zur Verfügung, diese können aber nicht herunter geladen werden. Wenn ich nun also die "www-Adresse" intern mit HTTPS aufrufe, zeigt er mir die Seite zwar an, aber mit Sicherheitshinweis dass das Zertifikat nicht gültig ist. Schaue ich mir das Zertifikat an, zieht er sich auch das selbstsignierte aus der Domäne.
Rufe ich die Seite via Smartphone oder von einem anderen externen Standort auf, funktioniert die HTTPS-Verbindung.
Viele Grüße
Ich verstehe bloß "Bahnhof".
Warum sollte denn ein Webserver bei einer Verbindung von einem externen Client mit der Website ein anderes Zertifikat verwenden als wenn ein interner Client sich mit derselben Website verbindet?
Und was hat die Art und Weise, wie ein Client einen FQDN auflöst (also über welchen DNS-Server und wie dieser konfiguriert ist) mit dem Zertifikat zu tun, welches dieser Webserver liefert?
Wofür ist hier der interne IIS in diesem Szenario gut, wenn die Website, um welche es geht, auf dem Webserver im Internet läuft?
Warum sollte denn ein Webserver bei einer Verbindung von einem externen Client mit der Website ein anderes Zertifikat verwenden als wenn ein interner Client sich mit derselben Website verbindet?
Und was hat die Art und Weise, wie ein Client einen FQDN auflöst (also über welchen DNS-Server und wie dieser konfiguriert ist) mit dem Zertifikat zu tun, welches dieser Webserver liefert?
Wofür ist hier der interne IIS in diesem Szenario gut, wenn die Website, um welche es geht, auf dem Webserver im Internet läuft?
Moin,
Gruß
Ich verstehe bloß "Bahnhof".
sind wir schon zu Zweit.Warum sollte denn ein Webserver bei einer Verbindung von einem externen Client mit der Website ein anderes Zertifikat verwenden als wenn ein interner Client sich mit derselben Website verbindet?
Das kann ich dir nicht sagen. Ich weiß nicht, warum innerhalb der Domäne das eigene Zertifikat und nicht das vom externen Provider genommen wird.Wofür ist hier der interne IIS in diesem Szenario gut
Weil unser ERP und CRM webbasierend ist und dieses auf dem IIS läuft. Hat mit der Webseite als solches aber nichts zu tun und ähnelt sich auch nicht im Domainnamen.Gruß
Wofür ist hier der interne IIS in diesem Szenario gut
Weil unser ERP und CRM webbasierend ist und dieses auf dem IIS läuft. Hat mit der Webseite als solches aber nichts zu tun und ähnelt sich auch nicht im Domainnamen.OK.
Wenn Du von itern den FQDN der externen Website auflöst, welche IP-Adresse bekommst Du dann? Die des externen Webservers oder eine interne?
Moin,
Und warum hast Du das dann in Deiner Frage überhaupt erwähnt?
damit bekannt ist das ein IIS betrieben wird und der eventuell zur Fehlersuche dienen kann.Wenn Du von itern den FQDN der externen Website auflöst, welche IP-Adresse bekommst Du dann?
Die vom externen Provider. Die Seite kann ja auch normal aufgerufen werden, es macht einzig das Zertifikat ein Problem. Ich vermute, weil vom Systemhaus ein Wildcard-Zertifikat angelegt wurde *.meinedomain.com. Ich muss den Clients also nun sagen, dass diese für die www-Adresse nicht das Wildcard-Zertifikat nutzen sollen.Ich muss den Clients also nun sagen, dass diese für die www-Adresse nicht das Wildcard-Zertifikat nutzen sollen.
Wieso dem Client? Das hängt doch davon ab, was der Server ihm liefert.Deine Sätze sind echt schwer auseinander zu klauben.
Wenn ich nun also die "www-Adresse" intern mit HTTPS aufrufe, zeigt er mir die Seite zwar an, aber mit Sicherheitshinweis dass das Zertifikat nicht gültig ist.
Das ist erstmal nichts Besonderes. Das heißt bloß, dass Du das öffentliche Zertifikat der CA, von welcher das SSL-Zertifikat ausgestellt wurde, auf dem Client als vertrauenswürdige Zertifizerungsstelle oder Zwischenzertifizierungsstelle eintragen musst.Schaue ich mir das Zertifikat an, zieht er sich auch das selbstsignierte aus der Domäne.
Das ist der Satz, der mich ablenkt. Was heißt "auch"? Zwei Zertifikate? Wie soll das gehen? Poste doch mal nen Screenshot.
