Gestire i certificati IoT Edge

Si applica a: IoT Edge 1.4

Importante

IoT Edge 1.4 è la versione supportata. 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 usata 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 con diffusione o la radice dell'autorità di certificazione dell'organizzazione. Spesso, si tratta in realtà di un certificato CA intermedio.

Prerequisiti

• È necessario avere familiarità con i concetti descritti in Comprendere come Azure IoT Edge usa i certificati, in particolare il modo in cui IoT Edge usa i certificati.

• Un dispositivo IoT Edge.

  Se non è configurato un dispositivo IoT Edge, è possibile crearne uno in una macchina virtuale di Azure. Seguire la procedura descritta in uno di questi articoli di avvio rapido per creare un dispositivo Linux virtuale o Creare un dispositivo Windows virtuale.

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

• config.toml Se non si basa sul modello, aprire il modello e usare le indicazioni commentate per aggiungere sezioni di configurazione seguendo 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 der con codifica base64 seguita da un -----END CERTIFICATE----- piè di pagina.
• Analogamente al certificato, la chiave privata può essere codificata in FORMATO DER binario o pem per rappresentazione testuale.
• Poiché pem è delineato, è anche possibile costruire un pem che combina sia il CERTIFICATE che 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 file comando 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 .pfx file 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 file comando . È possibile convertire un file PKCS#12 .pfx in file PEM usando il comando openssl pkcs12.

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

• Se è in formato DER (binary), 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 a 2048 bit RSA 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-2048 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
/var/aziot/certs/ Directory dei certificati	drwxr-xr-x (755)	aziotcs
File di certificato in /var/aziot/certs/	-wr-r--r-- (644)	aziotcs
/var/aziot/secrets/ directory delle chiavi	drwx------ (700)	aziotks
File chiave 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 l'autorizzazione corretti è 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 autofirmato 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 CA radice da un provider PKI.

2. Verificare 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 /var/aziot/certs directory:

   # 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 config.tomldi configurazione di IoT Edge individuare la sezione Trust bundle cert (Certificato bundle trust). 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 trust_bundle_cert chiave 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 trust lo rende disponibile per i moduli contenitore, ma non per ospitare moduli come Azure Device Update o Defender. Se si usano componenti a livello di host o si verificano altri problemi TLS, installare anche il certificato 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 certificato e di chiave privata

IoT Edge può usare i certificati esistenti e i file di chiave privata per autenticare o attestare Azure, rilasciare nuovi certificati server modulo ed eseguire l'autenticazione ai server EST. Per installarli:

1. Controllare i file di certificato e di chiave privata in base ai 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 e al servizio aziotcsaziotks chiavi 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.tomltrovare 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 dal provider PKI

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

Requisiti del certificato di identità del dispositivo:

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

Assicurarsi che il nome comune corrisponda all'ID dispositivo IoT Edge registrato con hub IoT o 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 testare senza accesso ai file di certificato forniti da un'infrastruttura a chiave pubblica, vedere Creare certificati demo per testare le funzionalità del dispositivo per generare un certificato di identità del dispositivo non di produzione e una chiave privata di breve durata.

Esempio di configurazione durante il provisioning con 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 l'autorità di certificazione edge

L'autorità di certificazione edge ha due modalità diverse:

• Avvio rapido è il comportamento predefinito. La guida introduttiva riguarda i test e non è adatto per la produzione.
• Per la modalità di produzione è necessario fornire un'origine personalizzata per il certificato della CA Edge e la chiave privata.

Guida introduttiva all'autorità di certificazione Edge

Per iniziare, IoT Edge genera automaticamente un certificato ca Edge quando viene avviato per la prima volta per impostazione predefinita. 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.

L'autorità di certificazione edge di avvio rapido abilita edgeHub e altri moduli di IoT Edge per avere un certificato server valido quando IoT Edge viene installato per la prima volta senza alcuna configurazione. Il certificato è necessario perché edgeHub i moduli o i dispositivi downstream devono stabilire canali di comunicazione sicuri. Senza la CA edge di avvio rapido, l'introduzione sarebbe notevolmente più difficile perché sarebbe necessario fornire un certificato server valido da un provider PKI o con 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 un'infrastruttura a chiave pubblica.

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

Personalizzare la durata per la CA edge di avvio rapido

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

[edge_ca]
auto_generated_edge_ca_expiry_days = 180

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

Rinnovare l'autorità di certificazione edge di avvio rapido

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

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

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

CA perimetrale nell'ambiente di produzione

Dopo aver eseguito lo spostamento in uno scenario di produzione o si vuole creare un dispositivo gateway, non è più possibile usare la CA edge di avvio rapido.

Un'opzione consiste nel fornire certificati personalizzati e gestirli manualmente. Tuttavia, per evitare il processo di gestione manuale manuale rischioso e soggetto a errori, usare un server EST quando possibile.

Attenzione

Il nome comune (CN) del certificato CA Edge non può corrispondere al parametro nome host del dispositivo definito nel file di configurazione del dispositivo config.toml o l'ID dispositivo registrato in 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 assegnare ai moduli nuovi certificati server, IoT Edge riavvia tutti i moduli quando il certificato ca Edge viene rinnovato.

Per ridurre al minimo i potenziali effetti negativi dei riavvii del modulo, pianificare il rinnovo del certificato 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 CA Edge dal provider PKI

Richiedere i file seguenti dal provider PKI:

• Certificato ca radice dell'infrastruttura a chiave pubblica (PKI)
• Certificato emittente/CA e chiave privata associata

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

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

Esempio del certificato 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, è consigliabile usare EST per la gestione automatica.

Gestione automatica dei certificati con il server EST

IoT Edge può interfacciarsi con un server Enrollment over Secure Transport (EST) 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, il certificato bootstrap e la chiave privata devono essere 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 a DPS o hub IoT.

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

   • Creare un server EST di test seguendo la procedura descritta in Esercitazione: Configurare la registrazione su Secure Transport Server per Azure IoT Edge.

   • Microsoft collabora con GlobalSign per fornire un account demo.

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

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

3. Specificare un URL predefinito per il server EST. In config.tomlaggiungere 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 di 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. La registrazione su server EST (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.tomltrovare 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: 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: 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 involontaria in cui è 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 a una percentuale o un 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à dei dispositivi, consigliato 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 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 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 est automatic Edge CA rilascio e rinnovo 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 dei moduli

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

Rinnovo

I certificati server possono essere rilasciati al di fuori del 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 in cui 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 e EdgeAgent.

Modifiche apportate alla versione 1.2 e successive

• Il certificato CA del dispositivo è stato rinominato come certificato CA Edge.
• Il certificato della CA del carico di lavoro è deprecato. A questo punto, il gestore della sicurezza di IoT Edge genera il certificato del server dell'hub edgeHub IoT Edge direttamente dal certificato della CA Edge, senza il certificato ca intermedio del carico di lavoro 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 iotedge config import comando può essere usato per eseguire la migrazione delle informazioni di configurazione dalla posizione precedente e dalla sintassi a quella nuova.

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.