Perché apache httpd mi dice che i miei host virtuali basati sul nome funzionano solo con i browser abilitati SNI (RFC 4366)

Perché apache mi dà questo messaggio di errore nei miei registri? È un falso positivo?

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

Ho recentemente aggiornato da Centos 5.7 a 6.3, e da quello a una versione httpd più recente. Ho sempre fatto le mie configurazioni ssl virtualhost come di seguito. Dove tutti i domini che condividono lo stesso certificato (principalmente / sempre caratteri jolly) condividono lo stesso IP. Ma non ho mai ricevuto questo messaggio di errore prima (o forse non ho cercato abbastanza nei miei registri?) Da quello che ho imparato questo dovrebbe funzionare senza SNI (Server Name Indication)

Ecco le parti rilevanti del mio file httpd.conf. Senza questo VirtualHost non ricevo il messaggio di errore.

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
fonte

Risposte:

È perché la direttiva VirtualHost non corrisponde alla direttiva ServerName e / o al CN del certificato. Tutti e tre devono essere identici, a meno che non si disponga di un certificato jolly in cui le parti non jolly devono essere identiche.

— bahamat
fonte

Quindi la risposta qui è cambiare la <VirtualHost 10.101.0.135:443>linea per essere <VirtualHost sub2.domain.com:443>? Potenzialmente?

— Michael Jones,

@MichaelJones risolve il problema?

— Fernando Santiago,

@FernandoSantiago Ora pago per diversi indirizzi IP per i miei host virtuali ora perché ho trovato SNI non sufficientemente affidabile. E ho l'indirizzo IP nelle mie VirtualHostdichiarazioni.

— Michael Jones il

Questo ha risolto perfettamente il mio problema. Stavo usando un VirtualHostjolly ma la ServerNamedirettiva corrisponde al certificato CN. Tutti e 3 abbinati e viola! PS: questa risposta serverfault.com/questions/578061/… ti dice come ottenere la CN che hai inserito nel tuo certificato RSA

— 3bdalla

Non è un errore, è un messaggio di avviso.

E lo stai ottenendo perché 1) hai aggiornato la tua versione di Apache e 2) hai 2 VirtualHosts SSL usando lo stesso indirizzo IP esatto (invece di usare 2 IP).

Dato che stai condividendo l'IP, i browser senza supporto SNI otterranno solo il primo sito Web e mai il secondo.

— cose giuste
fonte

I browser senza SNI riceveranno il certificato configurato per il primo sito Web, ma per mapparli effettivamente a un vhost per servire la richiesta, l' Hostintestazione viene controllata normalmente.

— Shane Madden,

@ShaneMadden, non credo che sia corretto come Host: l'intestazione NON è selezionata PRIMA che sia stabilita la connessione SSL. E questo è l'intero punto di avere il supporto SNI. O in caso contrario è necessario 1 IP per SSL VH. Quindi, senza SNI, Apache passerà per impostazione predefinita al primo VH trovato con quell'indirizzo IP, l'intestazione Host: viene praticamente ignorata.

— rightstuff,

... Altrimenti potresti fare centinaia di SSL NameBasedVirtualHosts su 1 singolo indirizzo IP, e sappiamo che non è vero (senza supporto SNI da server e 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)

Puoi. L'uso normale di questo è quando tutti hanno lo stesso certificato, un carattere jolly o un certificato di nome alternativo di solito. Supponiamo che tu abbia due host con i loro certificati SSL: domain1.com e domain2.com, con domain1.com configurato per primo. Un browser non compatibile con SNI richiede domain2.com - ottengono un errore di mancata corrispondenza del dominio del certificato, perché hanno ricevuto il certificato domain1 - ma se lo fanno clic, ottengono il contenuto domain2.

— Shane Madden,

Se l'intestazione host fosse ignorata, anche il caso semplice e ampiamente diffuso di "un certificato jolly con vhosts basati su più nomi" si spezzerebbe. Comunque, ecco un paio di esempi di domande a cui ho risposto qui in cui è stato mostrato quel comportamento; serverfault.com/q/292637 serverfault.com/q/330212

— Shane Madden