Não é possível desabilitar o SNI no Windows Server 2012

Question

Eu tenho duas 'famílias' diferentes de sites relacionados, cada um com seu próprio certificado UCC no mesmo servidor.

Estou hospedando-os no mesmo servidor IIS, usando um endereço IP para cada família.

Ambas as certificações da UCC são da GoDaddy.

Cada uma das ligações (para cada SAN no UCC) tem 'Exigir indicação do nome do servidor' desativada.

Noentanto,quandotentoacessarositeapartirdoIE8noWindowsXP,apenasumadas'famílias'desitesfunciona.Ooutrosimplesmentenãonegocia.

AoanalisaroSSLno SSLLabs.com , recebo o seguinte resultado: "Este site funciona somente em navegadores com suporte a SNI. '

Mas como isso é possível! Desativei 'Exigir SNI' para cada: 443 ligação.

Eu até observei o arquivo applicationHost.config e não há um único site com sslFlags="1" para indicar que essa configuração está ativada. Sim, eu também reiniciei o IIS.

O que está acontecendo? Estou muito perplexo. Eu estou querendo saber se eu posso desabilitar completamente o SNI no servidor de alguma forma, ou o que teria provocado isso acontecer. Eu fiz vários meses de atualizações do Windows ontem, mas para ser franco, eu acho que tem sido assim por muito tempo sem que eu perceba - com base em US $ 0 em vendas de clientes XP do IE8; -)

Editar: Estou realmente pensando meu IIS está corrompido. Quando executo netsh http show sslcert , cada ligação é da forma IP: port. De acordo com este artigo se o SNI estiver ativado, então eu veria hostname:port e não vejo entradas nesse formato. Também não há entradas em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo no registro - mas confirmei que uma nova será criada aqui se eu adicionar temporariamente uma ligação SNI.

IP:port                      : 10.0.0.2:443
Certificate Hash             : d59a149e6678bc10d62093401c5b705cc23094be
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

    

Answer 1

Uma coisa que não mencionei é que estou usando o Armazenamento de Certificados Centralizado do IIS - que se tornou importante.

Para os meus sites, vamos fingir que são os seguintes grupos (o IP é interno e mapeado através do firewall).

Group A : red.com, blue.com, green.com   (UCC certificate A)  10.0.0.1
Group B : cat.com, dog.com, mouse.com    (UCC certificate B)  10.0.0.2

O Grupo A é o grupo que estava trabalhando como eu queria (não relatando que requer SNI). O grupo B não estava funcionando no XP com o IIS 8.

No meu armazenamento de certificados, tenho várias cópias de cada certificado (apenas pfx arquivos no sistema de arquivos).

red.com.pfx blue.com.pfx green.com.pfx etc. para todos os sites

Quando eu executei o comando netsh http show sslcert , houve apenas uma entrada para 10.0.0.1:443 e não para 10.0.0.2:443 . Isso é o que estava causando o comportamento diferente em cada site.

IP:port                      : 10.0.0.1:443
Certificate Hash             : d4a17e3b57e48c1166f18394a819edf770459ac8
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : My
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check                  : Enabled
Revocation Freshness Time    : 0
URL Retrieval Timeout        : 0
Ctl Identifier               : (null)
Ctl Store Name               : (null)
DS Mapper Usage              : Disabled
Negotiate Client Certificate : Disabled

Por que esse IP estava mostrando uma entrada? Eu também tive uma ligação adicional em outro site com este mesmo certificado para o mesmo endereço IP (usado para redirecionar o SSL para SSL).

Eu acho que o IIS está supondo que, se você estiver usando o armazenamento centralizado que você está usando o SNI, parece implicitamente relatar que ele exige isso - mesmo que isso não ocorra.

Consegui [finalmente] resolver isso alterando uma das minhas ligações para o grupo B para fazer referência explícita ao certificado em vez de apenas procurá-lo na loja. Depois de fazer isso, é claro que a entrada 10.0.0.2:443 estava presente na lista netsh http show sslcert e o site funcionou bem no XP: -)

(Eu só tive que fazer isso por dog.com . Os outros sites de animais ainda estão definidos para usar o armazenamento central).