Entenda como o Azure IoT Edge usa certificados

Aplica-se a: IoT Edge 1.4

Importante

A versão com suporte é a IoT Edge 1.4. Se você estiver em uma versão anterior, confira Atualizar o IoT Edge.

O IoT Edge usa diferentes tipos de certificados para diferentes finalidades. Este artigo descreve as diferentes maneiras pelas quais o IoT Edge usa certificados com os cenários de gateway do Hub IoT do Azure e do IoT Edge.

Importante

Para resumir, este artigo se aplica ao IoT Edge versão 1.2 ou posterior. Os conceitos de certificado da versão 1.1 são semelhantes, mas há algumas diferenças:

• O Certificado de Autoridade de Certificação do dispositivo da versão 1.1 foi renomeado para Certificado de Autoridade de Certificação do Edge.
• O Certificado de Autoridade de Certificação da carga de trabalho da versão 1.1 foi desativado. Na versão 1.2 ou posterior, o runtime do módulo do IoT Edge gera todos os certificados do servidor diretamente do Certificado de Autoridade de Certificação do Edge, sem o Certificado de Autoridade de Certificação da carga de trabalho intermediário entre eles na cadeia de certificados.

Resumo

Esses principais cenários são os locais em que o IoT Edge usa certificados. Use os links para saber mais sobre cada cenário.

Ator	Finalidade	Certificado
IoT Edge	Verifica se ele está se comunicando com o Hub IoT certo	Certificado do servidor do Hub IoT
Hub IoT	Verifica se a solicitação é proveniente de um dispositivo IoT Edge legítimo	Certificado de identidade do IoT Edge
Dispositivo IoT downstream	Verifica se ele está se comunicando com o gateway do IoT Edge certo	Certificado do servidor do módulo edgeHub do Hub do IoT Edge, emitido pela AC do Edge
IoT Edge	Assina os novos certificados do servidor do módulo. Por exemplo, edgeHub	Certificado de Autoridade de Certificação de borda
IoT Edge	Verifica se a solicitação é proveniente de um dispositivo downstream legítimo	Certificado de identidade do dispositivo IoT

Pré-requisitos

• Você deve ter uma compreensão básica da criptografia por chave pública, dos pares de chaves e de como uma chave pública e uma chave privada podem criptografar ou descriptografar dados. Para obter mais informações sobre como o IoT Edge usa a criptografia por chave pública, confira Noções básicas sobre a criptografia por chave pública e a infraestrutura de chave pública X.509.
• Você deve ter uma compreensão básica sobre como o IoT Edge se relaciona com o Hub IoT. Para obter mais informações, confira Noções básicas sobre o runtime e a arquitetura do Azure IoT Edge.

Cenário de dispositivo individual

Para ajudar a entender os conceitos de certificado do IoT Edge, imagine um cenário em que um dispositivo IoT Edge chamado EdgeGateway se conecta a um Hub IoT do Azure chamado ContosoIotHub. Neste exemplo, toda a autenticação é feita com a autenticação de certificado X.509 em vez de chaves simétricas. Para estabelecer a relação de confiança nesse cenário, precisamos garantir que o Hub IoT e o dispositivo IoT Edge sejam autênticos: "Este dispositivo é genuíno e válido?" e "A identidade do Hub IoT está correta?". O cenário pode ser ilustrado da seguinte maneira:

Explicaremos as respostas para cada pergunta e, em seguida, expandiremos o exemplo nas próximas seções do artigo.

O dispositivo verifica a identidade do Hub IoT

Como o EdgeGateway verifica se ele está se comunicando com o ContosoIotHub autêntico? Quando o EdgeGateway quer se comunicar com a nuvem, ele se conecta ao ponto de extremidade ContosoIoTHub.Azure-devices.NET. Para verificar se o ponto de extremidade é autêntico, o IoT Edge precisa do ContosoIoTHub para mostrar a ID (identificação). A ID precisa ser emitida por uma autoridade em que o EdgeGateway confia. Para verificar a identidade do Hub IoT, o IoT Edge e o Hub IoT usam o protocolo de handshake TLS para verificar a identidade do servidor do Hub IoT. Um handshake TLS é ilustrado no diagrama a seguir. Para manter o exemplo simples, alguns detalhes foram omitidos. Para saber mais sobre o protocolo de handshake TLS, confira Handshake TLS na Wikipédia.

Observação

Neste exemplo, ContosoIoTHub representa o nome do host do Hub IoT ContosoIotHub.Azure-devices.NET.

Nesse contexto, você não precisa saber os detalhes exatos do algoritmo de criptografia. É importante entender que o algoritmo garante que o servidor tenha a chave privada emparelhada com a chave pública. Ele verifica se o apresentador do certificado não o copiou nem o roubou. Se usarmos uma ID de foto como exemplo, seu rosto corresponderá à foto na ID. Se alguém roubar sua ID, ele não poderá usá-la para identificação, porque seu rosto é exclusivo e difícil de ser reproduzido. Para as chaves criptográficas, o par de chaves é relacionado e exclusivo. Em vez de corresponder um rosto a uma ID de foto, o algoritmo de criptografia usa o par de chaves para verificar a identidade.

Em nosso cenário, o ContosoIotHub mostra a seguinte cadeia de certificados:

A AC (autoridade de certificação) raiz é o certificado Baltimore CyberTrust Root. Esse certificado raiz é assinado pela DigiCert e é amplamente confiável e armazenado em muitos sistemas operacionais. Por exemplo, o Ubuntu e o Windows o incluem no repositório de certificados padrão.

Repositório de certificados do Windows:

Repositório de certificados do Ubuntu:

Quando um dispositivo verifica a existência do certificado Baltimore CyberTrust Root, ele é pré-instalado no sistema operacional. Do ponto de vista do EdgeGateway, como a cadeia de certificados apresentada pelo ContosoIotHub é assinada por uma AC raiz em que o sistema operacional confia, o certificado é considerado confiável. O certificado é conhecido como certificado do servidor do Hub IoT. Para saber mais sobre o certificado do servidor do Hub IoT, confira Suporte ao protocolo TLS no Hub IoT.

Em resumo, o EdgeGateway pode verificar a identidade do ContosoIotHub e confiar nela porque:

• O ContosoIotHub apresenta o certificado do servidor do Hub IoT
• O certificado do servidor é confiável no repositório de certificados do sistema operacional
• Os dados criptografados com a chave pública do ContosoIotHub podem ser descriptografados pelo ContosoIotHub, provando a posse da chave privada

O Hub IoT verifica a identidade do dispositivo IoT Edge

Como o ContosoIotHub verifica se ele está se comunicando com o EdgeGateway? Como Hub IoT dá suporte ao TLS mútuo (mTLS), ele verifica o certificado do EdgeGateway durante o handshake TLS autenticado pelo cliente. Para simplificar, vamos ignorar algumas etapas no diagrama a seguir.

Nesse caso, o EdgeGateway fornece o certificado de identidade do dispositivo IoT Edge. Da perspectiva ContosoIotHub, ele verifica se a impressão digital do certificado fornecido corresponde ao registro e se EdgeGateway tem a chave privada emparelhada com o certificado que ele apresentou. Ao provisionar um dispositivo IoT Edge no Hub IoT, você fornece uma impressão digital. A impressão digital é o que o Hub IoT usa para verificar o certificado.

Dica

O Hub IoT requer duas impressões digitais ao registrar um dispositivo IoT Edge. Uma prática recomendada é preparar dois certificados de identidade de dispositivo diferentes com datas de expiração diferentes. Dessa forma, se um certificado vencer, o outro ainda será válido e dará tempo para girar o certificado vencido. No entanto, também é possível usar apenas um certificado para registro. Use um único certificado definindo a mesma impressão digital do certificado para as impressões digitais primária e secundária ao registrar o dispositivo.

Por exemplo, podemos usar o seguinte comando para obter a impressão digital do certificado da identidade no EdgeGateway:

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

O comando gera a impressão digital do certificado SHA256:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

Se visualizarmos o valor da impressão digital SHA256 para o dispositivo EdgeGateway registrado no Hub IoT, poderemos ver que ele corresponde à impressão digital no EdgeGateway:

Em resumo, o ContosoIotHub pode confiar no EdgeGateway porque o EdgeGateway apresenta um certificado de identidade do dispositivo IoT Edge válido cuja impressão digital corresponde à registrada no Hub IoT.

Para obter mais informações sobre o processo de criação de certificados, consulte Criar e provisionar um dispositivo IoT Edge no Linux usando certificados X.509.

Observação

Este exemplo não aborda o DPS (Serviço de Provisionamento de Dispositivos) no Hub IoT do Azure, que tem suporte para a autenticação de AC X.509 com o IoT Edge quando provisionado com um grupo de registro. Usando o DPS, você carrega o Certificado de Autoridade de Certificação ou um certificado intermediário, a cadeia de certificados é verificada e, em seguida, o dispositivo é provisionado. Para saber mais, confira Atestado de certificado X.509 do DPS.

No Portal do Azure, o DPS exibe a impressão digital SHA1 para o certificado em vez da impressão digital SHA256.

O DPS registra ou atualiza a impressão digital SHA256 para o Hub IoT. Verifique a impressão digital usando o comando openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. Depois de registrado, o IoT Edge usa a autenticação de impressão digital com o Hub IoT. Se o dispositivo for provisionado novamente e um novo certificado for emitido, o DPS atualizará o Hub IoT com a nova impressão digital.

Atualmente, o Hub IoT não dá suporte à autenticação de AC X.509 diretamente com o IoT Edge.

Uso de certificado para operações de identidade do módulo

Nos diagramas de verificação de certificado, pode parecer que o IoT Edge usa apenas o certificado para se comunicar com o Hub IoT. O IoT Edge consiste em vários módulos. Como resultado, o IoT Edge usa o certificado para gerenciar identidades de módulo para os módulos que enviam mensagens. Os módulos não usam o certificado para se autenticar no Hub IoT, mas usam chaves SAS derivadas da chave privada gerada pelo runtime do módulo do IoT Edge. Essas chaves SAS não serão alteradas mesmo que o certificado de identidade do dispositivo vencer. Se o certificado vencer, o edgeHub, por exemplo, continuará sendo executado e somente as operações de identidade do módulo falharão.

A interação entre os módulos e o Hub IoT é segura, porque a chave SAS é derivada de um segredo e o IoT Edge gerencia a chave sem o risco de intervenção humana.

Cenário de hierarquia de dispositivo aninhado com o IoT Edge como o gateway

Agora você tem uma boa compreensão de uma simples interação entre o IoT Edge e o Hub IoT. No entanto, o IoT Edge também pode funcionar como um gateway para os dispositivos downstream ou outros dispositivos IoT Edge. Esses canais de comunicação também precisam ser criptografados e confiáveis. Devido à complexidade adicional, precisamos expandir nosso cenário de exemplos para incluir um dispositivo downstream.

Adicionamos um dispositivo IoT comum chamado TempSensor, que se conecta ao dispositivo IoT Edge pai EdgeGateway que se conecta ao Hub IoT ContosoIotHub. Semelhante a antes, toda a autenticação é feita com a autenticação de certificado X.509. Nosso novo cenário gera duas novas questões: "O dispositivo TempSensor é legítimo?" e "A identidade do EdgeGateway está correta?". O cenário pode ser ilustrado da seguinte maneira:

Dica

O TempSensor é um dispositivo IoT no cenário. O conceito de certificado será o mesmo se o TempSensor for um dispositivo IoT Edge downstream do EdgeGateway pai.

O dispositivo verifica a identidade do gateway

Como o TempSensor verifica se ele está se comunicando com o EdgeGateway original? Quando o TempSensor quer se comunicar com o EdgeGateway, o TempSensor precisa do EdgeGateway para mostrar uma ID. A ID precisa ser emitida por uma autoridade em que o TempSensor confia.

O fluxo é o mesmo de quando o EdgeGateway se comunica com o ContosoIotHub. O TempSensor e o EdgeGateway usam o protocolo de handshake TLS para verificar a identidade do EdgeGateway. Há dois detalhes importantes:

• Especificidade do nome do host: o certificado apresentado pelo EdgeGateway precisa ser emitido para o mesmo nome do host (domínio ou endereço IP) usado pelo TempSensor para se conectar ao EdgeGateway.
• Especificidade da AC raiz autoassinada: a cadeia de certificados apresentada pelo EdgeGateway provavelmente não está no repositório raiz confiável padrão do sistema operacional.

Para entender os detalhes, primeiro, vamos examinar a cadeia de certificados apresentada pelo EdgeGateway.

Especificidade do nome do host

O nome comum do certificado CN = edgegateway.local está listado no início da cadeia. edgegateway.local é o nome comum do certificado de servidor do edgeHub. edgegateway.local também é o nome do host para EdgeGateway na rede local (LAN ou VNet) onde o TempSensor e o EdgeGateway estão conectados. Pode ser um endereço IP privado, como 192.168.1.23, ou um nome de domínio totalmente qualificado (FQDN), como o diagrama. O certificado do servidor edgeHub é gerado usando o parâmetro hostname definido no arquivo config.toml do IoT Edge. Não confunda o certificado do servidor edgeHub com o certificado da CA de Borda. Para obter mais informações sobre como gerenciar o certificado de autoridade de certificação de Borda, consulte Gerenciar certificados de borda do IoT.

Quando o TempSensor se conecta ao EdgeGateway, o TempSensor usa o nome de host edgegateway.local para se conectar ao EdgeGateway. O TempSensor verifica o certificado apresentado pelo EdgeGateway e verifica se o nome comum do certificado é edgegateway.local. Se o nome comum do certificado for diferente, o TempSensor rejeitará a conexão.

Observação

Para simplificar, o exemplo mostra o CN (nome comum) do certificado da entidade como uma propriedade validada. Na prática, se um certificado tiver um SAN (nome alternativo da entidade), o SAN será validado em vez do CN. Geralmente, como a SAN pode conter vários valores, ela tem o domínio/o nome do host principal do titular do certificado, bem como todos os domínios alternativos.

Por que o EdgeGateway precisa ser informado sobre o respectivo nome do host?

O EdgeGateway não tem uma forma confiável de saber como outros clientes na rede podem se conectar a ele. Por exemplo, em uma rede privada, pode haver servidores DHCP ou serviços mDNS que listam o EdgeGateway como 10.0.0.2 ou example-mdns-hostname.local. No entanto, algumas redes podem ter servidores DNS que mapeiam edgegateway.local para o endereço IP 10.0.0.2 do EdgeGateway.

Para resolver o problema, o IoT Edge usa o valor de nome do host configurado em config.toml e cria um certificado do servidor para ele. Quando uma solicitação chega ao módulo edgeHub, ela apresenta o certificado com o CN (nome comum) do certificado correto.

Por que o IoT Edge cria certificados?

No exemplo, observe que há um iotedged workload ca edgegateway na cadeia de certificados. É a AC (autoridade de certificação) que existe no dispositivo IoT Edge conhecida como AC do Edge (antiga AC do Dispositivo na versão 1.1). Assim como a AC raiz do Baltimore CyberTrust no exemplo anterior, a AC do Edge pode emitir outros certificados. E o mais importante: também neste exemplo, ela emite o certificado do servidor para o módulo edgeHub. No entanto, ela também pode emitir certificados para outros módulos em execução no dispositivo IoT Edge.

Importante

Por padrão, sem configuração, a AC do Edge é gerada automaticamente pelo runtime do módulo do IoT Edge quando é iniciada pela primeira vez, conhecida como AC do Edge de início rápido, e emite um certificado para o módulo edgeHub. Esse processo acelera a conexão do dispositivo downstream, permitindo que o edgeHub apresente um certificado válido assinado. Sem esse recurso, você precisaria fazer com que a AC emitisse um certificado para o módulo edgeHub. Não há suporte para o uso em produção de uma AC do Edge de início rápido gerada automaticamente. Para obter mais informações sobre a AC do Edge de início rápido, confira AC do Edge de início rápido.

Não é perigoso ter um certificado do emissor no dispositivo?

A AC do Edge foi projetada para habilitar soluções com conectividade limitada, não confiável, cara ou ausente, mas ao mesmo tempo que tem regulamentações ou políticas estritas sobre as renovações do certificado. Sem a AC do Edge, o IoT Edge (e em particular, o edgeHub) não podem funcionar.

Para proteger a AC do Edge em produção:

• Coloque a chave privada do EdgeCA em um TPM (Trusted Platform Module), preferencialmente, de uma forma em que a chave privada seja gerada de modo efêmero e nunca saia do TPM.
• Use uma PKI (infraestrutura de chave pública) para a qual a AC do Edge é acumulada. Isso fornece a capacidade de desabilitar ou recusar a renovação dos certificados comprometidos. A PKI poderá ser gerenciada pela TI do cliente se ela tiver o conhecimento sobre como fazer isso (menor custo) ou por meio de um provedor de PKI comercial.

Especificidade de AC raiz autoassinada

O módulo edgeHub é um componente importante que compõe o IoT Edge processando todo o tráfego de entrada. Neste exemplo, ele usa um certificado emitido pela AC do Edge, que, por sua vez, é emitido por uma AC raiz autoassinada. Como a AC raiz não é confiável para o sistema operacional, a única maneira de o TempSensor confiar nela é instalar o Certificado de Autoridade de Certificação no dispositivo. Isso também é conhecido como o cenário de pacote de relação de confiança, em que você precisa distribuir a raiz para os clientes que precisam confiar na cadeia. O cenário de pacote de relação de confiança pode ser problemático porque você precisa acessar o dispositivo e instalar o certificado. A instalação do certificado exige planejamento. Isso pode ser feito com scripts, adicionados durante a fabricação ou pré-instalados na imagem do sistema operacional.

Observação

Alguns clientes e SDKs não usam o repositório raiz confiável do sistema operacional, e você precisa transmitir o arquivo da AC raiz diretamente.

Aplicando todos esses conceitos, o TempSensor pode verificar se ele está se comunicando com o EdgeGateway original, porque ele apresentou um certificado que correspondia ao endereço e o certificado é assinado por uma raiz confiável.

Para verificar a cadeia de certificados, você pode usar o openssl no dispositivo do TempSensor. Neste exemplo, observe que o nome do host para conexão corresponde à CN do certificado de profundidade 0 e que a AC raiz é correspondente.

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

Para saber mais sobre o comando openssl, confira a documentação do OpenSSL.

Inspecione também os certificados em que eles são armazenados por padrão em /var/lib/aziot/certd/certs. Encontre os certificados da AC do Edge, os certificados de identidade do dispositivo e os certificados do módulo no diretório. Use os comandos openssl x509 para inspecionar os certificados. Por exemplo:

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

Em resumo, o TempSensor pode confiar no EdgeGateway porque:

• O módulo edgeHub mostrou um certificado do servidor do módulo do IoT Edge válido para edgegateway.local
• O certificado é emitido pela AC do Edge, que é emitida por my_private_root_CA
• Essa AC raiz privada também é armazenada no TempSensor como a AC raiz confiável anteriormente
• Os algoritmos de criptografia verificam se a cadeia de propriedade e de emissão pode ser confiável

Certificados para outros módulos

Outros módulos podem obter os certificados do servidor emitidos pela AC do Edge. Por exemplo, um módulo do Grafana que tem uma interface da Web. Ele também pode obter um certificado da AC do Edge. Os módulos são tratados como dispositivos downstream hospedados no contêiner. No entanto, a capacidade de obter um certificado do runtime do módulo do IoT Edge é um privilégio especial. Os módulos chamam a API de carga de trabalho para receber o certificado do servidor encadeado para a AC do Edge configurada.

O gateway verifica a identidade do dispositivo

Como o EdgeGateway verifica se ele está se comunicando com o TempSensor? O EdgeGateway usa a autenticação de cliente TLS para autenticar o TempSensor.

A sequência é semelhante ao ContosoIotHub verificando um dispositivo. No entanto, em um cenário de gateway, o EdgeGateway depende do ContosoIotHub como a fonte de verdade para o registro dos certificados. O EdgeGateway também mantém uma cópia ou um cache offline caso não haja nenhuma conexão com a nuvem.

Dica

Ao contrário dos dispositivos IoT Edge, os dispositivos IoT downstream não se limitam à autenticação X.509 da impressão digital. A autenticação da AC X.509 também é uma opção. Em vez de apenas procurar uma correspondência na impressão digital, o EdgeGateway também pode verificar se o certificado do TempSensor tem a raiz em uma AC que foi carregada no ContosoIotHub.

Em resumo, o EdgeGateway pode confiar no TempSensor porque:

• O TempSensor apresentou um certificado de identidade do dispositivo IoT válido para o nome
• A impressão digital do certificado de identidade corresponde àquela carregada no ContosoIotHub
• Os algoritmos de criptografia verificam se a cadeia de propriedade e de emissão pode ser confiável

Local de obtenção dos certificados e do gerenciamento

Na maioria dos casos, você pode fornecer certificados próprios ou usar certificados gerados automaticamente. Por exemplo, a AC do Edge e o certificado edgeHub são gerados automaticamente.

No entanto, a melhor prática é configurar seus dispositivos para usar um servidor EST (Registro por Transporte Seguro) para gerenciar os certificados X.509. O uso de um servidor EST libera você de processar manualmente os certificados e instalá-los nos dispositivos. Para obter mais informações sobre como usar um servidor EST, confira Configurar o Servidor de Registro por Transporte Seguro para o Azure IoT Edge.

Use também certificados para autenticação no servidor EST. Esses certificados são usados para autenticação nos servidores EST para emissão de outros certificados. O serviço de certificado usa um certificado de inicialização para autenticação em um servidor EST. O certificado de inicialização é de longa duração. Após a autenticação inicial, o serviço de certificado faz uma solicitação ao servidor EST para emitir um certificado de identidade. Esse certificado de identidade é usado nas solicitações EST futuras para o mesmo servidor.

Se você não puder usar um servidor EST, deverá solicitar certificados do provedor de PKI. Você pode gerenciar os arquivos de certificado manualmente no Hub IoT e nos seus dispositivos IoT Edge. Para obter mais informações, confira Gerenciar certificados em um dispositivo IoT Edge.

Para o desenvolvimento de prova de conceito, você pode criar certificados de teste. Para obter mais informações, confira Criar certificados de demonstração para testar recursos do dispositivo IoT Edge.

Certificados na IoT

Autoridade de certificação

A AC (autoridade de certificação) é uma entidade que emite certificados digitais. Uma autoridade de certificação atua como um terceiro confiável entre o proprietário e o destinatário do certificado. Um certificado digital certifica a propriedade de uma chave pública pelo destinatário do certificado. A cadeia de certificados de confiança funciona inicialmente emitindo um certificado raiz, que é a base da confiança em todos os certificados emitidos pela autoridade. Em seguida, o proprietário do certificado raiz pode emitir certificados intermediários adicionais (certificados de dispositivo downstream).

Certificado de AC raiz

Um certificado CA raiz é a raiz da confiança de todo o processo. Em cenários de produção, esse Certificado de Autoridade de Certificação normalmente é adquirido de uma autoridade de certificação comercial confiável, como a Baltimore, a Verisign ou a DigiCert. Se você tiver controle total sobre os dispositivos que se conectam aos dispositivos IoT Edge, é possível usar uma autoridade de certificação de nível corporativo. Em um dos casos, toda a cadeia de certificados do IoT Edge para o Hub IoT o usa. Os dispositivos IoT downstream precisam confiar no certificado raiz. Você pode armazenar o Certificado de Autoridade de Certificação raiz no armazenamento de autoridade de certificação raiz confiável ou fornecer os detalhes do certificado no código de aplicativo.

Certificados intermediários

Em um processo de fabricação típico para criar dispositivos seguros, os certificados de CA raiz raramente são usados diretamente, principalmente devido ao risco de vazamento ou exposição. O Certificado de Autoridade de Certificação raiz cria e assina digitalmente um ou mais Certificados de Autoridade de Certificação intermediários. Pode haver apenas um ou uma cadeia desses certificados intermediários. Cenários que exigem uma cadeia de certificados intermediários incluem:

• Uma hierarquia de departamentos em um fabricante
• Várias empresas envolvidas em série na produção de um dispositivo
• Um cliente que compra uma CA raiz e obtém um certificado de autenticação para o fabricante assinar os dispositivos que eles fazem em nome desse cliente

Em qualquer caso, o fabricante usa um certificado CA intermediário no final dessa cadeia para assinar o Certificado de Autorização de borda colocado no dispositivo final. Esses certificados intermediários são protegido de perto na fábrica. Eles passam por processos rigorosos, tanto físicos quanto eletrônicos, para seu uso.

Próximas etapas

• Para obter mais informações sobre como instalar certificados em um dispositivo IoT Edge e referenciá-los no arquivo config, consulte Gerenciar certificado em um dispositivo IoT Edge.
• Entenda os módulos do Azure IoT Edge
• Configure um dispositivo IoT Edge para atuar como um gateway transparente
• Este artigo aborda os certificados usados para proteger as conexões entre os diferentes componentes em um dispositivo IoT Edge ou entre um dispositivo IoT Edge e os dispositivos downstream. Você também pode usar certificados para autenticar o dispositivo IoT Edge no Hub IoT. Esses certificados de autenticação são diferentes e não são discutidos neste artigo. Para obter mais informações sobre como autenticar o dispositivo com certificados, confira Criar e provisionar um dispositivo IoT Edge usando certificados X.509.