Esercitazione: Creare e caricare certificati per i test

  • Articolo

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

Tuttavia, la creazione di una CA privata self-managed che usa una CA radice interna perché l'ancoraggio di attendibilità è adeguato per gli ambienti di test. Una CA privata autogestito con almeno una CA subordinata concatenato 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 autofirmato per gli ambienti di produzione. Questa esercitazione viene presentata solo a scopo dimostrativo.

L'esercitazione seguente usa OpenSSL e il cookbook 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 hub IoT di Azure per C. Gli script vengono forniti solo a scopo dimostrativo. I certificati creati da tali certificati 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 della CA di test per esempi ed esercitazioni nel repository GitHub per hub IoT di Azure Device SDK 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.

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

  • 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 openSSL. In alternativa, è possibile scaricare OpenSSL predefinito da una terza parte. Per altre informazioni, vedere il 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 OPENSSL_CNF variabile di ambiente 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 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 Directory in cui vengono creati e archiviati i certificati CA per la CA radice.
    rootca/db Directory in cui vengono archiviati il database del certificato e i file di supporto per la CA radice.
    rootca/db/index Database del certificato per la CA radice. Il touch comando crea un file senza contenuto, per usarlo 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 File utilizzato per archiviare il numero di serie del certificato successivo da creare per la CA radice. Il openssl comando 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 File usato per archiviare i numeri di serie per i certificati revocati rilasciati dalla CA radice. Il echo comando invia 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 e 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 rootca directory 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 test. 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:

    • Criteri ca usati dalla CA radice per i campi DN (Distinguished Name) del certificato
    • Richieste di certificati create dalla CA radice
    • 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 ca_default sezione , è impostato su ../rootca perché questo file di configurazione viene usato anche durante la creazione del certificato per la CA subordinata. Il percorso relativo specificato consente a OpenSSL di passare dalla cartella CA subordinata alla cartella CA radice durante tale processo.

    Per altre informazioni sulla sintassi dei file di configurazione OpenSSL, vedere la pagina manuale della configurazione 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 (CSR) nella rootca directory e una chiave privata nella rootca/private directory. Per altre informazioni sul comando OpenSSL req , vedere la pagina manuale openssl-req nella documentazione di OpenSSL.

    Nota

    Anche se questa CA radice è a scopo di test 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 pass phrase PEM, come illustrato nell'esempio seguente, per il file di chiave privata. Immettere e confermare una pass phrase 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 CSR, rootca.csr, sia presente nella rootca directory e nel file di chiave privata, rootca.key, sia presente nella private sottodirectory prima di continuare.

  5. Nella finestra Git Bash eseguire il comando seguente per creare un certificato CA radice autofirmato. Il comando applica le estensioni di ca_ext file di configurazione 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 (CRL). Per altre informazioni sul comando OpenSSL ca , vedere la pagina 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 specificare la pass phrase PEM, come illustrato nell'esempio seguente, per il file di chiave privata. Dopo aver specificato la pass phrase, 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 dei certificati, verificare che sia il file del certificato, rootca.crt, sia presente nella rootca directory che il file del certificato PEM (con estensione pem) per il certificato sia presente nella rootca/certs directory. 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 di trust. In un ambiente di produzione, la catena di certificati di attendibilità consente una delega di attendibilità verso la firma dei dispositivi. Per altre informazioni sull'accesso dei dispositivi a una catena di certificati di attendibilità, vedere Autenticare i dispositivi con certificati ca X.509.

Analogamente alla CA radice, i file usati per creare e gestire la CA subordinata 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 che contiene la rootca directory . 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 i file di supporto per la CA subordinata in modo simile 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 subca directory 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 test, questo file fornisce a OpenSSL i valori necessari per configurare la CA subordinata di test. È 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 manuale del master di configurazione 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 (CSR) nella directory CA subordinata.

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

    Viene richiesto di immettere una pass phrase PEM, come illustrato nell'esempio seguente, per il file di chiave privata. Immettere e verificare una pass phrase 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 subca.csr CSR sia presente nella directory CA subordinata e che il file subca.key di chiave privata sia presente nella private sottodirectory prima di continuare.

  5. Nella finestra Git Bash eseguire il comando seguente per creare un certificato CA subordinato nella directory CA subordinata. Il comando applica le estensioni di sub_ca_ext file di configurazione al certificato. Queste estensioni indicano che il certificato è per una CA subordinata e può essere usato anche per firmare certificati ed elenchi di revoche di certificati (CRL). 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 la pass phrase, come illustrato nell'esempio seguente, per il file di chiave privata della CA radice. Dopo aver immesso la pass phrase, OpenSSL genera e visualizza i dettagli del certificato, quindi richiede di firmare ed eseguire il commit del certificato per la CA subordinata. Specificare y per entrambe le richieste di 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 dei certificati, verificare che il file subca.crt del certificato sia presente nella directory CA subordinata e che il file del certificato PEM (con estensione pem) per il certificato sia presente nella rootca/certs directory. 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, che lo usa per autenticare i dispositivi durante la registrazione e la connessione. I passaggi seguenti descrivono come caricare e verificare automaticamente il certificato ca subordinato nell'hub IoT.

  1. Nella portale di Azure passare all'hub IoT e selezionare Certificati dal menu della risorsa 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 del certificato PEM (con estensione pem) del certificato CA subordinato dalla rootca/certs directory da aggiungere nel campo Certificato con estensione pem o .cer file .

  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, chiave privata e certificato per i certificati client.

Il valore del campo Nome comune soggetto (CN) del certificato client deve essere impostato sul valore dell'ID dispositivo usato durante la registrazione del dispositivo corrispondente in hub IoT di Azure.

Effettuare le seguenti operazioni per:

  • Creare una chiave privata e una richiesta di firma del certificato (CSR) per un certificato client
  • Creare un certificato client firmato dal certificato ca subordinato

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

  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 csr 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 specifico è Il nome comune, che deve essere lo stesso nome del dispositivo specificato nel passaggio precedente. È possibile ignorare o fornire valori arbitrari per il resto delle richieste.

    Dopo aver specificato i dettagli del certificato, OpenSSL genera e visualizza i dettagli del certificato, 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 CSR sia presente nella directory CA subordinata e che il file di chiave privata sia presente nella private sottodirectory prima di continuare. Per altre informazioni sui formati dei file csr e delle chiavi private, 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 CA subordinata. Il comando applica le estensioni di client_ext file di configurazione 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 con il certificato CA subordinato.

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

    Viene richiesto di immettere la pass phrase, come illustrato nell'esempio seguente, per il file di chiave privata della CA subordinata. Dopo aver immesso la pass phrase, OpenSSL genera e visualizza i dettagli del certificato, quindi richiede di firmare ed eseguire il commit del certificato client per il dispositivo. Specificare y per entrambi i prompt per generare 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 dei certificati, verificare che il file di certificato per il certificato client sia presente nella directory CA subordinata e che il file del certificato PEM (con estensione pem) per il certificato client sia presente nella sottodirectory certs della directory 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 la sezione Registrare un nuovo dispositivo nell'hub IoT in Creare un hub IoT usando il portale di Azure.

Se sono presenti più dispositivi correlati da testare, è possibile usare il servizio Device Provisioning 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.

Per altre informazioni sui formati dei file di certificato, vedere Certificati X.509.