Warum sagt mir Apache httpd, dass meine namensbasierten virtuellen Hosts nur mit SNI-fähigen Browsern funktionieren (RFC 4366)?

Warum gibt mir Apache diese Fehlermeldung in meinen Protokollen? Ist es falsch positiv?

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

Ich habe kürzlich ein Upgrade von Centos 5.7 auf 6.3 und damit auf eine neuere httpd-Version durchgeführt. Ich habe meine SSL VirtualHost-Konfigurationen immer wie unten vorgenommen. Wobei alle Domänen, die dasselbe Zertifikat verwenden (meistens / immer Platzhalterzertifikate), dieselbe IP-Adresse haben. Aber ich habe diese Fehlermeldung noch nie erhalten (oder habe ich, vielleicht habe ich nicht genug in meinen Protokollen gesucht?). Nach dem, was ich gelernt habe, sollte dies ohne SNI (Server Name Indication) funktionieren.

Hier sind relevante Teile meiner httpd.conf-Datei. Ohne diesen VirtualHost erhalte ich keine Fehlermeldung.

NameVirtualHost 10.101.0.135:443

<VirtualHost 10.101.0.135:443>
  ServerName sub1.domain.com

  SSLEngine on
  SSLProtocol -all +SSLv3 +TLSv1
  SSLCipherSuite ALL:!aNull:!EDH:!DH:!ADH:!eNull:!LOW:!EXP:RC4+RSA+SHA1:+HIGH:+MEDIUM
  SSLCertificateFile /opt/RootLive/etc/ssl/ssl.crt/wild.fareoffice.com.crt
  SSLCertificateKeyFile /opt/RootLive/etc/ssl/ssl.key/wild.fareoffice.com.key
  SSLCertificateChainFile /opt/RootLive/etc/ssl/ca/geotrust-ca.pem
</VirtualHost>

<VirtualHost 10.101.0.135:443>
  ServerName sub2.domain.com

  SSLEngine on
  SSLProtocol -all +SSLv3 +TLSv1
  SSLCipherSuite ALL:!aNull:!EDH:!DH:!ADH:!eNull:!LOW:!EXP:RC4+RSA+SHA1:+HIGH:+MEDIUM
  SSLCertificateFile /opt/RootLive/etc/ssl/ssl.crt/wild.fareoffice.com.crt
  SSLCertificateKeyFile /opt/RootLive/etc/ssl/ssl.key/wild.fareoffice.com.key
  SSLCertificateChainFile /opt/RootLive/etc/ssl/ca/geotrust-ca.pem
</VirtualHost>

httpd ssl-certificate sni

— Arlukin
quelle

Antworten:

Dies liegt daran, dass Ihre VirtualHost-Direktive nicht mit Ihrer ServerName-Direktive und / oder dem CN des Zertifikats übereinstimmt. Alle drei müssen identisch sein, es sei denn, Sie haben ein Platzhalterzertifikat, bei dem die nicht freien Teile identisch sein müssen.

— Bahamat
quelle

Die Antwort hier ist also, die <VirtualHost 10.101.0.135:443>Zeile zu ändern <VirtualHost sub2.domain.com:443>? Möglicherweise?

— Michael Jones

@ MichaelJones hat dies das Problem gelöst?

— Fernando Santiago

@FernandoSantiago Ich bezahle jetzt für verschiedene IP-Adressen für meine virtuellen Hosts, da ich festgestellt habe, dass SNI nicht ausreichend zuverlässig ist. Und ich habe diese IP-Adresse in meinen VirtualHostErklärungen.

— MichaelJones

Dies hat mein Problem perfekt gelöst. Ich habe einen VirtualHostPlatzhalter verwendet, aber die ServerNameDirektive stimmt mit dem Zertifikat CN überein. Alle 3 zusammen und Viola! PS: Diese Antwort serverfault.com/questions/578061/… zeigt Ihnen, wie Sie den CN erhalten, den Sie in Ihr RSA-Zertifikat

— eingegeben haben

Es ist kein Fehler, es ist eine Warnmeldung.

Und Sie bekommen es, weil 1) Sie Ihre Apache-Version aktualisiert haben und 2) Sie 2 SSL VirtualHosts haben, die genau dieselbe IP-Adresse verwenden (im Gegensatz zu 2 IPs).

Da Sie die IP-Adresse freigeben, erhalten Browser ohne SNI-Unterstützung nur die erste Website und niemals die zweite.

— richtiges Zeug
quelle

Browser ohne SNI erhalten das für die erste Website konfigurierte Zertifikat. Um sie jedoch tatsächlich einem vhost zuzuordnen, um die Anforderung zu bearbeiten, wird der HostHeader normal überprüft.

— Shane Madden

@ShaneMadden, ich glaube nicht, dass dies korrekt ist, da der Host: -Header NICHT überprüft wird, bevor die SSL-Verbindung hergestellt wird. Und das ist der springende Punkt bei der Unterstützung von SNI. Oder Sie benötigen andernfalls 1 IP pro SSL VH. Ohne SNI verwendet Apache standardmäßig die erste VH, die mit dieser IP-Adresse gefunden wurde. Der Host: -Header wird praktisch ignoriert.

— Rightstuff

... Andernfalls könnten Sie Hunderte von SSL NameBasedVirtualHosts auf einer einzigen IP-Adresse ausführen, und wir wissen, dass dies nicht der Fall ist (ohne SNI-Unterstützung durch Server und Client).

— Rightstuff

Otherwise you could do 100s of SSL NameBasedVirtualHosts on 1 single IP address, and we know that's not true (without SNI support by server and client)

Sie können. Dies wird normalerweise verwendet, wenn alle das gleiche Zertifikat, einen Platzhalter oder ein Zertifikat mit einem alternativen Namen haben. Angenommen, Sie haben zwei vhosts mit eigenen SSL-Zertifikaten - domain1.com und domain2.com, wobei domain1.com zuerst konfiguriert wird. Ein nicht SNI-fähiger Browser fordert domain2.com an - sie erhalten einen Fehler bei der Nichtübereinstimmung der Zertifikatdomäne, weil ihnen das Zertifikat domain1 gesendet wurde. Wenn sie jedoch darauf klicken, erhalten sie den Inhalt domain2.

— Shane Madden

Wenn der Host-Header ignoriert würde, würde sogar der einfache und weit verbreitete Fall eines "Wildcard-Zertifikats mit mehreren namenbasierten vhosts" brechen. Wie auch immer, hier sind einige Beispiele für Fragen, die ich hier beantwortet habe, wo dieses Verhalten angezeigt wurde. serverfault.com/q/292637 serverfault.com/q/330212

— Shane Madden