Compreender como o Azure IoT Edge utiliza certificados

Aplica-se a: IoT Edge 1.5 IoT Edge 1.4

Importante

IoT Edge 1.5 LTS e IoT Edge 1.4 LTS são versões suportadas. O IoT Edge 1.4 LTS termina a vida útil em 12 de novembro de 2024. Se tiver uma versão anterior, consulte Atualizar IoT Edge.

O IoT Edge utiliza diferentes tipos de certificados para diferentes finalidades. Este artigo orienta você pelas diferentes maneiras como o IoT Edge usa certificados com cenários do Hub IoT do Azure e do gateway do IoT Edge.

Importante

Por uma questão de brevidade, este artigo aplica-se ao IoT Edge versão 1.2 ou posterior. Os conceitos de certificado para a versão 1.1 são semelhantes, mas há algumas diferenças:

• O certificado de autoridade de certificação do dispositivo na versão 1.1 foi renomeado para certificado de autoridade de certificação de borda.
• O certificado de autoridade de certificação de carga de trabalho na versão 1.1 foi desativado. Na versão 1.2 ou posterior, o tempo de execução do módulo IoT Edge gera todos os certificados de servidor diretamente do certificado de CA de Borda, sem o certificado de CA de carga de trabalho intermediário entre eles na cadeia de certificados.

Resumo

É nestes cenários fundamentais que o IoT Edge utiliza certificados. Utilize as ligações para saber mais sobre cada cenário.

Ator	Objetivo	Certificado
IoT Edge	Garante que está a comunicar com o Hub IoT correto	Certificado de servidor do Hub IoT
IoT Hub	Garante que o pedido provém de um dispositivo IoT Edge legítimo	Certificado de identidade do IoT Edge
Dispositivo IoT a jusante	Garante que está a comunicar com o gateway do IoT Edge correto	Certificado de servidor do módulo edgeHub do IoT Edge Hub, emitido pela AC do Edge
IoT Edge	Assina novos certificados de servidor de módulos. Por exemplo, edgeHub	Certificado de AC do Edge
IoT Edge	Garante que o pedido provém de um dispositivo a jusante legítimo	Certificado de identidade do dispositivo IoT

Pré-requisitos

• Você deve ter uma compreensão básica da criptografia de chave pública, pares de chaves e 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 de chave pública, consulte Noções básicas sobre criptografia de chave pública e 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, consulte Compreender o tempo de execução do Azure IoT Edge e sua arquitetura.

Cenário de dispositivo único

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 autenticação de certificado X.509 em vez de chaves simétricas. Para estabelecer 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 forma:

Explicaremos as respostas a cada pergunta e, em seguida, expandiremos o exemplo nas seções posteriores do artigo.

O dispositivo verifica a identidade do Hub IoT

Como o EdgeGateway verifica se está se comunicando com o ContosoIotHub original? Quando o EdgeGateway quer falar com a nuvem, ele se conecta ao endpoint ContosoIoTHub.Azure-devices.NET. Para garantir que o ponto de extremidade seja autêntico, o IoT Edge precisa de ContosoIoTHub para mostrar a identificação (ID). A ID deve ser emitida por uma autoridade na qual 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, consulte Handshake TLS na Wikipedia.

Nota

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

Neste contexto, você não precisa saber os detalhes exatos do algoritmo criptográfico. É importante entender que o algoritmo garante que o servidor possua a chave privada que está emparelhada com sua chave pública. Verifica se o apresentador do certificado não o copiou ou roubou. Se usarmos um documento de identificação com foto como exemplo, seu rosto corresponde à foto no documento de identificação. Se alguém roubar o seu documento de identificação, não poderá usá-lo para identificação porque o seu rosto é único e difícil de reproduzir. Para chaves criptográficas, o par de chaves é relacionado e exclusivo. Em vez de fazer a correspondência de um rosto com um documento de identificação com foto, o algoritmo criptográfico usa o par de chaves para verificar a identidade.

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

A autoridade de certificação (CA) raiz é o certificado raiz do Baltimore CyberTrust . Este certificado raiz é assinado pela DigiCert, e é amplamente confiável e armazenado em muitos sistemas operacionais. Por exemplo, tanto o Ubuntu quanto o Windows o incluem no armazenamento de certificados padrão.

Armazenamento de certificados do Windows:

Armazenamento de certificados do Ubuntu:

Quando um dispositivo verifica o certificado raiz do Baltimore CyberTrust , ele é pré-instalado no sistema operacional. Do ponto de vista do EdgeGateway , como a cadeia de certificados apresentada pelo ContosoIotHub é assinada por uma autoridade de certificação raiz na qual o sistema operacional confia, o certificado é considerado confiável. O certificado é conhecido como certificado de servidor do Hub IoT. Para saber mais sobre o certificado do servidor do Hub IoT, consulte Suporte a TLS (Transport Layer Security) no Hub IoT.

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

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

O Hub IoT verifica a identidade do dispositivo IoT Edge

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

Nesse caso, o EdgeGateway fornece seu certificado de identidade de dispositivo IoT Edge. Da perspetiva do ContosoIotHub , ele verifica se a impressão digital do certificado fornecido corresponde ao seu registro e se o EdgeGateway tem a chave privada emparelhada com o certificado apresentado. 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.

Gorjeta

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 validade diferentes. Desta forma, se um certificado expirar, o outro ainda é válido e dá-lhe tempo para alternar o certificado expirado. No entanto, também é possível usar apenas um certificado para o 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 de 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 de 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 de 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.

Nota

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

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

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

Atualmente, o Hub IoT não suporta autenticação de CA X.509 diretamente com o IoT Edge.

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

Nos diagramas de verificação de certificado, pode parecer que o IoT Edge usa apenas o certificado para falar com o Hub IoT. O IoT Edge é composto por vários módulos. Como resultado, o IoT Edge usa o certificado para gerenciar identidades de módulo para módulos que enviam mensagens. Os módulos não usam o certificado para autenticar no Hub IoT, mas usam chaves SAS derivadas da chave privada que são geradas pelo tempo de execução do módulo IoT Edge. Essas chaves SAS não são alteradas mesmo se o certificado de identidade do dispositivo expirar. Se o certificado expirar, o edgeHub , por exemplo, continuará a ser 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 dispositivos aninhados com o IoT Edge como gateway

Agora você tem uma boa compreensão de uma interação simples do IoT Edge entre o IoT Hub e o Hub IoT. Mas, o IoT Edge também pode atuar como um gateway para dispositivos downstream ou outros dispositivos IoT Edge. Esses canais de comunicação também devem ser criptografados e confiáveis. Devido à complexidade adicional, temos que expandir nosso cenário de exemplo para incluir um dispositivo a jusante.

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

Gorjeta

TempSensor é um dispositivo IoT no cenário. O conceito de certificado é 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 está se comunicando com o EdgeGateway original? Quando o TempSensor quer falar com o EdgeGateway, o TempSensor precisa do EdgeGateway para mostrar um ID. O ID deve ser emitido por uma autoridade em que o TempSensor confia.

O fluxo é o mesmo de quando o EdgeGateway fala com 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 deve ser emitido para o mesmo nome de host (domínio ou endereço IP) que o TempSensor usa para se conectar ao EdgeGateway.
• Especificidade da autoridade de certificação raiz autoassinada: a cadeia de certificados apresentada pelo EdgeGateway provavelmente não está no armazenamento raiz confiável padrão do sistema operacional.

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

Especificidade do nome do host

O nome comum do certificado CN = edgegateway.local está listado na parte superior da cadeia. edgegateway.local é o nome comum do certificado do servidor edgeHub. edgegateway.local também é o nome do host para EdgeGateway na rede local (LAN ou VNet) onde TempSensor e 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 autoridade de certificação de borda. Para obter mais informações sobre como gerenciar o certificado de CA de Borda, consulte Gerenciar certificados de Borda 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.

Nota

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

Por que o EdgeGateway precisa ser informado sobre seu próprio nome de host?

O EdgeGateway não tem uma maneira 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. Mas, algumas redes podem ter servidores DNS mapeados edgegateway.local para o endereço 10.0.0.2IP do EdgeGateway.

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

Por que o IoT Edge cria certificados?

No exemplo, observe que há uma carga de trabalho iotedged ca edgegateway na cadeia de certificados. É a autoridade de certificação (CA) que existe no dispositivo IoT Edge conhecido como CA de Borda (anteriormente conhecida como CA de dispositivo na versão 1.1). Como a autoridade de certificação raiz do Baltimore CyberTrust no exemplo anterior, a autoridade de certificação de borda pode emitir outros certificados. Mais importante, e também neste exemplo, ele emite o certificado do servidor para o módulo edgeHub . Mas, ele também pode emitir certificados para outros módulos em execução no dispositivo IoT Edge.

Importante

Por padrão, sem configuração, a CA de Borda é gerada automaticamente pelo tempo de execução do módulo IoT Edge quando é iniciada pela primeira vez, conhecida como CA de Borda 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ê teria que fazer com que sua CA emitisse um certificado para o módulo edgeHub . O uso de uma CA de borda de início rápido gerada automaticamente não é suportado para uso em produção. Para obter mais informações sobre a autoridade de certificação de borda de início rápido, consulte AC de borda de início rápido.

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

A CA de borda foi projetada para permitir soluções com conectividade limitada, não confiável, cara ou ausente, mas, ao mesmo tempo, ter regulamentações ou políticas rígidas sobre renovações de certificados. Sem a AC do Edge, o IoT Edge - e em particular edgeHub - não pode funcionar.

Para proteger a autoridade de certificação de borda em produção:

• Coloque a chave privada do EdgeCA em um módulo de plataforma confiável (TPM), de preferência de uma forma em que a chave privada seja gerada de forma efêmera e nunca saia do TPM.
• Use uma PKI (infraestrutura de chave pública) na qual a autoridade de certificação de borda é acumulada. Isso fornece a capacidade de desabilitar ou recusar a renovação de certificados comprometidos. A PKI pode ser gerenciada pela TI do cliente se ele tiver o know how (menor custo) ou através de um provedor de PKI comercial.

Especificidade da autoridade de certificação raiz autoassinada

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

Nota

Alguns clientes e SDKs não usam o armazenamento raiz confiável do sistema operacional e você precisa passar o arquivo de autoridade de certificação raiz diretamente.

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

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

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 openssl comando, consulte a documentação do OpenSSL.

Você também pode inspecionar os certificados onde eles estão armazenados por padrão no /var/lib/aziot/certd/certs. Você pode encontrar certificados de CA de Borda, certificados de identidade de dispositivo e certificados de módulo no diretório. Você pode usar openssl x509 comandos 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 de servidor válido do módulo IoT Edge para edgegateway.local
• O certificado é emitido pela AC de Borda, que é emitida por my_private_root_CA
• Esta autoridade de certificação raiz privada também é armazenada no TempSensor como autoridade de certificação raiz confiável anteriormente
• Algoritmos criptográficos verificam se a propriedade e a cadeia de emissão podem ser confiáveis

Certificados para outros módulos

Outros módulos podem obter certificados de servidor emitidos pela autoridade de certificação de borda. Por exemplo, um módulo Grafana que tem uma interface web. Ele também pode obter um certificado da CA de Borda. Os módulos são tratados como dispositivos a jusante alojados no contentor. No entanto, ser capaz de obter um certificado do tempo de execução do módulo IoT Edge é um privilégio especial. Os módulos chamam a API de carga de trabalho para receber o certificado do servidor encadeado à CA de Borda configurada.

O gateway verifica a identidade do dispositivo

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

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

Gorjeta

Ao contrário dos dispositivos IoT Edge, os dispositivos IoT downstream não estão limitados à autenticação X.509 de impressão digital. A autenticação X.509 CA 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 está enraizado em uma CA que foi carregada no ContosoIotHub.

Em resumo, o EdgeGateway pode confiar no TempSensor porque:

• O TempSensor apresentou um certificado de identidade de dispositivo IoT válido para seu nome
• A impressão digital do certificado de identidade corresponde à carregada no ContosoIotHub
• Algoritmos criptográficos verificam se a propriedade e a cadeia de emissão podem ser confiáveis

Onde obter os certificados e a gestão

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

No entanto, a prática recomendada é configurar seus dispositivos para usar um servidor EST (Enrollment over Secure Transport) para gerenciar certificados x509. O uso de um servidor EST libera você de manipular manualmente os certificados e instalá-los em dispositivos. Para obter mais informações sobre como usar um servidor EST, consulte Configurar o registro no Servidor de Transporte Seguro para o Azure IoT Edge.

Você também pode usar certificados para autenticar no servidor EST. Esses certificados são usados para autenticar com servidores EST para emitir outros certificados. O serviço de certificado usa um certificado de bootstrap para autenticar com um servidor EST. O certificado de bootstrap é 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 em solicitações EST futuras para o mesmo servidor.

Se não for possível usar um servidor EST, solicite certificados ao seu provedor de PKI. Você pode gerenciar os arquivos de certificado manualmente no Hub IoT e em seus dispositivos IoT Edge. Para obter mais informações, gerencie certificados em um dispositivo IoT Edge.

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

Certificados em IoT

Autoridade de certificação

A autoridade de certificação (CA) é 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 confiança de certificados funciona emitindo inicialmente um certificado raiz, que é a base para a confiança em todos os certificados emitidos pela autoridade. O proprietário do certificado raiz pode então emitir certificados intermediários adicionais (certificados de dispositivo downstream).

Certificado de autoridade de certificação raiz

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

Certificados intermédios

Em um processo de fabricação típico para a criação de 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 pode haver uma cadeia destes certificados intermédios. Os cenários que exigiriam uma cadeia de certificados intermediários incluem:

• Uma hierarquia de departamentos dentro de um fabricante
• Várias empresas envolvidas em série na produção de um dispositivo
• Um cliente comprando uma autoridade de certificação raiz e derivando um certificado de assinatura para o fabricante assinar os dispositivos que eles fazem em nome desse cliente

Em qualquer caso, o fabricante usa um certificado de autoridade de certificação intermediário no final dessa cadeia para assinar o certificado de autoridade de certificação de borda colocado no dispositivo final. Estes certificados intermédios são guardados de perto na unidade fabril. Eles passam por processos rigorosos, tanto físicos quanto eletrônicos para seu uso.

Próximos passos

• Para obter mais informações sobre como instalar certificados em um dispositivo IoT Edge e fazer referência a eles a partir do arquivo de configuração, consulte Gerenciar certificado em um dispositivo IoT Edge.
• Compreender os módulos do Azure IoT Edge
• Configurar um dispositivo IoT Edge para atuar como um gateway transparente
• Este artigo fala sobre os certificados usados para proteger conexões entre os diferentes componentes em um dispositivo IoT Edge ou entre um dispositivo IoT Edge e quaisquer dispositivos downstream. Você também pode usar certificados para autenticar seu 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 seu dispositivo com certificados, consulte Criar e provisionar um dispositivo IoT Edge usando certificados X.509.