You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users-de@httpd.apache.org by Jens Reinartz <jr...@snackpointplus.de> on 2004/04/02 10:59:01 UTC

Apache2,multiple Zertifikate und nur einer externen ip

Hallo zusammen,

folgendes Szenario:

Hinter einer Firewall (iptables), die per dynamischer IP-Adresse im Internet
hängt, befindet sich das Intranet mit einem Apache2-Webserver. Hierbei wird
jedlicher 80 und 443 Traffic von der Firewall an den Webserver weiter
geleitet.

Der Webserver soll verschiedene Homepages zur Verfügung stellen.

Ein Zugriff aus dem Internet ist über verschiedene DynDns-Links auf die
Homepages möglich.

Beispiel:
eins.dyndns.net -> firewall ->webserver (virtual hosts)-> /srv/www/eins
zwei.dyndns.net -> firewall ->webserver (virtual hosts)-> /srv/www/zwei

--schnipp ---
NameVirtualHost *:443

<virtualhost  _default_:443>
    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl.cert/mail01Cert.pem
    SSLCertificateKeyFile /etc/apache2/ssl.cert/mail01DecodedCert.pem
    SSLCACertificateFile /etc/apache2/ssl.cert/cacert.pem
    [...]
</virtualhost>

<virtualhost *:443>
    servername zwei.dyndns.net
    documentroot /srv/www/eins
</virtualhost>
<virtualhost *:443>
    servername zwei.dyndns.net
    documentroot /srv/www/zwei
</virtualhost>

--/schnipp ---


Das Problem ist, Ihr könnt es Euch sicherlich denken, dass das Zertifikat
unter default für alle virtual hosts gilt. Laut dem Internet ist es nicht
möglich, den virtual hosts jeweils ein eigenes Zertifikat zuzuordnen. Der
Benutzer aus dem Internet bekommt also immer die Meldung, dass das
Zertifikat für die Domain nicht gültig ist.

Lösung laut Internet: jedes virtual host bekommt eine eigene IP-Adresse.

Dazu muss die Netzwerkkarte mehrere IP-Aliases bekommen. Dies geht so:
ifconfig eth0:1 192.168.1.1 netmask 255.255.255.0
ifconfig eth0:2 192.168.1.2 netmask 255.255.255.0

Und jetzt fangen meine Probleme an. Ich schätze, dass die virtuellen Hosts
etwa so angelegt werden müssen:

--schnipp ---
NameVirtualHost *:443

<virtualhost  _default_:443>
    SSLEngine on
    SSLCACertificateFile /etc/apache2/ssl.cert/cacert.pem
    [...]
</virtualhost>

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

--/schnipp ---

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"

Was wohl nicht funktioniert, ist ein redirect-Befehl innerhalb eines virtual
hosts, da dieser auf eine Internet-IP-Adresse bzw. URL verweisen muss. Ich
biete aber nur interne IP-Adressen.

Über Antworten , HowTos oder passende Links würde ich mich sehr freuen.

Viele Gruesse
Jens


P.S.: Dies ist mein erster Mailinglisten-Beitrag. Schicke ich mögliche
Antworten auf Eure Beiträge auch an users-de@httpd.apache.org?


--------------------------------------------------------------------------
                Apache HTTP Server Mailing List "users-de" 
      unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
           sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------


Re: Apache2,multiple Zertifikate und nur einer externen ip

Posted by Christian Völker <Ch...@Hamburg.de>.
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 users-de-unsubscribe@httpd.apache.org
           sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------


RE: Apache2,multiple Zertifikate und nur einer externen ip

Posted by Steffen Heil <li...@steffen-heil.de>.
Hi

> Und jetzt fangen meine Probleme an. Ich schätze, dass die virtuellen Hosts
etwa so angelegt werden müssen:
> 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"

Gar nicht.
Das Problem liegt viel tiefer. Beide DNS-Namen zeigen von außen auf die
selbe IP. Beide Zugriffe lösen also Abfragen auf die selbe IP und auf den
selben Port aus.
Alles, was über diese Verbindung geht, wird verschlüsselt. AUCH DER
HOST-HEADER.

Also muss jeder hier laufende Server ZUERST die ankommenden Daten
entschlüsseln und DANN die Header lesen.
Virtuelle Hosts werden aber über den HOST-Header unterschieden.

Daher sind Virtuelle Hosts mit einer IP auf dem Standartport defacto nicht
möglich. Punkt.

ES GIBT KEINEN WEG, DIES ZU UMGEHEN.

Möglich ist es nur mit unterschiedlichen Ips oder unterschiedlichen Hosts.

Du mappst 2 SSL-Seiten auf 2 Ips, weil apache es nicht auf einer IP erlaubt.
Wie du siehst, hat das einen Sinn und ist kein Problem von apache.
Du mußt es auf 2 Ports legen oder auf 2 Ips. Alles andere kann aufgrund der
Arbeitsweise des HTTPS Protokolls NIEMALS funktionieren.

Gruß,
  Steffen


--------------------------------------------------------------------------
                Apache HTTP Server Mailing List "users-de" 
      unsubscribe-Anfragen an users-de-unsubscribe@httpd.apache.org
           sonstige Anfragen an users-de-help@httpd.apache.org
--------------------------------------------------------------------------