SSL und VirtualHosts (apache)
Markus König
ich hab erfolgreich (*schwitz*) nen apache 1.3.23 mit ssl kompiliert - und
man stelle sich sogar vor : er läuft ! :)
SSL läuft auch ohne probleme auf meinem DocumentRoot im SSL-Config teil vom
apache.
Nun möchte ich aber mehrere subdomains auch mit ssl anbieten können ...
Apache.org meint dazu :
"Name-based virtual hosting cannot be used with SSL secure servers
because of the nature of the SSL protocol."
Allerdings muss das doch irgendwie gehen ... web.de macht das z.b. doch auch
;)
(ich weis das mein certifikat dann fuer die subs nicht gültig ist .. ist mir
auch egal ich will nur
das die kommunikation verschlüsselt ist und damit ein sniffen sehr erschwert
wird
- das ist z.b. innen firmennetz wichtig, da ich selbst weis wie gern man
"logs" liest *LOL*)
Hat da jemand nen ansatz - oder besser gleich tutorial - wie man das
hinbiegen kann ?
Vielen Dank.
Markus König
Christoph Vogel
> SSL läuft auch ohne probleme auf meinem DocumentRoot im SSL-Config teil
vom
> apache.
> Nun möchte ich aber mehrere subdomains auch mit ssl anbieten können ...
> Apache.org meint dazu :
> "Name-based virtual hosting cannot be used with SSL secure servers
> because of the nature of the SSL protocol."
Das ist in der Tat so und es wäre müßig die Debatte darüber, daß es doch
irgendwie ginge, wieder hier aufzurollen (damit meine ich, die von Dir
wiedergegebene Aussage ist in dieser Form richtig). Indes gibt es Tricks,
deren Ergebnis sich etwas von "echten" SSL-enabled VHs unterscheidet.
Also Du nimmst ein Wildcard-Zertifikat nehmen, das für all Deine Subdomains
gültig sein soll (so wie Du es beschreibst, könntest Du auch drauf
verzichten). Den SSL-VH fütterst Du mit RewriteRules, die in Abhängigkeit
von der angeforderten Subdomain die Requests in ein bestimmtes
Unterverzeichnis umleiten. Es geht nur so herum, weil zum Zeitpunkt des
Requestaufbaus die Verbindung schon verschlüsselt ist und Apache nicht
entscheiden kann, an welchen VH sie gerichtet ist. Es nimmt daher den ersten
VH mit zutreffender Adresse, sollte es mehrere geben. Solltest Du einen
namebased VH dafür nehmen, so wird der angegebene Name keine Auswirkung
haben, sondern der SSL-VH hört auf alle HTTPS-Anforderungen auf der einen
IP. Etwas unglücklich (wenn auch nachvollziehbar) ist, daß die meisten
Browser ein Wilcard-Domainzertifikat nicht für die Domain ohne Subdomain
akzeptieren; also mit *.test.de geht dann zwar irgendwas.test.de, nicht aber
test.de selber (bzw. im zweiten Fall kriegt man eine Warnung für das
Wildcard-Zertifikat). Bevor Kritik kommt - ja dieses "Workaround" ist
getestet und funktioniert :-)
Wie web.de das macht, weiß ich nicht, kannst Du mal kurz ein Beispiel
nennen, wo das bei web.de so ist?
Gruß,
Christoph.
Markus König
"Christoph Vogel" <cv.n...@corbach.de> schrieb im Newsbeitrag
news:a3s8rg$1alcmh$1...@ID-41014.news.dfncis.de...
> Den SSL-VH fütterst Du mit RewriteRules, die in Abhängigkeit
> von der angeforderten Subdomain die Requests in ein bestimmtes
> Unterverzeichnis umleiten.
das ist bestimmt cool wenn man wuesste wie man das anstellen kann ;-(
> Wie web.de das macht, weiß ich nicht, kannst Du mal kurz ein Beispiel
> nennen, wo das bei web.de so ist?
ein konkretes beispiel müsste ich jetzt erst suchen, aber die verwenden z.b.
fuer
freemail.web.de das gleiche zertifikat und server/ip wie fuer lotto.web.de
(oder so ..)
thx fuer deine antwort :)
Bye,
Markus König
Christoph Vogel
["Virtual Subdomains" im SSL-Host]
> das ist bestimmt cool wenn man wuesste wie man das anstellen kann ;-(
<VirtualHost _default_:443>
# ...auch wenn ich das mit _default_ nicht so mag
DocumentRoot /www/mein_normales_verzeichnis
ServerName test.de
# oder folgendes stärker eingeschränkt
ServerAlias *.test.de
RewriteEngine On
# verwendete Aliase besser ausschliessen, könnte Stress geben
RewriteCond %{REQUEST_URI} !^(/icons/|/mein_eigener_alias/)
# Condition für "virtuelle Subdomain" anlegen
RewriteCond %{HTTP_HOST} ^subdomain\.test\.de$
# den HTTP_HOST fürs Rewrting verfügbar machen
RewriteRule ^(.+)$ %{HTTP_HOST}$1 [C]
# und nun die Requests in neues Verzeichnis umschreiben
RewriteRule ^subdomain\.test\.de(.*) /www/subdomainverzeichnis$1 [L]
SSLEngine on
# und was sonst noch zu SSL reingehört...
</VirtualHost>
Das [C] in der vorletzten RewriteRule kannst Du eigentlich weglassen; wenn
Du das Beispiel allerdings verallgemeinerst und es auf verschiedene
"virtuelle Subdomains" (oder besser: "virtuelle Virtual Hosts") gleichzeitig
anwenden willst, ist es sicherer, beide Regeln miteinander zu verketten.
[SSL bei web.de]
> ein konkretes beispiel müsste ich jetzt erst suchen, aber die verwenden
z.b.
> fuer
> freemail.web.de das gleiche zertifikat und server/ip wie fuer lotto.web.de
> (oder so ..)
Also, leider sind weder die IP-Adressen gleich, noch die Zertifikate. Ich
glaube auch nicht, dass man bei Thawte Wildcard-Zertifikate bekommen kann,
werde das aber mal nachsehen. Allerdings tut das der Lösung oben keinen
Abbruch :-)
Gruß,
Christop.
Tim Evers
> "Markus König" schrieb:
>
>> SSL läuft auch ohne probleme auf meinem DocumentRoot im SSL-Config teil
> vom
>> apache.
>> Nun möchte ich aber mehrere subdomains auch mit ssl anbieten können ...
>> Apache.org meint dazu :
>> "Name-based virtual hosting cannot be used with SSL secure servers
>> because of the nature of the SSL protocol."
>
> Das ist in der Tat so und es wäre müßig die Debatte darüber, daß es doch
> irgendwie ginge, wieder hier aufzurollen (damit meine ich, die von Dir
> wiedergegebene Aussage ist in dieser Form richtig). Indes gibt es
> Tricks, deren Ergebnis sich etwas von "echten" SSL-enabled VHs
> unterscheidet.
Genau, machen wir es kurz: Es geht, Christoph will's nicht wahr haben und
diffamiert mich als Lügner statt es zu testen und ich hab keine Lust hier
nochmal gegen die Wand zu reden.
Die Geschichte dazu ist ab <9glb0r$p7e$1...@newsfeed.nordcom.net>
nachzulesen.
regards
tim
Christoph Vogel
> > Das ist in der Tat so und es wäre müßig die Debatte darüber, daß es doch
> > irgendwie ginge, wieder hier aufzurollen (damit meine ich, die von Dir
> > wiedergegebene Aussage ist in dieser Form richtig). Indes gibt es
> > Tricks, deren Ergebnis sich etwas von "echten" SSL-enabled VHs
> > unterscheidet.
> Genau, machen wir es kurz: Es geht, Christoph will's nicht wahr haben und
> diffamiert mich als Lügner statt es zu testen und ich hab keine Lust hier
> nochmal gegen die Wand zu reden.
Hallo Tim,
wundert mich, daß das immer noch an Dir nagt. Einen Lügner wabe ich Dich nie
gescholten. Du warst damals (06/01), wie
einige vielleicht noch wissen, nicht bereit, Deine Lösung mit uns zu teilen
und behauptetest nur, "es geht" - wie im übrigen jetzt auch. Glenn Kusardi
bist Du ebeso die Antwort schuldig geblieben. Bitte belege doch noch einmal
mit einem Konfigurationsbeispiel Deine These "Zwei Virtual Hosts, eine IP,
ein Port, ein Zertifikat, kein Problem" von damals! Ich würde ja auch gern
was dazulernen, aber dieses Verhalten halte ich nicht für besonders nett,
wenn Du meine ausdrückliche Nachfrage dieses Mal wieder einfach ignorierst,
denn offensichtlich liest Du noch mit. Insofern hast Du damals wie heute vor
keine Wand geredet.
Gruß,
Christoph.
Markus König
> <VirtualHost _default_:443>
> # ...auch wenn ich das mit _default_ nicht so mag
>
> DocumentRoot /www/mein_normales_verzeichnis
> ServerName test.de
> # oder folgendes stärker eingeschränkt
> ServerAlias *.test.de
>
> RewriteEngine On
> # verwendete Aliase besser ausschliessen, könnte Stress geben
> RewriteCond %{REQUEST_URI} !^(/icons/|/mein_eigener_alias/)
> # Condition für "virtuelle Subdomain" anlegen
> RewriteCond %{HTTP_HOST} ^subdomain\.test\.de$
> # den HTTP_HOST fürs Rewrting verfügbar machen
> RewriteRule ^(.+)$ %{HTTP_HOST}$1 [C]
> # und nun die Requests in neues Verzeichnis umschreiben
> RewriteRule ^subdomain\.test\.de(.*) /www/subdomainverzeichnis$1 [L]
>
> SSLEngine on
> # und was sonst noch zu SSL reingehört...
>
> </VirtualHost>
>
> Das [C] in der vorletzten RewriteRule kannst Du eigentlich weglassen; wenn
> Du das Beispiel allerdings verallgemeinerst und es auf verschiedene
> "virtuelle Subdomains" (oder besser: "virtuelle Virtual Hosts")
gleichzeitig
> anwenden willst, ist es sicherer, beide Regeln miteinander zu verketten.
vielen dank für die tipps - werde das morgen mal ausprobieren und melde mich
dann wieder.
Bye,
Markus
Tim Evers
> "Tim Evers" schrieb:
>> Genau, machen wir es kurz: Es geht, Christoph will's nicht wahr haben
>> und diffamiert mich als Lügner statt es zu testen und ich hab keine
>> Lust hier nochmal gegen die Wand zu reden.
>
> Hallo Tim,
>
> wundert mich, daß das immer noch an Dir nagt.
Keine Sorge, es nagt nicht. Ich habe es nicht nötig mich hier zu beweisen.
> Einen Lügner wabe ich Dich nie gescholten. Du warst damals (06/01), wie
> einige vielleicht noch wissen, nicht bereit, Deine Lösung mit uns zu
> teilen und behauptetest nur, "es geht" - wie im übrigen jetzt auch.
Sorry, du hast recht. Es war Glenn, der versucht hat, mein Beispiel als
quasi "billigen Trick" hinzustellen (<Xns90C4EE...@62.153.159.134>).
> Glenn Kusardi bist Du ebeso die Antwort schuldig geblieben. Bitte belege
> doch noch einmal mit einem Konfigurationsbeispiel Deine These "Zwei
> Virtual Hosts, eine IP, ein Port, ein Zertifikat, kein Problem" von
> damals!
Ich glaube nach wie vor, dass es wg Trivialität nicht viel Sinn macht,
das hier zu tun, zumal es nur eine weitere unbeweisbare Behauptung ist.
Aber gut:
<VirtualHost 212.72.185.10:443>
DocumentRoot "/home/www/doc/www.euroimmun.de"
ServerName eurogroe.c.ubcom.net
ServerAdmin hostm...@ubcom.net
ScriptAlias /cgi-bin/ /home/www/doc/www.euroimmun.de/cgi-bin/ TransferLog
/usr/local/etc/httpd/logs/www.euroimmun.de.access_log
SSLEngine on
SSLCertificateFile /usr/local/etc/httpd/conf/ssl.crt/thawte.crt
SSLCertificateKeyFile /usr/local/etc/httpd/conf/ssl.key/server.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
</VirtualHost>
<VirtualHost 212.72.185.10:443>
DocumentRoot "/home/www/doc/www.next-dynamic.de"
ServerName nextdynamic.c.ubcom.net
ServerAdmin hostm...@ubcom.net
ScriptAlias /cgi-bin/ /home/www/doc/www.next-dynamic.de/cgi-bin/
TransferLog /usr/local/etc/httpd/logs/www.next-dynamic.de.access_log
SSLEngine on
SSLCertificateFile /usr/local/etc/httpd/conf/ssl.crt/thawte.crt
SSLCertificateKeyFile /usr/local/etc/httpd/conf/ssl.key/server.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
</VirtualHost>
that's all. thawte.crt ist in diesem Fall ein Wildcard Zertifikat auf
*.ubcom.net.
> Gruß,
>
> Christoph.
regards
tim
Glenn Kusardi
news:pan.2002.02.08.09...@massaker.de:
> Sorry, du hast recht. Es war Glenn, der versucht hat, mein Beispiel als
> quasi "billigen Trick" hinzustellen
> (<Xns90C4EE...@62.153.159.134>).
Soweit ich mich erinnern kann ging es um die Möglichkeit
Domain-"übergreifend" zu arbeiten. Sprich nicht mehrere Subdomains zu haben
sondern mehrere Domains.
Und das ist eben nicht möglich.
Christophs Beispiel hat, soweit ich es erkennen kann, den Nachteil, dass
beim Aufruf auf jeden Fall ein Redirect erzeugt wird und die URL verändert
wird (also am Ende nicht mehr die eigentlich aufgerufene URL angezeigt
wird), da afair die RewriteRule nicht stimmt weil die Zieladresse eine URL
sein müsste?!
>> Glenn Kusardi bist Du ebeso die Antwort schuldig geblieben. Bitte
>> belege doch noch einmal mit einem Konfigurationsbeispiel Deine These
>> "Zwei Virtual Hosts, eine IP, ein Port, ein Zertifikat, kein Problem"
>> von damals!
> Ich glaube nach wie vor, dass es wg Trivialität nicht viel Sinn macht,
> das hier zu tun, zumal es nur eine weitere unbeweisbare Behauptung ist.
> Aber gut:
>
> <VirtualHost 212.72.185.10:443>
> DocumentRoot "/home/www/doc/www.euroimmun.de"
> ServerName eurogroe.c.ubcom.net
^^^^^^^^^
> </VirtualHost>
> <VirtualHost 212.72.185.10:443>
> DocumentRoot "/home/www/doc/www.next-dynamic.de"
> ServerName nextdynamic.c.ubcom.net
^^^^^^^^^
> </VirtualHost>
> that's all. thawte.crt ist in diesem Fall ein Wildcard Zertifikat auf
> *.ubcom.net.
Wie machst du es, dass www.euroimmun.de und www.next-dynamic.de aufgerufen
und die Adresse auch angezeigt werden (also dass man ubcom.net zu keinem
Zeitpunkt sieht)?!
--
pvt: http://www.kusardi.de/
biz: http://www.projektmedien.de/
deutscher (X)HTML Validator: http://validator.projektmedien.de/
Tim Evers
> Tim Evers <dev...@massaker.de> wrote in
> news:pan.2002.02.08.09...@massaker.de:
>
>> Sorry, du hast recht. Es war Glenn, der versucht hat, mein Beispiel als
>> quasi "billigen Trick" hinzustellen
>> (<Xns90C4EE...@62.153.159.134>).
>
> Soweit ich mich erinnern kann ging es um die Möglichkeit
> Domain-"übergreifend" zu arbeiten. Sprich nicht mehrere Subdomains zu
> haben sondern mehrere Domains.
>
> Und das ist eben nicht möglich.
Doch geht genauso, nur dass dann bei mindestens einer Domain das
Zertifikat natürlich den falschen cn hat.
> Wie machst du es, dass www.euroimmun.de und www.next-dynamic.de
> aufgerufen und die Adresse auch angezeigt werden (also dass man
> ubcom.net zu keinem Zeitpunkt sieht)?!
s.o.
regards
tim
Tim Evers
> Tim Evers <dev...@massaker.de> schrieb:
>> that's all. thawte.crt ist in diesem Fall ein Wildcard Zertifikat auf
>> *.ubcom.net.
>
> Das _kann_ Ärger mit dem MSIE geben:
>
> "Please note, however, that MSIE does not implement wildcard certificate
> name checking, so we cannot guarantee that wildcarding will work with
> any Microsoft product for any period of time."
Die Warnung kenn ich wohl,
aber ich hab jetzt seit etwa 3 jahren Wildcard Zertifikate am Start (das
müsste damals noch IE 4.0 gewesen sein) und noch nie von Problemen damit
gehört.
Im übrigen ist die Zeit der Wildcard Zertifikate eh so gut wie abgelaufen.
Die Root CA Mafia hat da mittlerweile den Daumen drauf.
regards
tim
Christoph Vogel
> Keine Sorge, es nagt nicht. Ich habe es nicht nötig mich hier zu beweisen.
So sollte mein Posting auch nicht zu verstehen sein. Ich habe bei der Suche
nach dem alten Thread auch noch ältere Postings von Dir gefunden, in denen
Du genauso mit der mod_ssl-FAQ argumentiert hast. Insofern war meine
Nachfrgae doch glaube ich berechtigt.
>> Bitte belege
>> doch noch einmal mit einem Konfigurationsbeispiel Deine These "Zwei
>> Virtual Hosts, eine IP, ein Port, ein Zertifikat, kein Problem" von
>> damals!
> Ich glaube nach wie vor, dass es wg Trivialität nicht viel Sinn macht,
> das hier zu tun, zumal es nur eine weitere unbeweisbare Behauptung ist.
> Aber gut:
> <VirtualHost 212.72.185.10:443>
> DocumentRoot "/home/www/doc/www.euroimmun.de"
> ServerName eurogroe.c.ubcom.net
> SSLEngine on
> SSLCertificateFile /usr/local/etc/httpd/conf/ssl.crt/thawte.crt
> </VirtualHost>
> <VirtualHost 212.72.185.10:443>
> DocumentRoot "/home/www/doc/www.next-dynamic.de"
> ServerName nextdynamic.c.ubcom.net
> SSLEngine on
> SSLCertificateFile /usr/local/etc/httpd/conf/ssl.crt/thawte.crt
> </VirtualHost>
> that's all. thawte.crt ist in diesem Fall ein Wildcard Zertifikat auf
> *.ubcom.net.
Daß Deine These so wörtlich zu verstehen war, hätte ich auch nicht gedacht
:-) Es ist dehalb nicht trivial m.E. (oder zumindest _für mich_ nicht),
weil ich natürlich erwarten würde, daß diese Konfiguration als Fehler vom
Configtest erkannt wird, glaube Dir aber, daß es funktioniert. Also -
vielen Dank! Jetzt ist die Sache greif- und validierbar. Klar werde ich das
heute abend testen, ich habe nur gerade keine Möglichkeit dazu. Der nächste
Schritt wird dann sein, zu eruieren, _warum_ es funktioniert.
Gruß,
Christoph.
Christoph Vogel
> Tim Evers <dev...@massaker.de> schrieb:
>> that's all. thawte.crt ist in diesem Fall ein Wildcard Zertifikat auf
>> *.ubcom.net.
> Das _kann_ Ärger mit dem MSIE geben:
> "Please note, however, that MSIE does not implement wildcard certificate
> name checking, so we cannot guarantee that wildcarding will work with
> any Microsoft product for any period of time."
Kannst Du noch kurz die Quelle nennen? Für den IE als User-Agent ist indes
nur bedeutsam, daß Wildcard-Zertifikate nicht den "Root-Host" erfassen, wie
ich früher im Thread schon geschrieben habe. Ansonsten machen sie weder bei
IE5 noch bei IE6 Probleme; für den IE4 wäre das noch zu überprüfen.
Gruß,
Christoph.
Tim Evers
> Tim Evers wrote:
>
>> Keine Sorge, es nagt nicht. Ich habe es nicht nötig mich hier zu
>> beweisen.
>
> So sollte mein Posting auch nicht zu verstehen sein. Ich habe bei der
> Suche nach dem alten Thread auch noch ältere Postings von Dir gefunden,
> in denen Du genauso mit der mod_ssl-FAQ argumentiert hast. Insofern war
> meine Nachfrgae doch glaube ich berechtigt.
Obiges war eher wertfrei zu verstehen und ausschliesslich auf deine
Frage, ob es noch "nagt".
Insofern - alles halbe Höhe :)
in diesem Sinne
tim
Christoph Vogel
> <VirtualHost 212.72.185.10:443>
> DocumentRoot "/home/www/doc/www.euroimmun.de"
> ServerName eurogroe.c.ubcom.net
> SSLEngine on
> </VirtualHost>
> <VirtualHost 212.72.185.10:443>
> DocumentRoot "/home/www/doc/www.next-dynamic.de"
> ServerName nextdynamic.c.ubcom.net
> SSLEngine on
> </VirtualHost>
So, jetzt die Ergebnisse meiner Tests (entschuldige bitte, daß ich so
mißtrauisch bin, aber ich bin halt von Haus aus Naturwissenschaftler...) mit
Apache 1.3.23/mod_ssl 2.8.6:
Beide Test-VHs entsprechend dem DNS bekannt (test1 A, test2 CNAME auf
test1).
1. Entsprechende Konfiguration auf einer bisher unkonfigurierten IP
[Apache core]
=> [warn] VirtualHost 217.7.10.13:443 overlaps
=> with VirtualHost 217.7.10.13:443,
=> the first has precedence,
=> perhaps you need a NameVirtualHost directive
[mod_ssl]
=> Init: SSL server IP/port conflict:
=> test1.corbach.de:443 (/etc/apache/httpd.conf:1178) vs.
=> test2.corbach.de:443 (/etc/apache/httpd.conf:1190)
=> Init: You should not use name-based virtual hosts in conjunction with
SSL!!
Also die erwartete Fehlermeldung, es wird auch von beiden "VHs" nur der
Content von test1 geliefert.
2. Entsprechende Konfiguration auf einer bisher unkonfigurierten IP +
entspr. NameVirtualHost IP:Port
[mod_ssl]
=> Init: SSL server IP/port conflict:
=> test1.corbach.de:443 (/etc/apache/httpd.conf:1178) vs.
=> test2.corbach.de:443 (/etc/apache/httpd.conf:1190)
=> Init: You should not use name-based virtual hosts in conjunction with
SSL!!
Aber: Es geht tatsächlich, es wird der korrekte Content aus dem
konfigurierten DocumentRoot geliefert! Allerdings geht es auch, wenn ich die
SSL-Konfiguration aus dem VH "test2" entferne (!). Dann ist zwar die eine
mod_ssl-Fehlermeldung weg, ich kriege dafür aber:
=> Init: (test2.corbach.de:443) You configured HTTP(80) on the standard
HTTPS(443) port!
Mit drei VHs geht es genauso (test3 CNAME test1).
Bleibt noch, die Ursache und eventuelle Nachteile dieser Methode
herauszubekommen und Dir Anerkennung zu schulden :-)
Gruß,
Christoph.
Christoph Vogel
> Christophs Beispiel hat, soweit ich es erkennen kann, den Nachteil, dass
> beim Aufruf auf jeden Fall ein Redirect erzeugt wird und die URL verändert
> wird (also am Ende nicht mehr die eigentlich aufgerufene URL angezeigt
> wird), da afair die RewriteRule nicht stimmt weil die Zieladresse eine URL
> sein müsste?!
Nein, das Rewriting findet ausschließlich auf Dateisystemsbasis statt und
ist für den Client transparent. Es kommt nicht zu einem externen Redirect.
Gruß,
Christoph.