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]
--------------------------------------------------------------------------
