Condividi tramite

Esercitazione: Creare e caricare i certificati per i test

  • Articolo

È possibile usare certificati X.509 per autenticare i dispositivi dell'hub IoT. Per gli ambienti di produzione, è consigliabile acquistare un certificato della CA X.509 da un fornitore di servizi di certificazione professionale. È quindi possibile rilasciare certificati all'interno dell'organizzazione da un'autorità di certificazione (CA) interna autogestita concatenata al certificato della CA acquistato come parte di una strategia completa di infrastruttura a chiave pubblica (PKI). Per altre informazioni sull'ottenimento di un certificato della CA X.509 da un fornitore di servizi certificati professionali, vedere la sezione Ottenere un certificato della CA X.509 di Autenticare i dispositivi con certificati CA X.509.

Tuttavia, per gli ambienti di test è adeguato creare una CA privata e autogestita che usa una CA radice interna come trust anchor. Una CA privata e autogestita con almeno una CA subordinata concatenata alla CA radice interna, con certificati client per i dispositivi firmati dalle CA subordinate, consente di simulare un ambiente di produzione consigliato.

Importante

Non è consigliabile usare certificati autofirmati per gli ambienti di produzione. Questa esercitazione viene presentata solo a scopo dimostrativo.

L'esercitazione seguente usa OpenSSL e la guida di riferimento dettagliata di OpenSSL per descrivere come eseguire le attività seguenti:

  • Creare un'autorità di certificazione radice interna e un certificato CA radice
  • Creare una CA subordinata interna e un certificato CA subordinato, firmato dal certificato CA radice interno
  • Caricare il certificato CA subordinato nell'hub IoT a scopo di test
  • Usare la CA subordinata per creare certificati client per i dispositivi IoT da testare con l'hub IoT

Nota

Microsoft fornisce script di PowerShell e Bash per comprendere come creare certificati X.509 personalizzati e autenticarli in un hub IoT. Gli script sono inclusi nell'SDK per dispositivi dell'hub IoT di Azure per C. Gli script vengono forniti a scopo puramente dimostrativo. I certificati creati non devono essere usati per l'ambiente di produzione. I certificati contengono password hardcoded ("1234") e scadono dopo 30 giorni. È necessario usare le proprie procedure consigliate per la creazione e la gestione della durata dei certificati in un ambiente di produzione. Per altre informazioni, vedere Gestione dei certificati CA di prova per esempi e certificazioni nel repository GitHub per l'SDK per dispositivi dell'hub IoT di Azure per C.

Prerequisiti

  • Una sottoscrizione di Azure. Se non si ha una sottoscrizione di Azure, creare un account gratuito prima di iniziare.

  • Un hub IoT nella sottoscrizione di Azure. Se non si ha ancora un hub, è possibile seguire la procedura descritta in Creare un hub IoT.

  • L'ultima versione di Git. Verificare che Git venga aggiunto alle variabili di ambiente accessibili alla finestra di comando. Vedere gli strumenti client Git di Software Freedom Conservancy per la versione più recente degli strumenti git da installare, tra cui Git Bash, l'app da riga di comando che è possibile usare per interagire con il repository Git locale.

  • Un'installazione di OpenSSL. In Windows l'installazione di Git include un'installazione di OpenSSL. È possibile accedere a OpenSSL dal prompt di Git Bash. Per verificare che OpenSSL sia installato, aprire un prompt di Git Bash e immettere openssl version.

    Nota

    A meno che non si abbia familiarità con OpenSSL e che sia già installato nel computer Windows, è consigliabile usare OpenSSL dal prompt di Git Bash. In alternativa, è possibile scegliere di scaricare il codice sorgente e compilare OpenSSL. Per altre informazioni, vedere la pagina Download di OpenSSL. In alternativa, è possibile scaricare OpenSSL predefinito da una terza parte. Per altre informazioni, vedere la pagina Wiki di OpenSSL. Microsoft non garantisce la validità dei pacchetti scaricati da terze parti. Se si sceglie di compilare o scaricare OpenSSL, assicurarsi che il file binario OpenSSL sia accessibile nel percorso e che la variabile di ambiente OPENSSL_CNF sia impostata sul percorso del file openssl.cnf.

Creare una CA radice

Prima, è necessario creare un'autorità di certificazione radice interna e un certificato CA radice autofirmato da usare come trust anchor e da cui è possibile creare altri certificati per il test. I file usati per creare e gestire la CA radice interna vengono archiviati in una struttura di cartelle e inizializzati come parte di questo processo. Effettuare le seguenti operazioni per:

  • Creare e inizializzare le cartelle e i file usati dalla CA radice
  • Creare un file di configurazione usato da OpenSSL per configurare la CA radice e i certificati creati con la CA radice
  • Richiedere e creare un certificato CA autofirmato che funge da certificato CA radice

  1. Avviare una finestra Git Bash ed eseguire il comando seguente, sostituendo {base_dir} con la directory desiderata in cui creare i certificati in questa esercitazione.

    cd {base_dir}

  2. Nella finestra Git Bash eseguire i comandi seguenti, uno alla volta. Questo passaggio crea la struttura di directory e i file di supporto seguenti per la CA radice.

    Directory o file Descrizione
    rootca Directory radice della CA radice.
    rootca/certs La directory in cui vengono creati e archiviati i certificati CA per la CA radice.
    rootca/db La directory in cui vengono archiviati il database del certificato e i file di supporto per la CA radice.
    rootca/db/index Il database del certificato per la CA radice. Il comando touch crea un file senza contenuto, che verrà usato in un secondo momento. Il database del certificato è un file di testo normale gestito da OpenSSL che contiene informazioni sui certificati rilasciati. Per altre informazioni sul database dei certificati, vedere la pagina del manuale openssl-ca.
    rootca/db/serial Un file utilizzato per archiviare il numero di serie del certificato successivo da creare per la CA radice. Il comando openssl crea un numero casuale a 16 byte in formato esadecimale, quindi lo archivia in questo file per inizializzare il file per la creazione del certificato CA radice.
    rootca/db/crlnumber Un file usato per archiviare i numeri di serie per i certificati revocati rilasciati dalla CA radice. Il comando echo invia tramite pipe un numero di serie di esempio, 1001, nel file.
    rootca/private La directory in cui vengono archiviati i file privati per la CA radice, inclusa la chiave privata.
    I file in questa directory devono essere protetti.    		 
    mkdir rootca
cd rootca
mkdir certs db private
chmod 700 private
touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber

  3. Creare un file di testo denominato rootca.conf nella directory rootca creata nel passaggio precedente. Aprire il file in un editor di testo e quindi copiare e salvare le impostazioni di configurazione OpenSSL seguenti in tale file.

    Il file fornisce a OpenSSL i valori necessari per configurare la CA radice di prova. Per questo esempio, il file configura una CA radice denominata rootca usando le directory e i file creati nei passaggi precedenti. Il file fornisce anche le impostazioni di configurazione per:

    • I criteri CA usati dalla CA radice per i campi Nome distinto del certificato
    • Richieste di certificati create dalla CA radice
    • Le estensioni X.509 applicate ai certificati CA radice, ai certificati CA subordinati e ai certificati client rilasciati dalla CA radice

    Nota

    L'attributo home nella sezione ca_default è impostato su ../rootca perché questo file di configurazione viene usato anche per creare il certificato per la CA subordinata. Il percorso relativo specificato consente a OpenSSL di passare dalla cartella della CA subordinata alla cartella della CA radice durante tale processo.

    Per altre informazioni sulla sintassi dei file di configurazione OpenSSL, vedere la pagina del manuale config nella documentazione di OpenSSL.

    [default]
name                     = rootca
domain_suffix            = exampledomain.com
aia_url                  = http://$name.$domain_suffix/$name.crt
crl_url                  = http://$name.$domain_suffix/$name.crl
default_ca               = ca_default
name_opt                 = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
commonName               = "rootca_common_name"

[ca_default]
home                     = ../rootca
database                 = $home/db/index
serial                   = $home/db/serial
crlnumber                = $home/db/crlnumber
certificate              = $home/$name.crt
private_key              = $home/private/$name.key
RANDFILE                 = $home/private/random
new_certs_dir            = $home/certs
unique_subject           = no
copy_extensions          = none
default_days             = 3650
default_crl_days         = 365
default_md               = sha256
policy                   = policy_c_o_match

[policy_c_o_match]
countryName              = optional
stateOrProvinceName      = optional
organizationName         = optional
organizationalUnitName   = optional
commonName               = supplied
emailAddress             = optional

[req]
default_bits             = 2048
encrypt_key              = yes
default_md               = sha256
utf8                     = yes
string_mask              = utf8only
prompt                   = no
distinguished_name       = ca_dn
req_extensions           = ca_ext

[ca_ext]
basicConstraints         = critical,CA:true
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[sub_ca_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:true,pathlen:0
extendedKeyUsage         = clientAuth,serverAuth
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[client_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:false
extendedKeyUsage         = clientAuth
keyUsage                 = critical,digitalSignature
subjectKeyIdentifier     = hash

  4. Nella finestra Git Bash eseguire il comando seguente per generare una richiesta di firma del certificato nella directory rootca e una chiave privata nella directory rootca/private. Per altre informazioni sul comando req di OpenSSL, vedere la pagina del manuale openssl-req nella documentazione di OpenSSL.

    Nota

    Anche se questa CA radice è a scopo di prova e non verrà esposta come parte di un'infrastruttura a chiave pubblica (PKI), è consigliabile non copiare o condividere la chiave privata.

    winpty openssl req -new -config rootca.conf -out rootca.csr -keyout private/rootca.key

    Viene richiesto di immettere una passphrase PEM, come illustrato nell'esempio seguente, per il file di chiave privata. Immettere e confermare una passphrase per generare la chiave privata e la richiesta di firma del certificato.

    Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

    Verificare che il file di richiesta di firma del certificato, rootca.csr, sia presente nella directory rootca e che il file di chiave privata, rootca.key, sia presente nella sottodirectory private prima di continuare.

  5. Nella finestra Git Bash eseguire il comando seguente per creare un certificato CA radice autofirmato. Il comando applica le estensioni del file di configurazione ca_ext al certificato. Queste estensioni indicano che il certificato è per una CA radice e può essere usato per firmare certificati ed elenchi di revoche di certificati. Per altre informazioni sul comando ca di OpenSSL, vedere la pagina del manuale openssl-ca nella documentazione di OpenSSL.

    winpty openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt -extensions ca_ext

    Viene richiesto di fornire una passphrase PEM, come illustrato nell'esempio seguente, per il file di chiave privata. Dopo aver specificato la passphrase, OpenSSL genera un certificato, quindi richiede di firmare ed eseguire il commit del certificato per la CA radice. Specificare y per entrambi i prompt per generare il certificato autofirmato per la CA radice.

    Using configuration from rootca.conf
Enter pass phrase for ../rootca/private/rootca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:51:41 2033 GMT (3650 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated

    Dopo che OpenSSL aggiorna il database del certificato, verificare che il file del certificato, rootca.crt, sia presente nella directory rootca e che il file del certificato PEM (con estensione .pem) per il certificato sia presente nella directory rootca/certs. Il nome del file con estensione .pem corrisponde al numero di serie del certificato CA radice.

Creare una CA subordinata

Dopo aver creato la CA radice interna, è necessario creare una CA subordinata da usare come CA intermedia con cui firmare i certificati client per i dispositivi. In teoria, non è necessario creare una CA subordinata; è possibile caricare il certificato CA radice nell'hub IoT e firmare i certificati client direttamente dalla CA radice. Tuttavia, l'uso di una CA subordinata come CA intermedia per firmare più attentamente i certificati client simula un ambiente di produzione consigliato, in cui la CA radice viene mantenuta offline. È anche possibile usare una CA subordinata per firmare un'altra CA subordinata, che a sua volta può firmare un'altra CA subordinata e così via. L'uso di CA subordinate per firmare altre CA subordinate crea una gerarchia di CA intermedie come parte di una catena di certificati. In un ambiente di produzione, la catena di certificati consente una delega dell'attendibilità dei dispositivi di firma. Per altre informazioni sui dispositivi di firma in una catena di certificati, vedere Autenticare i dispositivi con certificati della CA X.509.

Come per la CA radice, i file usati per creare e gestire la CA subordinata interna vengono archiviati in una struttura di cartelle e inizializzati come parte di questo processo. Effettuare le seguenti operazioni per:

  • Creare e inizializzare le cartelle e i file usati dalla CA subordinata
  • Creare un file di configurazione usato da OpenSSL per configurare la CA subordinata e i certificati creati con la CA subordinata
  • Richiedere e creare un certificato CA firmato dalla CA radice che funge da certificato CA subordinato

  1. Tornare alla directory di base contenente la directory rootca. Per questo esempio, sia la CA radice che la CA subordinata si trovano nella stessa directory di base.

    cd ..

  2. Nella finestra Git Bash eseguire i comandi seguenti, uno alla volta.

    Questo passaggio crea una struttura di directory e file di supporto per la CA subordinata simili alla struttura di cartelle e ai file creati per la CA radice nella sezione precedente.

    mkdir subca
cd subca
mkdir certs db private
chmod 700 private
touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber

  3. Creare un file di testo denominato subca.conf nella directory subca creata nel passaggio precedente. Aprire il file in un editor di testo e quindi copiare e salvare le impostazioni di configurazione OpenSSL seguenti in tale file.

    Come per il file di configurazione per la CA radice di prova, questo file fornisce a OpenSSL i valori necessari per configurare la CA subordinata di prova. È possibile creare più CA subordinate per la gestione di scenari o ambienti di test.

    Per altre informazioni sulla sintassi dei file di configurazione OpenSSL, vedere la pagina del manuale master config nella documentazione di OpenSSL.

    [default]
name                     = subca
domain_suffix            = exampledomain.com
aia_url                  = http://$name.$domain_suffix/$name.crt
crl_url                  = http://$name.$domain_suffix/$name.crl
default_ca               = ca_default
name_opt                 = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
commonName               = "subca_common_name"

[ca_default]
home                     = ../subca
database                 = $home/db/index
serial                   = $home/db/serial
crlnumber                = $home/db/crlnumber
certificate              = $home/$name.crt
private_key              = $home/private/$name.key
RANDFILE                 = $home/private/random
new_certs_dir            = $home/certs
unique_subject           = no
copy_extensions          = copy
default_days             = 365
default_crl_days         = 90
default_md               = sha256
policy                   = policy_c_o_match

[policy_c_o_match]
countryName              = optional
stateOrProvinceName      = optional
organizationName         = optional
organizationalUnitName   = optional
commonName               = supplied
emailAddress             = optional

[req]
default_bits             = 2048
encrypt_key              = yes
default_md               = sha256
utf8                     = yes
string_mask              = utf8only
prompt                   = no
distinguished_name       = ca_dn
req_extensions           = ca_ext

[ca_ext]
basicConstraints         = critical,CA:true
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[sub_ca_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:true,pathlen:0
extendedKeyUsage         = clientAuth,serverAuth
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[client_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:false
extendedKeyUsage         = clientAuth
keyUsage                 = critical,digitalSignature
subjectKeyIdentifier     = hash

  4. Nella finestra Git Bash eseguire i comandi seguenti per generare una chiave privata e una richiesta di firma del certificato nella directory della CA subordinata.

    winpty openssl req -new -config subca.conf -out subca.csr -keyout private/subca.key

    Viene richiesto di immettere una passphrase PEM, come illustrato nell'esempio seguente, per il file di chiave privata. Immettere e verificare una passphrase per generare la chiave privata e la richiesta di firma del certificato.

    Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

    Verificare che il file di richiesta di firma del certificato subca.csr sia presente nella directory della CA subordinata e che il file di chiave privata subca.key sia presente nella sottodirectory private prima di continuare.

  5. Nella finestra Git Bash eseguire il comando seguente per creare un certificato CA subordinato nella directory della CA subordinata. Il comando applica le estensioni del file di configurazione sub_ca_ext al certificato. Queste estensioni indicano che il certificato è per una CA subordinata e che può essere usato anche per firmare certificati ed elenchi di revoche di certificati. A differenza del certificato CA radice, questo certificato non è autofirmato. Al contrario, il certificato CA subordinato viene firmato con il certificato CA radice, stabilendo una catena di certificati simile a quella usata per un'infrastruttura a chiave pubblica (PKI). Il certificato CA subordinato viene quindi usato per firmare i certificati client per il test dei dispositivi.

    winpty openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt -extensions sub_ca_ext

    Viene richiesto di immettere una passphrase, come illustrato nell'esempio seguente, per il file di chiave privata della CA radice. Dopo aver immesso la passphrase, OpenSSL genera un certificato e ne mostra i dettagli, quindi richiede di firmare ed eseguire il commit del certificato per la CA subordinata. Specificare y per entrambi i prompt per generare il certificato per la CA subordinata.

    Using configuration from rootca.conf
Enter pass phrase for ../rootca/private/rootca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:55:00 2024 GMT (365 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated

    Dopo che OpenSSL aggiorna il database del certificato, verificare che il file del certificato subca.crt sia presente nella directory della CA subordinata e che il file del certificato PEM (con estensione .pem) per il certificato sia presente nella directory rootca/certs. Il nome del file con estensione .pem corrisponde al numero di serie del certificato CA subordinato.

Registrare il certificato CA subordinato nell'hub IoT

Registrare il certificato CA subordinato nell'hub IoT in cui viene usato per autenticare i dispositivi durante la connessione e la registrazione. I passaggi seguenti descrivono come caricare e verificare automaticamente il certificato CA subordinato nell'hub IoT.

  1. Nel portale di Azure passare all'hub IoT e selezionare Certificati dal menu delle risorse, in Impostazioni di sicurezza.

  2. Selezionare Aggiungi dalla barra dei comandi per aggiungere un nuovo certificato della CA.

  3. Immettere un nome visualizzato per il certificato CA subordinato nel campo Nome certificato.

  4. Selezionare il file di certificato PEM (con estensione .pem) del certificato CA subordinato dalla directory rootca/certs da aggiungere nel campo File di certificato con estensione PEM o CER.

  5. Selezionare la casella accanto a Imposta stato certificato da verificare al caricamento.

    Screenshot che mostra come verificare automaticamente lo stato del certificato al caricamento.

  6. Seleziona Salva.

Il certificato CA subordinato caricato viene visualizzato con lo stato impostato su Verificato nella scheda Certificati del riquadro di lavoro.

Creare un certificato client per un dispositivo

Dopo aver creato la CA subordinata, è possibile creare certificati client per i dispositivi. I file e le cartelle creati per la CA subordinata vengono usati per archiviare i file CSR, della chiave privata e del certificato per i certificati client.

Il certificato client deve avere il valore del campo Nome comune del soggetto impostato sul valore dell'ID dispositivo usato per la registrazione nell'hub IoT di Azure.

Effettuare le seguenti operazioni per:

  • Creare una chiave privata e una richiesta di firma del certificato per un certificato client
  • Creare un certificato client firmato dal certificato CA subordinato

  1. Nella finestra di Git Bash assicurarsi di essere ancora nella directory subca.

  2. Nella finestra Git Bash eseguire i comandi seguenti, uno alla volta. Sostituire il segnaposto con un nome per il dispositivo IoT, ad esempio testdevice. Questo passaggio crea la chiave privata e la richiesta di firma per il certificato client.

    Questo passaggio crea una chiave privata RSA a 2048 bit per il certificato client e quindi genera una richiesta di firma del certificato usando tale chiave privata.

    winpty openssl genpkey -out private/<DEVICE_NAME>.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048
winpty openssl req -new -key private/<DEVICE_NAME>.key -out <DEVICE_NAME>.csr

  3. Quando richiesto, specificare i dettagli del certificato, come illustrato nell'esempio seguente.

    L'unico prompt per cui è necessario specificare un valore è Nome comune, che deve corrispondere al nome del dispositivo specificato nel passaggio precedente. È possibile ignorare o fornire valori arbitrari per il resto delle richieste.

    Dopo aver fornito i dettagli del certificato, OpenSSL genera un certificato e ne mostra i dettagli, quindi richiede di firmare ed eseguire il commit del certificato per la CA subordinata. Specificare y per entrambi i prompt per generare il certificato per la CA subordinata.

    -----
Country Name (2 letter code) [XX]:.
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:.
Organization Name (eg, company) [Default Company Ltd]:.
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server hostname) []:'<DEVICE_NAME>'
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

    Verificare che il file di richiesta di firma del certificato sia presente nella directory della CA subordinata e che il file di chiave privata sia presente nella sottodirectory private prima di continuare. Per altre informazioni sui formati dei file di richiesta della firma del certificato e di chiave privata, vedere Certificati X.509.

  4. Nella finestra Git Bash eseguire il comando seguente, sostituendo i segnaposto del nome del dispositivo con lo stesso nome usato nei passaggi precedenti.

    Questo passaggio crea un certificato client nella directory della CA subordinata. Il comando applica le estensioni del file di configurazione client_ext al certificato. Queste estensioni indicano che il certificato è per un certificato client, che non può essere usato come certificato della CA. Il certificato client viene firmato dal certificato CA subordinato.

    winpty openssl ca -config subca.conf -in <DEVICE_NAME>.csr -out <DEVICE_NAME>.crt -extensions client_ext

    Viene richiesto di immettere una passphrase, come illustrato nell'esempio seguente, per il file di chiave privata della CA subordinata. Dopo aver immesso la passphrase, OpenSSL genera un certificato e ne mostra i dettagli, quindi richiede di firmare ed eseguire il commit del certificato client per il dispositivo. Specificare y affinché entrambi i prompt generino il certificato client.

    Using configuration from subca.conf
Enter pass phrase for ../subca/private/subca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:51:41 2024 GMT (365 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated

    Dopo che OpenSSL aggiorna il database del certificato, verificare che il file del certificato client sia presente nella directory della CA subordinata e che il file del certificato PEM (con estensione .pem) per il certificato client sia presente nella sottodirectory certs della directory della CA subordinata. Il nome del file con estensione .pem corrisponde al numero di serie del certificato client.

Passaggi successivi

È possibile registrare il dispositivo con l'hub IoT per testare il certificato client creato per tale dispositivo. Per altre informazioni sulla registrazione di un dispositivo, vedere Creare e gestire le identità dei dispositivi.

Se sono presenti più dispositivi correlati da testare, è possibile usare il servizio Device Provisioning in hub IoT di Azure per effettuare il provisioning di più dispositivi in un gruppo di registrazione. Per altre informazioni sull'uso dei gruppi di registrazione nel servizio Device Provisioning, vedere Esercitazione: Effettuare il provisioning di più dispositivi X.509 usando i gruppi di registrazione.