Apache SNI namevhosts leiten immer zum ersten VirtualHost-Eintrag

Apache scheint alle https-Anforderungen an die erste <VirtualHost *:443>weiterzuleiten, unabhängig von der SNI-Übereinstimmung in den Feldern ServerName / ServerAlias.

Apache wird mit der SNI
Server-Version erstellt: Apache / 2.2.22 (Ubuntu)
Server erstellt: 8. März 2013 15:53:13
OpenSSL 1.0.1 14. März 2012

error.log meldet:

Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)

Was darauf hindeutet, dass SNI gemäß http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI funktioniert (Wie können Sie feststellen, ob Ihr Apache-Build SNI unterstützt?)

SSL_TLS_SNIscheint entsprechend eingestellt zu sein, wenn dies über HTTPS angefordert wird (verifiziert mit phpinfo())

Aufbau:

<IfModule mod_ssl.c>
    # If you add NameVirtualHost *:443 here, you will also have to change
    # the VirtualHost statement in /etc/apache2/sites-available/default-ssl
    # to <VirtualHost *:443>
    # Server Name Indication for SSL named virtual hosts is currently not
    # supported by MSIE on Windows XP.
    NameVirtualHost *:443
    Listen 443
</IfModule>

#<VirtualHost *:443>
#       <Location />
#               Order allow,deny
#               Deny from all
#       </Location>
#</VirtualHost>

<VirtualHost *:443>
        SSLEngine on
        ServerAdmin webmaster@localhost
        ServerName server.com
        ServerAlias server.com
        DocumentRoot /web/default
        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLCertificateFile /path/server.com.crt
        SSLCertificateKeyFile /path/server.com.key
</VirtualHost>
<VirtualHost *:443>
        SSLEngine on
        ServerAdmin webmaster@localhost
        ServerName alias.com
        ServerAlias alias.com
        DocumentRoot /web/default
        ErrorLog ${APACHE_LOG_DIR}/error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog ${APACHE_LOG_DIR}/access.log combined

        SSLCertificateFile /path/alias.com.crt
        SSLCertificateKeyFile /path/alias.com.key
</VirtualHost>

Sowohl https://server.com als auch https://alias.com versuchen, das Zertifikat (und den Inhalt, wenn Sie die Zertifikatswarnung ignorieren) von server.com bereitzustellen

Eine ähnliche Konfiguration funktioniert gut mit HTTP: 80 (nur die Änderung ist SSLEngine aktiviert und die Zertifikat- / Schlüsselpfade)

Wenn ich den ersten virtuellen Host auskommentiere (Einschränkung des HTTPS-Zugriffs auf definierte Sites), wird immer ein SSL-Fehler angezeigt (auch wenn es sich um eine definierte Site handelt).

Vielen Dank

EDIT:
Zusätzliche Flags

SSLProtocol all
SSLCipherSuite HIGH:MEDIUM
SSLStrictSNIVHostCheck on
SSLVerifyClient none
SSLProxyEngine off

SSLStrictSNIVHostCheck on Daher sollte es sowieso nur SNI-fähige Browser unterstützen

apache2ctl -S Ausgabe:

*:443                  is a NameVirtualHost
         default server server.com (/etc/apache2/sites-enabled/000-default:22)
         port 443 namevhost server.com (/etc/apache2/sites-enabled/000-default:22)
         port 443 namevhost alias.com (/etc/apache2/sites-enabled/000-default:39)
         port 443 namevhost other.com (/etc/apache2/sites-enabled/other:22)

Aktualisieren

Aus irgendeinem seltsamen Grund scheint sich das Problem von selbst gelöst zu haben.
Vielleicht ist es eine Art seltsamen Caching Problem oder etwas (obwohl ich habe apache2ctl stop/start/restartund sudo service apache2 stop/start/restart/reloaded viele Male und habe Tests lokal auf dem Server als auch mit mehreren verschiedenen Maschinen durchgeführt).

Nehmen Sie diese Frage gerne auf oder lassen Sie sie offen, wenn sie als Referenz dient.
Vielen Dank für all die Hilfe Jungs!

Ihre Konfiguration sieht in Ordnung aus. Die Direktive SSLEngine On wurde aufgenommen. Laut der Protokollnachricht scheint das Problem von der Clientseite zu kommen.

Nicht alle Clients unterstützen SNI, die meisten jedoch. Dies hängt davon ab, wie die SSL-Verhandlung erfolgt, vom System (funktioniert dann unter Win XP nicht) oder vom Browser (die Version muss aktuell genug sein). Sehen Sie sich die Liste der Browser mit Unterstützung von SNI an . Wenn Sie sicherstellen müssen, dass alle Clients Zugriff auf Ihre Websites erhalten, können Sie SNI aufgrund dieser alten Versionen (des Browsers oder des Systems) nicht verwenden. Sie benötigen eine IP pro Servername und verwenden VirtualHost $ IP_alias: 443 für Servername alias.com und VirtualHost $ IP_server: 443 für Servername server.com anstelle von VirtualHost *: 443 für beide.

Beim ersten virtuellen Host wird eine Fehlermeldung SSLEngine onangezeigt, da Apache ohne die Anweisung eine HTTP-Antwort ohne SSL sendet. Wenn Sie diese Art von Funktionalität wünschen, müssten Sie eine andere Site (möglicherweise mit einem anderen Zertifikat, sofern Sie keine vorhandene Domain wiederverwenden) für Ihren Standard-vhost einrichten, selbst wenn Sie nur einen netten Fehler zurückgeben möchten.

Überprüfen Sie vielleicht, ob die Zertifikate tatsächlich unterschiedlich sind? Ihre Konfiguration erscheint korrekt.

Stellen Sie außerdem sicher, dass keine anderen VirtualHostAbschnitte Port 443 überwachen. Apache wählt den am besten passenden aus. Wenn also etwas spezifischer für die Adresse ist, über die die Verbindung hergestellt wurde, hat dieser Eintrag Vorrang. Ich denke jedoch nicht, dass dies Ihr Problem ist.

Darüber hinaus sehen Sie auf der Benutzerseite, was passieren würde, wenn der Client SNI in den meisten Fällen nicht unterstützen würde.