Apache Vhost und Vhost SSL Problem

Hallo Firepower

Danke für Deine schnelle Antwort Ich bin sonst auch schneller mit Responses, nur heute waren Weihnachtseinkäufe dran, weshalb ich erst jetzt wirder am PC bin ;)

Mit "url-rewrite" habe ich noch nicht probiert, allerdings müsste ich das in gentoo mal rausfinden wie das dort geht. "a2enmod mode" kenne ich zwar, das ist von den Debianbasierten Linuxen, Ubuntu, Kubuntu, Debian, aber das ist in gentoo anders.

In gentoo ist es wie folgt:

Die apache-Modes werden hier in der apache2 Datei unter /etc/conf.d/apache2 Mit folgender Inhaltssteuerung:

1. The following two options provide the default virtual host for the HTTP and
2. HTTPS protocol. YOU NEED TO ENABLE AT LEAST ONE OF THEM, otherwise apache
3. will not listen for incomming connections on the approriate port.

#

1. DEFAULT_VHOST Enables name-based virtual hosts, with the default
2. virtual host being in /var/www/localhost/htdocs
3. SSL_DEFAULT_VHOST Enables default vhost for SSL (you should enable this
4. when you enable SSL)

#
APACHE2_OPTS="-D DEFAULT_VHOST -D INFO -D SSL -D SSL_DEFAULT_VHOST -D LANGUAGE -D PHP5"

Beispielsweise würde ein Löschen der Phrase ' -D SSL_DEFAULT_VHOST' den Enzug von SSL-Vhost bvedeuten, und '-d PHP5' würde den apache bei gento php-unfähig machen.


Das Problem ist folgendes:

Hab folgende Constellation: 8 vhosts (das sind nur Beispielhosts für Website-Tests mit unterschiedlichen CMS) wovon 4 OHNE ssl laufen und 4 mit.

Konfiguriere ich einen normalen vhost, also ohne ssl, dann generiere ich aus den Dateien:

default_vhost.conf
default_vhost.include

auf mich angepasste:

z.B. Beispieldateien sehen so aus: (nur Ausschnitt des wichtigen, sonst zu lang)

default.vhost.conf

1. Use name-based virtual hosting.

NameVirtualHost *:80

1. When virtual hosts are enabled, the main host defined in the default
2. httpd.conf configuration will go away. We redefine it here so that it is
3. still available.

#

1. If you disable this vhost by removing -D DEFAULT_VHOST from
2. /etc/conf.d/apache2, the first defined virtual host elsewhere will be
3. the default.

<VirtualHost *:80>
ServerName localhost
Include /etc/apache2/vhosts.d/000_default_vhost.include

<IfModule mpm_peruser_module>
ServerEnvironment apache apache
</IfModule>
</VirtualHost>
</IfDefine>


In der .include befinden sich die Pfade (weshalb man die nicht vergessen darf, einzubinden oben)

DocumentRoot "/var/www/localhost/htdocs"

1. This should be changed to whatever you set DocumentRoot to.

<Directory "/var/www/localhost/htdocs">
#
#
Options Indexes FollowSymLinks

AllowOverride All

Order allow,deny
Allow from all
</Directory>


Die default_ssl_vhost.conf siht so aus:

<IfDefine SSL>
<IfDefine SSL_DEFAULT_VHOST>
<IfModule ssl_module>

1. see bug #178966 why this is in here

1. When we also provide SSL we have to listen to the HTTPS port
2. Note: Configurations that use IPv6 but not IPv4-mapped addresses need two
3. Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443"

Listen 443

<VirtualHost _default_:443>
ServerName localhost
Include /etc/apache2/vhosts.d/000_default_vhost.include
ErrorLog /var/log/apache2/ssl_error_log

<IfModule log_config_module>
TransferLog /var/log/apache2/ssl_access_log
</IfModule>

## SSL Engine Switch:
SSLEngine on

## SSL Cipher Suite:
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

## Server Certificate:
SSLCertificateFile /etc/ssl/apache2/server.crt

## Server Private Key:
SSLCertificateKeyFile /etc/ssl/apache2/server.key

## Server Certificate Chain:
#SSLCertificateChainFile /etc/ssl/apache2/ca.crt

## Certificate Authority (CA):
#SSLCACertificatePath /etc/ssl/apache2/ssl.crt
#SSLCACertificateFile /etc/ssl/apache2/ca-bundle.crt

## Certificate Revocation Lists (CRL):
#SSLCARevocationPath /etc/ssl/apache2/ssl.crl
#SSLCARevocationFile /etc/ssl/apache2/ca-bundle.crl

## Client Authentication (Type):
#SSLVerifyClient require
#SSLVerifyDepth 10

## Access Control:
#<Location />
#</Location>

## SSL Engine Options:

## FakeBasicAuth:

## ExportCertData:

## StdEnvVars:

## StrictRequire:

## OptRenegotiate:
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>

<Directory "/var/www/localhost/cgi-bin">
SSLOptions +StdEnvVars
</Directory>

## SSL Protocol Adjustments:

## ssl-unclean-shutdown:

## ssl-accurate-shutdown:
<IfModule setenvif_module>
BrowserMatch ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
</IfModule>

## Per-Server Logging:
<IfModule log_config_module>
CustomLog /var/log/apache2/ssl_request_log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</IfModule>
</VirtualHost>
</IfModule>
</IfDefine>
</IfDefine>

1. vim: ts=4 filetype=apache

Doch ketzt kommt das seltsame:

Passe ich diese an (adde in ihr) weitere vhosts bekomme ich bei apache reload sofort einen Fehler, das NUR 1 Server ssl nutzen kann. Und schon default_ssl Port 443 nutzt :/ Daraufhin habe ich mich dann in verschiedenen gentoo-Foren schlauer gemacht und fand folgendes:
http://en.gentoo-wiki.com/wiki/Apache2/SSL_and_Name_Based_Virtual_Hosts ...

Setze ich diese, passe sie an usw, kommt es zu dem Fehler aus meinem ersten Posting. OBWOHL mehr als 1 Vhost nun ssl nutzt, kommt der "Vorrangsfehler" nicht mehr, dafür komme ich nach Bestätigung das ich auf die Seite (trotz unsicheren Zertifikat) dennoch gehen möchte, einen 403 Fehler "Forbidden".

Noch einige male getestet, benutze wirde die originale (die lange default.ssl von oben) geht es problemlos: Nach akzeptieren des Zertifikats bin ich über 443 ssl mit apache verbunden. Leider geht diese Variante dann aber nur mit einem vhost, oder der Vorrangsfehler erscheint wieder.

Ist echt wie verhext. Ich versteh nicht das überall steht, das "die Zeit vorbei sei, zu der man ssl nur für einen host nutzen konnte" und entweder 403 kommt oder das man nur einen ssl host betreiben kann... Bin selbst im Kopf schon den ganzen Tag am durchspielen ;)

Gruß
Neutrino

Hallo Firepower und anläßlich: Frohe Weihnachten Dir und Deinen Lieben

Ich vermute, das von Deiner Auswahl:

[quote]Nur eine IP Adresse für mehrere Zertifikate, dass wird nicht funktionieren

Die Vhosts sind nicht eindeutig, schon mal kontrolliert, wenn du die Fehler 403 bekommst, welches Zertifikat er nehmen möchte ?[/quote]

erstes zutrifft ;) Von der Logik her, kann ich es mir gar gut vorstellen. Das wenn das Handshaking noch nicht abgeschlossen ist, es zu keiner http(s) Verbindung kommen kann... Was mich allerdings ein wenig unsicher machte, an diesem Glauben festzuhalten, da es wohl nach einer neueren Reglementierung doch möglich sein soll ein Zertifikat für verschiedene (v)Hostnamen benutzen zu können. Das wurde meist auch mit der Adressknappheit von IPv4 begründet, dort wo ich das las. Weitere möglichkeit wäre es, ein catch Zertifikat zu nutzen. Was dann für mehrere Domains ausgestellt ist aber daher (wenn der host den selben Domainnamen nutzt) verwendet werden kann.

Früher soll das nicht gegangen haben, aber nun (unter Verwendung gleicher domainnamen) ja. hmmmm

Muss ich mir nochwas reinlesen ;)


EDIT

Hab bis jetzt gelesen: Einige Seiten schreiben, das mit gnutls mehrere namensbasierte Vhosts zulässig seien, andere sagen das Browser das nicht immer unterstützen. Habs schon mit der 2ten Netzwerkschnittstelle meines Rechners ausprobiert. Die ebenfalls mal an den Server verbunden um eine 2te lokale ip zu haben (und nutzen zu können) Doch das brachte mir in der Inet-Verbindung starke Einschränkungen (gleicher Gateway). Was ich nicht verstehe ist das es dafür 'nichts' geben soll, damit man es am heimischen PC mal testen kann. Also mit 2 ssl-vhosts oder mit 3. Gut, ich würde wahrscheinlich letztendlich nur 2 ssl-hosts im Inet betreiben - ssl beim Mailserver halte ich jedenfalls für absolute Pflicht. Andererseits sieht oder sehen Serviceseiten (wenn die Adressleiste im Browser grün ist) sehr ansprechend für den Kunden aus ;)

Das Problem ist, sobald ich was an der 00_default_ssl_vhost.conf in Bezug auf neue -hinzugefügte vhosts- "drehe" schmeisst Apache mit allem um sich was er an Fehlermeldungen zu bieten hat.

In selfhtml las ich, das man seinen Server (wenn man noch keine ECHTE Domain hat) dennoch mit domainname.tld testen kann, wenn der tld auf "test" endet. also -> www.domain.test Das werd ich morgen auch mal ausprobieren, da ich (schlagt mich, ich weiss nicht mehr wo ich was seit gestern abend 21Uhr gelesen habe) ;) irgendwo relevantes zu 'domain.tld' in Bezug auf ssl-namebased-vhosting gelesen hatte.

Ich raffs nicht, es MUSS doch eine Möglichkeit geben... (zumindest im privaten TEST-Umfeld) - Für den Root (später) kann ich ohne Probleme weitere IP-Addressen bekommen - womit sich dort die Frage nicht mehr stellt...

Wenn Ihr noch eine Anregung habt, ich wär Euch nicht böse, wenn Ihr es mir verratet ;))

Good night - von einem verzweifelnden Neutrino

/EDIT


Gruß
Neutrino