Am 02.04.2004 um 10:59 schrieb Jens Reinartz:
Und jetzt fangen meine Probleme an. Wie aber sage ich dem System:
...
"Wenn eine Anfrage zu eins.dyndns.net herein kommt, dann wähle den
virtual
host 192.168.1.1:443"
"Wenn eine Anfrage zur zwei.dyndns.net herein kommt, dann wähle den
virtual
host 192.168.1.2:443"
Ich schätze, dass die virtuellen Hosts etwa so angelegt werden müssen:
<virtualhost 192.168.1.1:443>
servername zwei.dyndns.net
documentroot /srv/www/eins
SSLCertificateFile /etc/apache2/ssl.cert/eins_Cert.pem
SSLCertificateKeyFile /etc/apache2/ssl.cert/eins_DecodedCert.pem
</virtualhost>
<virtualhost 192.168.1.2:443>
servername zwei.dyndns.net
documentroot /srv/www/zwei
SSLCertificateFile /etc/apache2/ssl.cert/zwei_Cert.pem
SSLCertificateKeyFile /etc/apache2/ssl.cert/zwei_DecodedCert.pem
</virtualhost>
Hallo,
hast Du das bereits ausprobiert und es hat nicht funktioniert oder
ist das noch die theoretische Fingerübung? Also, gemacht habe ich
das natürlich noch nicht aber Deine Überlegungen klingen schlüssig.
Ich habe zwar das dumme Gefühl, dass es auch einfacher gehen müsste,
aber wahrscheinlich muß man da durch und es erst mal so machen und
dann ausgehend von der funktionsfähigen Lösung optimieren. Meine
Idee geht dahin, https für die weiteren Adressen über einen nicht
privilegierten port, beispielsweise 4433, 4434 usw. abzuwickeln
und sicherheitshalber noch einen host auf Port 80 zu haben, der
Redirekt auf die betreffenden virtual hosts ausführt, um bei Ein-
gabe des Namens ohne voran gestelltes Protokoll im Browser die
Leute nicht ins Nirvana zu schicken. Aber das mit den Ports ist
vielleicht auch noch zu umständlich, siehe unten.
Das Problem das Du bei Deiner Lösung siehst kann ich nicht nach-
vollziehen. Der User gibt im Browser ein: https://zwei.dyndns.net.
Dieser geht zum Nmaeserver und fragt, hey sach ma, wer isn das,
"zwei.dyndns.net"? Der antwortet mit "192.168.1.2". Der Browser
macht nun eine Verbindung zu 192.168.1.2:443 auf. Dein Server bzw.
genauer genommen Deine Firewall erkennt den Verbindungsversuch
und ordnet den betreffenden virtual host zu. Die Antwort enthält
dann den dort angegeben Servername, der zufälliger Weise mit dem
im Nameserver registrierten Namen übereinstimmt. Brave Browser
aktualisieren dann die Adresszeile mit dem in der Antwort des
Servers enthaltenen Namen, woran der geneigte User auch einen
Redirect erkennen kann so der Servername in der Antwort einmal
nicht mit dem in der Anfrage ueberein stimmen sollte. In jedem
Fall benutzt der Browser aber den Servernamen in der Antwort
zur Überprüfung der Authentizität des Zertifikats. Der in Deinem
virtual host eingetragene Servername übernimmt also die Rolle
der Identifizierung, ohne die jede Authentifizierung wertlos
ist (genauso wie ein Passwort nur in Verbindung mit einem User-
namen Sinn macht).
Du solltest Dir bewußt sein, dass Du bei Deiner Lösung für jeden
Kunden ein neues Zertifikat signieren lassen mußt. Das ist teuer
und dauert lange. Das passt bestimmt nicht zu einer Site, die
auf einem per DynDNS angebundenen Rechner residiert. Mit selbst
signierten Zertifikaten kannst du Dir den ganzen Zauber auch
sparen, da der Browser des Users deren Echtheit nie prüfen kann
und daher immer die entsprechende Warnung ausgeben wird. Um dies
zu verhindern müsstest Du die User (nicht Deine Kunden) davon
überzeugen, daß Sie vorab Dein Zertifikat in Ihren Browser im-
portieren. Danach würde bei von Dir signierten Zertifikaten nicht
mehr gemeckert. Aber das macht natuerlich niemand. Das ist es,
womit Verisign und Co. Geld machen, denn deren Zertifikate sind
in den Browsern vorinstalliert.
Die Lösung für Dich ist in IMHO eher, dass Du Deinen Kunden an-
bietest, in ihrem Webspace ein paar ungeschützte Vorschaltseiten
zu gestalten, die an dem kritischen Punkt einen link auf
https://meinesicherenseiten.dyndns.org/zwei enthalten. Fuer
diesen sicheren virtual host besorgst Du Dir genau einmal ein
Zertifikat und unterhalb baust Du mit dem User-dir Modul Ver-
zeichnisstruktur nach, wobei die sicheren Seiten dann jeweils
unter /home/~/web/sicher liegen.
Gruß, Christian
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------
