Servus, am einfachsten kann man die ganze Geschichte unter Linux mit virtuellen Netzwerkdevices lösen. Einfach, sofern möglich natürlich, für jeden vhost ein eigenes device einrichten (also dann eth0:1, eth0:2 usw.). Dann braucht man keine NamebasedVirtualHost, sondern kann jedem vhost eine eigene ip geben. Dann läufts! Hab ich auch so gemacht.
Gruß Sven > On 13.09.2007, at 13:38, Lars Eilebrecht wrote: > > Daniel Schulz wrote: > >> Jetzt ist der Groschen gefallen. OK, das geht so also nicht. Aber > >> eine > >> Alternative wäre doch, einen Host ssl.domain.de anzulegen und dann > >> darüber alles verschlüsselte laufen zu lassen. Also dass > >> > >> webmail.domain.de > >> > >> eine Umleitung auf > >> > >> ssl.domain.de/webmail ist > >> > >> und dann müßte das doch auch noch mit dl.domain.de genau so > >> funktionieren, oder gibts da auch einen Haken? > > > > Vom Prinzip her geht das. Wenn allerdings ein https-Zugriff > > auf einen anderen Host als ssl.domain.de erfolgt, dann gibt der > > Browser ein Warning aus, dass der Hostname nicht zum Namen des > > Zertifikates passt. > > Der Vollständigkeit halber seien noch sog. Wildcard-Certs erwähnt, > also z.B. ein Cert für *.example.com - so lässt sich die 1-IP-pro-SSL- > VHost-Restriktion auch elegant lösen... > > Cheers, > Erik > > > -------------------------------------------------------------------------- > Apache HTTP Server Mailing List "users-de" > unsubscribe-Anfragen an [EMAIL PROTECTED] > sonstige Anfragen an [EMAIL PROTECTED] > -------------------------------------------------------------------------- -- Sven Kobow Universität Paderborn Sportmedizinisches Institut - Rechnerbetrieb Raum SP1-501 FON: +49 (05251) 60-3586 MAIL: [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
