Gerir certificados para Redes Definidas pelo Software
Aplica-se a: Azure Stack HCI, versões 23H2 e 22H2; Windows Server 2022, Windows Server 2019, Windows Server 2016
Este artigo descreve como gerir certificados para comunicações de Northbound e Southbound do Controlador de Rede quando implementa Redes Definidas pelo Software (SDN) e quando utiliza o System Center Virtual Machine Manager (SCVMM) como cliente de gestão do SDN.
Nota
Para obter informações de descrição geral sobre o Controlador de Rede, veja Controlador de Rede.
Se não estiver a utilizar o Kerberos para proteger a comunicação do Controlador de Rede, pode utilizar certificados X.509 para autenticação, autorização e encriptação.
O SDN no Windows Server 2019 e 2016 Datacenter suporta certificados X.509 autoassinados e assinados pela Autoridade de Certificação (AC). Este tópico fornece instruções passo a passo para criar estes certificados e aplicá-los para proteger canais de comunicação northbound do Controlador de Rede com clientes de gestão e comunicações southbound com dispositivos de rede, como o Software Balanceador de Carga (SLB).
Quando utiliza a autenticação baseada em certificados, tem de inscrever um certificado nos nós do Controlador de Rede que é utilizado das seguintes formas.
- Encriptar a Comunicação de Northbound com sSL (Secure Sockets Layer) entre nós do Controlador de Rede e clientes de gestão, como System Center Virtual Machine Manager.
- Autenticação entre nós do Controlador de Rede e dispositivos e serviços southbound, como anfitriões Hyper-V e Balanceadores de Carga de Software (SLBs).
Criar e inscrever um certificado X.509
Pode criar e inscrever um certificado autoassinado ou um certificado emitido por uma AC.
Nota
Quando utiliza o SCVMM para implementar o Controlador de Rede, tem de especificar o certificado X.509 que é utilizado para encriptar as comunicações northbound durante a configuração do Modelo de Serviço do Controlador de Rede.
A configuração do certificado tem de incluir os seguintes valores.
- O valor da caixa de texto RestEndPoint tem de ser o Nome de Domínio Completamente Qualificado (FQDN) ou o endereço IP do Controlador de Rede.
- O valor RestEndPoint tem de corresponder ao nome do requerente (Nome Comum, CN) do certificado X.509.
Criar um certificado X.509 autoassinado
Pode criar um certificado X.509 autoassinado e exportá-lo com a chave privada (protegida por uma palavra-passe) ao seguir estes passos para implementações de nó único e de múltiplos nós do Controlador de Rede.
Quando cria certificados autoassinados, pode utilizar as seguintes diretrizes.
- Pode utilizar o endereço IP do Ponto Final REST do Controlador de Rede para o parâmetro DnsName , mas tal não é recomendado porque requer que os nós do Controlador de Rede estejam todos localizados numa única sub-rede de gestão (por exemplo, num único rack)
- Para implementações do Controlador de Rede de vários nós, o nome DNS que especificar passará a ser o FQDN do Cluster do Controlador de Rede (os registos DNS Host A são criados automaticamente.)
- Para implementações do Controlador de Rede de nó único, o nome DNS pode ser o nome de anfitrião do Controlador de Rede seguido do nome de domínio completo.
Múltiplos nós
Pode utilizar o comando New-SelfSignedCertificate Windows PowerShell para criar um certificado autoassinado.
Syntax
New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCRESTName>")
Utilização de exemplo
New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "MultiNodeNC" -DnsName @("NCCluster.Contoso.com")
Nó único
Pode utilizar o comando New-SelfSignedCertificate Windows PowerShell para criar um certificado autoassinado.
Syntax
New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "<YourNCComputerName>" -DnsName @("<NCFQDN>")
Utilização de exemplo
New-SelfSignedCertificate -KeyUsageProperty All -Provider "Microsoft Strong Cryptographic Provider" -FriendlyName "SingleNodeNC" -DnsName @("SingleNodeNC.Contoso.com")
Criar um certificado X.509 assinado pela AC
Para criar um certificado com uma AC, tem de já ter implementado uma Infraestrutura de Chaves Públicas (PKI) com os Serviços de Certificados do Active Directory (AD CS).
Nota
Pode utilizar as ACs ou ferramentas de terceiros, como openssl, para criar um certificado para utilização com o Controlador de Rede. No entanto, as instruções neste tópico são específicas do AD CS. Para saber como utilizar uma AC ou ferramenta de terceiros, veja a documentação do software que está a utilizar.
A criação de um certificado com uma AC inclui os seguintes passos.
- O Utilizador ou o Administrador de Segurança ou Domínio da sua organização configuram o modelo de certificado.
- O Administrador do Controlador de Rede ou o Administrador do SCVMM da sua organização solicitam um novo certificado à AC.
Requisitos de configuração de certificados
Enquanto configura um modelo de certificado no passo seguinte, certifique-se de que o modelo que configura inclui os seguintes elementos necessários.
- O nome do requerente do certificado tem de ser o FQDN do anfitrião Hyper-V
- O certificado tem de ser colocado no arquivo pessoal do computador local (My – cert:\localmachine\my)
- O certificado tem de ter Autenticação do 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) Políticas de aplicação.
Nota
Se o arquivo de certificados Pessoal (O Meu – cert:\localmachine\my) no anfitrião Hyper-V tiver mais de um certificado X.509 com Nome do Requerente (CN) como Nome de Domínio Completamente Qualificado (FQDN) do anfitrião, certifique-se de que o o certificado que será utilizado pelo SDN tem uma propriedade de Utilização de Chave Avançada personalizada adicional 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 anfitrião poderá não funcionar.
Para configurar o modelo de certificado
Nota
Antes de efetuar este procedimento, deve rever os requisitos de certificado e os modelos de certificado disponíveis na consola de Modelos de Certificado. Pode modificar um modelo existente ou criar um duplicado de um modelo existente e, em seguida, modificar a cópia do modelo. É recomendada a criação de uma cópia de um modelo existente.
- No servidor onde o AD CS está instalado, em Gestor de Servidor, clique em Ferramentas e, em seguida, clique em Autoridade de Certificação. Abre-se a consola de gestão do certificação autoridade Microsoft (MMC).
- Na MMC, faça duplo clique no nome de AC, faça duplo clique modelos de certificado, e, em seguida, clique em Gerir.
- Abre-se a consola de modelos de certificado. Todos os modelos de certificado são apresentados no painel de detalhes.
- No painel de detalhes, clique no modelo que pretende duplicar.
- Clique na ação menu e, em seguida, clique Duplicar modelo. O modelo Propriedades é aberta a caixa de diálogo.
- Na caixa de diálogo Propriedades do modelo, no separador Nome do Requerente , clique em Fornecer no pedido. (Esta definição é necessária para certificados SSL do Controlador de Rede.)
- Na caixa de diálogo Propriedades do modelo, no separador Processamento de Pedidos , certifique-se de que a opção Permitir a exportação da chave privada está selecionada. Certifique-se também de que a opção Assinatura e encriptação está selecionada.
- Na caixa de diálogo Propriedades do modelo, no separador Extensões , selecione Utilização da Chave e, em seguida, clique em Editar.
- Em Assinatura, certifique-se de que a Assinatura Digital está selecionada.
- Na caixa de diálogo Propriedades do modelo, no separador Extensões , selecione Políticas de Aplicação e, em seguida, clique em Editar.
- Em Políticas de Aplicação, certifique-se de que a Autenticação de Cliente e a Autenticação do Servidor estão listadas.
- Guarde a cópia do modelo de certificado com um nome exclusivo, como o modelo controlador de rede.
Para pedir um certificado à AC
Pode utilizar o snap-in Certificados para pedir certificados. Pode pedir qualquer tipo de certificado que tenha sido pré-configurado e disponibilizado por um administrador da AC que processe o pedido de certificado.
Os utilizadores ou administradores locais são a associação de grupo mínima necessária para concluir este procedimento.
- Abra o snap-in Certificados para um computador.
- Na árvore da consola, clique em Certificados (Computador Local). Selecione o arquivo de certificados Pessoal .
- No menu Ação , aponte para** Todas as Tarefas e, em seguida, clique em **Pedir Novo Certificado para iniciar o assistente de Inscrição de Certificados. Clique em Seguinte.
- Selecione a Política configurada pelo administrador de Inscrição de Certificados e clique em Seguinte.
- Selecione a Política de Inscrição do Active Directory (com base no modelo de AC que configurou na secção anterior).
- Expanda a secção Detalhes e configure os seguintes itens.
- Certifique-se de que a Utilização de chaves inclui a Assinatura Digital **e **Enciframentação de chaves.
- Certifique-se de que as políticas de Aplicação incluem Autenticação do Servidor (1.3.6.1.5.5.7.3.1) e Autenticação de Cliente (1.3.6.1.5.5.7.3.2).
- Clique em Propriedades.
- No separador Assunto , em Nome do requerente, em Tipo, selecione Nome comum. Em Valor, especifique o Ponto Final REST do Controlador de Rede.
- Clique em Aplicar e, em seguida, clique em OK.
- Clique em Inscrever.
No MMC certificados, clique no Arquivo pessoal para ver o certificado que inscreveu na AC.
Exportar e copiar o certificado para a biblioteca do SCVMM
Depois de criar um certificado autoassinado ou assinado por AC, tem de exportar o certificado com a chave privada (no formato .pfx) e sem a chave privada (no formato base-64 .cer) do snap-in Certificados.
Em seguida, tem de copiar os dois ficheiros exportados para as pastas ServerCertificate.cr e NCCertificate.cr que especificou no momento em que importou o Modelo de Serviço NC.
- Abra o snap-in Certificados (certlm.msc) e localize o certificado no arquivo de certificados Pessoal do computador local.
- Clique com o botão direito do rato no certificado, clique em Todas as Tarefas e, em seguida, clique em Exportar. O Assistente de Exportação de Certificados é aberto. Clique em Seguinte.
- Selecione Sim, exporte a opção de chave privada e clique em Seguinte.
- Selecione Troca de Informações Pessoais - PKCS n.º 12 (. PFX) e aceite a predefinição incluir todos os certificados no caminho de certificação, se possível.
- Atribua os Utilizadores/Grupos e uma palavra-passe para o certificado que está a exportar, clique em Seguinte.
- Na página Ficheiro a exportar, procure a localização onde pretende colocar o ficheiro exportado e atribua-lhe um nome.
- Da mesma forma, exporte o certificado em . Formato CER. Nota: para exportar para o formato .CER, desmarque a opção Sim, exportar a chave privada.
- Copie o .PFX para a pasta ServerCertificate.cr.
- Copie o ficheiro .CER para a pasta NCCertificate.cr.
Quando terminar, atualize estas pastas na Biblioteca do SCVMM e certifique-se de que tem estes certificados copiados. Continue com a Configuração e Implementação do Modelo de Serviço do Controlador de Rede.
Autenticar dispositivos e serviços southbound
A comunicação do Controlador de Rede com anfitriões e dispositivos SLB MUX utiliza certificados para autenticação. A comunicação com os anfitriões é através do protocolo OVSDB enquanto a comunicação com os dispositivos SLB MUX é através do protocolo WCF.
Comunicação do anfitrião Hyper-V com o Controlador de Rede
Para a comunicação com os anfitriões Hyper-V através de OVSDB, o Controlador de Rede tem de apresentar um certificado aos computadores anfitriões. Por predefinição, o SCVMM recolhe o certificado SSL configurado no Controlador de Rede e utiliza-o para comunicação para sul com os anfitriões.
Este é o motivo pelo qual o certificado SSL tem de ter o EKU de Autenticação de Cliente configurado. Este certificado está configurado no recurso REST "Servidores" (os anfitriões Hyper-V são representados no Controlador de Rede como um recurso do Servidor) e pode ser visualizado ao executar o comando de Windows PowerShell Get-NetworkControllerServer.
Segue-se 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 a autenticação mútua, o anfitrião Hyper-V também tem de ter um certificado para comunicar com o Controlador de Rede.
Pode inscrever o certificado a partir de uma Autoridade de Certificação (AC). Se não for encontrado um certificado baseado em AC no computador anfitrião, o SCVMM cria um certificado autoassinado e aprovisiona-o no computador anfitrião.
O Controlador de Rede e os certificados de anfitrião Hyper-V têm de ser considerados fidedignos entre si. O certificado de raiz do certificado de anfitrião Hyper-V tem de estar presente no arquivo Autoridades de Certificação de Raiz Fidedigna do Controlador de Rede para o Computador Local e vice-versa.
Quando estiver a utilizar certificados autoassinados, o SCVMM garante que os certificados necessários estão presentes no arquivo de Autoridades de Certificação de Raiz Fidedigna do Computador Local.
Se utilizar certificados baseados em AC para os anfitriões Hyper-V, tem de garantir que o certificado de raiz da AC está presente no arquivo de Autoridades de Certificação de Raiz Fidedigna do Controlador de Rede para o Computador Local.
Software Balanceador de Carga comunicação MUX com o Controlador de Rede
O Software Balanceador de Carga Multiplexor (MUX) e o Controlador de Rede comunicam através do protocolo WCF, utilizando certificados para autenticação.
Por predefinição, o SCVMM recolhe o certificado SSL configurado no Controlador de Rede e utiliza-o para comunicação para sul com os dispositivos Mux. Este certificado está configurado no recurso REST "NetworkControllerLoadBalancerMux" e pode ser visualizado ao executar o cmdlet do PowerShell Get-NetworkControllerLoadBalancerMux.
Exemplo de recurso REST MUX (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, também tem de ter um certificado nos dispositivos SLB MUX. Este certificado é configurado automaticamente pelo SCVMM quando implementa o balanceador de carga de software com o SCVMM.
Importante
Nos nós anfitrião e SLB, é fundamental que o arquivo de certificados das Autoridades de Certificação de Raiz Fidedigna não inclua nenhum certificado em que "Emitido para" não seja o mesmo que "Emitido por". Se isto ocorrer, a comunicação entre o Controlador de Rede e o dispositivo de direção sul falha.
O Controlador de Rede e os certificados SLB MUX têm de ser considerados fidedignos entre si (o certificado de raiz do certificado SLB MUX tem de estar presente no arquivo de Autoridades de Certificação de Raiz Fidedigna do computador controlador de rede e vice-versa). Quando estiver a utilizar certificados autoassinados, o SCVMM garante que os certificados necessários estão presentes no arquivo de Autoridades de Certificação de Raiz Fidedigna do Computador Local.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários