Torsten Foertsch schrieb:
On Wed 18 Jun 2008, Stefan König wrote:
sslumleit.conf:
NameVirtualHost subdomain1.example.com.com:80 <virtualhost subdomain1.example.com:80> ServerName subdomain1.example.com RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R] </virtualhost>
das funktioniert wunderbar. der webserver ist nun auch noch unter subdomain2.example.com erreichbar, diese subdomain2 soll jedoch auf ein verzeichnis auf subdomain1 umleiten:
subdomain2.conf:
<VirtualHost subdomain2.example.com:80> ServerName subdomain2.example.com RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://subdomain1.example.com/dir [R] </VirtualHost>
Das funktioniert auch einwandfrei soweit. Nun komtm das ABER. Aber wenn jemand selbstständig https://sudomain2.examlpe.com aufsucht, kommt logischer weise der Inhalt von subdomain1.example.com, da der sub2 vhost nur auf port 80 reagiert. Experimente mit eniem weiteren port 443 vhost brachten leider nur ein Totalversagen mit sich.....
Hat jemand eine Idee?
Du hast Dein Ziel gut verschleiert oder ich bin zu dumm das zu verstehen. Nach dem, was Du sagst kann ich nur antworten, es tut doch.
Dein Besucher auf https://subdomain2 wird eine SSL Fehlermeldung sehen, weil das Zertifikat auf subdomain1 ausgestellt ist. Ist das Dein Problem?
Falls ja, so sei Dir gesagt, das es sich dabei um ein Henne/Ei Problem handelt. Der Apache muss dem Client im SSL Handshake ein Zertifikat über seine Identität geben. Die vom Client gewünschte Identität steht im HTTP Host Header, der verschlüsselt übertragen wird, also erst nach dem SSL Handshake vom Server gelesen werden kann. Darum sind NameVirtualHosts mit SSL generell keine gute Idee.
Man kann aber trotzdem einiges tun:
1) ein wildcard-Zertifikat benutzen. Bei Dir könnte der Servername im Zertifikat (CN) auf *.example.com lauten. Damit wird subdomain1 und subdomain2 funktionieren und Du kannst NameVirtualHosts aufsetzen. Der Apache wird beim Start meckern, es funktioniert aber trotzdem.
2) Du benutzt die "Subject Alternative Name" Extension in x509v3. Damit kannst Du einem Zertifikat mehrere Namen geben. Ich setze das auf einigen Servern seit vielen Jahren erfolgreich ein.
Diese beiden Varianten haben den Nachteil, dass Du beim Erstellen des Zertifikats alle Namen kennen musst und eine Zertifizierungsstelle brauchst, die das auch mitmacht.
3) Etwas moderner und daher wahrscheinlich nicht mit allen Browsern kompatibel ist die TLS Server Name Indication Extension (danach oder nach SNI googlen). Ich habe damit keine Erfahrung. Du brauchst auf jeden Fall einen sehr modernen Apache, den Du möglicherweise selbst patchen musst. Die modernen Browser IE7++, FF2++, opera 8++ sollten SNI können, safari weiß ich nciht. Trotzdem würde ich SNI noch nicht im Internet einsetzen. In einem wohl kontrollierten Intranet oder zum Experimentieren - ja.
Torsten
-- Need professional mod_perl support? Just hire me: torsten.foertsch@gmx.net
vielleicht hab ich es einfach zu kompliziert ausgedrückt. also. ich will 1. ALLE http anfragen an den server auf https umleiten. das klappt soweit auch. 2. http://subdomain2.example.com auf https://subdomain1.example.com/dir umleiten. das klappt auch 3. https://subdomain2.example.com auf https://subdomain1.example.com/dir umleiten. das klapt NICHT, ich komme auf https://subdomain1.example.com raus (d aja noch nix konfiguriert ist, hierfür suche ich eine lösung) :) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org