Compartilhar via


Gerenciar certificados de Redes Definidas por Software

Aplica-se a: Azure Local 2311.2 e posterior; Windows Server 2022, Windows Server 2019, Windows Server 2016

Este artigo descreve como gerenciar certificados para comunicações Northbound e Southbound do Controlador de Rede ao implantar SDN (Rede Definida pelo Software) e quando você usa o SCVMM (System Center Virtual Machine Manager) como seu cliente de gerenciamento de SDN.

Observação

Para obter uma visão geral do Controlador de Rede, confira Controlador de Rede.

Se você não estiver usando o Kerberos para proteger a comunicação do Controlador de Rede, poderá usar certificados X.509 para autenticação, autorização e criptografia.

O SDN no Windows Server 2019 e no Data center 2016 suportam certificados X.509 autoassinados e assinados pela AC (Autoridade de Certificação). Este tópico fornece instruções passo a passo para criar esses certificados e aplicá-los para proteger os canais de comunicação Northbound do Controlador de Rede com clientes de gerenciamento e comunicações Southbound com dispositivos de rede, como o SLB (Software Load Balancer).

Ao usar a autenticação baseada em certificado, você deve registrar um certificado nos nós do Controlador de Rede que é usado das seguintes maneiras.

  1. Criptografia da Comunicação Northbound com protocolo SSL entre os nós do Controlador de Rede e os clientes de gerenciamento, como o System Center Virtual Machine Manager.
  2. Autenticação entre os nós do Controlador de Rede e os dispositivos e serviços de Southbound, como hosts de Hyper-V e Balanceadores de Carga de Software (SLBs).

Criando e registrando um certificado X.509

É possível criar e registrar um certificado autoassinado ou um certificado emitido por uma AC.

Observação

Ao usar o SCVMM para implantar o Controlador de Rede, você deve especificar o certificado X.509 usado para criptografar as comunicações Northbound durante a configuração do Modelo de Serviço do Controlador de Rede.

A configuração do certificado deve incluir os valores descritos abaixo.

  • O valor da caixa de texto RestEndPoint deve ser o FQDN (Nome de Domínio Totalmente Qualificado) do Controlador de Rede ou o endereço IP.
  • O valor de RestEndPoint deve corresponder ao nome do sujeito (Nome Comum, CN) do certificado X.509.

Criando um certificado X.509 autoassinado

Para criar um certificado X.509 autoassinado e exportá-lo com a chave privada (protegida por uma senha), siga estas etapas para implantações de nó único e de vários nós do Controlador de Rede.

Use as orientações a seguir para criar certificados autoassinados.

  • Você pode usar o endereço IP do Ponto de Extremidade REST do Controlador de Rede para o parâmetro DnsName, mas isso não é recomendado porque requer que os nós do Controlador de Rede estejam todos localizados em uma única sub-rede de gerenciamento (por exemplo, em um único rack)
  • Para implantações de Controlador de Rede em vários nós, o nome DNS especificado se tornará o FQDN do Cluster do Controlador de Rede (registros de Host A DNS são criados automaticamente).
  • Para implantações de Controlador de Rede de nó único, o nome DNS pode ser o nome do host do Controlador de Rede seguido pelo nome do domínio completo.

Vários nós

Você pode usar o comando New-SelfSignedCertificate do PowerShell no Windows para criar um certificado autoassinado.

Sintaxe

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCRESTName>")

Exemplo de uso

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "MultiNodeNC" -DnsName @("NCCluster.Contoso.com")

Nó único

Você pode usar o comando New-SelfSignedCertificate do PowerShell no Windows para criar um certificado autoassinado.

Sintaxe

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCFQDN>")

Exemplo de uso

New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "SingleNodeNC" -DnsName @("SingleNodeNC.Contoso.com")

Criando um certificado X.509 assinado pela autoridade de certificação

Para criar um certificado usando uma AC, você já deve ter uma PKI (Infraestrutura de Chave Pública) implantada com o AD CS (Serviços de Certificados do Active Directory).

Observação

É possível usar ACs ou ferramentas de terceiros, como o openssl, para criar um certificado para utilizar com o Controlador de Rede, no entanto, as instruções neste tópico são específicas para AD CS. Para saber como usar uma CA ou ferramenta de terceiros, consulte a documentação do software que você está usando.

As etapas para criar um certificado com uma AC são as seguintes.

  1. Você ou o Administrador de Domínio ou Segurança da sua organização configura o modelo de certificado.
  2. Você, o Administrador do Controlador de Rede de sua organização, ou o Administrador do SCVMM solicita um novo certificado da CA.

Requisitos de configuração do certificado

Ao configurar um modelo de certificado na próxima etapa, certifique-se de que o modelo configurado inclua os seguintes elementos necessários.

  1. O nome da entidade do certificado deve ser o FQDN do host de Hyper-V.
  2. O certificado deve ser colocado no repositório pessoal da máquina local (My – cert:\localmachine\my).
  3. O certificado deve ter as Políticas de Aplicativo da Autenticação de Servidor (EKU: 1.3.6.1.5.5.7.3.1) e da Autenticação de Cliente (EKU: 1.3.6.1.5.5.7.3.2).

Observação

Se o armazenamento de certificados pessoais (My – cert:\localmachine\my) no host Hyper-V possuir mais de um certificado X.509 com o Nome do Assunto (CN) igual ao FQDN (Nome de Domínio Totalmente Qualificado) do host, certifique-se de que o certificado que será usado pelo SDN tenha uma propriedade adicional personalizada de Uso Avançado de Chave com o OID 1.3.6.1.4.1.311.95.1.1.1. Caso contrário, a comunicação entre o controlador de rede e o host pode não funcionar.

Para configurar um modelo de certificado

Observação

Antes de executar este procedimento, analise os requisitos e os modelos de certificado disponíveis no console Modelos de certificado. Você pode modificar um modelo existente ou criar uma cópia de um modelo existente e depois modificar a sua cópia do modelo. Recomenda-se criar uma cópia de um modelo existente.

  1. No servidor em que o AD CS está instalado, em Gerenciador do Servidor, clique em Ferramentas e em Autoridade de Certificação. O MMC (Console de Gerenciamento da Microsoft) da Autoridade de Certificação é aberto.
  2. No MMC, clique duas vezes no nome da Autoridade de Certificação, clique com o botão direito do mouse em Modelos de Certificado e clique em Gerenciar.
  3. O console de Modelos de Certificado abre. Todos os modelos de certificado são exibidos no painel de detalhes.
  4. No painel de detalhes, clique no modelo que você deseja copiar.
  5. Clique no menu Ação e em Duplicar Modelo. A caixa de diálogo Propriedades do modelo é aberta.
  6. Na caixa de diálogo Propriedades do modelo, na guia Nome da Entidade, clique em Fornecer na solicitação. (Essa configuração é obrigatória para certificados SSL do Controlador de Rede.)
  7. Na caixa de diálogo Propriedades do modelo, na guia Processamento da Solicitação, verifique se Permitir que a chave privada seja exportada está selecionado. Verifique também se o objetivo de Assinatura e criptografia está selecionado.
  8. Na caixa de diálogo Propriedades do modelo, na guia Extensões, selecione Uso de chave e clique em Editar.
  9. Em Assinatura, verifique se Assinatura Digital está selecionada.
  10. Na caixa de diálogo Propriedades do modelo, na guia Extensões, selecione Políticas de Aplicativo e clique em Editar.
  11. Em Políticas de Aplicativo, verifique se a Autenticação de Cliente e a Autenticação de Servidor estão na lista.
  12. Salve a cópia do modelo de certificado com um nome exclusivo, como por exemplo, Modelo de Controlador de Rede.

Para solicitar um certificado da AC

Você pode usar o snap-in de Certificados para solicitar certificados. É possível solicitar qualquer tipo de certificado que foi pré-configurado e disponibilizado por um administrador da AC que processará a solicitação de certificado.

A mínima associação de grupo necessária para concluir este procedimento é Usuários ou Administradores locais.

  1. Abra o Snap-in de certificados para um computador.
  2. Na árvore do console, clique em Certificados (Computador Local). Selecione o repositório de certificados Pessoal.
  3. No menu Ação, aponte para** Todas as Tarefase clique em **Solicitar Novo Certificado para iniciar o assistente de Registro de Certificado. Clique em Próximo.
  4. Selecione a Política de Registro de Certificado Configurada pelo administrador e clique em Avançar.
  5. Selecione a Política de Registro do Active Directory (com base no modelo da AC configurado na seção anterior).
  6. Expanda a seção Detalhes e configure os itens abaixo.
  7. Verifique se o Uso da chave inclui a Assinatura digital **e a **Criptografia de chave.
  8. Verifique se as Políticas de aplicativo incluem a Autenticação de Servidor (1.3.6.1.5.5.7.3.1) e a Autenticação de Cliente (1.3.6.1.5.5.7.3.2).
  9. Clique em Propriedades.
  10. Na guia Entidade, no campo Nome da entidade em Tipo, selecione Nome comum. Em Valor, especifique Ponto de extremidade REST do Controlador de Rede.
  11. Clique em Aplicar e em OK.
  12. Clique em Registrar.

No MMC de Certificados, clique no Repositório pessoal para visualizar o certificado que você registrou na AC.

Exportar e copiar o certificado para a biblioteca SCVMM

Depois de criar um certificado autoassinado ou assinado pela AC, você deve exportar o certificado do Snap-in de certificados com a chave privada (no formato .pfx) e sem a chave privada (no formato Base-64 .cer).

Depois, você deve copiar os dois arquivos exportados nas pastas ServerCertificate.cr e NCCertificate.cr que especificou no momento em que importou o Modelo de Serviço NC.

  1. Abra o Snap-in de certificados (certlm.msc) e localize o certificado no repositório de certificados Pessoal do computador local.
  2. Clique com o botão direito do mouse no certificado, clique em Todas as Tarefas e clique em Exportar. O Assistente para Exportação de Certificados é aberto. Clique em Próximo.
  3. Escolha a opção Sim, exportar a chave privada e clique em Avançar.
  4. Selecione Troca de Informações Pessoais – PKCS #12 (.PFX) e aceite o padrão Incluir todos os certificados no caminho de certificação, se possível.
  5. Atribua os Usuários/Grupos e uma senha para o certificado que você está exportando e clique em Avançar.
  6. Na página Arquivo para exportar, procure o local em que você deseja colocar o arquivo exportado e nomeá-lo.
  7. Seguindo o mesmo procedimento, exporte o certificado no formato .CER Observação: para exportar para o formato .CER, desmarque a opção Sim, exportar a chave privada.
  8. Copie o .PFX para a pasta ServerCertificate.cr.
  9. Copiar o arquivo .CER para a pasta NCCertificate.cr.

Quando terminar, atualize essas pastas na Biblioteca SCVMM e verifique se esses certificados foram copiados. Continue a fazer a Configuração e a Implantação do Modelo de Serviço do Controlador de Rede.

Autenticação de dispositivos e serviços Southbound

A comunicação do Controlador de Rede com hosts e dispositivos MUX SLB usa certificados para autenticação. A comunicação com os hosts usa o protocolo OVSDB e a comunicação com os dispositivos MUX SLB usa o protocolo WCF.

Comunicação do host Hyper-V com o Controlador de Rede

Para comunicação com hosts Hyper-V via OVSDB, o Controlador de Rede precisa apresentar um certificado aos computadores host. Por padrão, o SCVMM obtém o certificado SSL configurado no Controlador de Rede e o usa para comunicação southbound com os hosts.

Por essa razão, é necessário configurar o EKU de Autenticação do Cliente no certificado SSL. Esse certificado é configurado no recurso REST dos "Servidores" (os hosts Hyper-V são representados no Controlador de Rede como um recurso de Servidor) e podem ser visualizados ao executar o comando Get-NetworkControllerServer do PowerShell no Windows.

Veja a seguir um exemplo parcial do recurso REST do servidor.

   "resourceId": "host31.fabrikam.com",
      "properties": {
        "connections": [
          {
            "managementAddresses": [
               "host31.fabrikam.com"
            ],
            "credential": {
              "resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
            },
            "credentialType": "X509Certificate"
          }
        ],

Em autenticações mútuas, o host Hyper-V também deve ter um certificado para se comunicar com o Controlador de Rede.

Você pode registrar o certificado de uma AC (Autoridade de Certificação). Se um certificado baseado em CA não for encontrado no computador host, o SCVMM criará um certificado autoassinado e o provisionará no computador host.

Os certificados do Controlador de Rede e do host Hyper-V devem ser confiáveis um para o outro. O certificado raiz do certificado do host de Hyper-V deve estar presente no repositório das Autoridades de Certificação Raiz de Confiança do Controlador de Rede para o computador local e vice-versa.

Ao estiver usando certificados autoassinados, o SCVMM garante que os certificados necessários estejam presentes no armazenamento de Autoridades de Certificação Raiz Confiáveis do Computador Local.

Se você usar certificados baseados em CA para os hosts Hyper-V, precisará garantir que o certificado raiz da CA esteja presente no repositório de Autoridades de Certificação Raiz Confiáveis do Controlador de Rede para o Computador Local.

Comunicação MUX do Balanceador de Carga de Software com o Controlador de Rede

O MUX (Multiplexador de Balanceador de Carga de Software) e o Controlador de Rede se comunicam através do protocolo WCF, usando certificados para autenticação.

Por padrão, o SCVMM obtém o certificado SSL configurado no Controlador de Rede e o usa para comunicação southbound com os dispositivos MUX. Esse certificado é configurado no recurso REST "NetworkControllerLoadBalancerMux" e pode ser visualizado ao executar o cmdlet Get-NetworkControllerLoadBalancerMux do PowerShell.

Exemplo parcial do recurso REST do MUX:

      "resourceId": "slbmux1.fabrikam.com",
      "properties": {
        "connections": [
          {
            "managementAddresses": [
               "slbmux1.fabrikam.com"
            ],
            "credential": {
              "resourceRef": "/credentials/a738762f-f727-43b5-9c50-cf82a70221fa"
            },
            "credentialType": "X509Certificate"
          }
        ],

Para autenticações mútuas, você também precisa ter um certificado nos dispositivos MUX SLB. Esse certificado é configurado automaticamente pelo SCVMM quando você implanta o balanceador de carga de software usando SCVMM.

Importante

Nos nós host e do SLB, é fundamental que o repositório de certificados das Autoridades de Certificação Raiz Confiáveis não inclua nenhum certificado em que “Emitido para” não seja o mesmo que “Emitido por”. Se isso ocorrer, a comunicação entre o Controlador de Rede e o dispositivo southbound falhará.

Os certificados do Controlador de Rede e do SLB MUX devem ser confiáveis um para o outro (o certificado raiz do certificado do SLB MUX deve estar presente no repositório de Autoridades de Certificação Raiz de Confiança do computador do Controlador de Rede e vice-versa). Ao estiver usando certificados autoassinados, o SCVMM garante que os certificados necessários estejam presentes no armazenamento de Autoridades de Certificação Raiz Confiáveis do Computador Local.