Certificados SSL SNI e curingas no mesmo servidor com o IIS

Question

Gostaria de hospedar um site que deve ouvir subdomínios (por exemplo, sub.dominio.com), juntamente com vários sites que vivem apenas sob um domínio de segundo nível (por exemplo, domínio2.com, domínio3.com) com o IIS e com SSL.

Para o site com os subdomínios, tenho um certificado curinga (* .domain.com) e também tenho certificados especificamente para os outros sites (domain2.com e domain3.com).

Essa configuração pode ser hospedada no mesmo IIS (se isso for importante, em uma função da Web do Serviço de Nuvem do Azure)?

A questão é exatamente o que titobf explicou aqui : teoricamente, para isso, precisaríamos de ligações usando o SNI, com o host especificado para o domínio2 / 3.com e, em seguida, um site abrangente com * host para * .domain.com. Mas na prática, não importa como as ligações sejam configuradas, se o site pega-tudo estiver presente, ele também receberá todas as solicitações para o domínio2 / 3.com (embora supostamente ele seja correspondido apenas como último recurso).

Qualquer ajuda seria apreciada.

Ainda não resolvido

Infelizmente eu não consegui resolver isso: parece ser solucionável apenas de maneiras extremamente complicadas, como criar um software que fica entre o IIS e a internet (então, basicamente, um firewall) e modifica as solicitações recebidas (antes do handshake SSL) acontece!) para permitir o cenário. Estou bastante confiante de que isso não é possível com o IIS, não importa, nem mesmo de um módulo nativo.

Preciso esclarecer: usamos o Azure Cloud Services, por isso temos uma restrição adicional de não podermos usar vários endereços IP (consulte: link ). Se você puder apontar vários IPs para o seu servidor, então você não tem esse problema, já que você pode criar ligações para IPs também, e eles irão trabalhar juntos com ligações curinga. Mais especificamente, você precisa de um IP para o site curinga (mas já que você tem um IP separado agora você não teria que configurar uma ligação de nome de host curinga) e outro IP para todos os outros não-curinga.

Na verdade, nossa solução alternativa era o uso de uma porta SSL não padrão, 8443. Portanto, a ligação SNI está realmente vinculada a essa porta, portanto, funciona junto com as outras ligações. Não é legal, mas é uma solução aceitável para nós até que você possa usar vários IPs para funções da Web.

As ligações não funcionais agora

A primeira ligação https é SNI com um certificado simples, a segunda não é SNI, com um certificado curinga.

O site http funciona, assim como o site SNI https, mas aquele com a ligação de caractere curinga fornece um "Erro HTTP 503. O serviço está indisponível". (sem qualquer informação adicional, nenhum rastreamento de solicitação com falha ou entrada de log de eventos).

Finalmente conseguindo basicamente trabalhar

Ativar o log de rastreio do ETW como Tobias descrito mostrou que o erro de raiz era o seguinte:

Request (request ID 0xF500000080000008) rejected due to reason: UrlGroupLookupFailed.

Tanto quanto eu entendo isso significa que o http.sys não é capaz de encaminhar o pedido para qualquer ponto de extremidade disponível.

A verificação dos terminais registrados com netsh http show urlacl mostrou que realmente havia algo registrado para a porta 443:

Reserved URL            : https://IP:443/
    User: NT AUTHORITY\NETWORK SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;NS)

Remover isso com netsh http delete urlacl url=https://IP:443/ finalmente ativou minha ligação SSL.

    

Answer 1

Baris está certo! O certificado SSL configurado em uma ligação IP: PORT (exemplo: 100.74.156.187:443) sempre tem precedência no http.sys! Então a solução é a seguinte:

Não configure uma ligação IP: 443 para seu certificado de fallback com curinga, mas configure uma ligação *: 443 (* significa "Todos os não atribuídos") para ela .

Se você configurou seu certificado curinga no terminal SSL do Serviço do Cloud Azure (como eu), precisará alterar a ligação SSL criada pelo Tempo de Execução do Serviço de Nuvem do Azure (IISconfigurator.exe) de IP: PORT para *: PORT. Estou chamando o método a seguir em OnStart da minha função da web:

public static void UnbindDefaultSslBindingFromIp()
{
    Trace.TraceInformation(">> IISTenantManager: Unbind default SSL binding from IP");
    using (var serverManager = new Microsoft.Web.Administration.ServerManager())
    {
        try
        {
            var websiteName = string.Format("{0}_Web", Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CurrentRoleInstance.Id);
            var site = serverManager.Sites[websiteName];
            var defaultSslBinding = site.Bindings.Single(b => b.IsIPPortHostBinding && b.Protocol == "https");
            defaultSslBinding.BindingInformation = string.Format("*:{0}:", defaultSslBinding.EndPoint.Port);
            serverManager.CommitChanges();
        }
        catch (Exception ex)
        {
            Trace.TraceError(ex.ToString());
        }
    }
}

A captura de tela a seguir mostra uma configuração funcional do nosso serviço de nuvem. Por favor, não fique confuso sobre as portas não padronizadas. A captura de tela é do serviço de nuvem emulado.

Umaoutracoisaamencionar:Nãoaltereasligaçõesdeallpara*porquealigaçãoHTTP(porta80)sófuncionacomaligaçãoIP:PORTnoserviçodenuvemimplementado.AlgomaiséligadoaoIP:80,então*:80nãofuncionaporque*significa"todos não atribuídos" e o IP já está atribuído em algum outro lugar no http.sys.

    

Answer 2

Certifique-se de que sua ligação catch-all não seja do tipo IP: Port. Quando existe uma ligação IP: Port para uma ligação HTTPS enquanto SNI não é necessário, essa ligação sempre terá precedência. Para o seu caso catch-all, use uma ligação *: Port (* sendo todos os não atribuídos).

    

Answer 3

O IIS oferece suporte a SNI, mesmo em funções da Web do serviço de nuvem azure, embora você não consiga acessar a configuração por meio do portal e, se fizer isso na caixa após a implantação, ela será limpa com sua próxima implantação. A solução é automatizar a configuração. Dê uma olhada aqui para mais detalhes:

link