Falha de SSL no web farm Auzre com configuração compartilhada e certificados centralizados

Falha de SSL no web farm Auzre com configuração compartilhada e certificados centralizados

[Desculpe se esta pergunta é um pouco longa, há muitas informações extras caso seja relevante]

Visão geral

Estou tendo um problema com SSL em um farm com balanceamento de carga de 4 VMs no Azure. Se a solicitação HTTPS for para o primeiro servidor do farm, tudo estará bem. Se chegar a qualquer um dos outros 3, a chamada falhará. O Chrome emitirá um erro de protocolo SSL, o IE e o Firefox simplesmente dirão que a página não pode ser exibida.

A configuração

Eu tenho quatro VMs do Windows Server 2012 no Azure (instância pequena apenas como teste). As VMs estão no mesmo serviço de nuvem e conjunto de disponibilidade. Foram adicionados endpoints com balanceamento de carga para as portas 80 e 443 (o retorno direto do servidor éNÃOativado nestes). Todas as quatro máquinas foram configuradas por meio do mesmo script do PowerShell e, com duas exceções, foram totalmente configuradas dessa forma.

A configuração do IIS de cada servidor é definida para usar uma configuração de compartilhamento, que é replicada via DFS para cada servidor do primeiro servidor do grupo. Isso foi configurado manualmente para cada servidor e está funcionando bem.

O DFS também é usado para replicar a pasta webs do primeiro servidor para os demais.

Também descobri o "novo" recurso de Certificados Centralizados depois de escrever o script de implantação, portanto, ele também foi instalado e configurado manualmente nos quatro servidores. Estou usando um compartilhamento em um servidor separado para armazenar os arquivos de certificado.

A solicitação de certificado foi gerada no primeiro servidor e usei SSL.com para obter um SSL gratuito de 90 dias para um endereço subdomain.domain.com. Adicionei um registro CNAME subdomainao DNS para domain.comapontar para o cloudappendereço do Azure.

Importei o certificado SSL para o primeiro servidor, exportei-o novamente como subdomain.domain.com.pfx(com uma senha) e copiei-o para o compartilhamento de arquivos do certificado. Ao verificar os certificados centralizados em todos os quatro servidores, eles listam o certificado corretamente, sem ícones de erro, indicando que a senha na configuração estava errada, etc.

Por fim, alterei as ligações do servidor 1 para adicionar https com host name subdomain.domain.come com oExigir indicação do nome do servidoreUse armazenamento centralizado de certificadosopções marcadas. A verificação dos outros servidores mostra as ligações propagadas conforme esperado.

O problema

Eu adicionei uma página básica que simplesmente exibe o nome do servidor pelo qual a solicitação foi tratada. Se eu acessar várias janelas do IE http://subdomain.domain.com, elas imprimirão uma variedade de nomes de servidores, mostrando que a configuração do IIS e os arquivos da web estão sendo implantados corretamente, e o balanceamento de carga do Azure também está fazendo isso. O que eu achei muito legal, na verdade.

No entanto, tudo vai por água abaixo quando tento fazer isso via HTTPS. Somente as solicitações que chegam ao primeiro servidor são bem-sucedidas, o restante delas trava e queima com "Esta página não pode ser exibida" ou "Erro de protocolo SSL", dependendo do navegador com o qual testei. No servidor 1, a página é exibida corretamente, o certificado pode ser visualizado e não há erros de certificado.

Tenho certeza de que este é um problema de configuração nos servidores em algum lugar, mas simplesmente não consigo dizer o que é. A maior parte do que estou brincando é nova para mim, pois no passado usamos servidores Windows 2003 físicos sem cluster com IIS6.

O que é ainda mais desconcertante é que desliguei as quatro VMs durante a noite e, quando reiniciei o serviço esta manhã, o servidor 2 agora aparentemente responde às solicitações SSL além do servidor 1. Dito isso, eu também fiz um desligamento completo ontem e ainda assim, apenas o servidor 1 funcionou depois disso.

Os arquivos de log do IIS não mostram as solicitações SSL com falha, apenas um monte de 200 para a porta 80 e uma mistura de 200 e 304 para a porta 443 nos servidores 1 e 2.

Fiz algumas diligências nas pesquisas do Google, mas nada está esclarecendo. Na verdade, exatamente o oposto, pelo que posso dizer, o que fiz deveria funcionar.

Qualquer conselho para ajudar a resolver isso será recebido com gratidão.

Responder1

Gostaria de compartilhar algumas etapas que devem resolver a maioria dos problemas com o armazenamento centralizado de certificados no IIS. O Armazenamento Centralizado de Certificados (CCS) cria uma ligação de certificado falsa que é usada para canalizar solicitações de certificados SSL para o CCS. Se esta ligação não estiver presente ou se houver várias ligações no mesmo endereço IP, você receberá erros do navegador quando os clientes tentarem se conectar a sites habilitados para SSL.

Considere a seguinte configuração; um servidor IIS com endereço IP 172.16.0.41e armazenamento centralizado de certificados habilitado contém dois domínios; www.adomain.come www.bdomain.com. Os pacotes de certificados PFX são instalados no armazenamento centralizado de certificados do IIS para cada um dos domínios.

Normalmente existem dois erros;

PROBLEMA 1

Quando os navegadores se conectam ao site, o certificado errado é compartilhado. Por exemplo, visitar www.adomain.compela primeira vez resulta na entrega do certificado correto. No entanto, quando um navegador visita www.bdomain.com, o certificado www.adomain.comé retornado, fazendo com que o navegador sinalize um erro de certificado inválido.

SOLUÇÃO

A razão para esse problema geralmente é porque vários sites estão vinculados ao mesmo endereço IP e pelo menos um dos sites não está ativadoExigir identificação do nome do servidor. Sem esta configuração habilitada para todos os sites que compartilham o mesmo IP e PORTA, o IIS não consegue determinar qual certificado servir e, portanto, umprimeiro em vitóriaspolítica parece ser aplicável.

Isso significa que as solicitações subsequentes para outros sites hospedados no mesmo servidor IIS retornam o certificado errado.

Passos para resolver

  1. Certifique-se de que cada site esteja configurado para Require Server Name Identification. Faça isso clicando em cada site no Gerenciador do IIS, escolhendo Vinculações...->Selecione a ligação HTTPS->Escolha Editar->Verificar Require Server Name Identificatione certifique-se Use Centralized Certificate Storede que também esteja marcado.

  2. Verifique as ligações no servidor. A partir de uma caixa de comando elevada, executenetsh http show sslcert

A vinculação para o CCS deverá estar presente:

SSL Certificate bindings:
------------------------- 

Central Certificate Store    : 443
Certificate Hash             : (null)
Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
Certificate Store Name       : (null)
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

Observe que a ligação com o (null)Hash do certificado indica a presença da ligação de passagem do CCS. Se houver outras ligações escutando o endereço IP do seu servidor e a porta SSL ( 172.16.0.41:443em nosso cenário), elas precisam ser removidas.

  1. Para remover as ligações, digite netsh http delete sslcert <binding>. Em nosso cenário, isso seria netsh http delete sslcert 172.16.0.41:443e a ligação deveria ser removida. A (null)ligação de passagem CCS não deve ser removida. Se esta ligação não estiver presente, consultePROBLEMA 2abaixo.

  2. Redefina o iis iisresete conecte-se a cada domínio no servidor web. O certificado correto deve ser compartilhado. Você também pode verificar as ligações repetindo a etapa 2 e garantindo que não IP:PORTexistam ligações específicas para sua porta SSL e IP do servidor web.

PROBLEMA 2

Mesmo depois de confirmar que o Armazenamento Centralizado de Certificados está habilitado, tem visibilidade nos certificados e todos os sites são obrigados a utilizá-lo, quando um navegador se conecta ao site ele gera um erro Page Cannot be displayedou invalid encryption. O site pretendido não é exibido.

No IE (Edge), isso normalmente se manifestará como uma sugestão para verificar se os tipos de criptografia apropriados estão habilitados no navegador.

Uma iisresetreinicialização ou reinicialização do servidor não resolve o problema.

SOLUÇÃO

Isto parece ser um bug na criação da ligação de passagem CCS. Ele não é criado no servidor web quando a funcionalidade CCS está habilitada para que as solicitações recebidas de um certificado sejam descartadas silenciosamente.

Passos para resolver

  1. Primeiro, verifique se o Armazenamento Centralizado de Certificados foi habilitado e pode ver todos os certificados em seu caminho. Para fazer isso, IISManagerselecione o nó do servidor->Certificados centralizados (na seção Gerenciamento)->Editar configurações de recursos.. e certifique-se de que esteja configurado e ativado.

  2. Verifique se todos os sites que utilizam certificados comuns estão vinculados ao CCS. Faça isso clicando em cada site no Gerenciador do IIS, escolhendo Vinculações...->Selecione a ligação HTTPS->Escolha Editar->Verificar Require Server Name Identificatione certifique-se Use Centralized Certificate Storede que também esteja marcado.

  3. Verifique se a ligação CCS foi criada. Correr netsh http show sslcert. Se os resultados estiverem vazios ou o (null)certificado de passagem não estiver presente (consulte a etapa 2 no PROBLEMA 1 para saber como é a ligação do CCS), a ligação do CCS não foi habilitada.

    SSL Certificate bindings:
    -------------------------
    
  4. No Gerenciador do IIS, escolhendo um site que usa o CCS, clique em Vinculações...->Selecione a ligação HTTPS->Escolha Editar->edesmarque Use Centralized Certificate Storeedesmarque Require Server Name Identification.

No SSL certificatemenu suspenso, selecione o WMSVCcertificado padrão do servidor e clique em OK. Deixe a Site Bindingsjanela aberta.

  1. Volte para o prompt de comando elevado e execute o netsh http show sslcert. Isso deve gerar uma ligação como esta:

    SSL Certificate bindings:
    ------------------------- 
    IP:port                      : 172.16.0.41:443
    Certificate Hash             : 64498c920fecb31b8f7ccbdac2fa2baa2ec4f19a
    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
    
  2. Retorne à Site Bindingsjanela e reverta as alterações da Etapa 4. Ativando Require Server Name Indicatione Use Centralized Certificate Storee clique em OK.

  3. Volte para o prompt de comando elevado e execute netsh http show sslcertmais uma vez e - se os deuses sorrirem para você - a ligação do Armazenamento Centralizado de Certificados deverá ter surgido, substituindo a ligação atual:

      SSL Certificate bindings:
      -------------------------
    
      Central Certificate Store    : 443
      Certificate Hash             : (null)
      Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
      Certificate Store Name       : (null)
      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
    

Se você vir a ligação do certificado acima com o (null)valor, Certificate Hashele funcionou e a passagem CSS agora deve estar habilitada.

  1. Abra um navegador e tente conectar-se aos domínios no servidor através do soquete seguro (HTTPS) e tudo ficará bem.

Anotações importantes

  • Você precisa repetir esse processo em cada servidor web do seu web farm. Deve ser possível via PowerShell automatizar e verificar o processo.

  • Depois que a associação de passagem tiver sido criada, ela será retida indefinidamente (a menos que você desative o suporte ao certificado centralizado no nó).

Como um aparte; este link contém informações sobre como funciona o CCS a nível técnico e vale a pena ler:https://blogs.msdn.microsoft.com/kaushal/2012/10/11/central-certificate-store-ccs-with-iis-8-windows-server-2012/

Espero que isso ajude.

informação relacionada