Pregunta ¿Múltiples dominios SSL en la misma dirección IP y el mismo puerto?


Esto es un Pregunta canónica sobre el alojamiento de múltiples sitios web SSL en la misma IP.

Tenía la impresión de que cada certificado SSL requería su propia combinación única de dirección IP / puerto. Pero el responder a una pregunta anterior que publiqué está en desacuerdo con esta afirmación.

Al usar la información de esa Pregunta, pude obtener varios certificados SSL para trabajar en la misma dirección IP y en el puerto 443. Estoy muy confundido acerca de por qué esto funciona dado el supuesto anterior y reforzado por otros que cada sitio web de dominio SSL en el El mismo servidor requiere su propio IP / Puerto.

Sospecho que hice algo mal. ¿Pueden usarse múltiples certificados SSL de esta manera?


107
2018-02-04 22:36


origen


Este cuerpo Q dice múltiples certificados y las respuestas son correctas para eso. Pero el título dice múltiples dominios y tú. puede tener múltiples dominios con un certificado (y no SNI), ver serverfault.com/questions/126072/… y serverfault.com/questions/279722/… También cruce en seguridad.SX. - dave_thompson_085


Respuestas:


Para obtener la información más actualizada sobre Apache y SNI, incluidas las RFC específicas de HTTP adicionales, consulte la Apache Wiki


FYsI: la magia de la actualización de TLS le ofrece "certificados SSL múltiples (diferentes) en una IP". Funciona con los servidores Apache más nuevos (2.2.x) y los navegadores bastante recientes (no sé las versiones de la parte superior de mi cabeza).

RFC 2817 (actualizar a TLS dentro de HTTP / 1.1) tiene los detalles sangrientos, pero básicamente funciona para muchas personas (si no la mayoría).
Puedes reproducir el antiguo comportamiento funky con openssl's s_client comando (o cualquier navegador "suficientemente antiguo") sin embargo.

Editar para agregar: aparentemente curl Puede mostrarle lo que está pasando aquí mejor que openssl:


SSLv3

mikeg@flexo% curl -v -v -v -3 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: serialNumber=wq8O9mhOSp9fY9JcmaJUrFNWWrANURzJ; C=CA; 
              O=staging.bossystem.org; OU=GT07932874;
              OU=See www.rapidssl.com/resources/cps (c)10;
              OU=Domain Control Validated - RapidSSL(R);
              CN=staging.bossystem.org
*    start date: 2010-02-03 18:53:53 GMT
*    expire date: 2011-02-06 13:21:08 GMT
* SSL: certificate subject name 'staging.bossystem.org'
       does not match target host name 'www.yummyskin.com'
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
curl: (51) SSL: certificate subject name 'staging.bossystem.org'
does not match target host name 'www.yummyskin.com'

TLSv1

mikeg@flexo% curl -v -v -v -1 https://www.yummyskin.com
* About to connect() to www.yummyskin.com port 443 (#0)
*   Trying 69.164.214.79... connected
* Connected to www.yummyskin.com (69.164.214.79) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /usr/local/share/certs/ca-root-nss.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
*    subject: C=CA; O=www.yummyskin.com; OU=GT13670640;
              OU=See www.rapidssl.com/resources/cps (c)09;
              OU=Domain Control Validated - RapidSSL(R);
              CN=www.yummyskin.com
*    start date: 2009-04-24 15:48:15 GMT
*    expire date: 2010-04-25 15:48:15 GMT
*    common name: www.yummyskin.com (matched)
*    issuer: C=US; O=Equifax Secure Inc.; CN=Equifax Secure Global eBusiness CA-1
*    SSL certificate verify ok.

68
2018-02-04 23:46



Eso es muy útil - ¡Gracias! ¿Alguna información sobre cómo configurar Apache para TLS en lugar de SSL? - Josh
Creo que Apache 2.2 solo necesita tener los bits TLS habilitados en su lista de cifrado. Admito que nunca he visto el bit completo de "Actualización de SSL a TLS" hasta que estos dos sitios, sin embargo. Mi comprensión de los documentos TLS es que es una situación permisible (pero inusual) para negociar este tipo de actualización ... - voretaq7
Esta es la primera vez que lo veo y todavía estoy tratando de sacar mi mandíbula del piso ... - Josh
OK, mi respuesta simplemente se triplicó en longitud. Al parecer, curl puede hacer negociaciones tanto SSLv3 como TLSv1, por lo que puedo mostrar el fracaso y el éxito. Desearía tener un depurador de protocolo a mano para mostrar la parte mágica. (También probado y feliz de informar que el servidor de johnlai2004 niega correctamente las conexiones SSLv2 :-) - voretaq7
Eso es extremadamente útil y espero que johnlai2004 acepte su respuesta. ¡Muchas gracias! - Josh


Sí, pero hay algunas advertencias.

Esto se logra a través de la Indicación del nombre del servidor, una extensión de la Seguridad de la capa de transporte.

¿Qué es la indicación del nombre del servidor?

Indicación del nombre del servidor (RFC 6066; obsoleto RFC 4366, RFC 3546) es una extensión de Transport Layer Security lo que permite al cliente decirle al servidor el nombre del host al que intenta acceder.

SNI es compatible con TLS 1.0 y superior de acuerdo con las especificaciones, pero las implementaciones pueden variar (ver más abajo). No se puede usar con SSL, por lo que una conexión debe negociar TLS (ver RFC 4346 apéndice E) para utilizar SNI. Esto generalmente ocurre automáticamente con el software compatible.

¿Por qué se necesita SNI?

En un normal HTTP conexión, el navegador informa al servidor del nombre de host del servidor al que intenta acceder utilizando el Host: encabezamiento. Esto permite que un servidor web en una sola dirección IP sirva contenido para múltiples nombres de host, lo que comúnmente se conoce como alojamiento virtual basado en nombre.

La alternativa es asignar direcciones IP únicas para cada nombre de host web a ser servido. Esto se hizo comúnmente en los primeros días de la web, antes de que se supiera ampliamente que las direcciones IP se agotarían y que comenzaran las medidas de conservación, y todavía se hace de esta manera para los hosts virtuales SSL (sin usar SNI).

Debido a que este método de transmisión del nombre de host requiere que la conexión ya esté establecida, no funciona con conexiones SSL / TLS. En el momento en que se configura la conexión segura, el servidor web ya debe saber qué nombre de host va a servir al cliente, porque el servidor web en sí está configurando la conexión segura.

SNI resuelve este problema haciendo que el cliente transmita el nombre de host como parte de la negociación TLS, de modo que el servidor ya esté al tanto de qué host virtual se debe usar para atender la conexión. El servidor puede usar el certificado y la configuración para el host virtual correcto.

¿Por qué no usar diferentes direcciones IP?

El HTTP Host: el encabezado se definió para permitir que más de un servidor web se sirva desde una única dirección IP debido a la escasez de direcciones IPv4, que se reconoció como un problema desde mediados de los años noventa. En entornos de alojamiento web compartido, se pueden servir cientos de sitios web únicos, no relacionados, utilizando una única dirección IP de esta manera, conservando el espacio de direcciones.

Los entornos de alojamiento compartido descubrieron que el mayor consumidor de espacio de direcciones IP era la necesidad de que los sitios web seguros tuvieran direcciones IP únicas, lo que creaba la necesidad de SNI como una medida de interferencia en el camino hacia IPv6. Hoy en día, a veces es difícil obtener tan solo 5 direcciones IP (/ 29) sin una justificación significativa, lo que a menudo genera demoras en la implementación.

Con el advenimiento de IPv6, tales técnicas de conservación de direcciones ya no son necesarias, ya que un solo host puede tener más direcciones IPv6 asignadas que las que contiene Internet en la actualidad, pero es probable que las técnicas aún se utilicen en el futuro para dar servicio al IPv4 heredado. conexiones

Advertencias

Algunas combinaciones de sistema operativo / navegador no son compatibles con SNI (ver más abajo), por lo que el uso de SNI no es apropiado para todas las situaciones. Los sitios dirigidos a tales combinaciones de sistema / navegador tendrían que renunciar a SNI y continuar usando direcciones IP únicas para cada host virtual.

En particular, ninguna versión de Internet Explorer en Windows XP admite SNI. Dado que esta combinación aún representa una parte significativa (aunque disminuye constantemente; aproximadamente el 16% del tráfico de Internet en diciembre de 2012, según NetMarketShare) del tráfico de Internet, el SNI sería inadecuado para un sitio dirigido a estas poblaciones de usuarios.

Apoyo

Muchos, pero no todos, los paquetes de software comúnmente usados ​​son compatibles con SNI.

(La omisión de esta lista no significa necesariamente falta de soporte; significa que hubo un límite en cuanto a la cantidad que podía escribir o no pude encontrar rápidamente la información en una búsqueda. Si su paquete de software no figura en la lista, busque por su nombre plus sni debe revelar si existe soporte y cómo configurarlo.)

Soporte de biblioteca

La mayoría de los paquetes dependen de una biblioteca externa para proporcionar soporte SSL / TLS.

  • GNU TLS
  • JSSE (Oracle Java) 7 o superior, solo como cliente
  • libcurl 7.18.1 o superior
  • NSS 3.1.1 o superior
  • OpenSSL 0.9.8j o superior
    • OpenSSL 0.9.8f o superior, con banderas de configuración
  • Qt 4.8 o superior

Soporte del servidor

La mayoría de las versiones actuales del software de servidor popular admiten SNI. Las instrucciones de configuración están disponibles para la mayoría de estos:

Soporte al cliente

La mayoría de los navegadores web actuales y los agentes de usuario de la línea de comandos admiten SNI.

Escritorio

  • Chrome 5 o superior
    • Chrome 6 o superior en Windows XP
  • Firefox 2 o superior
  • Internet Explorer 7 o superior, ejecutándose en Windows Vista / Server 2008 o superior
    • Internet Explorer en Windows XP no admite SNI independientemente de la versión de IE
  • Konqueror 4.7 o superior
  • Opera 8 o superior (puede requerir TLS 1.1 habilitado para funcionar)
  • Safari 3.0 en Windows Vista / Server 2008 o superior, o Mac OS X 10.5.6 o superior

Móvil

  • Navegador de Android en 3.0 Honeycomb o superior
  • iOS Safari en iOS 4 o superior
  • Windows Phone 7 o superior

Línea de comando

  • CURL 7.18.1 o superior
  • wget 1.14 o superior (es posible que las distribuciones hayan parche para soporte de SNI)

Sin soporte

  • Navegador BlackBerry
  • Internet Explorer (cualquier versión) en Windows XP

(Nota: Alguna información para esta respuesta se obtuvo de Wikipedia.)


96
2017-08-14 23:05



Mucho mejor :-) Con suerte, esto puede obtener un puntaje más alto que el que se acepta actualmente, lo cual, aparte de la última edición en la parte superior, es, en su mayoría, incorrecto. - Bruno
@Bruno Desde luego, no me quejaré si encuentras a unos cientos de personas para promocionarlo. :) - Michael Hampton♦
El último BlackBerry Browser (10?) Usa una versión reciente de WebKit, por lo que es muy probable que ahora admita SNI. - dave1010


El problema:

Cuando un cliente web y un servidor web se comunican entre sí a través de HTTPS, el el primero de todos Lo que debe suceder es el apretón de manos seguro.

Aquí hay un ejemplo simplificado de tal apretón de manos:

tls handshake

Si esto fuera HTTP y no HTTPS, lo primero que habría enviado el cliente sería algo como esto:

GET /index.html HTTP/1.1
Host: example.com

Esto hizo posible múltiples hosts virtuales en una única dirección IP, ya que el servidor sabe exactamente a qué dominio quiere acceder el cliente, es decir, example.com.

HTTPS es diferente. Como dije antes, el apretón de manos viene antes que todo lo demás. Si observa el tercer paso del protocolo de enlace ilustrado anteriormente (Certificado), el servidor debe presentar un certificado al cliente como parte del protocolo de enlace, pero no tiene idea de a qué nombre de dominio intenta acceder el cliente. La única opción que tiene el servidor es enviar el mismo certificado cada vez, su certificado predeterminado.

Aún podría configurar hosts virtuales en su servidor web, pero el servidor siempre enviaría el mismo certificado a cada cliente. Si intentó alojar los sitios web example.com y example.org en su servidor, el servidor siempre enviaría el certificado para example.com cuando un cliente solicite una conexión HTTPS. Entonces, cuando un cliente solicita example.org a través de una conexión HTTPS establecida, esto sucedería:

enter image description here

Este problema limita efectivamente la cantidad de dominios que puede enviar a través de HTTPS a uno por dirección IP.

La solución:

La forma más fácil de resolver este problema es que el cliente le diga al servidor a qué dominio quiere acceder durante el apretón de manos. De esta manera el servidor puede entregar el certificado correcto.

Esto es exactamente lo que SNI, o Indicación del nombre del servidor hace.

Con SNI, el cliente envía el nombre del servidor al que desea acceder como parte del primer mensaje, el paso "Hola del cliente" en el diagrama de intercambio que aparece arriba.

Algunos navegadores web más antiguos no son compatibles con SNI. Por ejemplo, en Windows XP hay No es una versión única de Internet Explorer que tiene soporte para SNI. Al acceder a un recurso a través de HTTPS en un servidor que utiliza hosts virtuales de SNI, se le presentará un certificado genérico, que puede hacer que el navegador muestre una advertencia o error.

enter image description here

He simplificado las cosas aquí solo para explicar el principio detrás del problema y la solución. Si desea una explicación más técnica, la wikipedia página o RFC 6066 Podría servir como buenos puntos de partida. También puede encontrar una lista actualizada de servidores y navegadores que admiten SNI en wikipedia


37
2017-08-14 19:13





http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

El navegador del cliente también debe ser compatible con SNI. Aquí hay algunos navegadores que hacen:

* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (with TLS 1.1 enabled)
* Internet Explorer 7.0 or later (on Vista, not XP)
* Google Chrome
* Safari 3.2.1 on Mac OS X 10.5.6 

16
2018-02-05 00:46





La extensión TLS de indicación de nombre de servidor (RFC6066) es necesaria para que los vhosts basados ​​en nombre funcionen a través de HTTPS.

La extensión está ampliamente implementada y todavía no he encontrado ningún problema con el software actual, pero existe la posibilidad de que algunos clientes (los que no lo admiten) se enruten a su sitio predeterminado si depende de SNI.


6
2017-08-14 19:10



Además de la respuesta de Falcon, IIS también requiere algunos cambios especiales para que varios sitios de IIS funcionen con la misma IP. Tiene que editar manualmente el archivo de configuración para el servidor o usar una herramienta CLI para realizar los cambios de enlace, la herramienta GUI no puede hacerlo. En IIS se hace referencia a la asignación de certificados SSL a los encabezados de host. Apache no ha tenido el problema por un tiempo. - Brent Pabst
Ah bien, eso se aclara un poco. ¿Cómo puedes saber si un cliente (navegador) soporta esto? Por ejemplo, si quiero verificar MSIE6, ¿cómo puedo probar eso sin tener que instalar una máquina virtual XP o algo así? - Luc
@Luc es.wikipedia.org/wiki/Server_Name_Indication#Support - cjc
@Falcon SNI no funciona con IE en XP; que todavía representa casi una cuarta parte de los usuarios de Internet de escritorio. No lo llamaría "implementado ampliamente" cuando una cuarta parte de los visitantes potenciales no funcionan. - Chris S
@MichaelHampton IE utiliza la pila criptográfica nativa de Windows para SSL. XP no es compatible con SNI, por lo que cualquier versión de IE que ejecute XP tampoco. IE solo admite SNI en Vista y sistemas operativos más nuevos. - Chris S