Esercitazione: Creare e caricare certificati per i test
È 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
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}
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
Creare un file di testo denominato
rootca.conf
nellarootca
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
, nellaca_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
Nella finestra Git Bash eseguire il comando seguente per generare una richiesta di firma del certificato (CSR) nella
rootca
directory e una chiave privata nellarootca/private
directory. Per altre informazioni sul comando OpenSSLreq
, 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 nellarootca
directory e nel file di chiave privata,rootca.key
, sia presente nellaprivate
sottodirectory prima di continuare.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 OpenSSLca
, 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 nellarootca
directory che il file del certificato PEM (con estensione pem) per il certificato sia presente nellarootca/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
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 ..
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
Creare un file di testo denominato
subca.conf
nellasubca
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
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.
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 filesubca.key
di chiave privata sia presente nellaprivate
sottodirectory prima di continuare.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 nellarootca/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.
Nella portale di Azure passare all'hub IoT e selezionare Certificati dal menu della risorsa in Impostazioni di sicurezza.
Selezionare Aggiungi dalla barra dei comandi per aggiungere un nuovo certificato della CA.
Immettere un nome visualizzato per il certificato CA subordinato nel campo Nome certificato.
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 .Selezionare la casella accanto a Imposta stato certificato da verificare al caricamento.
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
Nella finestra di Git Bash assicurarsi di essere ancora nella
subca
directory.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.
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.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.