Hallo Freunde der Kunst,

zwecks Aufwandssondierung habe ich eine Frage an Euch.

Ein Apache Webserver, mit W32 Basis (bereits mit einem aktiv eingepflegten und laufenden SSL Zertifikat), soll zusätzlich mit SSL Zertifikaten für alle anderen auf ihm gehostete Seiten (4 unabhängige Domänen) ausgestattet werden. Das Problem ist, dass nach aussen (durch Router) wie innen (local) nur eine IP Adresse zum binden an jene zur Verfügung steht.

Fällt einem/einer evtl. noch eine Lösung ein ? (Aufteilung auf andere Server fällt flach). Interne IPs kann ich dem Host zwar noch zuweisen und binden, aber mit externen ... da siehts schwierig aus.

Dank und Gruß !

Merlin

Dann sieht's sehr düster aus.

Das "Problem" bei HTTPS ist, das es im Gegensatz zu HTTP keine Virtual Hosts unterstützt da der Server sein Zertifikat senden muß, bevor er überhaupt weiß, welche Domain der Client ansprechen möchte.

Als einziger Hack fällt mir spontan ein die einzelnen HTTPS-Instanzen auf verschiedenen Ports laufen zu lassen, aber das ist natürlich auch alles andere als schön, vor allem der Server nicht nur intern genutzt wird.

Hallo Ihr Lieben.

Tja das Projekt lag einige Zeit auf Eis und ist in den Hintergrund getreten.

Aus internem Anlass aber nun leider wieder aktueller denn je.

Habe mir nochmal ein paar Gedanken dazu gemacht, und evtl. hat einer schon Erfahrung / Erfolg mit dem Weg.

Kurz nochmal umrissen:

* W32 Webserver

* Apache for Win

* 4 verschieden (Web)Domains laufen schon

* 1 SSL Zertifikat eingepflegt und läuft

* 1 IP intern

* 1 IP extern (WAN über Router)

* Hausinterner DNS Server (erhöht Spielraum)

Ziel: Weitere SSL Zertifikate für die anderen Domains auf bestehenden Webserver einpflegen.

Als erstes work around hatte ich an weitere interne IP Adressen gedacht, geht bei W32 ja, und diese an dien neuen SSL VHOSTs zu binden.

Macht das Sinn, da ja trotzdem nur einen WAN Ip vorhanden ?!

Tja, sonst den DNS Server umgestalten, dass er bei externer Anfrage von https://www.bla.de auf intern 192.168.123.123:443 geht, nur ist dann die Frage ob das SSL dann auch richtig arbeitet, da man ja eigentlich eine solche "Verschleierung" der Server mit Proxy usw. mit SSL verhindern will (zusätzlich zur Verschlüsselung).

Ist einem vielleicht eine elegantere Lösung gelungen ?

Würde mich über Tips freuen. Danke schon im Vorraus.

Mfg,

Merlin_Level_E

Als erstes work around hatte ich an weitere interne IP Adressen gedacht, geht bei W32 ja, und diese an dien neuen SSL VHOSTs zu binden. Macht das Sinn, da ja trotzdem nur einen WAN Ip vorhanden ?!

Nein, macht keinen Sinn.

Tja, sonst den DNS Server umgestalten, dass er bei externer Anfrage von https://www.bla.de auf intern 192.168.123.123:443 geht

Das geht mit DNS auch nicht.

Ich sehe da nicht wirklich viele Möglichkeiten, vielleicht fällt jemand anders noch was ein.

Was kann Deine Firewall?

Kann diese Hostheaderwerte pruefen (domain1.tld und domain2.tld unterscheiden)?

Kann diese PAT?

Ja ->

Dann kannst Du die zweite HTTPS-Seite intern auf einen anderen Port setzen und das dann mit einer Firewallregel erschlagen.

Z.B. koennen ISA Server Deine gewuenschte Konfiguration abbilden.

Eine andere Idee:

Wenn es Subdomains sind, kannst Du ein Wildcard-Zertifikat fuer SSL nutzen. Das Zertifikat gilt dann fuer *.domain.tld.

Kann diese Hostheaderwerte pruefen (domain1.tld und domain2.tld unterscheiden)?

Sollte mir jedem Reverse-Proxy gehen.

Eine andere Idee:

Wenn es Subdomains sind, kannst Du ein Wildcard-Zertifikat fuer SSL nutzen. Das Zertifikat gilt dann fuer *.domain.tld.

Das funktioniert in der Tat sehr gut, eine derartige Lösung betreibe ich selber. Allerdings hättest du auch die Möglich ein "vollständiges" Wildcardzertifikat anzufertigen, also nicht *.domain.tld, sondern *. Allerdings mag das z.B. der neue IE7 gar nicht und auch sonst ist das nicht wirklich sauber.