Partilhar via

Gerenciar certificados para rede definida 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 quando você implanta o Software Defined Networking (SDN) e quando você usa o System Center Virtual Machine Manager (SCVMM) como seu cliente de gerenciamento SDN.

Nota

Para obter informações gerais sobre o controlador de rede, consulte Controlador de rede.

Se você não estiver usando 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 2016 Datacenter oferece suporte a certificados X.509 autoassinados e assinados pela Autoridade de Certificação (CA). Este tópico fornece instruções passo a passo para criar esses certificados e aplicá-los a canais de comunicação seguros do Controlador de Rede Northbound com clientes de gerenciamento e comunicações Southbound com dispositivos de rede, como o Software Load Balancer (SLB).

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. Criptografando a comunicação Northbound com SSL (Secure Sockets Layer) entre nós do controlador de rede e clientes de gerenciamento, como o System Center Virtual Machine Manager.
  2. Autenticação entre nós do Controlador de Rede e dispositivos e serviços Southbound, como hosts Hyper-V e SLBs (Software Load Balancers).

Criando e registrando um certificado X.509

Você pode criar e registrar um certificado autoassinado ou um certificado emitido por uma autoridade de certificação.

Nota

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

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

  • O valor da caixa de texto RestEndPoint deve ser o FQDN (Network Controller Fully Qualified Domain Name) ou o endereço IP.
  • O valor RestEndPoint deve corresponder ao nome da entidade (Common Name, CN) do certificado X.509.

Criando um certificado X.509 autoassinado

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

Ao criar certificados autoassinados, você pode usar as seguintes diretrizes.

  • 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 de vários nós, o nome DNS especificado se tornará o FQDN do Cluster de Controlador de Rede (os registros de Host DNS A são criados automaticamente.)
  • Para implantações de Controlador de Rede de nó único, o nome DNS pode ser o nome de host do Controlador de Rede seguido pelo nome de domínio completo.

Vários nós

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

Sintaxe

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

Exemplo de utilização

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 Windows PowerShell para criar um certificado autoassinado.

Sintaxe

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

Exemplo de utilização

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

Criando um certificado X.509 assinado por CA

Para criar um certificado usando uma autoridade de certificação, você já deve ter implantado uma PKI (infraestrutura de chave pública) com os Serviços de Certificados do Ative Directory (AD CS).

Nota

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

A criação de um certificado com uma autoridade de certificação inclui as etapas a seguir.

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

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 Hyper-V.
  2. O certificado deve ser colocado no armazenamento pessoal da máquina local (My – cert:\localmachine\my).
  3. O certificado deve ter políticas de Aplicativo de Autenticação de Servidor (EKU: 1.3.6.1.5.5.7.3.1) e Autenticação de Cliente (EKU: 1.3.6.1.5.5.7.3.2).

Nota

Se a loja de certificados Pessoal (My – cert:\localmachine\my) no host Hyper-V tiver mais de um certificado X.509 com Nome Comum (CN) correspondente ao Nome de Domínio Completamente Qualificado (FQDN) do host, assegure-se de que o certificado a ser utilizado 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 o modelo de certificado

Nota

Antes de executar este procedimento, você deve revisar os requisitos de certificado e os modelos de certificado disponíveis no console Modelos de Certificado. Você pode modificar um modelo existente ou criar uma duplicata de um modelo existente e, em seguida, modificar sua cópia do modelo. Recomenda-se criar uma cópia de um modelo existente.

  1. No servidor onde o AD CS está instalado, no Gestor de Servidor, clique em Ferramentas e, em seguida, clique em Autoridade de Certificação. Abre-se a consola de gestão da Autoridade de Certificação Microsoft (MMC).
  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. A consola de Modelos de Certificado é aberta. Todos os modelos de certificado são apresentados no painel de detalhes.
  4. No painel de detalhes, clique no modelo que deseja duplicar.
  5. Clique no menu Ação e, em seguida, clique em Duplicar modelo. A caixa de diálogo Propriedades do modelo é aberta.
  6. Na caixa de diálogo Propriedades do modelo, na guia Nome do Assunto , clique em Fornecer na solicitação. (Esta configuração é necessária para certificados SSL do Controlador de Rede.)
  7. Na caixa de diálogo Propriedades do modelo, na guia Tratamento de Solicitação , verifique se a opção Permitir a exportação de chave privada está selecionada. Certifique-se também de que a Assinatura e a finalidade de criptografia estejam selecionadas.
  8. Na caixa de diálogo Propriedades do modelo, na guia Extensões , selecione Uso da Chave e clique em Editar.
  9. Em Assinatura, verifique se a opção 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 listadas.
  12. Salve a cópia do modelo de certificado com um nome exclusivo, como modelo de controlador de rede.

Para solicitar um certificado da autoridade de certificação

Você pode usar o snap-in Certificados para solicitar certificados. Você pode solicitar qualquer tipo de certificado que tenha sido pré-configurado e disponibilizado por um administrador da autoridade de certificação que processa a solicitação de certificado.

Utilizadores ou Administradores locais são a associação mínima de grupo necessária para concluir este procedimento.

  1. Abra o snap-in de Certificados para um computador.
  2. Na árvore de console, clique em Certificados (Computador Local). Selecione o armazenamento de certificados pessoal .
  3. No menu Ação , aponte para** Todas as Tarefas e clique em **Solicitar Novo Certificado para iniciar o assistente de Registro de Certificado. Clique em Avançar.
  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 Ative Directory (com base no modelo de autoridade de certificação que você configurou na seção anterior).
  6. Expanda a seção Detalhes e configure os seguintes itens.
  7. Certifique-se de que Utilização da chave inclui tanto Assinatura Digital como Cifragem de chave.
  8. Certifique-se de que as políticas de Aplicativo incluam a Autenticação do Servidor (1.3.6.1.5.5.7.3.1) e a Autenticação do Cliente (1.3.6.1.5.5.7.3.2).
  9. Clique em Propriedades.
  10. Na guia Assunto , em Nome do assunto, em Tipo, selecione Nome comum. Em Valor, especifique Ponto de extremidade REST do controlador de rede.
  11. Clique em Aplicar e, em seguida, clique em OK.
  12. Clique em Registrar.

Na Consola de Gestão Microsoft (MMC) de Certificados, clique em Armazenamento Pessoal para visualizar o certificado obtido da autoridade de certificação.

Exportar e copiar o certificado para a biblioteca do SCVMM

Depois de criar um certificado auto-assinado ou assinado pela CA, deve-se exportar o certificado com a chave privada (no formato .pfx) e sem a chave privada (no formato .cer Base-64) do snap-in Certificados.

Em seguida, você deve copiar os dois arquivos exportados para as pastas ServerCertificate.cr e NCCertificate.cr que você 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 na loja de certificados pessoais do computador local.
  2. Clique com o botão direito do rato no certificado, clique em Todas as Tarefas e, em seguida, clique em Exportar. O Assistente para Exportação de Certificados é aberto. Clique em Avançar.
  3. Selecione Sim, exportar a opção de chave privada, clique em Avançar.
  4. Escolha Troca de Informações Pessoais - PKCS #12 (.PFX) e aceite o padrão de 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, clique em Avançar.
  6. Na página Arquivo a ser exportado, procure o local onde deseja colocar o arquivo exportado e dê um nome a ele.
  7. Da mesma forma, exporte o certificado em . Formato CER. Nota: Para exportar para . CER format, desmarque a opção Sim, exportar a chave privada.
  8. Copie o arquivo . PFX para a pasta ServerCertificate.cr.
  9. Copie o arquivo . CER para a pasta NCCertificate.cr.

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

Autenticando dispositivos e serviços Southbound

A comunicação do controlador de rede com hosts e dispositivos SLB MUX usa certificados para autenticação. A comunicação com os hosts é feita pelo protocolo OVSDB, enquanto a comunicação com os dispositivos SLB MUX é feita pelo protocolo WCF.

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

Para comunicação com os hosts Hyper-V pelo OVSDB, o Controlador de Rede precisa apresentar um certificado para as máquinas host. Por padrão, o SCVMM captura o certificado SSL configurado no Controlador de Rede e utiliza-o para comunicação sul-bound com os hosts.

Essa é a razão pela qual o certificado SSL deve ter o EKU de Autenticação de Cliente configurado. Esse certificado é configurado no recurso REST "Servidores" (Hyper-V hosts são representados no Controlador de Rede como um recurso de Servidor) e pode ser exibido executando o comando Get-NetworkControllerServer do Windows PowerShell.

A seguir está 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"
          }
        ],

Para autenticação mútua, 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 Autoridade de Certificação (CA). Se um certificado baseado em CA não for encontrado na máquina host, o SCVMM criará um certificado autoassinado e o provisionará na máquina host.

O controlador de rede e os certificados de host Hyper-V devem ser confiáveis um pelo outro. O certificado raiz do host do Hyper-V deve estar presente no repositório de Autoridades de Certificação Raiz Confiáveis do Controlador de Rede para o Computador Local e vice-versa.

Quando estiveres a usar certificados autoassinados, o SCVMM garante que os certificados necessários estejam presentes no repositório das Autoridades de Certificação Raiz Confiáveis para o 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 armazenamento 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 Multiplexador de Balanceador de Carga de Software (MUX) e o Controlador de Rede se comunicam pelo protocolo WCF, usando certificados para autenticação.

Por padrão, o SCVMM obtém o certificado SSL configurado no Controlador de Rede e o utiliza para comunicação em direção sul com os dispositivos Mux. Esse certificado é configurado no recurso REST "NetworkControllerLoadBalancerMux" e pode ser exibido executando o cmdlet do PowerShell Get-NetworkControllerLoadBalancerMux.

Exemplo de recurso MUX REST (parcial):

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

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

Importante

Nos nós host e SLB, é fundamental que o armazenamento 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 para o sul falhará.

O Controlador de Rede e os certificados SLB MUX devem confiar mutuamente entre si (o certificado raiz do SLB MUX deve estar presente no armazenamento de Autoridades de Certificação Raiz Confiáveis da máquina do Controlador de Rede e vice-versa). Quando estiveres a usar certificados autoassinados, o SCVMM garante que os certificados necessários estejam presentes no repositório das Autoridades de Certificação Raiz Confiáveis para o Computador Local.