Kurze Antwort : ja, mit apache2.2.9 aus debian lenny während alle Subdomains in eigenen vhost-Kontainern stehen, hier notiert der apache2 beim Start nur, dass ihm die Konfiguration so nicht ganz passt, das Ergebnis ist aber Funktion wie gewünscht.
Das error-log dazu:
[Mon Dec 05 14:09:17 2011] [warn] Init: SSL server IP/port conflict: sub1.domain.tld:443 (/etc/apache2/sites-enabled/domain_ssl:21) vs. sub2.domain.tld:443 (/etc/apache2/sites-enabled/domain_ssl:143) ... [Mon Dec 05 14:09:17 2011] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
Lange Feststellung : wenn ich auf squeeze und damit apache2.2.16 upgrade ist die Konfiguration ein Starthindernis
Wie erreiche ich es also, dass bei Vorhandensein eines Wildcardzertifikates SSL-Konfigurationen für verschiedene Subdomains auf völlig verschiedene Verzeichnisse mit nur einer IP gefahren werden können?
Die Meldung im error.log habe ich nicht mehr verfügbar und kann Sie auch nicht ohne weiteres rekonstruieren - ich bin genau genommen froh, dass ich in dem squeeze jetzt den alten apache wieder am Laufen habe.
VirtualDocumentRoot ist nicht die Lösung, die ich suche, da auf dem Server ein Managementpanel läuft welches mir DocRoot-Anpassungen a la /var/www/sub[1-n].domain.tld/ nicht erlaubt (es sieht eher so aus: /var/customers/[1-n]/$irgendwasausgedachtes).
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Wie erreiche ich es also, dass bei Vorhandensein eines Wildcardzertifikates SSL-Konfigurationen für verschiedene Subdomains auf völlig verschiedene Verzeichnisse mit nur einer IP gefahren werden können?
Ich habe viele solche VirtualHosts, alle mit der gleichen IP-Adresse und dem gleichen Zertifikat:
<VirtualHost 213.239.202.144:443> ServerName www.netaction.de ServerAdmin webmaster@netaction.de
SSLEngine on SSLCertificateFile /etc/apache2/ssl/netaction.crt SSLCertificateKeyFile /etc/apache2/ssl/netaction.key
DocumentRoot /www/netaction/html <Directory /www/netaction/html> ...
extrem kurze Antwort auf lange Frage:
http://www.google.com/search?q=ssl+virtual+hosts => http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-host...
Bedenke, dass SNI von vielen Browsern afaik nicht implementiert wird (=> die Zertifikate "gehen nicht richtig") und Fehlermeldungen, die auf dieses serveragnostische Designproblem von SSL hinweisen, keine Apachefehler sind.
Viele Grüße Fabian
Wenn du von den 2007 existierenden Browsern ausgehst schon.
Heute geht jeder Browser auf Windows größer Vista und bei kleiner mindestens Firefox und Opera. Linux kann das schon ewig, die Voraussetzung auf Server-Seite ist openssl >=0.9.8h.
Gruß, Andre
Moin Ronny,
On Mon, Dec 05, 2011 at 04:52:37PM +0100, Ronny Seffner wrote:
Kurze Antwort : ja, mit apache2.2.9 aus debian lenny während alle Subdomains in eigenen vhost-Kontainern stehen, hier notiert der apache2 beim Start nur, dass ihm die Konfiguration so nicht ganz passt, das Ergebnis ist aber Funktion wie gewünscht.
Das error-log dazu:
[Mon Dec 05 14:09:17 2011] [warn] Init: SSL server IP/port conflict: sub1.domain.tld:443 (/etc/apache2/sites-enabled/domain_ssl:21) vs. sub2.domain.tld:443 (/etc/apache2/sites-enabled/domain_ssl:143) ... [Mon Dec 05 14:09:17 2011] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
Du solltest nahe der Stelle, wo Debian die Listen-Angaben hat (/etc/apache2/ports.conf) ein "NameVirtualHost *:443" einfügen.
Danach ist es dem Apache gestattet, wieder nach Namen die vHosts auszusuchen.
Da kannst du dann auch wenn nötig verschiedene Zertifikate verwenden, solange deine Clients TLS-ServerNameIndication (SNI) unterstützen. Das ist bei Windows seit Vista im HTTP-Stack enthalten, Linuxe können das schon ne Weile länger.
Wenn du über mein konkretes Setup noch was wissen magst sag Bescheid, ich teile gern ;).
Gruß, Andre
Hallo noch mal,
also ich habe jetzt in prots.conf u.a. Folgendes stehen:
<IfModule mod_ssl.c> Listen 88.1xx.5x.72:443 NameVirtualHost 88.1xx.5x.72:443 </IfModule>
und in einer Konfiguration für die vhosts u.a. dies hier:
<VirtualHost 88.1xx.5x.72:443> SSLEngine On SSLCACertificateFile /etc/apache2/ssl/ssl.ca SSLCertificateFile /etc/apache2/ssl/ssl.crt SSLCertificateKeyFile /etc/apache2/ssl/ssl.key ServerName demo.domain.tld ServerAdmin info@domain.tld DocumentRoot "/var/kunden/webs/XYZ/Demoportal/mandanten/demo/" ErrorLog "/var/kunden/logs/XYZ-error.log" CustomLog "/var/kunden/logs/XYZ-access.log" combined </VirtualHost>
<VirtualHost 88.1xx.5x.72:443> SSLEngine On SSLCACertificateFile /etc/apache2/ssl/ssl.ca SSLCertificateFile /etc/apache2/ssl/ssl.crt SSLCertificateKeyFile /etc/apache2/ssl/ssl.key ServerName dev.domain.tld ServerAdmin info@domain.tld DocumentRoot "/var/kunden/webs/ABC/Devportal/" ErrorLog "/var/kunden/logs/ABC-error.log" CustomLog "/var/kunden/logs/ABC-access.log" combined </VirtualHost>
Trotzdem meldet der apache2.2.9 von debian lenny noch:
[Tue Dec 06 16:19:57 2011] [warn] Init: SSL server IP/port conflict: demo.domain.tld:443 (/etc/apache2/sites-enabled/vhosts_ssl:126) vs. Dev.domain.tld:443 (/etc/apache2/sites-enabled/vhosts_ssl:143)
und
[Tue Dec 06 16:19:57 2011] [warn] Init: You should not use name-based virtual hosts in conjunction with SSL!!
Nun sagen Andre und Thomas, dass genau solch eine Konfiguration bei ihnen läuft. Klar, tut sie hier auch, unter lenny. Upgrade ich auf squeeze und damit apache2.2.16 hört die Gesprächigkeit auf, im error log steht dann nur:
[Mon Dec 05 13:44:33 2011] [error] Server should be SSL-aware but has no certificate configured [Hint: SSLCertificateFile] ((null):0)
Aber starten tut er nicht ;-(
Vielleicht hat das eine mit dem anderen auch gar nichts zu tun, so einen bug hatte debian ja schonmal:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541607
Jetzt habe ich aber eine Spur : http://serverfault.com/questions/232782/debian-squeeze-upgrade-breaks-apache -ssl
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Fassen wir zusammen:
1) nur ein Zertifikat pro IP:Port - das ist Fakt, weil SSL vor HTTP request kommt 2) keine named based virtual hosts mit mod_ssl - das sagt apache doc, u.U. geht es aber trotzdem 3) apache2 ab Version 2.2.12 hat SNI support implementiert, der zu strengeren Konfigurationsprüfungen führt und damit das "u.U." im vorigen Punkt aushebelt. 4) für verschiedenen Versionen des Indianers existieren verschiedene workarounds um 2) zumindest bis Version 2.2.11 auch ohne Warnungen zu realisieren
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Hallo,
ein Schuß ins Blaue wäre ja, daß Du die SSL*-Options außerhalb der VirtualHosts verwendest, ich bin beim Überfliegen der Config-Dokumentation nicht schlau geworden über die Konsequenzen. Stehen dürften sie auch außerhalb (dort steht über den Context: server config, virtual host).
In den NameBased Virtual Hosts gehts nicht, wie Du schon selbst festgestellt hast, erst kommt SSL, dann die Selektion des VHosts über den Host:-Header, den der Client mitschickt. Da aber ist es für die SSL*-Options schon zu spät, denn das ist ja schon aufgebaut.
(SNI wäre eine andere Baustelle und hat mit Deinem Problem nichts zu tun, ebenso wie subjectAltNames, denn Du hast ja ein Wildcard-Zertifikat.)
Hallo Heiko,
ein Schuß ins Blaue wäre ja, daß Du die SSL*-Options außerhalb der VirtualHosts verwendest, ich bin beim Überfliegen der
Ja das hatte ich in verschiedenen Beispielkonfigurationen auch gesehen. Da scheint jede apache2.2.x-Version unterschiedlich empfindlich: - der 2.2.9er meckerte wenn SSL* in mehreren vhosts vorkommt, läuft aber trotzdem - der 2.2.16er braucht es in allen vhosts, sonst startet er nicht - um 2.2.12 hatte ich gesehen, dass das einmalige Verwenden der SSL* Optionen vor dem ersten vhost sein sollte
Jetzt geht es auf jeden Fall unter squeeze (siehe mein zweiter Stichpunkt oben).
Mit freundlichen Grüßen / Kind regards Ronny Seffner
lug-dd@mailman.schlittermann.de
-
Andre Klärner -
Fabian Hänsel -
Heiko Schlittermann -
Ronny Seffner -
Thomas Schmidt