Condividi tramite

Informazioni su come Azure IoT Edge usa i certificati

Si applica a:Segno di spunta IoT Edge 1.5 IoT Edge 1.5

Importante

IoT Edge 1.5 LTS è la versione supportata. IoT Edge 1,4 LTS ha raggiunto la fine della vita il 12 novembre 2024. Se si usa una versione precedente, vedere Update IoT Edge.

IoT Edge usa diversi tipi di certificati per scopi diversi. Questo articolo illustra come IoT Edge usa i certificati con scenari di gateway Azure IoT Hub e 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 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 che stia comunicando con il suo corretto IoT Hub certificato del server IoT Hub
IoT Hub Garantisce che la richiesta provenga da un dispositivo IoT Edge legittimo Certificato di identità IoT Edge
Dispositivo IoT a valle Si assicura che stia comunicando con il gateway IoT Edge corretto Certificato del server del modulo IoT Edge Hub edgeHub, rilasciato da Edge CA
IoT Edge Firma i nuovi certificati del server del modulo. Ad esempio, edgeHub Certificato CA Edge
IoT Edge Garantisce che la richiesta provenga da un dispositivo downstream legittimo Certificato di identità del dispositivo IoT

Prerequisiti

Scenario di un singolo dispositivo

Per apprendere IoT Edge concetti relativi ai certificati, si immagini uno scenario in cui un dispositivo IoT Edge denominato EdgeGateway si connette a un Azure IoT Hub 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 l'IoT Hub e IoT Edge dispositivo siano autenticati: "Il dispositivo è autentico e valido?" e "L'identità del IoT Hub corretta?" Di seguito è riportata un'illustrazione dello scenario:

diagramma di stato dello scenario Trust che mostra la connessione tra dispositivo IoT Edge e IoT Hub.

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

Dispositivo verifica l'identità dell'IoT Hub

In che modo EdgeGateway verifica che stia parlando 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 richiede a ContosoIoTHub di mostrare l'identificazione (ID). L'ID deve essere emesso da un'autorità considerata attendibile da EdgeGateway . Per verificare l'identità di IoT Hub, IoT Edge e IoT Hub usano l'handshake TLS per controllare l'identità del server di IoT Hub. 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 nome host IoT Hub ContosoIotHub.Azure-devices.NET.

Diagramma della sequenza che mostra lo scambio di certificati dall'IoT Hub al dispositivo IoT Edge con verifica del certificato nell'archivio radice attendibile sul dispositivo IoT Edge.

In questo contesto non è necessario conoscere i dettagli esatti dell'algoritmo di crittografia. Il concetto di chiave è che l'algoritmo verifica che il server abbia la chiave privata che si associa 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:

diagramma di flusso che mostra la catena di autorità di certificazione intermedia e radice per IoT Hub.

L'autorità di certificazione radice è il certificato DigiCert Global Root G2. DigiCert firma questo certificato radice ed è ampiamente attendibile e archiviato in molti sistemi operativi. Ad esempio, Ubuntu lo include nell'archivio certificati predefinito:

Screenshot che mostra il certificato DigiCert Global Root G2 elencato nell'archivio certificati Ubuntu.

Quando un dispositivo verifica la presenza del certificato DigiCert Global Root G2 , 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 viene chiamato certificato server IoT Hub. Per altre informazioni sul certificato del server IoT Hub, vedere il supporto Transport Layer Security (TLS) in IoT Hub.

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

  • ContosoIotHub presenta il certificato del server IoT Hub.
  • 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.

IoT Hub verifica l'identità del dispositivo IoT Edge

In che modo ContosoIotHub verifica che stia comunicando con EdgeGateway? Poiché IoT Hub supporta mutual TLS (mTLS), controlla il certificato del gateway Edge durante un handshake TLS autenticato dal client. Per semplicità, il diagramma seguente ignora alcuni passaggi.

Diagramma di sequenze che mostra lo scambio di certificati dal dispositivo IoT Edge all'IoT Hub con verifica dell'impronta digitale del certificato su IoT Hub.

In questo caso, EdgeGateway fornisce il relativo 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 IoT Hub, si fornisce un'impronta digitale (thumbprint). IoT Hub usa l'identificazione personale per verificare il certificato.

Suggerimento

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

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'impronta digitale 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 in IoT Hub, si vede che corrisponde all'impronta digitale su EdgeGateway:

Screenshot dal portale di Azure dell'impronta digitale del dispositivo EdgeGateway in ContosoIotHub.

In sintesi, ContosoIotHub considera attendibile EdgeGateway perché EdgeGateway presenta un certificato di identità IoT Edge valido con un'impronta digitale corrispondente a quella registrata in IoT Hub.

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 copre l'Azure IoT Hub Device Provisioning Service (DPS), che supporta l'autenticazione CA X.509 con IoT Edge quando viene eseguito il provisioning 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 X.509 dps.

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 usa l'autenticazione tramite impronta digitale con IoT Hub. Se il dispositivo viene sottoposto nuovamente a provisioning e viene rilasciato un nuovo certificato, il servizio Device Provisioning aggiorna l'hub IoT con la nuova identificazione personale.

Attualmente, IoT Hub 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 autenticarsi su IoT Hub, ma usano chiavi SAS derivate dalla chiave privata generate dal runtime del modulo IoT Edge. Queste chiavi SAS 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 moduli e IoT Hub è 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 IoT Hub. Ma IoT Edge può anche fungere 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.

Aggiungere un normale dispositivo IoT denominato TempSensor, che si connette al dispositivo padre IoT Edge EdgeGateway, che si connette al IoT Hub 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 nel diagramma seguente:

Diagram che mostra la connessione tra un dispositivo IoT Edge, un gateway IoT Edge e IoT Hub.

Suggerimento

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

Il dispositivo verifica l'identità del gateway

TempSensor come verifica che stia comunicando con il vero EdgeGateway? Quando TempSensor si vuole comunicare con EdgeGateway, TempSensor deve EdgeGateway mostrare un ID. L'ID deve provenire da un'autorità che TempSensor considera attendibile.

Diagramma di sequenza che mostra lo scambio di certificati dal dispositivo gateway al dispositivo IoT Edge con la verifica del certificato utilizzando l'autorità di certificazione radice privata.

Il flusso è uguale a quando EdgeGateway comunica con ContosoIotHub. TempSensor e EdgeGateway usano il protocollo di stretta di mano TLS per verificare l'identità EdgeGateway. Due dettagli importanti si distinguono:

  • Specificità del nome host: EdgeGateway deve presentare un certificato rilasciato allo stesso nome host (dominio o indirizzo IP) che TempSensor usa per connettersi a EdgeGateway.
  • Specificità dell'autorità di certificazione radice autofirmata: presenta probabilmente una catena di certificati che non si trova nell'archivio radice attendibile predefinito del sistema operativo.

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

Diagramma di flusso che mostra la catena di autorità di certificazione per un gateway IoT Edge.

Specificità del nome host

Il nome CN = edgegateway.local comune del certificato viene visualizzato nella parte superiore della catena. edgegateway.local è il nome comune del certificato del edgeHub server. edgegateway.local è anche il nome host per EdgeGateway nella rete locale (LAN o rete virtuale) in cui TempSensor e EdgeGateway si connettono. Può essere un indirizzo IP privato, ad 192.168.1.23esempio , o un nome di dominio completo (FQDN) come il diagramma. Per generare il certificato server edgeHub, utilizzare il parametro hostname definito nel file config.toml di IoT Edge. Non confondere il certificato del edgeHub server con il certificato della 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 edgegateway.local host per connettersi a EdgeGateway. TempSensor controlla il certificato che EdgeGateway presenta 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), il processo di convalida controlla la SAN anziché il 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 conoscere il proprio nome host?

EdgeGateway non dispone di 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 di edgegateway.local all'indirizzo IP EdgeGateway10.0.0.2.

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

Perché IoT Edge crea certificati?

Nell'esempio, si noti che nella catena di certificati è presente un ca edgegateway del carico di lavoro iotedged. È l'autorità di certificazione (CA) presente nel dispositivo IoT Edge noto come CA Edge CA (in precedenza nota come Device CA nella versione 1.1). Analogamente a DigiCert Global Root G2 nell'esempio precedente, la CA Edge può rilasciare altri certificati. Soprattutto, e anche in questo esempio rilascia il certificato del server al edgeHub modulo. Ma può anche rilasciare certificati ad altri moduli in esecuzione nel dispositivo IoT Edge.

Importante

Per impostazione predefinita e senza configurazione, il runtime del modulo IoT Edge genera automaticamente Edge CA all'avvio per la prima volta. Questa autorità di certificazione è conosciuta come quickstart Edge CA. Rilascia quindi un certificato al modulo edgeHub . Questo processo velocizza la connessione del dispositivo downstream consentendo a edgeHub di presentare un certificato valido che firma. Senza questa funzionalità, è necessario ottenere la CA per rilasciare un certificato per il modulo edgeHub . L'uso di una CA Edge di avvio rapido generata automaticamente non è supportato per l'uso in produzione. Per altre informazioni sulla CA edge di avvio rapido, vedere Guida introduttiva alla CA edge.

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

La Edge CA è progettata per abilitare soluzioni con connettività limitata, inaffidabile, costosa o assente, ma che allo stesso tempo devono rispettare normative o criteri rigorosi per i rinnovi dei certificati. Senza CA Edge, IoT Edge e in particolare edgeHub non può funzionare.

Per proteggere il CA perimetrale in produzione:

  • Inserire la chiave privata EdgeCA in un modulo TPM (Trusted Platform Module), preferibilmente in modo che la chiave privata sia generata in maniera temporanea e non lasci mai il TPM.
  • Usare un'infrastruttura a chiave pubblica (PKI) alla quale la CA Edge si integra. Questa configurazione consente di disabilitare o rifiutare il rinnovo dei certificati compromessi. L'infrastruttura a chiave pubblica può essere gestita dall'IT del cliente se ha il know-how (costo inferiore) o tramite un provider PKI commerciale.

Specificità del CA radice autofirmato

Il modulo edgeHub gestisce tutto il traffico in ingresso per IoT Edge. In questo esempio si usa un certificato emesso dalla CA Edge, che a sua volta è emesso da una CA root autofirmata. Poiché la CA radice non è attendibile per il sistema operativo, l'unico modo per renderla attendibile è installare il certificato CA sul dispositivo. Questo metodo di attendibilità è noto anche come scenario di aggregazione di attendibilità, in cui è necessario distribuire la radice ai client che devono fidarsi della 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 usando 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 il vero EdgeGateway 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 TempSensor dispositivo. In questo esempio, il nome host per la connessione corrisponde al nome comune del certificato depth 0 e il file 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, si può fidare di TempSensorEdgeGateway perché:

  • Il modulo edgeHub mostra un certificato del server del modulo IoT Edge valido per edgegateway.local.
  • Il certificato viene emesso dalla Edge CA, emessa da my_private_root_CA.
  • Questa autorità di certificazione radice privata viene archiviata anche in TempSensor come autorità di certificazione radice attendibile precedente.
  • 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 da Edge CA. 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

EdgeGateway Come verifica che stia comunicando con TempSensor? EdgeGateway usa TLS client authentication per autenticare TempSensor.

Diagram che mostra uno scambio di certificati tra un dispositivo IoT Edge e un gateway, con controllo dei certificati IoT Hub.

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 "thumbprint" X.509. L'autenticazione della CA X.509 è anche un'opzione. Invece di cercare solo una corrispondenza sull'impronta digitale, EdgeGateway, può anche verificare se il certificato TempSensor's è radicato in una CA caricata in ContosoIotHub.

In breve, può considerare attendibile EdgeGatewayTempSensor perché:

  • TempSensor presenta, nel nome, un certificato di identità dispositivo IoT valido.
  • L'impronta del certificato di identità corrisponde a quella caricata su 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 in IoT Hub 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 i certificati demo per testare IoT Edge funzionalità del dispositivo.

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 è la base per l'attendibilità del processo. In produzione, in genere si acquista questo certificato CA da un'autorità di certificazione commerciale attendibile come 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 di certificati da IoT Edge a IoT Hub usa il certificato CA radice. I dispositivi IoT downstream devono considerare attendibile il certificato radice. 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

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 ottiene un certificato di firma per il produttore, per 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

  • Last updated on