Apache 2, virtual hosts, ssl klappt nicht zusammen?

[Wiedmann]

Oder wie?? Nach meinem möglicherweise veralteten Wissensstand sollte das nämlich gerade so nicht funktionieren.

Das, warum man SSL benutzt, funktiniert mit namebased VirtualHosts auch nicht: die Zertififizierung

(Allerdings ist das den ganzen Wohnzimmeradmins egal )

[rowitech]

Hallo,

sorry, ich war für 2 Wochen offline. Dass das Zertifikat nicht klappen kann, sollte man wohl so nicht unbedingt sagen, denn immerhin wird es für die erste (passende) URL korrekt sein (können). Da ich prinzipiell wohl für jeden VirtualHost eigene Zertifikate anbringen kann, sollte aber auch sogar das klappen. Who cares, für mich war es nicht so wichtig, ob _ich_ mein Zertifikat korrekt angezeigt bekomme, sondern dass mein Loginpasswort nicht im Klartext übermittelt wird. Klar, es gibt Paranoide, die eine Tresortüre als Hauseingangstüre nutzen, aber ich halte adäquate Mittel für die gesuchte Lösung sinnvoller, als für den Adminzugang zu einem kleinen Forum gleich Fort Knox oder Bank von England zu spielen...

Gruß
Rolf

Hier meine Config für SSL:

Code: Select all

NameVirtualHost 88.1.2.3:443

<VirtualHost 88.1.2.3:443>
# SSL (START)
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/cert.crt
SSLCertificateKeyFile /etc/apache2/ssl/cert.key
SSLProtocol all
SSLCipherSuite HIGH:MEDIUM
# SSL (ENDE)
DocumentRoot /usr/share/web
ServerName mail.example.net
</VirtualHost>

<VirtualHost 88.1.2.3:443>
# SSL (START)
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/cert.crt
SSLCertificateKeyFile /etc/apache2/ssl/cert.key
SSLProtocol all
SSLCipherSuite HIGH:MEDIUM
# SSL (ENDE)
DocumentRoot /var/www/lara
ServerName lara.example.net
</VirtualHost>


[Wiedmann]

sondern dass mein Loginpasswort nicht im Klartext übermittelt wird.

Dafür gibt es Auth_Digest.

[rowitech]

...nur, wenn man keine eigene Loginmaske in PHP baut.

Gruß
Rolf

[Wiedmann]

...nur, wenn man keine eigene Loginmaske in PHP baut.

Wie meinen

[Ol'man]

Da ich prinzipiell wohl für jeden VirtualHost eigene Zertifikate anbringen kann, sollte aber auch sogar das klappen

Das ist doch leider immer noch am Problem vorbei. Zuordnung der Zertifikate - kein Thema, die .conf-Syntax sieht das so vor. Es ist nur leider so, daß NameVirtualHosts vom Apache nicht auseinandergehalten werden können, wenn die Requests verschlüsselt hereinkommen. Das steht jedenfalls immer noch so unwidersprochen in der Apache-Doc: http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2

Hier noch mal für alle, bevor es noch jemand liest und auch so machen will:

Das folgende Beispiel funktioniert nur, solange man die VirtualHosts z. B. per http://lara.example.net:443/ (http ohne 's') adressiert. Client-Requests für https://lara.example.net/ sollten statt dessen bei mail.example.net:443 landen.

HTTP anstelle HTTPS zu verwenden geht wiederum, da Apache per default trotz "SSLEngine enable" noch beide Protokolle akzeptiert (was man wohl allerdings in den meisten Fällen aus Sicherheitsgründen gar nicht will). Erst wenn man in jeden VirtualHost auch noch die Direktive "SSLRequireSSL" hineinschreibt, wird HTTP abgeschaltet.

Edit: Meine Annahme, es funktionieren per default noch HTTP und HTTPS gleichzeitig, hat sich bei einem Test erst mal nicht bestätigt (was ja wiederum auch gar nicht so schlecht ist). Wahrscheinlich muß man dafür noch an der 'SSLCipherSuite'-Direktive herumschrauben und irgendwas wie "None"- oder "NULL"-Verschlüsselung erlauben. Bei Gelegenheit werd' ich's ausprobieren und evtl. hier ergänzen.

Code: Select all

NameVirtualHost 88.1.2.3:443

<VirtualHost 88.1.2.3:443>
ServerName mail.example.net
SSLEngine On
...
</VirtualHost>

<VirtualHost 88.1.2.3:443>
ServerName lara.example.net
SSLEngine On
...
</VirtualHost>


[ospx]

Eure Posts waren ja wahrlich interessant, hat mich um einiges weitergebracht. Trotzdem hänge ich hier an einem Problem mit ssl auf apache2, dass ich partout nicht aus der Welt kriege. Wahrscheinlich habe ich mir das ganze zu einfach vorgestellt. Ich möchte auf meinem Testserver (debian+ apache2), der an einer dynIp hängt, eine (sub)-Domain auf ssl laufen lassen.
Bisher liefen die anderen Subdomains über einfache NameVirtualHosts. Das funktioniert/e gut.
Nun habe ich eine 2. virtuelle Netzwerkschnittstelle mit einer 2. (lokalen IP-Adresse) am Server aufgeschaltet. Der Router leitet Port 80 über Portforwarding an die eine lokale IP-Adresse des Servers, über die andere 2. (virtuelle) Schnittstelle und IP am Server wird Port 443 weitergeleitet. Soweit, so gut. Im lokalen Netz kann ich https auch über die 2. lokale IP ansprechen. Versuche ich jedoch aus dem WAN auf https://xxy.example.de zuzugreifen, bringt mir Mozilla eine Fehlermeldung und der IE6 springt gleich auf seine Suchseite. Ursprünglich wollte ich mir den hickhack mit einem eigenen DNS sparen. War das zu kurz gedacht, mit getrenntem Portforwarding ohne eigenen DNS das Ziel zu erreichen oder könnte man es und ich mache irgendwas anderes falsch?
Liegt es daran, dass der Server auf der lokalen IP lauscht, Anfragen aber aus dem Inet kommen oder kann es am Router liegen? Keine Ahnung, wo ich nun noch suchen soll. War es zu kurz gedacht, die IP's nur zwischen Server und Router aufzuspalten, da sie ja danach wieder zusammenlaufen?

Der Fehler von Mozilla bei Aufruf von 'https://xxy.example.de' lautet:
"xxy.example.de hat eine falsche oder unerwartete Nachricht gesendet. Fehler-Code 12263" Denselben Fehler bekomme ich aber auch bei jeglicher anderer Subdomaine auf https://irgendwas.example.de, obwohl die ja gar nicht in der Config eingetragen sind. Irgendwelche Ideen, Anregungen oder Lösungsvorschläge. Sitze hier nun schon seit zwei- drei Tagen an diesem Problem und könnte in den Tisch beißen, was dann aber wahrscheinlich außer an meinem Gebiß nichts weiter ändern würde oder habt ihr auf diese Weise eure Server überredet? Gehts vielleicht mit Hypnose oder gut- zureden? Nein, ich will hier nicht über meine Unzulänglichkeiten im Thema DNS und ssl hinweggehen. Ein kleiner Tipp wäre genehm.
Dank
mfg ospx

ps: kann man nun eigentlich NameVirtualHosts und IP-basierte VirtualHosts in einer Config an verschiedenen IP's über die Listen- Direktive prinzipiell nebeneinander betreiben oder geht das nicht überhaupt gar nicht?

ps:bekomme oben erwähnte Fehlermeldungen "...mixingPorts..., wenn ich:

<VirtualHost 88.1.2.3:443>

, mit Portangabe nutze.

[Ol'man]

Wenn Du Apache auf einem "multi-homed-host" betreibst, d. h. mehrere virtuelle IPs oder sogar mehrere physische Netzwerk-Interfaces auf derselben Kiste hast, brauchst Du doch gerade KEIN 'NameVirtualHost'.

Weder der Router noch der Webserver muß dann "oberhalb von OSI-Level 3" ins Innere der IP-Pakete schauen. Soll heißen, auch das Portforwarding müßte dann ganz einfach auf Basis der Quell- und Ziel-IPs/Portnummern - also Informationen, die aus den nicht von Verschlüsselung betroffenen IP-Headern zu beziehen sind - möglich sein.
Nun gut, es könnte aber schon so sein, daß der Router sich bei SSL aus Gründen, die nur der Hersteller kennt, bockig anstellt. Das wäre hier halt genauer zu untersuchen.

Ein eigener Nameserver würde Dir außerhalb des Intranets auch nicht weiterhelfen, solange Du nur den einen Hostnamen xxy.example.de aufzulösen hast, denn das erledigt Dein DynDNS-Provider schon ganz hervorragend für Dich. Damit kommt die Welt bis zum WAN-Port Deines Routers, und dieser muß dann für die "Diversifikation" (per NAT/Masquerading/Port-Forwarding) auf zwei Intranet-IPs sorgen. Allerdings ist es immer gut, einen eigenen DNS für die konsistente Auflösung solcher Hostnamen im Intranet "vorrätig" zu haben.

Zu Deiner letzten Frage: Selbstverständlich kann man in Apache IP-basiertes und 'NameVirtualHost'-basiertes virtual hosting miteinander mixen. Beispiel:

VirtualHost www.domain1.tld (ServerAlias domain1.tld) auf einer IP
(Name-)VirtualHosts [mehrere|verschiedene|Hostnamen].domain2.tld auf einer anderen IP

Zu Deinem PS: Poste doch mal die fragliche Fehlermeldung mit "...mixing ports..." im vollen Wortlaut. Vielleicht fehlt Dir nämlich nur eine konsistente Zuordnung der IPs/Ports bei den 'Listen'-, 'VirtualHost'- und 'ServerName'-Direktiven (ich darf erinnern: es kann nicht schaden, überall IP UND Port anzugeben)

HTH

-OL-

[ospx]

Hallo Ol'man

Ich danke dir vielmals für deine ausführlichen Erklärungen.
Da du mir bestätigtest, dass es über Portforwarding funktionieren müsse und es wohl tatsächlich am Router liegen könnte, habe ich mich nun nochmal intensiver mit diesen Geräten( es sind mehrere hintereinander geschaltet) beschäftigt. Bisher suchte ich den Fehler in der Apache-Konfig bzw. in der Konfiguration der Netzwerk-'interfaces' der virtuellen IP's am Server, da ich mir hier unsicher war und mit eigenen Fehlern rechnete.
Und nun beiße ich doch noch herzhaft in den Tisch... ich hatte einen saublöden Dusselfehler in meiner Routerkonfiguration des 1. Routers. Der hat desshalb schlicht und ergreifend Port 443 nicht geroutet. Darum war https aus dem gesamten Intranet zu erreichen, jedoch nicht aus dem WAN. Hätte ich doch gottverdammt gleich sehen können. Ohne deine Antwort würde ich wohl noch tagelang an den Konfigs des Servers suchen.

Eigentlich funktioniert nun alles, wie es soll.

Dank auch für die Klarstellung, dass IP-basierte VirtualHosts und NameVirtualhosts in obiger Form gemeinsam laufen können. Hatte in manch anderem Forum entgegengesetztes gelesen b.z.w. manche howtos hatten sich nicht eindeutig und z.Teil mißverständlich zum Thema ausgedrückt.
Da es mich sowieso stört, dass ich im Thema DNS nur die nötigsten Grundlagen kenne, werde ich mich mittelfristig wohl auch damit intensiver auseinandersetzen. Bin aber froh, dieses nicht jetzt und heute tun zu müssen, um https zum laufen zu bringen.

Ihr hattet ja schon am Anfang dieses Threads über Inkonsistenzen bei der Zuordnung der IP's und Ports gesprochen und ich hatte darum schon vor dem 1. Post meine Konfig daraufhin überprüft und werde das nun nochmal wiederholen. Sicherlich wird es irgendwo eine betreffende VirtualHost oder ServerName -Direktive sein, die ich übersehen habe. Die Listen-Direktiven können es 100% nicht sein. Werde posten, was rauskommt.
Ansonsten nochmal tausend Dank für die hervorragende(n) und umfangreiche(n) Antwort(en), denn die vorhergehenden waren nicht minder interessant und hilfreich.