Gerenciar certificados de Redes Definidas por 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 gerenciar certificados para comunicações northbound e southbound do controlador de rede ao implantar o SDN (Rede Definida pelo Software) e quando você usa System Center Virtual Machine Manager (SCVMM) 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 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 em nós do Controlador de Rede usados das seguintes maneiras.
- Criptografia da comunicação Northbound com SSL (Secure Sockets Layer) entre os nós do Controlador de Rede e os clientes de gerenciamento, como o System Center Virtual Machine Manager.
- Autenticação entre os nós do Controlador de Rede e os dispositivos e serviços Southbound, como os hosts Hyper-V e os 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 norte 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 da entidade (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 do Controlador de Rede de vários nós, o nome DNS especificado se tornará o FQDN do Cluster do Controlador de Rede (os registros do Host A do 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 completo do domínio.
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 AC
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 AC ou ferramenta de terceiros, consulte a documentação do software que você está usando.
Veja abaixo, as etapas para criar um certificado usando uma AC.
- Você ou o Administrador de Segurança ou Domínio da sua organização configura o modelo de certificado.
- Você ou o Administrador do Controlador de Rede da sua organização ou o Administrador do SCVMM pode solicitar um novo certificado para a AC.
Requisitos de configuração do certificado
Ao configurar um modelo de certificado na próxima etapa, verifique se o modelo configurado inclui os seguintes elementos necessários.
- O nome da entidade do certificado deve ser o FQDN do host Hyper-V.
- O certificado deve ser colocado no repositório pessoal do computador local (My – cert:\localmachine\my).
- 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 repositório pessoal de certificados (My – cert:\localmachine\my) no host Hyper-V tiver mais de um certificado X.509 com o Nome de Entidade (CN) como o FQDN (Nome de Domínio Totalmente Qualificado) do host, verifique se o certificado usado pelo SDN tem uma propriedade personalizada de Uso de Chave Aprimorado com 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 copiar um modelo existente e alterar a cópia. Recomenda-se criar uma cópia de um modelo existente.
- 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.
- 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.
- O console de Modelos de Certificado é aberto. Todos os modelos de certificado são exibidos no painel de detalhes.
- No painel de detalhes, clique no modelo que você deseja copiar.
- Clique no menu Ação e em Duplicar Modelo. A caixa de diálogo Propriedades do modelo é aberta.
- 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.)
- 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.
- Na caixa de diálogo Propriedades do modelo, na guia Extensões, selecione Uso de chave e clique em Editar.
- Em Assinatura, verifique se Assinatura Digital está selecionada.
- Na caixa de diálogo Propriedades do modelo, na guia Extensões, selecione Políticas de Aplicativo e clique em Editar.
- Em Políticas de Aplicativo, verifique se a Autenticação de Cliente e a Autenticação de Servidor estão na lista.
- Salve a cópia do modelo de certificado com um nome exclusivo, como por exemplo, Modelo de Controlador de Rede.
Para solicitar um certificado para a AC
Use 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.
- Abra o snap-in de Certificados para computador.
- Na árvore do console, clique em Certificados (Computador Local). Selecione o repositório de certificados Pessoal.
- 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.
- Selecione a Política de Registro de Certificado Configurada pelo administrador e clique em Avançar.
- Selecione a Política de Registro do Active Directory (com base no modelo da AC configurado na seção anterior).
- Expanda a seção Detalhes e configure os itens abaixo.
- Verifique se o Uso da chave inclui a Assinatura digital **e a **Criptografia de chave.
- 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).
- Clique em Propriedades.
- Na guia Entidade, no campo Nome da entidade em Tipo, selecione Nome comum. Em Valor, especifique Ponto de extremidade REST do Controlador de Rede.
- Clique em Aplicar e em OK.
- Clique em Registrar.
No MMC de Certificados, clique no repositório Pessoal para exibir o certificado da AC que você registrou.
Exportar e copiar o certificado para a biblioteca do SCVMM
Após 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.
- Abra o snap-in de Certificados (certlm.msc) e localize o certificado no repositório de certificados Pessoal do computador local.
- 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.
- Escolha a opção Sim, exportar a chave privada e clique em Avançar.
- 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.
- Atribua os Usuários/Grupos e uma senha para o certificado que você está exportando, clique em Avançar.
- Na página Arquivo para exportar, procure o local em que você deseja colocar o arquivo exportado e nomeá-lo.
- 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.
- Copie o. PFX para a pasta ServerCertificate.cr.
- Copiar o arquivo .CER para a pasta NCCertificate.cr.
Quando terminar, atualize essas pastas na Biblioteca SCVMM e verifique se você tem esses certificados 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 de host do 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 AC não for encontrado no computador host, o SCVMM criará um certificado autoassinado e o provisionará no computador host.
O Controlador de Rede e o host Hyper-V devem validar o certificado um do outro. O certificado raiz do certificado do host Hyper-V deve estar presente no repositório das Autoridades de Certificação Raiz de Confiança do Controlador de Rede no Computador local e vice-versa.
Ao usar certificados autoassinados, o SCVMM garante que os certificados necessários estejam presentes no Computador local, no repositório das Autoridades de Certificação Raiz de Confiança.
Se você usar certificados baseados em AC para os hosts Hyper-V, precisará garantir que o certificado raiz da AC esteja presente no repositório Autoridades de Certificação Raiz Confiáveis do Controlador de Rede para o Computador Local.
Comunicação de software Load Balancer MUX 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
No host e nos nós SLB, é fundamental que o repositório de certificados autoridades de certificação raiz confiáveis não inclua nenhum certificado no qual "Emitido" 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 MUX SLB devem ser validados um pelo outro (o certificado raiz do certificado do MUX SLB deve estar presente no repositório das Autoridades de Certificação Raiz de Confiança do computador do Controlador de Rede e vice-versa). Ao usar certificados autoassinados, o SCVMM garante que os certificados necessários estejam presentes no Computador local, no repositório das Autoridades de Certificação Raiz de Confiança.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de