Dalai
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
Hallo Leute, ich hab mal wieder eine Frage an die (Besser)wisser ☺ zu einer (vielleicht?) ungewöhnlichen Konfiguration. Gegeben ist ein Apache Webserver, der im LAN verschiedene Seiten bereitstellt (z.B. Munin). Kürzlich ist ein DAViCal hinzugekommen, der von außen erreichbar sein soll - das funktioniert bereits. Der Server selbst hat nur eine IP im LAN und auf diese wird der Port vom Router weitergeleitet. Die externe IP ist mit zwei verschiedenen Namen (mail.domain.de und ho.domain.de) zu erreichen. Die Konfig sieht derzeit so aus: /etc/apache2/conf.d/homeoffice: <IfModule mod_ssl.c>
Listen 8443
[...]
</IfModule>
/etc/apache2/sites-available/davical: <IfModule mod_ssl.c>
<VirtualHost *:8443>
ServerName ho.domain.de
Alias /davical /usr/share/davical/htdocs
[...]
</VirtualHost>
</IfModule> Der VHost setzt noch einige Einstellungen für SSL, die für die Frage bzw. das Problem aber keine Rolle spielen. Der VHost funktioniert einwandfrei, auch von außen beim Zugriff auf ho.domain.de:8443. Frage: Wie kann ich verhindern, dass ein Zugriff auf mail.domain.de:8443 auf dem VHost für ho.domain.de landet? Ich habe bereits probiert, die Domain im <VirtualHost>-Tag anzugeben sowie beim NameVirtualHost ho.domain.de:8443 zu ergänzen, aber von außen funktioniert der Zugriff weiterhin über den "falschen" Namen. Was übersehe ich? Geht das überhaupt mit einer einzelnen internen IP-Adresse des Servers? MfG Dalai
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Dalai schrieb: Frage: Wie kann ich verhindern, dass ein Zugriff auf mail.domain.de:8443 auf dem VHost für ho.domain.de landet?
Wenn das der einzige VHost mit dieser IP-Port-Kombination ist: Gar nicht. Aber du kannst einen Default-Dummy-VHost einrichten, der ausgeliefert wird, wenn mit einem anderen Name zugegriffen wird. Alternativ kannst du auch einfach Umleitungen auf die korrekte Domain einrichten.
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
misterunknown schrieb: Wenn das der einzige VHost mit dieser IP-Port-Kombination ist: Gar nicht.
Dachte ich mir schon.
Aber du kannst einen Default-Dummy-VHost einrichten, der ausgeliefert wird, wenn mit einem anderen Name zugegriffen wird.
Du meinst sowas:
<IfModule mod_ssl.c>
NameVirtualHost *:8443
<VirtualHost *:8443>
DocumentRoot /var/www
</VirtualHost>
<VirtualHost ho.domain.de:8443>
ServerName ho.domain.de
Alias /davical /usr/share/davical/htdocs
[...]
</VirtualHost>
</IfModule> Oder kann ich gar den Namen im <VirtuaHost> weglassen, weil ServerName bereits nur auf die richtige Adresse reagiert?
Alternativ kannst du auch einfach Umleitungen auf die korrekte Domain einrichten.
Das ist es, was ich nicht will. Ziel ist, dass man nur mit richtiger Kombination aus Domain und Port auf den DAViCal kommt. Ja, ich weiß, bietet keine Abwehr von Angriffen usw., aber das Verlegen von Ports hilft schon sehr deutlich vor automatisierten Loginversuchen, vor allem bei SSH, aber mit Sicherheit auch bei anderen Diensten. MfG Dalai
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Dalai schrieb: Du meinst sowas:
Genau, so ähnlich. Beachte, dass die Direktive NameVirtualHost im Apache 2.4 keine Wirkung mehr hat, und daher um Missverständnissen vorzubeugen weggelassen werden sollte.
Oder kann ich gar den Namen im <VirtuaHost> weglassen, weil ServerName bereits nur auf die richtige Adresse reagiert?
Nein, den Name kannst du nicht weglassen. Der String hinter VirtualHost bezieht sich nur auf die IP und den Port. Wenn dort ein Name steht wird er nur aufgelöst. ServerName ist dort also Pflicht. Bei mir würde es also ungefähr so aussehen:
<VirtualHost *:8443>
DocumentRoot /var/www/dummy
…
</VirtualHost>
<VirtualHost *:8443>
ServerName ho.domain.de
…
</VirtualHost>
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
misterunknown schrieb: Genau, so ähnlich. Beachte, dass die Direktive NameVirtualHost im Apache 2.4 keine Wirkung mehr hat, und daher um Missverständnissen vorzubeugen weggelassen werden sollte.
OK, danke für den Hinweis. Spielt bei Ubuntu Precise aber keine Rolle, weil Apache 2.2.22, aber merke ich mir für die Zukunft.
Nein, den Name kannst du nicht weglassen. Der String hinter VirtualHost bezieht sich nur auf die IP und den Port. Wenn dort ein Name steht wird er nur aufgelöst. ServerName ist dort also Pflicht. Bei mir würde es also ungefähr so aussehen:
<VirtualHost *:8443>
DocumentRoot /var/www/dummy
…
</VirtualHost>
<VirtualHost *:8443>
ServerName ho.domain.de
…
</VirtualHost>
Hier hast du den Namen im <VirtualHost>-Tag doch aber auch weggelassen; genau darauf bezog ich mich. Dass die Angabe ServerName ho.domain.de Pflicht ist, ist klar, denn darauf reagiert ja der VHost im Apache. Es war nur die Frage, ob <VirtualHost *:8443> oder <VirtualHost ho.domain.de:8443>. Ich werd das nach Feierabend der Mitarbeiter mal ausprobieren, in der Hoffnung, dass keiner schreit oder anruft 😉. MfG Dalai
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Dalai schrieb: OK, danke für den Hinweis. Spielt bei Ubuntu Precise aber keine Rolle, weil Apache 2.2.22, aber merke ich mir für die Zukunft.
Achso, ok, dann ist sie noch nötig.
Es war nur die Frage, ob <VirtualHost *:8443> oder <VirtualHost ho.domain.de:8443>.
Das kommt darauf an, auf welche IP der Apache reagieren soll. Mit *:8443 lauscht er auf allen konfigurierten IPs (also auch private IPs und localhost), bei ho.domain.de.8443 lauscht er nur auf die IP, auf die ho.domain.de auflöst.
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
Es funktioniert leider nicht, wie es soll. <IfModule mod_ssl.c>
NameVirtualHost *:8443
<VirtualHost *:8443>
DocumentRoot /var/www
[...]
</VirtualHost>
<VirtualHost ho.domain.de:8443>
ServerName ho.domain.de
Alias /davical /usr/share/davical/htdocs
[...]
</VirtualHost>
</IfModule> In beiden VHosts ist SSL eingeschaltet. Beide liefern Zertifikate aus, der Dummy nur das snakeoil, der echte VHost natürlich das gekaufte Cert. LAN-intern funktioniert das wunderbar, ein Zugriff auf mail.domain.de:8443 liefert das selbstsignierte Cert (mit entsprechender Warnung im Browser), ein Zugriff auf ho.domain.de:8443 liefert das gekaufte. Soweit alles in Ordnung. Aber von außen funktioniert das nicht, der Browser zeigt immer das gekaufte Cert, auch beim Zugriff auf mail.domain.de:8443. Wo ist denn jetzt noch mein Denkfehler? [EDIT] Korrektur: Intern wird auch das falsche Cert ausgeliefert, sofern man nicht auf dem Server selbst auf die Adresse zugreift sondern von einem anderen Client aus. [/EDIT] MfG Dalai
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Dalai schrieb: Es funktioniert leider nicht, wie es soll.
Achja... Das ist so eine tricky Sache mit NameVirtualHost, denn was dort definiert ist muss exakt der Definition im VirtualHost-Abschnitt entsprechen. In deinem Fall müsstest du also noch eine NameVirtualHost-Direktive einbauen, die ho.domain.com:8443 enthält:
NameVirtualHost *:8443
NameVirtualHost ho.domain.com:8443
<VirtualHost *:8443>
…
</VirtualHost>
<VirtualHost ho.domain.com:8443>
…
</VirtualHost> Das Problem umgeht man, indem man sich an die einfache Regel hält: Weder bei NameVirtualHost, noch bei VirtualHost sollte irgendein Domainname auftauchen, außer es gibt einen triftigen Grund. Das verwirrt nur und ist extrem unpraktisch im Handling mit dem Apache 2.2. Wenn du also nicht die Anforderung hast, den VHost wirklich nur auf einer dedizierten IP lauschen zu lassen, lass dieses Domain-Geraffel einfach weg. Das ist einfach, übersichtlich und funktioniert 😉 NameVirtualHost *:8443
<VirtualHost *:8443>
# Dummy
…
</VirtualHost>
<VirtualHost *:8443>
# eigentlicher Host
ServerName ho.domain.com
…
</VirtualHost>
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
misterunknown schrieb: Das Problem umgeht man, indem man sich an die einfache Regel hält: Weder bei NameVirtualHost, noch bei VirtualHost sollte irgendein Domainname auftauchen, außer es gibt einen triftigen Grund. Das verwirrt nur und ist extrem unpraktisch im Handling mit dem Apache 2.2. Wenn du also nicht die Anforderung hast, den VHost wirklich nur auf einer dedizierten IP lauschen zu lassen, lass dieses Domain-Geraffel einfach weg. Das ist einfach, übersichtlich und funktioniert 😉 NameVirtualHost *:8443
<VirtualHost *:8443>
# Dummy
…
</VirtualHost>
<VirtualHost *:8443>
# eigentlicher Host
ServerName ho.domain.com
…
</VirtualHost>
Schön wär's, wenn das funktionieren würde. Das habe ich selbstverständlich ebenfalls probiert. Leider wird immer der erste davon bevorzugt - also landet alles im Dummy oder alles im gewünschten VHost. Irgendwie muss das mit SSL zusammenhängen, denn mit den anderen VHosts nach gleichem Schema für den internen Betrieb funktioniert das. Bei den VHosts nach dem von dir gezeigten Schema bekomme ich beim Zugriff immer das snakeoil-Cert, wenn der Dummy zuerst aufgeführt ist. MfG Dalai
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Dalai schrieb: Irgendwie muss das mit SSL zusammenhängen, denn mit den anderen VHosts nach gleichem Schema für den internen Betrieb funktioniert das. Bei den VHosts nach dem von dir gezeigten Schema bekomme ich beim Zugriff immer das snakeoil-Cert, wenn der Dummy zuerst aufgeführt ist.
Hast du im Dummy-VHost auch SSL aktiv? Springt eventuell noch ein anderer VHost dazwischen (ls -l /etc/apache2/sites-enabled/)? Apache2 neu gestartet? Ansonsten kann es auch sein, dass Browser Zertifikate cachen. Du kannst mit openssl testen, ob das richtige kommen würde:
openssl s_client -servername ho.domain.de -connect ho.domain.de:443 | openssl x509 -noout -text | egrep "(Subject:|DNS)"
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
misterunknown schrieb: Hast du im Dummy-VHost auch SSL aktiv?
Selbstverständlich.
Springt eventuell noch ein anderer VHost dazwischen (ls -l /etc/apache2/sites-enabled/)?
Nein, es gibt nur diese beiden VHosts, in denen SSL eingeschaltet ist und die auf diesem Port aktiv sind. Alle anderen VHosts sind auf Port 80 und ohne SSL.
Apache2 neu gestartet?
Jep, nach jeder Änderung an der Konfig und Überprüfen selbiger mit apache2ctl -S .
Ansonsten kann es auch sein, dass Browser Zertifikate cachen.
Unwahrscheinlich. Da das Cert nicht zur eingegebenen Domain passt bzw. überhaupt ein selbstsigniertes ist, ich den weiteren Verbindungsaufbau natürlich nach Prüfen des Domainnamens ablehne, sollte da gar nichts im Cache sein (ich war ja nie auf der Seite). Zudem habe ich natürlich verschiedene Browser im Einsatz, darunter auch portable.
Du kannst mit openssl testen, ob das richtige kommen würde:
openssl s_client -servername ho.domain.de -connect ho.domain.de:443 | openssl x509 -noout -text | egrep "(Subject:|DNS)"
Das werde ich mal tun. MfG Dalai
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
Hm. Es gibt noch die Direktive SSLStrictSNIVHostCheck. Diese sollte bei SNI mit SSL auf "on" gesetzt sein:
SNIStrictSNIVHostCheck on
Die gehört Einstellung gehört nach mods-available/ssl.conf.
|
Dalai
(Themenstarter)
Anmeldungsdatum: 16. Juni 2008
Beiträge: 2316
Wohnort: Meiningen
|
Sorry, dass ich so lange nichts von mir hören ließ. Andere Dinge hatten leider Vorrang. Es funktioniert wie von dir vorgeschlagen. Nur lynx will damit nicht. Der sieht auf beiden VHosts immer nur das selbstsignierte Cert, warum auch immer. Der Einfachheit und Geschwindigkeit halber hatte ich hauptsächlich mit lynx getestet. Das unterschiedliche Verhalten der verschiedenen Webclients/-browser hat mich glauben lassen, die Konfig wäre verkehrt oder würde nicht funktionieren. Mit Midori, Firefox, SeaMonkey, IE11 und einem Android-Schlaufon funktionieren beide VHosts wie gewünscht - beim Dummy sehen sie nur das selbstsignierte, beim echten VHost das gekaufte Cert. Vielen Dank für deine umfangreiche und kompetente Hilfe 👍! Ich markiere das Thema als gelöst, wenn nicht innerhalb der nächsten Tage irgendein Mitarbeiter schreit, weil er nicht auf den DAViCal kommt. MfG Dalai
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21725
Wohnort: Lorchhausen im schönen Rheingau
|
Nur als Nachtrag: Dalai schrieb: Es funktioniert wie von dir vorgeschlagen. Nur lynx will damit nicht.
lynx kann kein SNI: 1066424 Das wird wohl auch nicht gefixed. Evtl solltest Du zum Testen links, w3m, curl oder wget nehmen 😉
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5323
|
redknight schrieb: Nur als Nachtrag: Dalai schrieb: Es funktioniert wie von dir vorgeschlagen. Nur lynx will damit nicht.
lynx kann kein SNI: 1066424 Das wird wohl auch nicht gefixed. Evtl solltest Du zum Testen links, w3m, curl oder wget nehmen 😉
Dort steht: This bug report is a duplicate of: Bug #732177: No SNI support in Lynx.
Und dieser Bug wiederum ist gefixt. Ich erkenne allerdings nicht, ob das trusty betrifft oder nicht.
|