¿Podría alguien explicarme la diferencia entre estos certificados de manera simplificada? Leí algunos artículos, pero parece que hacen el mismo trabajo, es decir, encriptar muchos dominios con un solo certificado.
Respuestas:
SAN (Nombre alternativo del sujeto) es parte de la especificación del certificado X509 , donde el certificado tiene un campo con una lista de nombres alternativos que también son válidos para el sujeto (además del Nombre común / CN único). Este campo y los nombres comodín son esencialmente las dos formas de usar un certificado para varios nombres.
SNI (Indicación de nombre del servidor) es una extensión de protocolo TLS que es una especie de protocolo TLS equivalente al encabezado de host HTTP. Cuando un cliente envía esto, le permite al servidor elegir el certificado adecuado para presentar al cliente sin tener la limitación de usar direcciones IP separadas en el lado del servidor (de forma muy similar a cómo se usa mucho el encabezado del host HTTP para HTTP simple).
Tenga en cuenta que SNI no es algo que se refleja en el certificado y en realidad logra lo contrario de lo que pide la pregunta; simplifica tener muchos certificados, no usar un certificado para muchas cosas.
Por otro lado, depende en gran medida de la situación qué camino es realmente preferible. Como ejemplo, lo que la pregunta pide es casi seguro que no sea lo que realmente desea si necesita certificados para diferentes entidades.
SAN significa Nombre alternativo del sujeto , y es una propiedad de certificado x509, y SNI es una característica que el cliente SSL / TLS puede admitir, por lo tanto, una entidad totalmente diferente.
Al usar un certificado con SAN , puede alojar múltiples sitios habilitados para HTTPS en una dirección IP, incluso si el cliente no admite el SNI . En este caso, tiene un certificado para todos sus sitios, y dicho certificado debe contener todos los nombres de sitios ( ServerNames o ServerAliases en las coordenadas de apache, o server_nameen nginx) como SAN . Este es un subconjunto de un enfoque heredado, el que extendió el "sitio habilitado para HTTPS en cada dirección IP separada". Actualmente, solo las CDN grandes se adhieren a SAN .
Usando SNI también puede alojar múltiples sitios habilitados para HTTPS en una IP, tiene un certificado x509 separado para cada sitio y ninguno de estos menciona otros nombres de sitio en su propiedad SAN , sino clientes TLS (es decir, navegadores y clientes de consola como wgeto curl) debe ser compatible con SNI . Este es un enfoque moderno, ya que el último sistema operativo que no admitía SNI fuera de la caja fue Windows XP con IE 6.x, si no recuerdo mal. Hoy en día se puede ver la SAN propiedad si usted compra el comodín certificado - por ejemplo, un certificado de este tipo para *.foobar.comcontendrá un nombre común de *.foobar.comy una SAN de foobar.com.
Esto mezcla dos partes del proceso del certificado.
Una SAN es un nombre alternativo de sujeto. Es una forma de crear un certificado para múltiples dominios. Simplemente agregue los otros dominios para los que desea un certificado al campo SAN en el certificado. El navegador también aceptará la validez en estos dominios.
SNI es Indicación de nombre de servidor y es parte de SSL. Le permite alojar múltiples sitios SSL en una sola IP porque el nombre del servidor deseado se envía con el protocolo de enlace SSL y el servidor puede elegir el certificado correcto para la respuesta.
Aquí una (posiblemente) respuesta más legible para humanos:
SNI se lleva a cabo en el lado del cliente y le dice a la pila TLS "Quiero hablar con un servidor cuyo nombre es [Servidor X]". El servidor ve esta cadena [Servidor X] y responde con un certificado apropiado. Un ejemplo práctico es cuando un solo servidor necesita servir tráfico para múltiples dominios. También es útil si el cliente usó una IP (para evitar demoras en la búsqueda de DNS) pero el certificado CN no menciona la IP.
SAN es una lista de "También conocido como" en los certificados. De esta manera, el servidor puede usar un solo certificado para muchos nombres. Se pueden agregar muchos dominios al mismo certificado e incluso una lista de IP.
Como puede ver, las cosas se superponen. Elegir entre uno o ambos depende de dónde se tenga el control. Es posible que algunos clientes no reconozcan los nombres en SAN y la única forma de abordarlo es mediante la provisión de un certificado apropiado basado en SNI. Hay escenarios en los que el servidor proporciona API para un solo certificado o el cliente no envía SNI. Para estos casos, SAN es la única salida.
Mi compañía hace uso de ambos. Proporcionan flexibilidad y facilitan la compatibilidad con versiones anteriores y posteriores.