Partilhar via


O que são certificados na GPU do Azure Stack Edge Pro?

APLICA-SE A: Sim para Pro GPU SKUAzure Stack Edge Pro - GPUSim para Pro 2 SKUAzure Stack Edge Pro 2Sim para Pro R SKUAzure Stack Edge Pro RSim para Mini R SKUAzure Stack Edge Mini R

Este artigo descreve os tipos de certificados que podem ser instalados no seu dispositivo GPU Azure Stack Edge Pro. O artigo também inclui os detalhes para cada tipo de certificado.

Acerca de certificados

Um certificado fornece um link entre uma chave pública e uma entidade (como nome de domínio) que foi assinada (verificada) por um terceiro confiável (como uma autoridade de certificação). Um certificado fornece uma maneira conveniente de distribuir chaves de criptografia públicas confiáveis. Assim, os certificados garantem que sua comunicação seja confiável e que você esteja enviando informações criptografadas para o servidor certo.

Implantando certificados no dispositivo

Em seu dispositivo Azure Stack Edge, você pode usar os certificados autoassinados ou trazer seus próprios certificados.

Tipos de certificado

Os vários tipos de certificados que você pode trazer para o seu dispositivo são os seguintes:

  • Assinatura de certificados

    • AC de Raiz
    • Intermédio
  • Certificados de nó

  • Certificados de ponto final

    • Certificados do Azure Resource Manager
    • Certificados de armazenamento de Blob
  • Certificados de interface do usuário local

  • Certificados de dispositivo IoT

  • Certificados Kubernetes

    • Certificado de Registro de Contêiner de Borda
    • Certificado do painel do Kubernetes
  • Certificados Wi-Fi

  • Certificados VPN

  • Certificados de encriptação

    • Certificados de sessão de suporte

Cada tipo de certificado é descrito em detalhe nas secções seguintes.

Assinatura de certificados de cadeia

Estes são os certificados para a autoridade que assina os certificados ou a autoridade de certificação de assinatura.

Tipos

Esses certificados podem ser certificados raiz ou os certificados intermediários. Os certificados raiz são sempre autoassinados (ou assinados por si só). Os certificados intermediários não são autoassinados e são assinados pela autoridade de assinatura.

Limitações

  • Os certificados raiz devem ser certificados de cadeia de assinatura.
  • Os certificados raiz podem ser carregados no seu dispositivo no seguinte formato:
    • DER – Estes estão disponíveis como uma extensão de .cer arquivo.
    • Base-64 codificado – Estes estão disponíveis como .cer extensão de arquivo.
    • P7b – Este formato é usado apenas para assinar certificados de cadeia que inclui os certificados raiz e intermediários.
  • Os certificados da cadeia de assinatura são sempre carregados antes de carregar quaisquer outros certificados.

Certificados de nó

Todos os nós em seu dispositivo estão constantemente se comunicando uns com os outros e, portanto, precisam ter uma relação de confiança. Os certificados de nó fornecem uma maneira de estabelecer essa confiança. Os certificados de nó também entram em ação quando você está se conectando ao nó do dispositivo usando uma sessão remota do PowerShell por https.

Limitações

  • O certificado do nó deve ser fornecido em .pfx formato com uma chave privada que pode ser exportada.

  • Você pode criar e carregar 1 certificado de nó curinga ou 4 certificados de nó individual.

  • Um certificado de nó deve ser alterado se o domínio DNS for alterado, mas o nome do dispositivo não for alterado. Se você estiver trazendo seu próprio certificado de nó, então você não pode alterar o número de série do dispositivo, você só pode alterar o nome de domínio.

  • Use a tabela a seguir para guiá-lo ao criar um certificado de nó.

    Type Nome do assunto (SN) Nome alternativo da entidade (SAN) Exemplo de nome do assunto
    <NodeSerialNo>.<DnsDomain> *.<DnsDomain>

    <NodeSerialNo>.<DnsDomain>
    mydevice1.microsoftdatabox.com

Certificados de ponto final

Para quaisquer pontos de extremidade que o dispositivo expõe, um certificado é necessário para comunicação confiável. Os certificados de ponto de extremidade incluem aqueles necessários ao acessar o Gerenciador de Recursos do Azure e o armazenamento de blob por meio das APIs REST.

Quando você traz um certificado assinado por conta própria, você também precisa da cadeia de assinatura correspondente do certificado. Para a cadeia de assinatura, o Gerenciador de Recursos do Azure e os certificados de blob no dispositivo, você precisará dos certificados correspondentes na máquina cliente também para autenticar e se comunicar com o dispositivo.

Limitações

  • Os certificados de ponto de extremidade precisam estar em .pfx formato com uma chave privada. A cadeia de assinatura deve ser no formato DER (.cer extensão de arquivo).

  • Quando você traz seus próprios certificados de ponto de extremidade, eles podem ser como certificados individuais ou certificados de vários domínios.

  • Se você estiver trazendo a cadeia de assinatura, o certificado da cadeia de assinatura deverá ser carregado antes de carregar um certificado de ponto de extremidade.

  • Esses certificados devem ser alterados se o nome do dispositivo ou os nomes de domínio DNS forem alterados.

  • Um certificado de ponto de extremidade curinga pode ser usado.

  • As propriedades dos certificados de ponto de extremidade são semelhantes às de um certificado SSL típico.

  • Use a tabela a seguir ao criar um certificado de ponto de extremidade:

    Type Nome do assunto (SN) Nome alternativo da entidade (SAN) Exemplo de nome do assunto
    Azure Resource Manager management.<Device name>.<Dns Domain> login.<Device name>.<Dns Domain>
    management.<Device name>.<Dns Domain>
    management.mydevice1.microsoftdatabox.com
    Armazenamento de Blobs *.blob.<Device name>.<Dns Domain> *.blob.< Device name>.<Dns Domain> *.blob.mydevice1.microsoftdatabox.com
    Certificado único Multi-SAN para ambos os endpoints <Device name>.<dnsdomain> <Device name>.<dnsdomain>
    login.<Device name>.<Dns Domain>
    management.<Device name>.<Dns Domain>
    *.blob.<Device name>.<Dns Domain>
    mydevice1.microsoftdatabox.com

Certificados de interface do usuário local

Pode aceder à IU Web local do seu dispositivo através de um browser. Para garantir que esta comunicação é segura, pode carregar o seu próprio certificado.

Limitações

  • O certificado de interface do usuário local também é carregado em um .pfx formato com uma chave privada que pode ser exportada.

  • Depois de carregar o certificado de interface do usuário local, você precisará reiniciar o navegador e limpar o cache. Consulte as instruções específicas para o seu navegador.

    Type Nome do assunto (SN) Nome alternativo da entidade (SAN) Exemplo de nome do assunto
    Interface do usuário local <Device name>.<DnsDomain> <Device name>.<DnsDomain> mydevice1.microsoftdatabox.com

Certificados de dispositivo IoT Edge

Seu dispositivo também é um dispositivo IoT com a computação habilitada por um dispositivo IoT Edge conectado a ele. Para qualquer comunicação segura entre esse dispositivo IoT Edge e os dispositivos downstream que podem se conectar a ele, você também pode carregar certificados do IoT Edge.

O dispositivo tem certificados autoassinados que podem ser usados se você quiser usar apenas o cenário de computação com o dispositivo. Se, no entanto, o dispositivo estiver ligado a dispositivos a jusante, terá de trazer os seus próprios certificados.

Há três certificados do IoT Edge que você precisa instalar para habilitar essa relação de confiança:

  • Autoridade de certificação raiz ou a autoridade de certificação proprietária
  • Autoridade de certificação do dispositivo
  • Certificado de chave de dispositivo

Limitações

  • Os certificados do IoT Edge são carregados em .pem formato.

Para obter mais informações sobre certificados do IoT Edge, consulte Detalhes do certificado do Azure IoT Edge e Criar certificados de produção do IoT Edge.

Certificados Kubernetes

Os seguintes certificados Kubernetes podem ser usados com seu dispositivo Azure Stack Edge.

  • Certificado de Registro de Contêiner de Borda: Se seu dispositivo tiver um Registro de Contêiner de Borda, você precisará de um certificado de Registro de Contêiner de Borda para comunicação segura com o cliente que está acessando o Registro no dispositivo.
  • Certificado de ponto de extremidade do painel: você precisará de um certificado de ponto de extremidade do painel para acessar o painel do Kubernetes em seu dispositivo.

Limitações

  • O certificado do Registro de Contêiner de Borda deve:

    • Seja um certificado de formato PEM.
    • Conter o nome alternativo da entidade (SAN) ou CName (CN) do tipo: *.<endpoint suffix> ou ecr.<endpoint suffix>. Por exemplo: *.dbe-1d6phq2.microsoftdatabox.com OR ecr.dbe-1d6phq2.microsoftdatabox.com
  • O certificado do painel deve:

    • Seja um certificado de formato PEM.
    • Conter o nome alternativo da entidade (SAN) ou CName (CN) do tipo: *.<endpoint-suffix> ou kubernetes-dashboard.<endpoint-suffix>. Por exemplo: *.dbe-1d6phq2.microsoftdatabox.com ou kubernetes-dashboard.dbe-1d6phq2.microsoftdatabox.com.

Certificados VPN

Se a VPN (Point-to-site) estiver configurada no seu dispositivo, pode trazer o seu próprio certificado VPN para garantir que a comunicação é fidedigna. O certificado raiz é instalado no Gateway de VPN do Azure e os certificados de cliente são instalados em cada computador cliente que se conecta a uma rede virtual usando o Ponto a Site.

Limitações

  • O certificado VPN deve ser carregado como um formato .pfx com uma chave privada.
  • O certificado VPN não depende do nome do dispositivo, do número de série do dispositivo ou da configuração do dispositivo. Requer apenas o FQDN externo.
  • Certifique-se de que o OID do cliente está definido.

Para obter mais informações, consulte Gerar e exportar certificados para ponto a site usando o PowerShell.

Certificados Wi-Fi

Se o seu dispositivo estiver configurado para operar em uma rede sem fio WPA2-Enterprise, você também precisará de um certificado Wi-Fi para qualquer comunicação que ocorra pela rede sem fio.

Limitações

  • O certificado Wi-Fi deve ser carregado como um formato .pfx com uma chave privada.
  • Certifique-se de que o OID do cliente está definido.

Certificados de sessão de suporte

Se o seu dispositivo estiver enfrentando problemas, para solucionar esses problemas, uma sessão remota de Suporte do PowerShell poderá ser aberta no dispositivo. Para habilitar uma comunicação segura e criptografada nesta sessão de Suporte, você pode carregar um certificado.

Limitações

  • Certifique-se de que o certificado correspondente .pfx com chave privada está instalado na máquina cliente usando a ferramenta de desencriptação.

  • Verifique se o campo Uso da Chave do certificado não é Assinatura de Certificado. Para verificar isso, clique com o botão direito do mouse no certificado, escolha Abrir e, na guia Detalhes, localize Uso da chave.

  • O certificado de sessão de suporte deve ser fornecido no formato DER com uma .cer extensão.

Próximos passos

Analise os requisitos do certificado.