Pourquoi Apache httpd me dit que mes hôtes virtuels basés sur le nom ne fonctionnent qu'avec les navigateurs compatibles SNI (RFC 4366)

Pourquoi apache me donne ce message d'erreur dans mes journaux? Est-ce un faux positif?

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

J'ai récemment mis à niveau de Centos 5.7 vers 6.3, et par là vers une version httpd plus récente. J'ai toujours fait mes configurations d'hôte virtuel SSL comme ci-dessous. Où tous les domaines qui partagent le même certificat (pour la plupart / toujours les certificats génériques) partagent la même IP. Mais je n'ai jamais reçu ce message d'erreur avant (ou ai-je, peut-être que je n'ai pas regardé suffisamment dans mes journaux?) D'après ce que j'ai appris, cela devrait fonctionner sans SNI (Server Name Indication)

Voici les parties pertinentes de mon fichier httpd.conf. Sans ce VirtualHost, je ne reçois pas le message d'erreur.

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
la source

Réponses:

C'est parce que votre directive VirtualHost ne correspond pas à votre directive ServerName et / ou au CN du certificat. Les trois doivent être identiques, sauf si vous disposez d'un certificat générique où les parties non génériques doivent être identiques.

bahamat
la source

Donc, la réponse ici est de changer la <VirtualHost 10.101.0.135:443>ligne pour être <VirtualHost sub2.domain.com:443>? Potentiellement?

MichaelJones

@MichaelJones est-ce que cela a résolu le problème?

Fernando Santiago

@FernandoSantiago Je paie maintenant pour différentes adresses IP pour mes hôtes virtuels maintenant car j'ai trouvé que SNI n'était pas suffisamment fiable. Et j'ai cette adresse IP dans mes VirtualHostdéclarations.

MichaelJones

Cela a parfaitement résolu mon problème. J'utilisais un VirtualHostjoker mais la ServerNamedirective correspond au certificat CN. Tous les 3 appariés et alto! PS: Cette réponse serverfault.com/questions/578061/… vous indique comment obtenir le CN que vous avez mis dans votre certificat RSA

3bdalla

Ce n'est pas une erreur, c'est un message d'avertissement.

Et vous l'obtenez parce que 1) vous avez mis à jour votre version d'Apache et 2) vous avez 2 VirtualHosts SSL utilisant la même adresse IP exacte (par opposition à l'utilisation de 2 IP).

Puisque vous partagez l'IP, les navigateurs sans prise en charge SNI obtiendront simplement le premier site Web et jamais le second.

droit
la source

Les navigateurs sans SNI obtiendront le certificat configuré pour le premier site Web - mais pour les mapper réellement à un vhost pour servir la demande, l'en- Hosttête est vérifié normalement.

Shane Madden

@ShaneMadden, je ne crois pas que ce soit correct car l'hôte: l'en-tête n'est PAS vérifié AVANT que la connexion SSL ne soit établie. Et c'est tout l'intérêt d'avoir le support SNI. Ou besoin de 1 IP par SSL VH sinon. Donc sans SNI, Apache sera par défaut le premier VH trouvé avec cette adresse IP, l'en-tête Host: est pratiquement ignoré.

droit

... Sinon, vous pourriez faire 100s de SSL NameBasedVirtualHosts sur 1 seule adresse IP, et nous savons que ce n'est pas vrai (sans le support SNI par le serveur et le client).

droit

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)

Vous pouvez. L'utilisation normale de ceci est lorsque tous ont généralement le même certificat, un caractère générique ou un certificat de nom alternatif. Mais supposons que vous ayez deux vhosts avec leurs propres certificats SSL - domain1.com et domain2.com, avec domain1.com configuré en premier. Un navigateur non compatible SNI demande domain2.com - il obtient une erreur de non-concordance de domaine de certificat, car il a reçu le certificat domain1 - mais s'il clique dessus, il obtient le contenu domain2.

Shane Madden

Si l'en-tête d'hôte était ignoré, même le cas simple et largement déployé "d'un certificat générique avec plusieurs vhosts basés sur le nom" se briserait. Quoi qu'il en soit, voici quelques exemples de questions auxquelles j'ai répondu ici où ce comportement a été affiché; serverfault.com/q/292637 serverfault.com/q/330212

Shane Madden