Alguém poderia me explicar a diferença entre esses certificados de uma maneira simplificada? Eu li alguns artigos, mas parece que eles fazem o mesmo trabalho, ou seja, criptografar muitos domínios com um certificado.
ssl
sni
subject-alternative-names
AFA Med
fonte
fonte
Respostas:
SAN (nome alternativo da entidade) faz parte da especificação do certificado X509 , na qual o certificado possui um campo com uma lista de nomes alternativos que também são válidos para a entidade (além do nome comum / CN único). Esse campo e os nomes curinga são essencialmente as duas maneiras de usar um certificado para vários nomes.
SNI (Server Name Indication) é uma extensão de protocolo TLS que é uma espécie de protocolo TLS equivalente ao cabeçalho do host HTTP. Quando um cliente envia isso, ele permite que o servidor escolha o certificado apropriado para apresentar ao cliente sem ter a limitação de usar endereços IP separados no lado do servidor (como o cabeçalho do host HTTP é muito usado para HTTP simples).
Observe que o SNI não é algo refletido no certificado e, na verdade, alcança o oposto do que a pergunta pede; simplifica ter muitos certificados, não usar um certificado para muitas coisas.
Por outro lado, depende muito da situação de qual caminho é realmente preferível. Como exemplo, o que a pergunta pede quase certamente não é o que você realmente deseja se precisar de certificados para entidades diferentes.
fonte
SAN significa Subject Alternative Name , e é uma propriedade de certificado x509, e SNI é um recurso que o cliente SSL / TLS pode suportar, portanto, uma entidade totalmente diferente.
Usando um certificado com SAN, você pode hospedar vários sites habilitados para HTTPS em um endereço IP, mesmo que o cliente não suporte o SNI . Neste caso você mantenha um certificado para todos os seus sites, e tal certificado deve conter todos os nomes de site (
ServerName
S ouServerAlias
es nas coordenadas apache, ouserver_name
no nginx) como é SANs . Esse é um subconjunto de uma abordagem herdada, que estendeu o "um site habilitado para HTTPS em cada endereço IP separado". Atualmente, apenas grandes CDNs permanecem na SAN .Usando o SNI, você também pode hospedar vários sites habilitados para HTTPS em um IP, possui um certificado x509 separado para cada site e nenhum deles menciona outros nomes de sites em sua propriedade SAN , mas os clientes TLS (por exemplo, navegadores e clientes de console como
wget
oucurl
) deve suportar SNI . Essa é uma abordagem moderna, já que o último sistema operacional que não oferece suporte ao SNI imediato foi o Windows XP com o IE 6.x, se bem me lembro. Atualmente, você pode ver a propriedade da SAN se comprar o certificado curinga - por exemplo, um certificado para esse*.foobar.com
conterá um Nome Comum de*.foobar.com
e uma SAN defoobar.com
.fonte
Isso combina duas partes do processo de certificado.
Uma SAN é um nome alternativo do assunto. É uma maneira de criar um certificado para vários domínios. Você simplesmente adiciona os outros domínios para os quais deseja um certificado ao campo SAN no certificado. O navegador também aceitará a validade desses domínios.
SNI é a indicação do nome do servidor e faz parte do SSL. Ele permite que você hospede vários sites SSL em um único IP, porque o nome do servidor desejado é enviado com o handshake SSL e o servidor pode escolher o certificado correto para a resposta.
fonte
Aqui está uma resposta legível (possivelmente) mais humana:
O SNI é conduzido no lado do cliente e diz à pilha TLS "Quero falar com um servidor cujo nome é [Servidor X]". O servidor vê essa string [Server X] e responde com um certificado apropriado. Um exemplo prático é quando um único servidor precisa servir o tráfego para vários domínios. Também é útil se o cliente usou um IP (para evitar atrasos na pesquisa de DNS), mas o certificado CN não menciona o IP.
SAN é uma lista de "Também conhecido como" nos certificados. Dessa forma, o servidor pode usar um único certificado para muitos nomes. Pode-se adicionar muitos domínios ao mesmo certificado e até uma lista de IPs.
Como você pode ver, as coisas se sobrepõem. Escolher entre um ou ambos depende de onde se tem controle. Alguns clientes podem não reconhecer nomes na SAN e a única maneira de resolver isso é fornecendo o certificado apropriado com base no SNI. Existem cenários em que servidor fornece API para um único certificado ou o cliente não envia SNI. Para esses casos, a SAN é a única saída.
Minha empresa faz uso de ambos. Eles fornecem flexibilidade e facilitam a compatibilidade com versões anteriores e posteriores.
fonte