Gestire i certificati 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à la fine del servizio il 12 novembre 2024. Se si usa una versione precedente, vedere Aggiornare IoT Edge.

Tutti i dispositivi IoT Edge usano i certificati per creare connessioni sicure tra il runtime e i moduli in esecuzione nel dispositivo. Anche i dispositivi IoT Edge che funzionano come gateway usano questi stessi certificati per connettersi ai dispositivi downstream.

Nota

Il termine CA radice usato in questo articolo si riferisce al certificato dell'autorità principale nella catena di certificati per la soluzione IoT. Non è necessario usare la radice del certificato di un'autorità di certificazione diffusa o la radice dell'autorità di certificazione dell'organizzazione. Spesso, si tratta in realtà di un certificato di una CA intermedia.

Prerequisiti

• È necessario avere familiarità con i concetti descritti in Informazioni sulla modalità di utilizzo dei certificati da parte di Azure IoT Edge, in particolare come IoT Edge usa i certificati.

• Un dispositivo IoT Edge.

  Se non si dispone di un dispositivo IoT Edge configurato, è possibile crearne uno in una macchina virtuale di Azure. Seguire la procedura descritta in uno di questi articoli della guida introduttiva per Creare un dispositivo Linux virtuale o Creare un dispositivo Windows virtuale.

• Possibilità di modificare il file di configurazione di IoT Edge config.toml seguendo il modello di configurazione.

• Se il file config.toml non è basato sul modello, aprire il modello e usare le indicazioni commentate per aggiungere sezioni di configurazione che seguono la struttura del modello.

• Se si dispone di una nuova installazione di IoT Edge che non è stata configurata, copiare il modello per inizializzare la configurazione. Non usare questo comando se si dispone di una configurazione esistente. Sovrascrive il file.

  sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
  

Requisiti di formato

Suggerimento

• Un certificato può essere codificato in una rappresentazione binaria denominata DER (Distinguished Encoding Rules) o in una rappresentazione testuale denominata PEM (Privacy Enhanced Mail). Il formato PEM ha un'intestazione -----BEGIN CERTIFICATE----- seguita dalla rappresentazione DER con codifica Base64 seguita da un piè di pagina -----END CERTIFICATE-----.
• Analogamente al certificato, la chiave privata può essere codificata in una rappresentazione binaria DER o in una rappresentazione testuale PEM.
• Poiché il formato PEM è delineato, è anche possibile costruire un formato PEM che combini gli oggetti CERTIFICATE e PRIVATE KEY in sequenza nello stesso file.
• Infine, il certificato e la chiave privata possono essere codificati insieme in una rappresentazione binaria denominata PKCS#12, crittografata con una password facoltativa.

Le estensioni di file sono arbitrarie ed è necessario eseguire il comando file o visualizzare il file per verificare il tipo. In generale, i file usano le convenzioni di estensione seguenti:

• .cer è un certificato in formato DER o PEM.
• .pem è un certificato, una chiave privata o entrambi in formato PEM.
• .pfx è un file PKCS#12.

IoT Edge richiede che il certificato e la chiave privata siano:

• Formato PEM
• File separati
• Nella maggior parte dei casi, con la catena completa

Se si ottiene un file .pfx dal provider PKI, è probabile che il certificato e la chiave privata vengano codificati insieme in un unico file. Verificare che si tratti di un tipo di file PKCS#12 usando il comando file. È possibile convertire un file PKCS#12 .pfx in file PEM usando il comando openssl pkcs12.

Se il provider PKI fornisce un file .cer, questo può contenere lo stesso certificato del file .pfx oppure potrebbe trattarsi del certificato di emissione (radice) del provider PKI. Per verificare, esaminare il file con il comando openssl x509. Se si tratta del certificato di emissione:

• Se è in formato DER (binario), convertirlo in PEM con openssl x509 -in cert.cer -out cert.pem.
• Usare il file PEM come bundle di attendibilità. Per altre informazioni sul bundle di attendibilità, vedere la sezione successiva.

Importante

L'infrastruttura PKI deve supportare chiavi RSA a 2048 bit e chiavi EC P-256. Ad esempio, i server EST devono supportare questi tipi di chiave. È possibile usare altri tipi di chiavi, ma vengono testate solo le chiavi RSA a 2048 bit e le chiavi EC P-256.

Requisiti relativi alle autorizzazioni

Nella tabella seguente sono elencate le autorizzazioni di file e directory necessarie per i certificati IoT Edge. La directory preferita per i certificati è /var/aziot/certs/ e /var/aziot/secrets/ per le chiavi.

File o directory	Autorizzazioni	Proprietario
Directory dei certificati /var/aziot/certs/	drwxr-xr-x (755)	aziotcs
File dei certificati in /var/aziot/certs/	-wr-r--r-- (644)	aziotcs
Directory delle chiavi /var/aziot/secrets/	drwx------ (700)	aziotks
File delle chiavi in /var/aziot/secrets/	-wr------- (600)	aziotks

Per creare le directory, impostare le autorizzazioni e impostare il proprietario; eseguire i comandi seguenti:

# If the certificate and keys directories don't exist, create, set ownership, and set permissions
sudo mkdir -p /var/aziot/certs
sudo chown aziotcs:aziotcs /var/aziot/certs
sudo chmod 755 /var/aziot/certs

sudo mkdir -p /var/aziot/secrets
sudo chown aziotks:aziotks /var/aziot/secrets
sudo chmod 700 /var/aziot/secrets

# Give aziotcs ownership to certificates
# Read and write for aziotcs, read-only for others
sudo chown -R aziotcs:aziotcs /var/aziot/certs
sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;

# Give aziotks ownership to private keys
# Read and write for aziotks, no permission for others
sudo chown -R aziotks:aziotks /var/aziot/secrets
sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;

# Verify permissions of directories and files
sudo ls -Rla /var/aziot

L'output dell'elenco con la proprietà e le autorizzazioni corrette è simile all'output seguente:

azureUser@vm:/var/aziot$ sudo ls -Rla /var/aziot
/var/aziot:
total 16
drwxr-xr-x  4 root    root    4096 Dec 14 00:16 .
drwxr-xr-x 15 root    root    4096 Dec 14 00:15 ..
drwxr-xr-x  2 aziotcs aziotcs 4096 Jan 14 00:31 certs
drwx------  2 aziotks aziotks 4096 Jan 23 17:23 secrets

/var/aziot/certs:
total 20
drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 .
drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
-rw-r--r-- 1 aziotcs aziotcs 1984 Jan 14 00:24 azure-iot-test-only.root.ca.cert.pem
-rw-r--r-- 1 aziotcs aziotcs 5887 Jan 14 00:27 iot-edge-device-ca-devicename-full-chain.cert.pem

/var/aziot/secrets:
total 16
drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 .
drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
-rw------- 1 aziotks aziotks 3243 Jan 14 00:28 iot-edge-device-ca-devicename.key.pem

Gestire l'autorità di certificazione radice attendibile (bundle di attendibilità)

L'uso di un certificato dell'autorità di certificazione autofirmata come radice di attendibilità con IoT Edge e i moduli è noto come bundle di attendibilità. Il bundle di attendibilità è disponibile per IoT Edge e i moduli per comunicare con i server. Per configurare il bundle di attendibilità, specificare il percorso del file nel file di configurazione di IoT Edge.

1. Ottenere il certificato della CA radice da un provider PKI.

2. Controllare che il certificato soddisfi i requisiti di formato.

3. Copiare il file PEM e concedere l'accesso al servizio certificati di IoT Edge. Ad esempio, con la directory /var/aziot/certs:

   # Make the directory if doesn't exist
   sudo mkdir /var/aziot/certs -p
   
   # Change cert directory user and group ownership to aziotcs and set permissions
   sudo chown aziotcs:aziotcs /var/aziot/certs
   sudo chmod 755 /var/aziot/certs
   
   # Copy certificate into certs directory
   sudo cp root-ca.pem /var/aziot/certs
   
   # Give aziotcs ownership to certificate and set read and write permission for aziotcs, read-only for others
   sudo chown aziotcs:aziotcs /var/aziot/certs/root-ca.pem
   sudo chmod 644 /var/aziot/certs/root-ca.pem
   

4. Nel file di configurazione di IoT Edge config.toml individuare la sezione certificato del bundle di attendibilità. Se la sezione non è presente, è possibile copiarla dal file del modello di configurazione.

   Suggerimento

   Se il file di configurazione non esiste ancora nel dispositivo, usare /etc/aziot/config.toml.edge.template come modello per crearne uno.

5. Impostare la chiave trust_bundle_cert sul percorso del file del certificato.

   trust_bundle_cert = "file:///var/aziot/certs/root-ca.pem"
   

6. Applicare la configurazione.

   sudo iotedge config apply
   

Installare l'autorità di certificazione radice nell'archivio certificati del sistema operativo

L'installazione del certificato nel file del bundle di attendibilità lo rende disponibile per i moduli contenitore, ma non per ospitare moduli come Aggiornamento dispositivi di Azure o Defender. Se si usano componenti a livello di host o si verificano altri problemi TLS, installare anche il certificato della CA radice nell'archivio certificati del sistema operativo:

Debian / Ubuntu

sudo cp /var/aziot/certs/my-root-ca.pem /usr/local/share/ca-certificates/my-root-ca.pem.crt

sudo update-ca-certificates

EFLOW / RHEL

sudo cp /var/aziot/certs/my-root-ca.pem /etc/pki/ca-trust/source/anchors/my-root-ca.pem.crt

sudo update-ca-trust

Importare i file di certificati e di chiavi private

IoT Edge può usare i certificati e i file di chiavi private esistenti per eseguire l'autenticazione o l'attestazione in Azure, per rilasciare nuovi certificati per i server del modulo e per eseguire l'autenticazione nei server EST. Per installarli:

1. Verificare che i file dei certificati e delle chiavi private soddisfino i requisiti di formato.

2. Copiare il file PEM nel dispositivo IoT Edge in cui i moduli IoT Edge possono avere accesso. Ad esempio, la directory /var/aziot/.

   # If the certificate and keys directories don't exist, create, set ownership, and set permissions
   sudo mkdir -p /var/aziot/certs
   sudo chown aziotcs:aziotcs /var/aziot/certs
   sudo chmod 755 /var/aziot/certs
   
   sudo mkdir -p /var/aziot/secrets
   sudo chown aziotks:aziotks /var/aziot/secrets
   sudo chmod 700 /var/aziot/secrets
   
   # Copy certificate and private key into the correct directory
   sudo cp my-cert.pem /var/aziot/certs
   sudo cp my-private-key.pem /var/aziot/secrets
   

3. Concedere la proprietà al servizio certificati aziotcs e al servizio chiavi aziotks di IoT Edge rispettivamente al certificato e alla chiave privata.

   # Give aziotcs ownership to certificate
   # Read and write for aziotcs, read-only for others
   sudo chown aziotcs:aziotcs /var/aziot/certs/my-cert.pem
   sudo chmod 644 /var/aziot/certs/my-cert.pem
   
   # Give aziotks ownership to private key
   # Read and write for aziotks, no permission for others
   sudo chown aziotks:aziotks /var/aziot/secrets/my-private-key.pem
   sudo chmod 600 /var/aziot/secrets/my-private-key.pem
   

4. In config.toml trovare la sezione pertinente per il tipo di certificato da configurare. Ad esempio, è possibile cercare la parola chiave cert.

5. Usando l'esempio del modello di configurazione, configurare il certificato di identità del dispositivo o i file della CA Edge. Il modello di esempio è:

   cert = "file:///var/aziot/certs/my-cert.pem"
   pk = "file:///var/aziot/secrets/my-private-key.pem"
   

6. Applicare la configurazione

   sudo iotedge config apply
   

Per evitare errori alla scadenza dei certificati, ricordarsi di aggiornare manualmente i file e la configurazione prima della scadenza del certificato.

Esempio: Usare i file del certificato di identità del dispositivo del provider PKI

Richiedere un certificato client TLS e una chiave privata al provider PKI.

Requisiti del certificato di identità del dispositivo:

• Estensioni del certificato client standard: extendedKeyUsage = clientAuth keyUsage = critical, digitalSignature
• Identificatori delle chiavi che consentono di distinguere tra CA emittenti con lo stesso nome comune per la rotazione dei certificati della CA.
  • subjectKeyIdentifier = hash
  • authorityKeyIdentifier = keyid:always,issuer:always

Assicurarsi che il nome comune corrisponda all'ID dispositivo IoT Edge registrato con l'hub IoT o all'ID di registrazione con DPS. Ad esempio, nel certificato di identità del dispositivo seguente Subject: CN = my-device è il campo importante che deve corrispondere.

Certificato di identità del dispositivo di esempio:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 48 (0x30)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = myPkiCA
        Validity
            Not Before: Jun 28 21:27:30 2022 GMT
            Not After : Jul 28 21:27:30 2022 GMT
        Subject: CN = my-device
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:ad:b0:63:1f:48:19:9e:c4:9d:91:d1:b0:b0:e5:
                    ...
                    80:58:63:6d:ab:56:9f:90:4e:3f:dd:df:74:cf:86:
                    04:af
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                C7:C2:DC:3C:53:71:B8:42:15:D5:6C:4B:5C:03:C2:2A:C5:98:82:7E
            X509v3 Authority Key Identifier:
                keyid:6E:57:C7:FC:FE:50:09:75:FA:D9:89:13:CB:D2:CA:F2:28:EF:9B:F6

    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:3c:d2:db:06:3c:d7:65:b7:22:fe:df:9e:11:5b:
         ...
         eb:da:fc:f1:6a:bf:31:63:db:5a:16:02:70:0f:cf:c8:e2
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----

Suggerimento

Per eseguire test senza accedere ai file di certificato forniti da una PKI, vedere Creare certificati demo per testare le funzionalità del dispositivo per generare un certificato di identità del dispositivo e una chiave privata non di produzione di breve durata.

Esempio di configurazione durante il provisioning con l'hub IoT:

[provisioning]
source = "manual"
# ...
[provisioning.authentication]
method = "x509"

identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"

Esempio di configurazione durante il provisioning con DPS:

[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"

identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"

Il sovraccarico con la gestione manuale dei certificati può essere rischioso e soggetto a errori. Per l'ambiente di produzione, è consigliabile usare IoT Edge con la gestione automatica dei certificati.

Gestire la CA Edge

La CA Edge ha due modalità diverse:

• Avvio rapido è il comportamento predefinito. L'avvio rapido è per i test e non è adatto per la produzione.
• La modalità di produzione richiede di fornire un'origine personalizzata per il certificato della CA Edge e la chiave privata.

CA Edge di avvio rapido

Per facilitare le attività iniziali, IoT Edge genera automaticamente per impostazione predefinita un certificato della CA Edge quando viene avviato per la prima volta. Questo certificato autofirmato è destinato solo agli scenari di sviluppo e test, non alla produzione. Per impostazione predefinita, il certificato scade dopo 90 giorni. La scadenza può essere configurata. Questo comportamento viene definito CA Edge di avvio rapido.

La CA Edge di avvio rapido consente a edgeHub e ad altri moduli IoT Edge di avere un certificato del server valido quando IoT Edge viene installato per la prima volta senza alcuna configurazione. Il certificato è necessario per edgeHub perché i moduli o i dispositivi downstream devono stabilire canali di comunicazione sicuri. Senza la CA Edge di avvio rapido, le attività iniziali sarebbero notevolmente più difficili perché sarebbe necessario fornire un certificato del server valido di un provider PKI o usare strumenti come openssl.

Importante

Non usare mai la CA Edge di avvio rapido per l'ambiente di produzione perché il certificato generato in locale non è connesso a una PKI.

La sicurezza di un'identità basata su certificati deriva da una PKI (l'infrastruttura) ben gestita in cui il certificato (un documento) è solo un componente. Una PKI ben gestita consente la definizione, l'applicazione, la gestione e le imposizione dei criteri di sicurezza che includono, a titolo esemplificativo, il rilascio, la revoca e la gestione del ciclo di vita dei certificati.

Personalizzare la durata della CA Edge di avvio rapido

Per configurare la scadenza del certificato con un valore diverso da quello predefinito di 90 giorni, aggiungere il valore in giorni nella sezione Certificato CA Edge (avvio rapido) del file di configurazione.

[edge_ca]
auto_generated_edge_ca_expiry_days = 180

Eliminare il contenuto delle cartelle /var/lib/aziot/certd/certs e /var/lib/aziot/keyd/keys per rimuovere eventuali certificati generati in precedenza e quindi applicare la configurazione.

Rinnovare la CA Edge di avvio rapido

Per impostazione predefinita, IoT Edge rinnova automaticamente il certificato della CA Edge di avvio rapido quando raggiunge l'80% della durata del certificato. Ad esempio, se un certificato ha una durata di 90 giorni, IoT Edge rigenera automaticamente il certificato della CA Edge a 72 giorni dal rilascio.

Per modificare la logica di rinnovo automatico, aggiungere le impostazioni seguenti nella sezione Certificato della CA Edge in config.toml. Ad esempio:

[edge_ca.auto_renew]
rotate_key = true
threshold = "70%"
retry = "2%"

CA Edge nell'ambiente di produzione

Quando si passa a uno scenario di produzione o si vuole creare un dispositivo gateway, non è più possibile usare la CA Edge di avvio rapido.

Un'opzione è quella di fornire i propri certificati e gestirli manualmente. Tuttavia, per evitare il processo di gestione manuale dei certificati, rischioso e soggetto a errori, usare un server EST quando possibile.

Attenzione

Il nome comune (CN) del certificato della CA Edge non può corrispondere al parametro nome host del dispositivo definito nel file di configurazione del dispositivo config.toml o all'ID dispositivo registrato nell'hub IoT.

Pianificare il rinnovo della CA Edge

Quando il certificato della CA Edge viene rinnovato, vengono rigenerati tutti i certificati rilasciati come i certificati del server dei moduli. Per fornire ai moduli nuovi certificati del server, IoT Edge riavvia tutti i moduli quando il certificato della CA Edge viene rinnovato.

Per ridurre al minimo i potenziali effetti negativi dei riavvii dei moduli, pianificare il rinnovo del certificato della CA Edge in un momento specifico (ad esempio, threshold = "10d") e notificare ai dipendenti della soluzione il tempo di inattività.

Esempio: Usare i file di certificato della CA Edge del provider PKI

Richiedere i file seguenti al provider PKI:

• Certificato della CA radice della PKI
• Certificato emittente/CA e chiave privata associata

Affinché il certificato della CA emittente diventi della CA Edge, deve avere queste estensioni:

subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, digitalSignature, keyCertSign

Esempio del certificato della CA Edge risultante:

openssl x509 -in my-edge-ca-cert.pem -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4098 (0x1002)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = myPkiCA
        Validity
            Not Before: Aug 27 00:00:50 2022 GMT
            Not After : Sep 26 00:00:50 2022 GMT
        Subject: CN = my-edge-ca.ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:e1:cb:9c:c0:41:d2:ee:5d:8b:92:f9:4e:0d:3e:
                    ...
                    25:f5:58:1e:8c:66:ab:d1:56:78:a5:9c:96:eb:01:
                    e4:e3:49
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                FD:64:48:BB:41:CE:C1:8A:8A:50:9B:2B:2D:6E:1D:E5:3F:86:7D:3E
            X509v3 Authority Key Identifier:
                keyid:9F:E6:D3:26:EE:2F:D7:84:09:63:84:C8:93:72:D5:13:06:8E:7F:D1
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign
    Signature Algorithm: sha256WithRSAEncryption
         20:c9:34:41:a3:a4:8e:7c:9c:6e:17:f5:a6:6f:e5:fc:6e:59:
         ...
         7c:20:5d:e5:51:85:4c:4d:f7:f8:01:84:87:27:e3:76:65:47:
         9e:6a:c3:2e:1a:f0:dc:9d
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----

Dopo aver ricevuto i file più recenti, aggiornare il bundle di attendibilità:

trust_bundle_cert = "file:///var/aziot/root-ca.pem"

Configurare quindi IoT Edge per usare i file di certificato e di chiave privata:

[edge_ca]
cert = "file:///var/aziot/my-edge-ca-cert.pem"
pk = "file:///var/aziot/my-edge-ca-private-key.key.pem"

Se sono stati usati altri certificati per IoT Edge nel dispositivo in precedenza, eliminare i file in /var/lib/aziot/certd/certs e le chiavi private associate ai certificati (non tutte le chiavi) in /var/lib/aziot/keyd/keys. IoT Edge li ricrea con il nuovo certificato della CA fornito.

Questo approccio richiede di aggiornare manualmente i file alla scadenza del certificato. Per evitare questo problema, provare a usare EST per la gestione automatica.

Gestione automatica dei certificati con il server EST

IoT Edge può interfacciarsi con un server EST (Enrollment over Secure Transport) per il rilascio e il rinnovo automatici dei certificati. L'uso di EST è consigliato per la produzione perché sostituisce la necessità di gestione manuale dei certificati, che può essere rischiosa e soggetta a errori. Può essere configurato a livello globale e sottoposto a override per ogni tipo di certificato.

In questo scenario, si prevede che il certificato bootstrap e la chiave privata siano di lunga durata e potenzialmente installati nel dispositivo durante la produzione. IoT Edge usa le credenziali bootstrap per eseguire l'autenticazione al server EST per la richiesta iniziale per rilasciare un certificato di identità per le richieste successive e per l'autenticazione in DPS o nell'hub IoT.

1. Ottenere l'accesso a un server EST. Se non si dispone di un server EST, usare una delle opzioni seguenti per iniziare i test:

   • Creare un server EST di test seguendo la procedura descritta in Esercitazione: Configurare la registrazione sul server di trasporto sicuro per Azure IoT Edge.

   • Microsoft collabora con GlobalSign per fornire un account demo.

2. Nel file di configurazione del dispositivo IoT Edge config.toml configurare il percorso di un certificato radice trusted usato da IoT Edge per convalidare il certificato TLS del server EST. Questo passaggio è facoltativo se il server EST ha un certificato TLS radice pubblicamente attendibile.

   [cert_issuance.est]
   trusted_certs = [
      "file:///var/aziot/root-ca.pem",
   ]
   

3. Specificare un URL predefinito per il server EST. In config.toml aggiungere la sezione seguente con l'URL del server EST:

   [cert_issuance.est.urls]
   default = "https://example.org/.well-known/est"
   

4. Per configurare il certificato EST per l'autenticazione, aggiungere la sezione seguente con il percorso del certificato e della chiave privata:

   [cert_issuance.est.auth]
   bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem"
   bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem"
   
   [cert_issuance.est.identity_auto_renew]
   rotate_key = true
   threshold = "80%"
   retry = "4%"
   

5. Applicare le modifiche alla configurazione.

   sudo iotedge config apply
   

Le impostazioni in [cert_issuance.est.identity_auto_renew] sono illustrate nella sezione successiva.

Autenticazione con nome utente e password

Se l'autenticazione al server EST con il certificato non è possibile, è possibile usare invece un segreto condiviso o un nome utente e una password.

[cert_issuance.est.auth]
username = "username"
password = "password"

Configurare i parametri di rinnovo automatico

Anziché gestire manualmente i file di certificato, IoT Edge ha la possibilità predefinita di ottenere e rinnovare i certificati prima della scadenza. Il rinnovo del certificato richiede un metodo di rilascio che IoT Edge può gestire. Il server EST (Enrollment over Secure Transport) è un metodo di rilascio, ma IoT Edge può anche rinnovare automaticamente la CA di avvio rapido per impostazione predefinita. Il rinnovo del certificato viene configurato per tipo di certificato.

1. In config.toml trovare la sezione pertinente per il tipo di certificato da configurare. Ad esempio, è possibile cercare la parola chiave auto_renew.

2. Usando l'esempio del modello di configurazione, configurare il certificato di identità del dispositivo, la CA Edge o i certificati di identità EST. Il modello di esempio è:

   [REPLACE_WITH_CERT_TYPE]
   # ...
   method = "est"
   # ...
   
   [REPLACE_WITH_CERT_TYPE.auto_renew]
   rotate_key = true
   threshold = "80%" 
   retry = "4%"
   

3. Applicare la configurazione

   sudo iotege config apply
   

Nella tabella seguente sono elencate le operazioni di ogni opzione in auto_renew:

Parametro	Descrizione
rotate_key	Controlla se la chiave privata deve essere ruotata quando IoT Edge rinnova il certificato.
threshold	Imposta quando IoT Edge deve iniziare a rinnovare il certificato. Può essere specificato come: - Percentuale: numero intero compreso tra 0 e 100 seguito da %. Il rinnovo inizia in relazione alla durata del certificato. Ad esempio, se impostato su 80%, un certificato valido per 100 giorni inizia il rinnovo a 20 giorni prima della scadenza. - Tempo assoluto: numero intero seguito da min (minuti) o day (giorni). Il rinnovo inizia in relazione all'ora di scadenza del certificato. Ad esempio, se impostato su 4day per quattro giorni o 10min per 10 minuti, il certificato inizia a rinnovarsi in quel momento prima della scadenza. Per evitare errori di configurazione involontari in cui il valore threshold è maggiore della durata del certificato, è consigliabile usare la percentuale, quando possibile.
retry	Controlla la frequenza di ripetizione del rinnovo in caso di errore. Come threshold, può essere specificato in modo analogo come percentuale o tempo assoluto usando lo stesso formato.

Esempio: Rinnovare automaticamente il certificato di identità del dispositivo con EST

Per usare EST e IoT Edge per il rilascio e il rinnovo automatici dei certificati di identità del dispositivo, consigliati per la produzione, IoT Edge deve eseguire il provisioning come parte di un gruppo di registrazione basato su CA DPS. Ad esempio:

## DPS provisioning with X.509 certificate
[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"

[provisioning.attestation.identity_cert]
method = "est"
common_name = "my-device"

[provisioning.attestation.identity_cert.auto_renew]
rotate_key = true
threshold = "80%"
retry = "4%"

Il rinnovo automatico per la CA Edge deve essere abilitato quando il metodo di rilascio è impostato su EST. La scadenza della CA Edge deve essere evitata perché interrompe molte funzionalità di IoT Edge. Se una situazione richiede il controllo totale sul ciclo di vita del certificato della CA Edge, usare invece il metodo di gestione manuale della CA Edge.

Non usare EST o auto_renew con altri metodi di provisioning, incluso il provisioning manuale X.509 con l'hub IoT e DPS con registrazione singola. IoT Edge non può aggiornare le identificazioni personali del certificato in Azure quando viene rinnovato un certificato, impedendo così la riconnessione di IoT Edge.

Esempio: Gestione automatica della CA Edge con EST

Usare il rilascio e il rinnovo automatici della CA Edge con EST per la produzione. Dopo aver configurato il server EST, è possibile usare l'impostazione globale oppure eseguirne l'override in modo simile all'esempio seguente:

[edge_ca]
method = "est"

common_name = "my-edge-CA"
url = "https://ca.example.org/.well-known/est"

bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem"
bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem"

[edge_ca.auto_renew]
rotate_key = true
threshold = "90%"
retry = "2%"

Certificati del server del modulo

Il daemon Edge rilascia i certificati di identità e del server del modulo per l'uso da parte dei moduli Edge. È responsabilità dei moduli Edge rinnovare i propri certificati di identità e del server in base alle esigenze.

Rinnovo

I certificati del server possono essere rilasciati dal certificato della CA Edge. Indipendentemente dal metodo di rilascio, questi certificati devono essere rinnovati dal modulo. Se si sviluppa un modulo personalizzato, è necessario implementare la logica di rinnovo nel modulo.

Il modulo edgeHub supporta una funzionalità di rinnovo del certificato. È possibile configurare il rinnovo del certificato del server del modulo edgeHub usando le variabili di ambiente seguenti:

• ServerCertificateRenewAfterInMs: imposta la durata in millisecondi quando il certificato del server edgeHub viene rinnovato indipendentemente dall'ora di scadenza del certificato.
• MaxCheckCertExpiryInMs: imposta la durata in millisecondi quando il servizio edgeHub controlla la scadenza del certificato del server edgeHub. Se la variabile è impostata, il controllo viene eseguito indipendentemente dall'ora di scadenza del certificato.

Per altre informazioni sulle variabili di ambiente, vedere Variabili di ambiente EdgeHub ed EdgeAgent.

Modifiche apportate alla versione 1.2 e successive

• Il certificato della CA del dispositivo è stato rinominato come certificato della CA Edge.
• Il certificato della CA del carico di lavoro è stato deprecato. Ora lo strumento di gestione della sicurezza di IoT Edge genera il certificato del server edgeHub dell'hub di IoT Edge direttamente dal certificato della CA Edge, senza il certificato della CA del carico di lavoro intermedio tra di essi.
• Il file di configurazione predefinito ha un nuovo nome e un nuovo percorso, da /etc/iotedge/config.yaml a /etc/aziot/config.toml per impostazione predefinita. Il comando iotedge config import può essere usato per eseguire la migrazione delle informazioni di configurazione dalla posizione e sintassi precedenti a quelle nuove.

Passaggi successivi

L'installazione dei certificati in un dispositivo IoT Edge è un passaggio necessario prima di distribuire la soluzione nell'ambiente di produzione. Altre informazioni su come Preparare la distribuzione della soluzione IoT Edge nell'ambiente di produzione.