Este es un Canónica Pregunta acerca del Alojamiento SSL varios sitios web en la misma IP.
Yo estaba bajo la impresión de que cada Certificado SSL requiere es propia y única Dirección IP/Puerto combinación. Pero la respuesta a una pregunta anterior que he publicado está en desacuerdo con esta afirmación.
Utilizando la información de la Pregunta que yo era capaz de conseguir varios certificados SSL para trabajar en la misma dirección IP y el puerto 443. Estoy muy confundido en cuanto a por qué esto funciona, dada la suposición arriba y reforzada por otros que cada SSL de dominio de web en el mismo servidor requiere su propia dirección IP y el Puerto.
Soy sospechosa que hice algo mal. Puede de varios Certificados SSL se utilizan de esta manera?
Respuestas
¿Demasiados anuncios?
Sí, pero hay algunas advertencias.
Esto se logra a través de la Indicación de Nombre de Servidor, una extensión de la Capa de Transporte de Seguridad.
¿Cuál es el Nombre del Servidor Indicación?
Server Name Indication (RFC 6066; obsoleto a RFC 4366, RFC 3546) es una extensión de la Capa de Transporte de Seguridad que permite que el cliente indica al servidor el nombre del host que está tratando de alcanzar.
SNI es compatible con TLS 1.0 y superiores de acuerdo a las especificaciones, pero las implementaciones pueden variar (ver más abajo). No se puede utilizar con SSL, por lo que una conexión se debe negociar TLS (ver RFC 4346 apéndice E) para el SNI para ser utilizado. Generalmente, esto sucede automáticamente con software compatible.
¿Por qué SNI necesario?
En una normal HTTP conexión, el navegador informa al servidor de nombre de host del servidor está tratando de alcanzar el uso de la Host: de encabezado. Esto permite que para un servidor web en una dirección IP única para servir contenido para múltiples nombres de host, el cual es comúnmente conocido como hosting virtual basado en nombres.
La alternativa es asignar direcciones IP únicas para cada web nombre de host para ser servido. Esto se hace comúnmente en los primeros días de la web, antes de que fuera ampliamente conocido que las direcciones IP se quedaría sin medidas de conservación y comenzó, y todavía se hace de esta manera para las máquinas virtuales SSL (SNI).
Debido a que este método de transmitir el nombre de host requiere que la conexión ya está establecida, no funciona con conexiones SSL/TLS. Por el momento la conexión segura está configurado, el servidor web ya debe saber que nombre de host que va a servir para el cliente, debido a que el servidor web es la configuración de la conexión segura.
SNI resuelve este problema haciendo que el cliente transmita el nombre de la máquina como parte de la negociación TLS, por lo que el servidor ya es consciente de que el host virtual debe ser utilizado para el servicio de la conexión. El servidor puede utilizar el certificado y la configuración para el correcto host virtual.
¿Por qué no utilizar direcciones IP diferentes?
HTTP Host: cabecera se ha definido para permitir más de un host Web que se sirve de una sola dirección IP, debido a la escasez de direcciones IPv4, reconocido como un problema tan temprano como a mediados de la década de 1990. En alojamiento web compartido de los entornos, cientos de único, no relacionados con sitios Web pueden ser servidas utilizando una sola dirección IP de esta manera, la conservación de su espacio de direcciones.
Entornos de hospedaje compartido, a continuación, encontró que el mayor consumo de espacio de direcciones IP fue la necesidad de asegurar que los sitios web tienen direcciones IP únicas, creando la necesidad de SNI como una medida paliativa en el camino a IPv6. Hoy en día es a veces difícil de obtener como mínimo de 5 direcciones IP (/29) sin justificación, a menudo resulta en la implementación de los retrasos.
Con la llegada de IPv6, la dirección de conservación de las técnicas ya no son necesarias, ya que una misma máquina puede tener más direcciones IPv6 asignadas a la misma de toda la Internet contiene en la actualidad, pero las técnicas probablemente todavía ser utilizado en el futuro para el servicio de legado conexiones IPv4.
Advertencias
Algunos de sistema operativo/navegador combinaciones no admiten SNI (ver más abajo), de modo que el SNI no es apropiado para todas las situaciones. Sitios dirigidas a tal sistema/navegador combinaciones tendría que renunciar al SNI y continuar el uso de direcciones IP únicas para cada host virtual.
De la nota particular, no hay ninguna versión de Internet Explorer en Windows XP es compatible con SNI. Como esta combinación todavía representa un importante (pero disminuyendo a un ritmo constante; aproximadamente el 16% del tráfico de Internet en diciembre de 2012, según NetMarketShare) parte del tráfico de Internet, SNI sería inapropiado para un sitio de la orientación de estas poblaciones de usuarios.
Apoyo
Muchos, pero no todos, de los que comúnmente se utilizan paquetes de software de apoyo SNI.
(Omisión de esta lista no significa necesariamente falta de apoyo; significa que hay un límite a lo que yo podría escribir, o no podía encontrar rápidamente la información en una búsqueda. Si el paquete de software no aparece en la lista, al buscar su nombre + sni debe revelar si existe apoyo y cómo configurarlo.)
Soporte De La 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, sólo como un cliente
- libcurl 7.18.1 o superior
- NSS 3.1.1 o superior
- OpenSSL 0.9.8 j o superior
- OpenSSL 0.9.8 f o más alta, con configurar banderas
- Qt 4.8 o superior
Soporte De Servidor
La mayoría de las versiones actuales de los populares software de servidor de apoyo SNI. Instrucciones de instalación están disponibles para la mayoría de estos:
- Apache 2.2.12 o superior
- Apache Traffic Server 3.2.0 o superior
- Cherokee
- IIS 8.0 o superior
- lighttpd 1.4.24 o superior
- LiteSpeed 4.1 o superior
- nginx 0.5.32 o superior
Soporte Al Cliente
La mayoría de los actuales navegadores web y línea de comandos de usuario de agentes de apoyo SNI.
Escritorio
- Chrome 5 o superior
- Chrome 6 o superior en Windows XP
- Firefox 2 o superior
- Internet Explorer 7 o superior, que se ejecuta en Windows Vista/Server 2008 o superior
- Internet Explorer en Windows XP no es compatible con SNI, independientemente de la versión de IE
- Konqueror 4.7 o superior
- Opera 8 o superior (se puede requerir TLS 1.1 habilitado para funcionar)
Móvil
- Navegador de Android en 3.0 Honeycomb o superior
- iOS Safari en iOS 4 o superior
- Windows Phone 7 o superior
De La Línea De Comandos
- cURL 7.18.1 o superior
- wget 1.14 o superior (Distribuciones pueden tener puesto un parche para el SNI de apoyo)
No Apoyo
- BlackBerry Browser
- Internet Explorer (cualquier versión) en Windows XP
(Nota: Algunos datos para que esta respuesta se ha obtenido de Wikipedia.)
For the most up-to-date information on Apache and SNI, including additional HTTP-Specific RFCs, please refer to the Apache wiki:http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
FYsI: "Múltiples (diferentes) de los certificados SSL en una sola IP" es traído a usted por la magia de TLS de la Actualización.
Funciona con los nuevos servidores Apache (2.2.x) y razonablemente reciente de los navegadores (no sé versiones de la parte superior de mi cabeza).
RFC 2817 (actualización a TLS dentro de HTTP/1.1) tiene los detalles escabrosos, pero básicamente se trabaja para un montón de gente (si no la mayoría).
Puede reproducir el viejo cobarde comportamiento con openssl s_client comando (o cualquier "la edad suficiente" del navegador).
Editar para agregar: al parecer, curl puede mostrar 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.
El problema:
Cuando un cliente web y un servidor web de hablar unos con otros a través de HTTPS, la primera cosa que debe suceder es que el seguro apretón de manos.
Aquí es un ejemplo simplificado de un apretón de manos:
Si esto fuera HTTP y no HTTPS, lo primero que el cliente hubiera enviado habría sido algo como esto:
GET /index.html HTTP/1.1
Host: example.com
Esto hizo que varios hosts virtuales en una única dirección IP que sea posible, ya que el servidor sabe exactamente qué dominio que el cliente quiere acceder, a saber example.com.
HTTPS es diferente. Como he dicho antes, el apretón de manos viene antes de todo lo demás. Si usted mira en el tercer paso de la apretón de manos se ilustra arriba (Certificado), el servidor deberá presentar un certificado para el cliente como parte de la apretón de manos, pero no tiene idea de lo que el nombre de dominio que el cliente está tratando de acceder. La única opción que el servidor tiene que enviar el mismo certificado cada vez, es el certificado predeterminado.
Usted todavía puede configurar las máquinas virtuales en el servidor web, pero el servidor enviar siempre el mismo certificado para cada cliente. Si se trató de albergar la example.com y example.org sitios web en su servidor, el servidor siempre enviar el certificado de example.com cuando un cliente solicita una conexión HTTPS. Así que cuando un cliente solicita example.org durante establecido una conexión HTTPS, esto iba a suceder:
Este problema limita efectivamente el número de dominios que pueden servidor a través de HTTPS a uno por dirección IP.
La solución:
La forma más sencilla de resolver este problema es para el cliente para decirle al servidor de dominio al que se quiere acceder durante el apretón de manos. De esta manera el servidor puede servir el certificado correcto.
Esto es exactamente lo SNI, o el Nombre de Servidor Indicación.
Con SNI, el cliente envía el nombre del servidor que desea acceder como parte de la primer mensaje, el Cliente "Hola" paso en el apretón de manos con el diagrama de arriba.
Algunos navegadores antiguos no soportan el SNI. Por ejemplo, en Windows XP no no es una única versión de Internet Explorer que tiene soporte para el SNI. Cuando se accede a un recurso a través de HTTPS en un servidor que hace uso de la SNI hosts virtuales, se le presentará con un certificado genérico, que puede causar que el navegador muestre un mensaje de error o advertencia.
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ían servir como puntos de partida. Usted también puede encontrar un hasta la fecha de la lista de servidores y navegadores que soporten SNI en wikipedia
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
El navegador del cliente también debe admitir SNI. Aquí hay algunos navegadores que hacer:
* 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
La extensión de TLS server nombre indicación (RFC6066) se requiere para vhosts basado en nombres a trabajar mediante HTTPS.
La extensión es ampliamente aplicada y todavía tengo que tiene problemas con el software actual, pero hay una posibilidad de que algunos clientes (aquellos que no lo apoyan) serán dirigidos a tu sitio predeterminado si dependes de SNI.
