5
SSL-WEB-Site auf eigenem Server aufbauen (IIS 7)
Damit die Verifikation des gültigen SSL-Zertifikats klappt, vergleicht der Browser den aktuellen Eintrag in der URL mit der im Zertifikat angegebenen Domain (= URL). Liefert dieser Vergleich ein TRUE, klappt es auch mit der SSL-Verschlüsselung; das grüne Schloß erscheint.
So weit, so gut. Das Problem besteht darin, den remote betriebenen Browser dazu zu kriegen, die URL der eigenen Domäne auch dann anzuzeigen, wenn der eigene Server (und nicht eine beim Provider gehostete Site) aufgerufen wird.
Szenario 1 : eigener Server hat feste externe IP (Firewall-IP, Weiterleitung an DMZ-Adresse des Servers als Eintrag in der Firewall)
Die für das Zertifikat gültige Site wird beim Provider 1und1 gehostet und ist damit im Internet über den DNS bei 1und bekannt; logische Voraussetzung dafür, daß die Site überhaupt aufgerufe werden kann.
Versuch 1: http-Weiterleitung Site => externe IP-Adresse
Es meldet sich zwar der Server und die Site auf dem Server. Da die URL im Browser aber die externe IP-Adresse anzeigt statt dem Site-Namen, liefert der Vergleich mit dem Zertifikat ein FALSE.
Versuch 2: Veränderung der Einstellung des 1und1-DNS-Servers: "A/AA-Eintrag" für die Site => externe IP-Adresse
(zu finden bei DNS-Einstellungen)
Damit verweist die Site -statt auf den 1und1-Site-Server- auf die eigene externe IP-Adresse ... und schon funktioniert's.
(Leider kann ich dem 1und1-Techniker nicht danken, der nach einigen Recherchen und Anfragen schließlich auf die Idee kam.)
--
Szenario 2 : eigener Server ist über eine flexible selfhost.bz-Adresse erreichbar.
Wir betreiben einen weiteren Server, der von extern statt mit einer festen IP über eine selfhost.bz-Adresse betrieben wird; also ist die externe Adresse variabel. Versucht man nun denselben Trick, stellt man fest, dass die Maske beim Provider 1und1 als zum 1und1-Server alternatives DNS-Ziel nur eine IP-Adresse, nicht aber eine Site -in diesem Fall die xxx.sellfhost.bz-Adresse- zulässt. Dieser Weg geht also in diesem Fall nicht.
...was zum alternativen Ansatz führt, bei einer Anfrage auf die interne IP des eigenen Servers über die dortigen eigenen DNS-Einstellungen dafür zu sorgen, daß sich die gewünschte Site auf dem WEB-Server im Browser meldet; somit die Auflösung "im eigenen Hause" geschieht.
Das funktioniert auch -am einfachsten durch Pflege der Datei hosts- und zwar dann, wenn man im Feld "Hostname" der Bindung der im IIS eingetragenen Website die gewünschte Site einträgt.
Und jetzt kommt's: man kann diesen Eintrag in das Feld "Hostname" aber nur vornehmen, wenn man darf und der IIS erlaubt einen Eintrag nur, wenn http als Protokoll gewählt wurde; nicht aber für https, dann wird das Feld ausgegraut und läßt keinen Eintrag zu.
Ich denke, daß es sich hierbei um einen gewollten Schutz handelt, der verhindern soll, daß die Sicherheit des Zertifikats hinsichtlich der Bestätigung der Site ausgehebelt werden kann. Dieses Ansinnen ist ja für sich genommen ehrenhaft, berücksichtigt aber leider nicht unseren legitimen Fall.
Hat jemand eine Idee, wie man intern -also auf dem eigenen Server- die Adresse https://localhost nach https://[Site] aufgelöst bekommt ?
Bin gespannt !
So weit, so gut. Das Problem besteht darin, den remote betriebenen Browser dazu zu kriegen, die URL der eigenen Domäne auch dann anzuzeigen, wenn der eigene Server (und nicht eine beim Provider gehostete Site) aufgerufen wird.
Szenario 1 : eigener Server hat feste externe IP (Firewall-IP, Weiterleitung an DMZ-Adresse des Servers als Eintrag in der Firewall)
Die für das Zertifikat gültige Site wird beim Provider 1und1 gehostet und ist damit im Internet über den DNS bei 1und bekannt; logische Voraussetzung dafür, daß die Site überhaupt aufgerufe werden kann.
Versuch 1: http-Weiterleitung Site => externe IP-Adresse
Es meldet sich zwar der Server und die Site auf dem Server. Da die URL im Browser aber die externe IP-Adresse anzeigt statt dem Site-Namen, liefert der Vergleich mit dem Zertifikat ein FALSE.
Versuch 2: Veränderung der Einstellung des 1und1-DNS-Servers: "A/AA-Eintrag" für die Site => externe IP-Adresse
(zu finden bei DNS-Einstellungen)
Damit verweist die Site -statt auf den 1und1-Site-Server- auf die eigene externe IP-Adresse ... und schon funktioniert's.
(Leider kann ich dem 1und1-Techniker nicht danken, der nach einigen Recherchen und Anfragen schließlich auf die Idee kam.)
--
Szenario 2 : eigener Server ist über eine flexible selfhost.bz-Adresse erreichbar.
Wir betreiben einen weiteren Server, der von extern statt mit einer festen IP über eine selfhost.bz-Adresse betrieben wird; also ist die externe Adresse variabel. Versucht man nun denselben Trick, stellt man fest, dass die Maske beim Provider 1und1 als zum 1und1-Server alternatives DNS-Ziel nur eine IP-Adresse, nicht aber eine Site -in diesem Fall die xxx.sellfhost.bz-Adresse- zulässt. Dieser Weg geht also in diesem Fall nicht.
...was zum alternativen Ansatz führt, bei einer Anfrage auf die interne IP des eigenen Servers über die dortigen eigenen DNS-Einstellungen dafür zu sorgen, daß sich die gewünschte Site auf dem WEB-Server im Browser meldet; somit die Auflösung "im eigenen Hause" geschieht.
Das funktioniert auch -am einfachsten durch Pflege der Datei hosts- und zwar dann, wenn man im Feld "Hostname" der Bindung der im IIS eingetragenen Website die gewünschte Site einträgt.
Und jetzt kommt's: man kann diesen Eintrag in das Feld "Hostname" aber nur vornehmen, wenn man darf und der IIS erlaubt einen Eintrag nur, wenn http als Protokoll gewählt wurde; nicht aber für https, dann wird das Feld ausgegraut und läßt keinen Eintrag zu.
Ich denke, daß es sich hierbei um einen gewollten Schutz handelt, der verhindern soll, daß die Sicherheit des Zertifikats hinsichtlich der Bestätigung der Site ausgehebelt werden kann. Dieses Ansinnen ist ja für sich genommen ehrenhaft, berücksichtigt aber leider nicht unseren legitimen Fall.
Hat jemand eine Idee, wie man intern -also auf dem eigenen Server- die Adresse https://localhost nach https://[Site] aufgelöst bekommt ?
Bin gespannt !
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: 333878
Url: https://administrator.de/contentid/333878
Ausgedruckt am: 21.11.2024 um 20:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
ich verstehe die Frage nicht wirklich.
Du möchtest eine bestimmte Webseite im Haus selber hosten.
OK, hat viele Nachteile, z.B. die Bandbreite. Webserver haben häufig 1GBit Down und Up.
Sagen wir mal www.firma.de
Also trägst Du für www.firma.de die IP Eures Anschlusses ein.
Fertig. Das geht auch mit 1und1 und ist Basiswissen.
Oder soll das parallel zur Homepage sein?
Dann einfach die URL ändern.
Z.B. intern.firma.de
Bei 1und1 muss man dazu eine Subdomäne erstellen und die IP dort dann eintragen.
Dem IIS sind Hostnamen und URLs egal solange man nur eine Seite hat.
Sonst muss man halt den richtigen Hostnamen verwenden.
Damit der Aufruf dann von intern funktioniert musst Du die internen DNS-Einträge für die Webseite anpassen.
Das machst Du am DNS-Server des AD.
Stichwort Split-DNS. (WAN intern.firma.de -> 83.50.51.52, LAN intern.firma.de -> 192.168.0.25)
Viele Grüße
Stefan
ich verstehe die Frage nicht wirklich.
Du möchtest eine bestimmte Webseite im Haus selber hosten.
OK, hat viele Nachteile, z.B. die Bandbreite. Webserver haben häufig 1GBit Down und Up.
Sagen wir mal www.firma.de
Also trägst Du für www.firma.de die IP Eures Anschlusses ein.
Fertig. Das geht auch mit 1und1 und ist Basiswissen.
Oder soll das parallel zur Homepage sein?
Dann einfach die URL ändern.
Z.B. intern.firma.de
Bei 1und1 muss man dazu eine Subdomäne erstellen und die IP dort dann eintragen.
Dem IIS sind Hostnamen und URLs egal solange man nur eine Seite hat.
Sonst muss man halt den richtigen Hostnamen verwenden.
Damit der Aufruf dann von intern funktioniert musst Du die internen DNS-Einträge für die Webseite anpassen.
Das machst Du am DNS-Server des AD.
Stichwort Split-DNS. (WAN intern.firma.de -> 83.50.51.52, LAN intern.firma.de -> 192.168.0.25)
Viele Grüße
Stefan
Wir betreiben einen weiteren Server, der von extern statt mit einer festen IP über eine selfhost.bz-Adresse betrieben wird; also ist die externe Adresse variabel. Versucht man nun denselben Trick, stellt man fest, dass die Maske beim Provider 1und1 als zum 1und1-Server alternatives DNS-Ziel nur eine IP-Adresse, nicht aber eine Site -in diesem Fall die xxx.sellfhost.bz-Adresse- zulässt. Dieser Weg geht also in diesem Fall nicht.
Und ob das geht!Du brauchst nur bei 1und1 statt einem A Record nur einen CNAME Eintrag anlegen der auf die selfhost.bz Adresse zeigt, fertig
, kein Gefrikel am IIS nötig! DNS Grundlagen ...Gruß p.
Das hört sich gut an. Probier' ich morgen mal. Danke. Gruss !
Hallo Stefan,
vielen Dank für Deine Mühe. Mit "Basiswissen" meintest Du sicher die http-Weiterleitungsmöglichkeit. Wie in meinem Text beschrieben (Szenario 1) führt das aber nicht zur Lösung, denn die Browser-URL lautet dann "https://[IP-Adresse]" statt 1", was zur Ablehnun der Zertifikats für [Site] führt.
Die korrekte Lösung für diesen Fall ist tatsächlich, die Domäne beim Povider -in diesem Falle 1und1- auf die eigene feste IP-Adresse zu routen mittels einem "A/AA-Eintrag".
Für den Fall, daß Ziel eine variable Adresse bzw. eine Provider-Site sein sollte -etwa xy.selfhost.bz- ist die Lösung, eine sog. "CName-Weiterleitung" zu veranstalten, die richtige. 1und1 läßt das zwar bloss für Subdomains zu, das spielt aber keine Rolle.
--
Hintergrund der Aktion ist nicht ein WEB-Auftritt, sondern die ssl-verschlüsselte Nutzung von WEBdav in Verbindung mit net use zwecks Dateiübertragung per xcopy / robocopy.
Voraussetzung für das Funktionieren der ssl-Verschlüsselung in WEBdav ist aber, daß ssl zunächst im Browser korrekt funktioniert; sonst geht's nicht.
Gruss Walter
vielen Dank für Deine Mühe. Mit "Basiswissen" meintest Du sicher die http-Weiterleitungsmöglichkeit. Wie in meinem Text beschrieben (Szenario 1) führt das aber nicht zur Lösung, denn die Browser-URL lautet dann "https://[IP-Adresse]" statt 1", was zur Ablehnun der Zertifikats für [Site] führt.
Die korrekte Lösung für diesen Fall ist tatsächlich, die Domäne beim Povider -in diesem Falle 1und1- auf die eigene feste IP-Adresse zu routen mittels einem "A/AA-Eintrag".
Für den Fall, daß Ziel eine variable Adresse bzw. eine Provider-Site sein sollte -etwa xy.selfhost.bz- ist die Lösung, eine sog. "CName-Weiterleitung" zu veranstalten, die richtige. 1und1 läßt das zwar bloss für Subdomains zu, das spielt aber keine Rolle.
--
Hintergrund der Aktion ist nicht ein WEB-Auftritt, sondern die ssl-verschlüsselte Nutzung von WEBdav in Verbindung mit net use zwecks Dateiübertragung per xcopy / robocopy.
Voraussetzung für das Funktionieren der ssl-Verschlüsselung in WEBdav ist aber, daß ssl zunächst im Browser korrekt funktioniert; sonst geht's nicht.
Gruss Walter
Das funktioniert. Jaja, sicher DNS. Wusste bloss nicht, daß man den DNS bei den Providern mitverwalten kann. Das ganze WEB-Zeugs ist normalerweise nicht so sehr meine Baustelle gewesen. Ich halte es eher mit SQL-Server und Co.
Gruss Walter
Gruss Walter
