¿Por qué apache httpd me dice que mis hosts virtuales basados ​​en nombres solo funcionan con navegadores habilitados para SNI (RFC 4366)

9

¿Por qué Apache me da este mensaje de error en mis registros? ¿Es un falso positivo?

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

Recientemente he actualizado de Centos 5.7 a 6.3, y por eso a una nueva versión httpd. Siempre he hecho mis configuraciones de host virtual SSL como a continuación. Donde todos los dominios que comparten el mismo certificado (en su mayoría / siempre certificados comodín) comparten la misma ip. Pero nunca recibí este mensaje de error antes (¿o acaso no he mirado lo suficiente en mis registros?) Por lo que he aprendido, esto debería funcionar sin SNI (Indicación de nombre del servidor)

Aquí hay partes relevantes de mi archivo httpd.conf. Sin este VirtualHost no recibo el mensaje de error.

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
fuente

Respuestas:

7

Esto se debe a que su directiva VirtualHost no coincide con su directiva ServerName y / o el CN ​​del certificado. Los tres deben ser idénticos, a menos que tenga un certificado comodín en el que las partes no comodines deben ser idénticas.

— bahamat
fuente
Entonces, ¿la respuesta aquí es cambiar la <VirtualHost 10.101.0.135:443>línea para que sea <VirtualHost sub2.domain.com:443>? ¿Potencialmente?
— MichaelJones
@MichaelJones ¿esto resolvió el problema?
— Fernando Santiago
@FernandoSantiago Ahora pago por diferentes direcciones IP para mis hosts virtuales ahora, ya que encontré que SNI era insuficientemente confiable. Y tengo esa dirección IP en mis VirtualHostdeclaraciones.
— MichaelJones
1
Esto resolvió perfectamente mi problema. Estaba usando un VirtualHostcomodín pero la ServerNamedirectiva coincide con el certificado CN. Los 3 emparejados y viola! PD: Esta respuesta serverfault.com/questions/578061/… le dice cómo obtener el CN ​​que puso en su certificado RSA
— 3bdalla
3

No es un error, es un mensaje de advertencia.

Y lo está obteniendo porque 1) ha actualizado su versión de Apache y 2) tiene 2 VirtualHosts SSL usando la misma dirección IP exacta (en lugar de usar 2 IP).

Como está compartiendo la IP, los navegadores sin soporte SNI obtendrán el primer sitio web y nunca el segundo.

— cosas correctas
fuente
Los navegadores sin SNI obtendrán el certificado configurado para el primer sitio web, pero para asignarlos realmente a un servidor virtual para atender la solicitud, el Hostencabezado se verifica normalmente.
— Shane Madden
@ShaneMadden, no creo que sea correcto ya que el host: el encabezado NO se verifica ANTES de establecer la conexión SSL. Y ese es el punto de tener soporte SNI. O necesita 1 IP por SSL VH de lo contrario. Entonces, sin SNI, Apache pasará por defecto al primer VH encontrado con esa dirección IP, el encabezado Host: prácticamente se ignora.
— rightstuff
... De lo contrario, podría hacer cientos de SSL NameBasedVirtualHosts en una sola dirección IP, y sabemos que eso no es cierto (sin el soporte de SNI por el servidor y el cliente).
— rightstuff
44
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)Usted puede. El uso normal de esto es cuando todos tienen el mismo certificado, un comodín o un certificado de nombre alternativo generalmente. Pero supongamos que tiene dos vhosts con sus propios certificados SSL: dominio1.com y dominio2.com, con dominio1.com configurado primero. Un navegador que no es compatible con SNI solicita domain2.com: obtiene un error de error de coincidencia de dominio del certificado porque se les envió el certificado de dominio1, pero si hacen clic a través de él, obtienen el contenido de dominio2.
— Shane Madden
1
Si se ignora el encabezado del host, incluso el caso simple y ampliamente implementado de "un certificado comodín con múltiples hosts basados ​​en nombres" se rompería. De todos modos, aquí hay un par de ejemplos de preguntas que he respondido aquí donde se ha mostrado ese comportamiento; serverfault.com/q/292637 serverfault.com/q/330212
— Shane Madden
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.