Ciclo di vita e rinnovo dei certificati
Importante
Questa è la documentazione di Azure Sphere (legacy). Azure Sphere (legacy) viene ritirato il 27 settembre 2027 e gli utenti devono eseguire la migrazione ad Azure Sphere (integrato) entro questo periodo. Usare il selettore di versione posizionato sopra il sommario per visualizzare la documentazione di Azure Sphere (integrata).
Le coppie certificato client-chiave e i certificati CA radice scadono regolarmente. L'infrastruttura di rete e i dispositivi devono essere in grado di gestire la scadenza dei certificati e di presentarne uno nuovo senza perdere connettività. I certificati CA radice, usati nell'autenticazione del server RADIUS, e i certificati client, usati nell'autenticazione del dispositivo, richiedono approcci diversi per l'aggiornamento.
Attenzione
Poiché gli ID certificato sono a livello di sistema, un comando azsphere o una chiamata di funzione che aggiunge un nuovo certificato può sovrascrivere un certificato aggiunto da un comando o una chiamata di funzione precedente, generando possibilmente errori di connessione di rete. È consigliabile sviluppare procedure ben definite per l'aggiornamento dei certificati e scegliere con attenzione gli ID certificato.
Per altre informazioni su come vengono usati gli ID certificato in Azure Sphere, vedere ID certificato.
Aggiornare un certificato CA radice
Per certificato CA si intende la CA radice del certificato di autenticazione nel server RADIUS. Se il certificato CA scade o l'infrastruttura PKI del server cambia, ad esempio se il server acquisisce un nuovo certificato CA radice da un'altra autorità di certificazione, i dispositivi Azure Sphere non possono più autenticare il server di autenticazione RADIUS. Tuttavia, i dispositivi devono continuare a funzionare.
In una tipica rete wireless non è possibile aggiornare tutti i dispositivi Azure Sphere nel momento esatto in cui il certificato CA radice diventa non valido. I dispositivi possono essere offline nel momento critico oppure è possibile che l'accuratezza del controllo temporale sia diversa tra le varie installazioni. L'applicazione di alto livello deve essere in grado di ottenere il nuovo certificato CA radice prima della scadenza o della modifica di quello corrente, in modo che sia pronto per l'uso quando necessario.
L'approccio consigliato consiste nel creare e abilitare una seconda rete con la stessa configurazione di quella esistente ma che usa il nuovo certificato CA radice. In caso di errore del certificato CA radice esistente nella rete originale, il sistema operativo proverà automaticamente a connettersi alla seconda rete. L'applicazione può quindi sostituire il certificato nella rete originale con il nuovo certificato CA radice ed eliminare la seconda rete. A quel punto il dispositivo può connettersi alla rete originale, che ora ha il nuovo certificato CA radice. Questo approccio è riepilogato nella figura seguente.
Per gestire facilmente un aggiornamento del certificato CA radice, un'applicazione di alto livello dovrà seguire questa procedura:
Come parte delle normali operazioni, l'applicazione configura la rete Network1 di tipo
WifiConfig_Security_Wpa2_EAP_TLS
. Questa rete è collegata al certificato client per il dispositivo e a Root CA1, ovvero il certificato radice CA originale per il server RADIUS.Circa 90 giorni prima della scadenza del certificato CA radice, il dispositivo riceve una notifica da cloud a dispositivo per avvisare che presto ne sarà necessario uno per il server RADIUS. La notifica può essere attivata da un amministratore di rete o da un altro operatore; i possibili meccanismi di notifica includono un messaggio da cloud a dispositivo hub IoT di Azure o Azure IoT Central.
L'amministratore di rete è responsabile dell'aggiornamento del certificato nel server RADIUS e di assicurarsi che i dispositivi Azure Sphere verranno aggiornati nel modo appropriato.
L'app acquisisce un nuovo certificato CA radice e chiama CertStore_InstallRootCACertificate per salvarlo come Root CA2.
L'app crea una nuova rete, Network2, chiamando WifiConfig_AddDuplicateNetwork per duplicare la configurazione di Network1. Collega quindi Root CA2 a Network2 e abilita questa seconda rete. Se Network2 è abilitata nel dispositivo e può connettersi a Internet, il dispositivo la userà qualora Network1 non sia disponibile.
L'app esegue il polling ogni giorno chiamando WifiConfig_GetConnectedNetworkId per determinare a quale rete è connesso il dispositivo.
Se il controllo giornaliero della rete connessa ha esito negativo, l'errore potrebbe essere causato da un problema di certificato, lato server o dispositivo, o di altro tipo. Per assistenza, vedere Risoluzione dei problemi di rete.
Se il dispositivo è connesso a Network1, significa che il certificato non è ancora scaduto e che tutto funziona correttamente. L'app ripete questo passaggio fino a quando il dispositivo non si connette a Network2.
Se il dispositivo è connesso a Network2, significa che il certificato precedente è scaduto, l'infrastruttura PKI aggiornata è configurata nel server RADIUS e il dispositivo è in grado di autenticare il server usando il certificato Root CA2.
Quando il dispositivo funziona correttamente con Network2, l'app completa le modifiche della configurazione di rete:
- Rinomina Root CA2 in Root CA1 chiamando CertStore_MoveCertificate. Questa funzione sovrascrive il certificato Root CA1 scaduto con il contenuto di Root CA2.
- Ricarica quindi la configurazione di Network1 chiamando WifiConfig_PersistConfig. La configurazione di Network1 corrisponde ora alla rete corrente.
- Elimina la configurazione di Network2 chiamando WifiConfig_ForgetNetworkById.
Aggiornare un certificato client
Il certificato client comprende la coppia di chiavi pubblica e privata usate per autenticare il dispositivo Azure Sphere. Analogamente al certificato CA radice, il certificato client scadrà di tanto in tanto e il dispositivo deve essere in grado di presentarne uno nuovo. L'applicazione di alto livello è responsabile del recupero del nuovo certificato prima della scadenza di quello esistente. Un'app può ottenere la data e l'ora di scadenza di un certificato chiamando CertStore_GetCertificateNotAfter.
Questa procedura è riepilogata nella figura seguente. Questo modello consente al codice di aggiornamento del certificato di usare gli ID certificato costanti, ad esempio ClientCert1 e ClientCert2, invece di creare un nome univoco per ogni nuovo certificato. Inoltre, non richiede scambi di rete o la pulizia del certificato client.
Per gestire facilmente un aggiornamento del certificato client, un'applicazione di alto livello dovrà seguire questa procedura:
Come parte delle normali operazioni, l'applicazione configura la rete Network1 di tipo
WifiConfig_Security_Wpa2_EAP_TLS
. Questa rete è collegata al certificato client per il dispositivo (ClientCert1) e al certificato radice CA per il server RADIUS. Prima di avviare la procedura di aggiornamento, l'app verifica che il dispositivo sia connesso a Network1 chiamando WifiConfig_GetNetworkIdByConfigName e WifiConfig_GetConnectedNetworkId. Se gli ID di rete corrispondono, significa che l'app è connessa alla rete prevista.L'app chiama CertStore_GetCertificateNotAfter a intervalli regolari per determinare quando scadrà il certificato client. In alternativa, l'applicazione potrebbe archiviare la data di scadenza nell'archiviazione modificabile, ma deve comunque controllare la scadenza ogni giorno e dopo ogni riavvio.
L'app confronta la data e l'ora di scadenza con la data e l'ora correnti. Se il certificato scade entro un periodo di soglia predeterminato, l'app ottiene un nuovo certificato. La durata del periodo di soglia è configurabile dall'utente. Come procedura consigliata, è consigliabile ottenere un nuovo certificato almeno quattro settimane prima della scadenza nel caso in cui il dispositivo sia offline per un lungo periodo di tempo o si verifichino problemi di rete o server ripetuti. Quanto prima si verifica, maggiore sarà il tempo a disposizione per risolvere eventuali problemi.
L'app ottiene un nuovo certificato dall'autorità di certificazione appropriata. La scelta di un'autorità di certificazione è responsabilità dell'amministratore di rete locale.
L'app salva il nuovo certificato come ClientCert2 chiamando CertStore_InstallClientCertificate e lo aggiunge alla configurazione Wi-Fi di Network1 chiamando WifiConfig_SetClientCertStoreIdentifier.
L'app ricarica la configurazione Wi-Fi chiamando WifiConfig_ReloadConfig. Con questo passaggio, ClientCert2 diventa disponibile per l'uso da parte del dispositivo nelle connessioni di rete.
Controllare se la connessione di rete è riuscita.
Se la connessione è riuscita, ClientCert2 è ora valido.
Rinominare ClientCert2 in ClientCert1 chiamando CertStore_MoveCertificate.
Disabilitare la rete Network1 chiamando WifiConfig_SetNetworkEnabled per impostarne lo stato di abilitazione su False e quindi riabilitarla chiamando WifiConfig_SetNetworkEnabled per impostare lo stato di abilitazione su
true
. La disabilitazione e la riabilitazione della configurazione rende disponibile per l'applicazione il contenuto del certificato rinominato.
La mancata connessione indica che ClientCert2 non è ancora valido o che si è verificato un altro errore.
- Se il certificato non è ancora valido, continuare con il passaggio 7 per ripristinare lo stato originale della configurazione di rete.
- Se si è verificato un altro errore, vedere Risoluzione dei problemi di rete per assistenza e ripetizione della connessione.
A prescindere dal fatto che la connessione di rete sia riuscita o meno, ricaricare la configurazione Wi-Fi chiamando WifiConfig_ReloadConfig. Se la connessione è riuscita, la configurazione ricaricata userà il nuovo certificato ClientCert1, che è stato sostituito da ClientCert2. Se la connessione non è riuscita, la configurazione ricaricata userà ClientCert1.