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

Si applica a: IoT Edge 1.5 IoT Edge 1.4

Importante

IoT Edge 1.5 LTS e IoT Edge 1.4 LTS sono versioni supportate. IoT Edge 1.4 LTS raggiungerà il fine vita il 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 i diversi modi in cui IoT Edge usa i certificati con hub IoT di Azure e scenari di gateway IoT Edge.

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 ca del dispositivo nella versione 1.1 è stato rinominato in Certificato CA Edge.
• Il certificato della CA del carico di lavoro nella versione 1.1 è stato 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 tra di essi nella catena di certificati.

Riepilogo

Questi scenari di base sono quelli in cui IoT Edge usa i certificati. Per altre informazioni su ogni scenario, usare i collegamenti.

Actor	Scopo	Certificate
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

• È necessario avere 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.
• È necessario avere una conoscenza di base del modo in cui IoT Edge si riferisce alle hub IoT. Per altre informazioni, vedere Informazioni sul runtime di Azure IoT Edge e sulla relativa architettura.

Scenario di un singolo dispositivo

Per comprendere i 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 vengono eseguite con l'autenticazione del certificato X.509 anziché con 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?". Lo scenario può essere illustrato come segue:

Verranno illustrate le risposte a ogni domanda e quindi si espanderà l'esempio nelle sezioni successive dell'articolo.

Il dispositivo verifica l'identità hub IoT

In che modo EdgeGateway verifica che stia comunicando con contosoIotHub originale? Quando EdgeGateway vuole comunicare 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à hub IoT, IoT Edge e hub IoT usare il protocollo handshake TLS per verificare l'identità del server di hub IoT. Un handshake TLS è illustrato nel diagramma seguente. Per semplificare l'esempio, alcuni dettagli sono stati omessi. 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. È importante comprendere che l'algoritmo garantisce che il server abbia la chiave privata associata alla chiave pubblica. Verifica che il relatore del certificato non abbia copiato o rubato. Se usiamo un ID foto come esempio, il tuo viso corrisponde alla foto sull'ID. Se qualcuno ruba l'ID, non può usarlo per l'identificazione perché il viso è unico e difficile da riprodurre. Per le chiavi crittografiche, la coppia di chiavi è correlata e univoca. Invece di 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 . Questo certificato radice è firmato da DigiCert 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 , viene preinstallato nel sistema operativo. Dal punto di vista di EdgeGateway , poiché la catena di certificati presentata da ContosoIotHub è firmata da una CA radice considerata attendibile dal sistema operativo. Il certificato è noto come certificato del server hub IoT. Per altre informazioni sul certificato del server hub IoT, vedere Supporto tls (Transport Layer Security) in 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é hub IoT supporta tls reciproco (mTLS), controlla il certificato di EdgeGateway durante l'handshake TLS autenticato dal client. Per semplicità, verranno ignorati 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'identificazione personale del certificato fornito corrisponda al record e 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'identificazione personale è ciò che hub IoT usa per verificare il certificato.

Suggerimento

L'hub IoT richiede due identificazioni personali durante la registrazione di un dispositivo IoT Edge. Una procedura consigliata consiste nel preparare due diversi certificati di identità del dispositivo con date di scadenza differenti. In questo modo, se un certificato scade, l'altro è ancora valido e consente di ruotare il certificato scaduto. Tuttavia, è anche possibile usare un solo certificato per la registrazione. Usare un singolo certificato impostando la stessa identificazione personale del certificato per le identificazioni personali primarie e secondarie durante la registrazione del dispositivo.

Ad esempio, è possibile usare il comando seguente per ottenere l'identificazione personale del certificato di identità in 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 di identificazione personale SHA256 per il dispositivo EdgeGateway registrato in hub IoT, è possibile vedere che corrisponde all'identificazione personale in EdgeGateway:

In sintesi, ContosoIotHub può considerare attendibile EdgeGateway perché EdgeGateway presenta un certificato di identità del dispositivo IoT Edge valido la cui identificazione personale corrisponde a quella registrata in 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 risolve hub IoT di Azure servizio Device Provisioning (DPS), che include il supporto per l'autenticazione della CA X.509 con IoT Edge durante il provisioning con un gruppo di registrazione. Usando 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 visualizza l'identificazione personale SHA1 per il certificato anziché l'identificazione personale SHA256.

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

hub IoT attualmente 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 del certificato può apparire che IoT Edge usi solo il certificato per comunicare con hub IoT. IoT Edge è costituito da diversi moduli. Di conseguenza, IoT Edge usa il certificato per gestire le identità dei moduli per i moduli che inviano messaggi. I moduli non usano il certificato per eseguire l'autenticazione per hub IoT, ma usano le 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, ad esempio, continua a essere eseguito e solo le operazioni di identità del modulo hanno esito negativo.

L'interazione tra moduli e hub IoT è sicura perché la chiave di firma di accesso condiviso deriva 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

Si ha ora una buona conoscenza di una semplice interazione di IoT Edge tra e hub IoT. IoT Edge può tuttavia fungere anche da gateway per dispositivi downstream o altri dispositivi IoT Edge. Questi canali di comunicazione devono anche essere crittografati e attendibili. A causa della complessità aggiunta, è necessario 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. Analogamente a prima, tutte le autenticazioni vengono eseguite con l'autenticazione del certificato X.509. Il nuovo scenario genera due nuove domande: "Il dispositivo TempSensor è legittimo?" e "L'identità di EdgeGateway è corretta?". Lo scenario può essere illustrato come segue:

Suggerimento

TempSensor è un dispositivo IoT nello 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 10.0.0.2IP di 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 verifica un dispositivo. Tuttavia, in uno scenario gateway, EdgeGateway si basa su ContosoIotHub come origine della verità per il record dei certificati. EdgeGateway mantiene anche una copia o una cache offline nel caso in cui non sia presente alcuna connessione al cloud.

Suggerimento

A differenza dei dispositivi IoT Edge, i dispositivi IoT downstream non sono limitati all'autenticazione X.509 di identificazione personale. L'autenticazione della CA X.509 è anche un'opzione. Invece di cercare solo una corrispondenza nell'identificazione personale, EdgeGateway può anche controllare se il certificato di TempSensor è radicato in una CA caricata in ContosoIotHub.

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

• TempSensor ha presentato un certificato di identità del dispositivo IoT valido per il 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, è possibile fornire certificati personalizzati o usare 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 per l'uso di un server Enrollment over Secure Transport (EST) per gestire i certificati x509. L'uso di un server EST consente di gestire manualmente i certificati e installarli 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 anche per eseguire l'autenticazione al server EST. Questi certificati vengono usati per eseguire 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. Dopo l'autenticazione iniziale, il servizio certificati invia una richiesta al server EST per rilasciare un certificato di identità. Questo certificato di identità viene usato nelle future richieste EST allo stesso server.

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

Per lo sviluppo di modelli di verifica, è possibile 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

L'autorità di certificazione (CA) è un'entità che rilascia certificati digitali. Un'autorità di certificazione funge da terza parte attendibile tra il proprietario e il destinatario del certificato. Un certificato digitale fornisce un'attestazione della proprietà di una chiave pubblica al destinatario del certificato. La catena di certificati attendibili funziona generando inizialmente un certificato radice, che rappresenta la base per la relazione di trust di tutti i certificati rilasciati dall'autorità. Il proprietario del certificato radice può quindi rilasciare certificati intermedi aggiuntivi (certificati del dispositivo downstream).

Certificato CA radice

Un certificato CA radice è la base per l'attendibilità dell'intero processo. Negli scenari di produzione, questo certificato della CA viene acquistato da un'autorità di certificazione commerciale attendibile come Baltimore, Verisign o DigiCert. Chi ha il controllo completo dei dispositivi che si connettono ai dispositivi IoT Edge può usare un'autorità di certificazione di livello aziendale. In entrambi i casi, l'intera catena di certificati da IoT Edge a hub IoT la usa. I dispositivi IoT downstream devono considerare attendibile il certificato radice. È possibile archiviare il certificato CA radice nell'archivio dell'autorità per i certificati radice attendibili o specificare i dettagli del certificato nel codice dell'applicazione.

Certificati intermedi

I certificati CA radice sono un modo tipico per rendere sicuri i dispositivi e raramente vengono usati direttamente, principalmente a causa del rischio di perdita o di esposizione. Il certificato CA radice crea e firma digitalmente uno o più certificati CA intermedi. Potrebbe esserci un solo certificato o potrebbe esserci una catena di questi 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 per il produttore per firmare i dispositivi che effettuano per conto del cliente

In ogni caso, il produttore usa un certificato CA intermedio alla fine di questa catena per firmare il certificato della CA Edge inserito nel dispositivo finale. Questi certificati intermedi sono strettamente sorvegliati presso l'impianto di produzione. Il loro utilizzo è subordinato a rigorosi processi sia fisici che elettronici.

Passaggi successivi

• Per altre informazioni su come installare i certificati in un dispositivo IoT Edge e farvi riferimento dal file di configurazione, vedere Gestire il certificato in un dispositivo IoT Edge.
• Informazioni sui moduli Azure IoT Edge
• Configurare un dispositivo IoT Edge come gateway trasparente
• Questo articolo illustra i certificati usati 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.