Informazioni sulla modalità di utilizzo dei certificati da parte di Azure IoT Edge

Si applica a: Edge 1.5

Importante

IoT Edge 1.5 LTS è la versione supportata. IoT Edge 1.4 LTS è di fine vita a partire dal 12 novembre 2024. Se si usa una versione precedente, vedere Aggiornare IoT Edge.

IoT Edge usa diversi tipi di certificati per scopi diversi. Questo articolo illustra come IoT Edge usa i certificati con gli scenari del gateway IoT e dell'hub IoT Edge di Azure.

Importante

Per brevità, questo articolo si applica a IoT Edge versione 1.2 o successiva. I concetti relativi ai certificati per la versione 1.1 sono simili, ma esistono alcune differenze:

• Il certificato della CA del dispositivo nella versione 1.1 è ora denominato certificato della CA Edge.
• Il certificato CA per i carichi di lavoro nella versione 1.1 è ritirato. Nella versione 1.2 o successiva, il runtime del modulo IoT Edge genera tutti i certificati server direttamente dal certificato CA Edge, senza il certificato CA intermedio del carico di lavoro nella catena di certificati.

Riepilogo

IoT Edge usa i certificati in questi scenari di base. Per altre informazioni su ogni scenario, usare i collegamenti.

Attore/Attrice	Scopo	Certificato
IoT Edge	Garantisce la comunicazione con l'hub IoT corretto	Certificato del server di hub IoT
Hub IoT	Garantisce che la richiesta provenga da un dispositivo IoT Edge legittimo	Certificato di identità IoT Edge
Dispositivo IoT downstream	Garantisce la comunicazione con il gateway IoT Edge corretto	Certificato del server del modulo edgeHub di Hub di IoT Edge, emesso da Edge CA
IoT Edge	Firma i nuovi certificati del server del modulo. Ad esempio, edgeHub	Certificato della CA perimetrale
IoT Edge	Garantisce che la richiesta provenga da un dispositivo downstream legittimo	Certificato di identità del dispositivo IoT

Prerequisiti

• È necessaria una conoscenza di base della crittografia a chiave pubblica, delle coppie di chiavi e del modo in cui una chiave pubblica e una chiave privata possono crittografare o decrittografare i dati. Per altre informazioni su come IoT Edge usa la crittografia a chiave pubblica, vedere Understanding Public Key Cryptography and X.509 Public Key Infrastructure.For more information about how IoT Edge uses public key cryptography, see Understanding Public Key Cryptography and X.509 Public Key Infrastructure.
• È necessaria una conoscenza di base del modo in cui IoT Edge si riferisce all'hub IoT. Per altre informazioni, vedere Informazioni sul runtime di Azure IoT Edge e sulla relativa architettura.

Scenario di un singolo dispositivo

Per informazioni sui concetti relativi ai certificati IoT Edge, si immagini uno scenario in cui un dispositivo IoT Edge denominato EdgeGateway si connette a un hub IoT di Azure denominato ContosoIotHub. In questo esempio, tutte le autenticazioni usano l'autenticazione del certificato X.509 anziché le chiavi simmetriche. Per stabilire l'attendibilità in questo scenario, è necessario garantire che il dispositivo hub IoT e IoT Edge siano autenticati: "Il dispositivo è autentico e valido?" e "L'identità del hub IoT corretta?". Ecco un'illustrazione dello scenario:

Questo articolo illustra le risposte a ogni domanda e quindi espande l'esempio nelle sezioni successive.

Il dispositivo verifica l'identità hub IoT

In che modo EdgeGateway controlla se sta comunicando con il vero ContosoIotHub? Quando EdgeGateway comunica con il cloud, si connette all'endpoint ContosoIoTHub.Azure-devices.NET. Per assicurarsi che l'endpoint sia autentico, IoT Edge necessita di ContosoIoTHub per mostrare l'identificazione (ID). L'ID deve essere emesso da un'autorità considerata attendibile da EdgeGateway . Per verificare l'identità dell'hub IoT, IoT Edge e l'hub IoT usano il protocollo handshake TLS per controllare l'identità del server dell'hub IoT. Il diagramma seguente mostra un handshake TLS. Alcuni dettagli sono rimasti per mantenerli semplici. Per altre informazioni sul protocollo di handshake TLS , vedere Handshake TLS su Wikipedia.

Nota

In questo esempio ContosoIoTHub rappresenta il ContosoIotHub.Azure-devices.NET nome host hub IoT.

In questo contesto non è necessario conoscere i dettagli esatti dell'algoritmo di crittografia. La chiave è che l'algoritmo controlla che il server abbia la chiave privata associata alla chiave pubblica. Questo controllo dimostra che chi presenta il certificato non lo ha copiato né rubato. Si pensi a un documento d'identità con foto in cui il viso corrisponde all'immagine. Se qualcuno ruba l'ID, non può usarlo perché il tuo viso è univoco. Per le chiavi crittografiche, la coppia di chiavi è correlata e univoca. Anziché associare un viso a un ID foto, l'algoritmo di crittografia usa la coppia di chiavi per verificare l'identità.

In questo scenario ContosoIotHub mostra la catena di certificati seguente:

L'autorità di certificazione radice (CA) è il certificato Baltimore CyberTrust Root . DigiCert firma questo certificato radice ed è ampiamente attendibile e archiviato in molti sistemi operativi. Ad esempio, sia Ubuntu che Windows lo includono nell'archivio certificati predefinito.

Archivio certificati Windows:

Archivio certificati Ubuntu:

Quando un dispositivo verifica la presenza del certificato Baltimore CyberTrust Root , si trova già nel sistema operativo. Dal punto di vista di EdgeGateway , poiché la catena di certificati di ContosoIotHub è firmata da una CA radice considerata attendibile dal sistema operativo, il certificato è attendibile. Questo certificato è denominato certificato del server dell'hub IoT. Per altre informazioni sul certificato del server dell'hub IoT, vedere Supporto di Transport Layer Security (TLS) nell'hub IoT.

In sintesi, EdgeGateway può verificare e considerare attendibile l'identità di ContosoIotHub perché:

• ContosoIotHub presenta il certificato del server hub IoT
• Il certificato del server è attendibile nell'archivio certificati del sistema operativo
• I dati crittografati con la chiave pubblica di ContosoIotHub possono essere decrittografati da ContosoIotHub, dimostrando il suo possesso della chiave privata

hub IoT verifica l'identità del dispositivo IoT Edge

In che modo ContosoIotHub verifica che stia comunicando con EdgeGateway? Poiché l'hub IoT supporta tls reciproco (mTLS), controlla il certificato di EdgeGateway durante un handshake TLS autenticato dal client. Per semplicità, ignorare alcuni passaggi nel diagramma seguente.

In questo caso EdgeGateway fornisce il certificato di identità del dispositivo IoT Edge. Dal punto di vista di ContosoIotHub, verifica che l'impronta digitale del certificato fornito corrisponda al suo record e che EdgeGateway abbia la chiave privata associata al certificato presentato. Quando si effettua il provisioning di un dispositivo IoT Edge in hub IoT, si fornisce un'identificazione personale. L'hub IoT usa l'identificazione personale per verificare il certificato.

Suggerimento

L'hub IoT richiede due identificazioni personali quando si registra un dispositivo IoT Edge. È consigliabile preparare due certificati di identità del dispositivo diversi con date di scadenza diverse. Se un certificato scade, l'altro è ancora valido e consente di ruotare il certificato scaduto. Tuttavia, è possibile usare un solo certificato per la registrazione. Utilizzare un singolo certificato impostando la stessa impronta digitale del certificato per le impronte digitali primarie e secondarie quando si registra il dispositivo.

Ad esempio, usare il comando seguente per ottenere l'impronta digitale del certificato su EdgeGateway:

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

Il comando restituisce l'identificazione personale SHA256 del certificato:

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 si visualizza il valore dell'impronta digitale SHA256 per il dispositivo EdgeGateway registrato nell'hub IoT, si può vedere che corrisponde all'impronta digitale su EdgeGateway:

In sintesi , ContosoIotHub considera attendibile EdgeGateway perché EdgeGateway presenta un certificato di identità del dispositivo IoT Edge valido con un'identificazione personale corrispondente a quella registrata nell'hub IoT.

Per altre informazioni sul processo di compilazione dei certificati, vedere Creare ed effettuare il provisioning di un dispositivo IoT Edge in Linux usando certificati X.509.

Nota

Questo esempio non riguarda il servizio di Provisioning dei dispositivi dell'IoT Hub di Azure, che supporta l'autenticazione CA X.509 con IoT Edge quando viene configurato con un gruppo di registrazione. Con DPS, si carica il certificato CA o un certificato intermedio, la catena di certificati viene verificata, quindi viene effettuato il provisioning del dispositivo. Per altre informazioni, vedere Attestazione del certificato DPS X.509.

Nel portale di Azure, DPS mostra l'impronta digitale SHA1 per il certificato anziché l'impronta digitale SHA256.

DPS registra o aggiorna l'impronta digitale SHA256 in IoT Hub. È possibile controllare l'impronta digitale usando il comando openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. Dopo la registrazione, IoT Edge utilizza l'autenticazione tramite impronta digitale con IoT Hub. Se il dispositivo viene eseguito nuovamente il provisioning e viene rilasciato un nuovo certificato, dps aggiorna hub IoT con la nuova identificazione personale.

Attualmente, l'hub IoT non supporta l'autenticazione ca X.509 direttamente con IoT Edge.

Uso del certificato per le operazioni di identità del modulo

Nei diagrammi di verifica dei certificati, può sembrare che IoT Edge usi solo il certificato per comunicare con IoT Hub. IoT Edge include diversi moduli. IoT Edge usa il certificato per gestire le identità dei moduli per i moduli che inviano messaggi. I moduli non usano il certificato per l'autenticazione nell'hub IoT, ma usano chiavi di firma di accesso condiviso derivate dalla chiave privata generata dal runtime del modulo IoT Edge. Queste chiavi di firma di accesso condiviso non cambiano anche se il certificato di identità del dispositivo scade. Se il certificato scade, edgeHub viene comunque eseguito, ma solo le operazioni di identità del modulo hanno esito negativo.

L'interazione tra i moduli e l'hub IoT è sicura perché la chiave di firma di accesso condiviso è derivata da un segreto e IoT Edge gestisce la chiave senza il rischio di intervento umano.

Scenario di gerarchia di dispositivi annidati con IoT Edge come gateway

È ora possibile comprendere una semplice interazione tra IoT Edge e l'hub IoT. IoT Edge può tuttavia fungere anche da gateway per dispositivi downstream o altri dispositivi IoT Edge. Questi canali di comunicazione devono essere crittografati e attendibili. A causa della complessità aggiunta, espandere lo scenario di esempio per includere un dispositivo downstream.

Si aggiunge un normale dispositivo IoT denominato TempSensor, che si connette al dispositivo IoT Edge padre EdgeGateway che si connette a hub IoT ContosoIotHub. Come in precedenza, tutte le autenticazioni usano l'autenticazione del certificato X.509. Questo scenario genera due domande: "Il dispositivo TempSensor è legittimo?" e "L'identità di EdgeGateway è corretta?". Lo scenario è illustrato di seguito:

Suggerimento

TempSensor è un dispositivo IoT in questo scenario. Il concetto di certificato è lo stesso se TempSensor è un dispositivo IoT Edge downstream di EdgeGateway padre.

Il dispositivo verifica l'identità del gateway

In che modo TempSensor verifica che stia comunicando con edgeGateway originale ? Quando TempSensor vuole comunicare con EdgeGateway, TempSensor necessita di EdgeGateway per visualizzare un ID. L'ID deve essere emesso da un'autorità considerata attendibile da TempSensor .

Il flusso è uguale a quando EdgeGateway comunica con ContosoIotHub. TempSensor e EdgeGateway usano il protocollo handshake TLS per verificare l'identità di EdgeGateway. Esistono due dettagli importanti:

• Specificità del nome host: il certificato presentato da EdgeGateway deve essere rilasciato allo stesso nome host (dominio o indirizzo IP) usato da TempSensor per connettersi a EdgeGateway.
• Specificità della CA radice autofirmato: la catena di certificati presentata da EdgeGateway probabilmente non si trova nell'archivio radice attendibile predefinito del sistema operativo.

Per comprendere i dettagli, esaminiamo prima di tutto la catena di certificati presentata da EdgeGateway.

Specificità del nome host

Il nome comune del certificato CN = edgegateway.local è elencato nella parte superiore della catena. edgegateway.local è il nome comune del certificato del server edgeHub. edgegateway.local è anche il nome host per EdgeGateway nella rete locale (LAN o rete virtuale) in cui sono connessi TempSensor e EdgeGateway . Potrebbe trattarsi di un indirizzo IP privato, ad esempio 192.168.1.23 o un nome di dominio completo (FQDN) come il diagramma. Il certificato del server edgeHub viene generato usando il parametro hostname definito nel file config.toml di IoT Edge. Non confondere il certificato del server edgeHub con il certificato ca Edge. Per altre informazioni sulla gestione del certificato ca Edge, vedere Gestire i certificati IoT Edge.

Quando TempSensor si connette a EdgeGateway, TempSensor usa il nome host edgegateway.local per connettersi a EdgeGateway. TempSensor controlla il certificato presentato da EdgeGateway e verifica che il nome comune del certificato sia edgegateway.local. Se il nome comune del certificato è diverso, TempSensor rifiuta la connessione.

Nota

Per semplicità, l'esempio mostra il nome comune del certificato soggetto (CN) come proprietà convalidata. In pratica, se un certificato ha un nome alternativo soggetto (SAN), san viene convalidato invece di CN. In genere, poiché SAN può contenere più valori, ha sia il dominio principale che il nome host per il titolare del certificato, nonché qualsiasi dominio alternativo.

Perché EdgeGateway deve essere informato del proprio nome host?

EdgeGateway non ha un modo affidabile per sapere come altri client nella rete possono connettersi. Ad esempio, in una rete privata, potrebbero essere presenti server DHCP o servizi mDNS che elencano EdgeGateway come 10.0.0.2 o example-mdns-hostname.local. Tuttavia, alcune reti potrebbero avere server DNS che eseguono il mapping edgegateway.local all'indirizzo EdgeGateway.

Per risolvere il problema, IoT Edge usa il valore del nome host configurato in config.toml e crea un certificato server per esso. Quando una richiesta arriva al modulo edgeHub , presenta il certificato con il nome comune del certificato corretto(CN).

Perché IoT Edge crea certificati?

Nell'esempio si noti che nella catena di certificati è presente un gateway perimetrale del carico di lavoro iotedged. Si tratta dell'autorità di certificazione (CA) presente nel dispositivo IoT Edge noto come CA Edge (in precedenza nota come CA del dispositivo nella versione 1.1). Come la CA radice Baltimore CyberTrust nell'esempio precedente, la CA Edge può emettere altri certificati. Soprattutto, e anche in questo esempio rilascia il certificato del server al modulo edgeHub . Ma può anche rilasciare certificati ad altri moduli in esecuzione nel dispositivo IoT Edge.

Importante

Per impostazione predefinita senza configurazione, la CA Edge viene generata automaticamente dal runtime del modulo IoT Edge quando viene avviata per la prima volta, nota come CA Edge di avvio rapido e quindi rilascia un certificato al modulo edgeHub. Questo processo velocizza la connessione del dispositivo downstream consentendo a edgeHub di presentare un certificato valido firmato. Senza questa funzionalità, è necessario ottenere la CA per rilasciare un certificato per il modulo edgeHub . L'uso di una CA Edge di avvio rapido generato automaticamente non è supportato per l'uso nell'ambiente di produzione. Per altre informazioni sull'avvio rapido della CA Edge, vedere Guida introduttiva alla CA Edge.

Non è pericoloso avere un certificato dell'autorità emittente nel dispositivo?

La CA Perimetrale è progettata per abilitare soluzioni con connettività limitata, inaffidabile, costosa o assente, ma allo stesso tempo hanno normative o criteri rigorosi per i rinnovi dei certificati. Senza l'autorità di certificazione Edge, IoT Edge, e in particolare edgeHub , non può funzionare.

Per proteggere l'autorità di certificazione Perimetrale nell'ambiente di produzione:

• Inserire la chiave privata EdgeCA in un modulo TPM (Trusted Platform Module), preferibilmente in modo da generare in modo temporaneo la chiave privata e non lascia mai il TPM.
• Usare un'infrastruttura a chiave pubblica (PKI) in cui viene eseguito il rollup della CA Edge. In questo modo è possibile disabilitare o rifiutare il rinnovo dei certificati compromessi. L'infrastruttura a chiave pubblica può essere gestita dal cliente IT se ha il know how (costo inferiore) o tramite un provider PKI commerciale.

Specificità della CA radice autofirmato

Il modulo edgeHub è un componente importante che costituisce IoT Edge gestendo tutto il traffico in ingresso. In questo esempio usa un certificato emesso dalla CA Edge, che a sua volta viene emesso da una CA radice autofirmato. Poiché la CA radice non è considerata attendibile dal sistema operativo, l'unico modo in cui TempSensor considererebbe attendibile l'installazione del certificato DELLA CA nel dispositivo. Questo scenario è noto anche come scenario del bundle di attendibilità, in cui è necessario distribuire la radice ai client che devono considerare attendibile la catena. Lo scenario del bundle di attendibilità può essere problematico perché è necessario accedere al dispositivo e installare il certificato. L'installazione del certificato richiede la pianificazione. Può essere eseguita con script, aggiunti durante la produzione o preinstallati nell'immagine del sistema operativo.

Nota

Alcuni client e SDK non usano l'archivio radice attendibile del sistema operativo ed è necessario passare direttamente il file CA radice.

Applicando tutti questi concetti, TempSensor può verificare che stia comunicando con edgeGateway originale perché ha presentato un certificato corrispondente all'indirizzo e il certificato è firmato da una radice attendibile.

Per verificare la catena di certificati, è possibile usare openssl nel dispositivo TempSensor . In questo esempio si noti che il nome host per la connessione corrisponde al nome comune del certificato di profondità 0 e che la CA radice corrisponde.

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

Per altre informazioni sul openssl comando, vedere la documentazione di OpenSSL.

È anche possibile esaminare i certificati in cui sono archiviati per impostazione predefinita in /var/lib/aziot/certd/certs. È possibile trovare i certificati della CA Edge, i certificati di identità del dispositivo e i certificati del modulo nella directory . È possibile usare openssl x509 i comandi per controllare i certificati. Ad esempio:

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

In breve, TempSensor può considerare Attendibile EdgeGateway perché:

• Il modulo edgeHub ha mostrato un certificato server del modulo IoT Edge valido per edgegateway.local
• Il certificato viene emesso dalla CA Edge emessa da my_private_root_CA
• Questa CA radice privata viene archiviata anche in TempSensor come CA radice attendibile in precedenza
• Gli algoritmi di crittografia verificano che la proprietà e la catena di rilascio possano essere attendibili

Certificati per altri moduli

Altri moduli possono ottenere i certificati server rilasciati dalla CA Edge. Ad esempio, un modulo Grafana con un'interfaccia Web. Può anche ottenere un certificato dalla CA Edge. I moduli vengono considerati come dispositivi downstream ospitati nel contenitore. Tuttavia, la possibilità di ottenere un certificato dal runtime del modulo IoT Edge è un privilegio speciale. I moduli chiamano l'API del carico di lavoro per ricevere il certificato server concatenato alla CA perimetrale configurata.

Il gateway verifica l'identità del dispositivo

In che modo EdgeGateway verifica che stia comunicando con TempSensor? EdgeGateway usa l'autenticazione client TLS per autenticare TempSensor.

La sequenza è simile a ContosoIotHub che controlla un dispositivo. Ma in uno scenario gateway, EdgeGateway si basa su ContosoIotHub come fonte affidabile per il record del certificato. EdgeGateway mantiene anche una copia o una cache offline se non è presente alcuna connessione al cloud.

Suggerimento

A differenza dei dispositivi IoT Edge, i dispositivi IoT downstream non sono limitati all'autenticazione con impronta digitale X.509. L'autenticazione della CA X.509 è anche un'opzione. Invece di cercare solo una corrispondenza sull'impronta digitale, EdgeGateway può anche controllare se il certificato di TempSensor ha come radice una CA caricata in ContosoIotHub.

In breve, EdgeGateway può considerare attendibile TempSensor perché:

• TempSensor presenta un certificato di identità del dispositivo IoT valido per il suo nome
• L'identificazione personale del certificato di identità corrisponde a quella caricata in ContosoIotHub
• Gli algoritmi di crittografia verificano che la proprietà e la catena di rilascio possano essere attendibili

Dove ottenere i certificati e la gestione

Nella maggior parte dei casi, si forniscono certificati personalizzati o si usano i certificati generati automaticamente. Ad esempio, la CA Edge e il certificato edgeHub vengono generati automaticamente.

Tuttavia, la procedura consigliata consiste nel configurare i dispositivi in modo da usare un server Enrollment over Secure Transport (EST) per gestire i certificati x509. Un server EST consente di evitare di gestire e installare manualmente i certificati nei dispositivi. Per altre informazioni sull'uso di un server EST, vedere Configurare la registrazione su Secure Transport Server per Azure IoT Edge.

È possibile usare i certificati per eseguire l'autenticazione anche nel server EST. Questi certificati eseguono l'autenticazione con i server EST per rilasciare altri certificati. Il servizio certificati usa un certificato bootstrap per l'autenticazione con un server EST. Il certificato bootstrap è di lunga durata. Quando esegue l'autenticazione, il servizio certificati richiede un certificato di identità dal server EST. Il certificato di identità viene usato nelle future richieste EST allo stesso server.

Se non è possibile usare un server EST, richiedere i certificati dal provider PKI. Gestire manualmente i file di certificato nell'hub IoT e nei dispositivi IoT Edge. Per altre informazioni, vedere Gestire i certificati in un dispositivo IoT Edge.

Per lo sviluppo di modelli di verifica, creare certificati di test. Per altre informazioni, vedere Creare certificati demo per testare le funzionalità dei dispositivi IoT Edge.

Certificati in IoT

Autorità di certificazione

Un'autorità di certificazione rilascia certificati digitali. La CA funge da terza parte attendibile tra il proprietario del certificato e il destinatario del certificato. Un certificato digitale dimostra che il ricevitore è proprietario di una chiave pubblica. La catena di certificati di trust inizia con un certificato radice, che è la base per l'attendibilità in tutti i certificati che l'autorità rilascia. Il proprietario del certificato radice può rilasciare certificati intermedi aggiuntivi (certificati del dispositivo downstream).

Certificato CA radice

Un certificato CA radice è il fondamento di fiducia per il processo. In produzione, in genere si acquista questo certificato CA da un'autorità di certificazione commerciale attendibile come Baltimore, Verisign o DigiCert. Se si controllano tutti i dispositivi che si connettono ai dispositivi IoT Edge, è possibile usare un'autorità di certificazione aziendale. In entrambi i casi, la catena dei certificati da IoT Edge all'hub IoT utilizza il certificato root CA. I dispositivi IoT downstream devono considerare attendibile il certificato radice. Archiviare il certificato CA radice nell'archivio delle autorità di certificazione radice attendibili oppure fornire i dettagli del certificato nel codice dell'applicazione.

Certificati intermedi

In un tipico processo di produzione per i dispositivi sicuri, i produttori usano raramente certificati CA radice direttamente a causa del rischio di perdita o esposizione. Il certificato CA radice crea e firma digitalmente uno o più certificati CA intermedi. Può esistere una o una catena di certificati intermedi. Gli scenari che richiedono una catena di certificati intermedi includono:

• Gerarchia di reparti all'interno di un produttore
• Più aziende coinvolte serialmente nella produzione di un dispositivo
• Un cliente acquista una CA radice e deriva un certificato di firma che permette al produttore di firmare i dispositivi per conto del cliente

Il produttore usa un certificato CA intermedio alla fine di questa catena per firmare il certificato ca Edge inserito nel dispositivo finale. L'impianto di produzione protegge attentamente questi certificati intermedi. I processi fisici e elettronici rigorosi controllano l'utilizzo.

Passaggi successivi

• Per altre informazioni su come installare i certificati su un dispositivo IoT Edge e farvi riferimento dal file di configurazione, vedere Gestire un certificato su un dispositivo IoT Edge.
• Informazioni sui moduli Azure IoT Edge
• Configurare un dispositivo IoT Edge come gateway trasparente
• Questo articolo illustra come vengono usati i certificati per proteggere le connessioni tra i diversi componenti in un dispositivo IoT Edge o tra un dispositivo IoT Edge e qualsiasi dispositivo downstream. È anche possibile usare i certificati per autenticare il dispositivo IoT Edge per l'hub IoT. Questi certificati di autenticazione sono diversi e non sono descritti in questo articolo. Per altre informazioni sull'autenticazione del dispositivo con certificati, vedere Creare ed effettuare il provisioning di un dispositivo IoT Edge usando certificati X.509.