Não há necessidade de ativar o SNI para vários sites SSL no mesmo IP, mas usando o mesmo certificado de curinga?

Question

Eu tenho um servidor IIS de hospedagem:

example.com/www.example.com
sub1.example.com
sub2.example.com

Eles são listados como 3 sites separados no IIS, todos vinculados ao mesmo IP por HTTPS no 443. Mas todos usam o mesmo certificado SSL, que é um certificado de curinga que abrange * .example.com

Neste cenário, meu entendimento é que o SNI não é necessário, porque o certificado que o servidor serve para qualquer solicitação (que é o mesmo certificado) funcionará para todos os sites, correto? Eu mesmo testei e parece estar funcionando, mas eu só quero ter certeza de que isso não causará nenhum resultado inesperado para certos usuários (eu não quero usar o SNI se possível, porque eu quero o suporte do Windows XP para eles). sites)

Por curiosidade, quero saber quando você tem uma configuração como essa (vários sites sobre SSL no mesmo IP, mas não habilita o SNI), como exatamente o IIS decide qual certificado será veiculado (a primeira ligação 443 em um IP ? Ou o último usado?)

Além disso, se essa configuração funcionar, no futuro, se eu adicionar o example.org no mesmo servidor IIS e usar um certificado SSL diferente, posso ativar o SNI apenas para example.org e não afetar os outros três sites. ?

    

Answer 1

A regra básica é que, no nível da API HTTP,

• Você pode ligar um certificado único ao IP: 443 como mapeamento baseado em IP.
• Você pode ligar um certificado ao domínio: 443 como mapeamento SNI.

Such mappings can be visually analyzed via Jexus Manager.

Quando o handshake SSL / TLS é iniciado, os mapeamentos SNI devem ser verificados primeiro para corresponder ao nome do host na solicitação (dos navegadores compatíveis com SNI). Se nenhum mapeamento SNI corresponder, o mapeamento baseado em IP será varrido. Essa é a ordem de resolução.

The mappings are created and updated when you configure sites in IIS Manager. However, such mappings in HTTP API are separate from IIS configuration. They can exist even if sites in IIS are removed.

No seu caso, como você só tem um certificado curinga, a configuração de vários sites no Gerenciador do IIS não substituirá o mapeamento baseado em IP e deverá funcionar sem falhas .

No entanto, quando você tenta configurar o segundo domínio com outro certificado, não é possível usar o mesmo endereço IP (já que esse mapeamento IP: 443 já existe). Se você forçar a configuração no Gerenciador do IIS, o certificado anterior deverá ser substituído. Claro, o mapeamento SNI pode ser usado então.

    

Answer 2

Tecnicamente falando, não, o SNI não é necessário porque todos os seus sites compartilham o mesmo certificado. O IIS é inteligente o suficiente (parece, pelo menos) para distinguir entre sites usando Host: cabeçalho HTTP em clientes não-SNI (e talvez mesmo em clientes habilitados para SNI) , então tudo está funcionando como esperado.

Para o certificado "precedence", você pode ver qual certificado é usado emitindo netsh http show sslcert e o certificado padrão (para cliente não-SNI) pode ser escolhido desabilitando a opção Require Server Name Indication para esse site específico (em janela de configurações de ligações do site ). Mais informações aqui: link

Isso também deve responder à sua terceira pergunta: se você adicionar outro site ao SNI, não haverá alterações nos sites existentes (obviamente, usando um domínio diferente e um certificado diferente, example.org só pode ser acessado por clientes habilitados para SNI )