Levenscyclus en verlenging van certificaat

Clientcertificaatsleutelparen en CA-certificaten verlopen regelmatig. Uw netwerkinfrastructuur en apparaten moeten het verlopen van certificaten kunnen verwerken en een nieuw certificaat kunnen presenteren zonder de connectiviteit te verliezen. Basis-CA-certificaten, die worden gebruikt in RADIUS-serververificatie, en clientcertificaten, die worden gebruikt in apparaatverificatie, vereisen verschillende benaderingen om bij te werken.

Voorzichtigheid

Omdat certificaat-id's systeembreed zijn, kan een az sphere-opdracht of een functieaanroep waarmee een nieuw certificaat wordt toegevoegd een certificaat overschrijven dat is toegevoegd door een eerdere opdracht of functieaanroep, waardoor netwerkverbindingsfouten kunnen optreden. We raden u ten zeerste aan duidelijke procedures voor het bijwerken van certificaten te ontwikkelen en certificaat-id's zorgvuldig te kiezen.

Zie Certificaat-id's voor meer informatie over hoe Azure Sphere certificaat-id's gebruikt.

Een basis-CA-certificaat bijwerken

Een CA-certificaat is de basis-CA van het verificatiecertificaat op de RADIUS-server. Als het CA-certificaat verloopt of de PKI voor de server verandert, bijvoorbeeld als de server een nieuwe basis-CA verkrijgt van een andere certificeringsinstantie, kunnen Azure Sphere-apparaten de RADIUS-verificatieserver niet meer verifiëren. De apparaten moeten echter blijven functioneren.

Op een typisch draadloos netwerk is het niet mogelijk om een cutover met mesrand uit te voeren; Dat wil dus dat u niet alle Azure Sphere-apparaten kunt bijwerken op het exacte moment dat de basis-CA ongeldig wordt. Apparaten zijn mogelijk offline op het kritieke moment of de nauwkeurigheid van de tijdregistratie kan per installatie variëren. Uw toepassing op hoog niveau moet het nieuwe basis-CA-certificaat kunnen ophalen voordat het huidige certificaat verloopt of wordt gewijzigd, zodat het nieuwe certificaat indien nodig klaar is voor gebruik.

De aanbevolen aanpak is om een tweede netwerk te maken en in te schakelen dat dezelfde configuratie heeft als het bestaande netwerk, maar het nieuwe basis-CA-certificaat gebruikt. Wanneer het bestaande basis-CA-certificaat mislukt op het oorspronkelijke netwerk, probeert het besturingssysteem automatisch verbinding te maken met het tweede netwerk. De toepassing kan vervolgens het certificaat op het oorspronkelijke netwerk vervangen door de nieuwe basis-CA en het tweede netwerk verwijderen. Het apparaat kan vervolgens verbinding maken via het oorspronkelijke netwerk, dat nu de nieuwe basis-CA heeft. In de volgende afbeelding ziet u een overzicht van deze benadering.

Een toepassing op hoog niveau moet deze stappen volgen om naadloos een update van het basis-CA-certificaat te verwerken:

1. Als onderdeel van de normale werking configureert de toepassing Netwerk1 van het type WifiConfig_Security_Wpa2_EAP_TLS. Dit netwerk is gekoppeld aan het clientcertificaat voor het apparaat en aan de basis-CA1, de oorspronkelijke basis-CA voor de RADIUS-server.

2. Ongeveer 90 dagen voordat de RootCA verloopt, ontvangt het apparaat een cloud-naar-apparaatmelding dat binnenkort een nieuw basis-CA-certificaat voor de RADIUS-server vereist is. De melding kan worden geactiveerd door een netwerkbeheerder of andere operator; mogelijke meldingsmechanismen zijn een Azure IoT Hub- of Azure IoT Central-bericht over cloud-naar-apparaat.

   De netwerkbeheerder is verantwoordelijk voor het bijwerken van het certificaat op de RADIUS-server en ervoor te zorgen dat de Azure Sphere-apparaten op de juiste manier worden bijgewerkt.

3. De app verkrijgt een nieuwe basis-CA en roept CertStore_InstallRootCACertificate aan om deze op te slaan als hoofd-CA2.

4. De app maakt een nieuw netwerk, Network2, door WifiConfig_AddDuplicateNetwork aan te roepen om de Netwerk1-configuratie te dupliceren. Vervolgens wordt hoofd-CA2 gekoppeld aan netwerk 2 en wordt Network2 ingeschakeld. Als Netwerk2 is ingeschakeld op het apparaat en verbinding kan maken met internet, gebruikt het apparaat dit als Network1 niet beschikbaar is.

5. De app peilt dagelijks door WifiConfig_GetConnectedNetworkId aan te roepen om te bepalen met welk netwerk het apparaat is verbonden.

   Als de dagelijkse controle van het verbonden netwerk mislukt, kan de fout het gevolg zijn van een certificaatprobleem aan de server- of apparaatzijde, of van een ander probleem. Zie Netwerkproblemen oplossen voor hulp.

   Als het apparaat is verbonden met Network1, betekent dit dat het certificaat nog niet is verlopen en dat alles goed werkt. De app herhaalt deze stap totdat het apparaat verbinding maakt met Network2.

   Als het apparaat is verbonden met Network2, betekent dit dat het oude certificaat is verlopen, dat de bijgewerkte PKI is ingesteld op de RADIUS-server en dat het apparaat de server kan verifiëren met basis-CA2.

6. Wanneer het apparaat goed werkt met Network2, voltooit de app de wijzigingen in de netwerkconfiguratie:

   • Wijzigt de naam van hoofd-CA2 in Hoofd-CA1 door CertStore_MoveCertificate aan te roepen. Met deze functie wordt de verlopen basis-CA1 overschreven met de inhoud van hoofd-CA2.
   • Laadt de Configuratie van Network1 opnieuw door WifiConfig_ReloadConfig aan te roepen. De configuratie Netwerk1 komt nu overeen met het huidige netwerk.
   • Hiermee verwijdert u de Netwerk2-configuratie door WifiConfig_ForgetNetworkById aan te roepen.

Een clientcertificaat bijwerken

Het clientcertificaat bestaat uit het openbare en persoonlijke sleutelpaar dat wordt gebruikt om het Azure Sphere-apparaat te verifiëren. Net als het basis-CA-certificaat verloopt het clientcertificaat van tijd tot tijd en moet het apparaat een nieuw certificaat kunnen presenteren. Uw toepassing op hoog niveau is verantwoordelijk voor het verkrijgen van het nieuwe certificaat voordat het bestaande certificaat verloopt. Een app kan de datum en tijd ophalen waarop een certificaat verloopt door CertStore_GetCertificateNotAfter aan te roepen.

In de volgende afbeelding ziet u een overzicht van deze procedure. Met dit patroon kan uw certificaatupdatecode constante certificaat-id's gebruiken, zoals ClientCert1 en ClientCert2, in plaats van een unieke naam te maken voor elk nieuw certificaat. Bovendien zijn er geen netwerkwisselingen of opschoning van clientcertificaten vereist.

Een toepassing op hoog niveau moet deze stappen volgen om naadloos een update van het clientcertificaat af te handelen:

1. Als onderdeel van de normale werking configureert de toepassing Netwerk1 van het type WifiConfig_Security_Wpa2_EAP_TLS. Dit netwerk is gekoppeld aan het clientcertificaat voor het apparaat (ClientCert1) en aan de basis-CA voor de RADIUS-server. Voordat de app de updateprocedure start, wordt gecontroleerd of het apparaat is verbonden met Network1 door WifiConfig_GetNetworkIdByConfigName aan te roepen en WifiConfig_GetConnectedNetworkId. Als de netwerk-id's overeenkomen, weet de app zeker dat deze is verbonden met het beoogde netwerk.

2. De app roept CertStore_GetCertificateNotAfter regelmatig aan om te bepalen wanneer het clientcertificaat verloopt. De toepassing kan de vervaldatum ook opslaan in onveranderbare opslag; Het moet echter nog steeds de vervaldatum dagelijks en na elke herstart controleren.

   De app vergelijkt de vervaldatum en tijd met de huidige datum en tijd. Als het certificaat binnen een vooraf bepaalde drempelwaardeperiode verloopt, krijgt de app een nieuw certificaat. De duur van de drempelwaardeperiode is uw keuze. Als best practice raden we u aan om ten minste vier weken voor de vervaldatum een nieuw certificaat te verkrijgen voor het geval het apparaat lange tijd offline is of herhaaldelijk netwerk- of serverproblemen ondervindt. Hoe eerder u controleert, hoe meer tijd u hebt om eventuele problemen op te lossen.

3. De app krijgt een nieuw certificaat van de juiste certificaatverlener. De keuze van een certificaatverlener is de verantwoordelijkheid van de lokale netwerkbeheerder.

4. De app slaat het nieuwe certificaat op als ClientCert2 door CertStore_InstallClientCertificate aan te roepen en voegt het toe aan de configuratie van Network1 Wi-Fi door WifiConfig_SetClientCertStoreIdentifier aan te roepen.

5. De app laadt de configuratie van de Wi-Fi opnieuw door WifiConfig_ReloadConfig aan te roepen. Met deze stap wordt ClientCert2 beschikbaar gemaakt voor het apparaat voor gebruik in netwerkverbindingen.

6. Controleer of de netwerkverbinding is geslaagd.

   • Geslaagde verbinding betekent dat ClientCert2 nu geldig is.

     • Wijzig de naam van ClientCert2 in ClientCert1 door CertStore_MoveCertificate aan te roepen.

     • Schakel Netwerk1 uit door WifiConfig_SetNetworkEnabled aan te roepen om de status Ingeschakeld van het netwerk in te stellen op false en schakel Vervolgens Netwerk1 opnieuw in door WifiConfig_SetNetworkEnabled aan te roepen om de status Ingeschakeld in te stellen op true. Als u de configuratie uitschakelt en opnieuw inschakelt, wordt de inhoud van het certificaat waarvan de naam is gewijzigd beschikbaar voor de toepassing.

   • Mislukte verbinding betekent dat ClientCert2 nog niet geldig is of dat er een andere fout is opgetreden.

     • Als het certificaat nog niet geldig is, gaat u verder met stap 7 om de netwerkconfiguratie terug te zetten naar de oorspronkelijke status.
     • Als er een andere fout is opgetreden, raadpleegt u Netwerkproblemen oplossen voor hulp en probeert u de verbinding opnieuw.

7. Ongeacht of de netwerkverbinding is geslaagd, laadt u de Wi-Fi configuratie opnieuw door WifiConfig_ReloadConfig aan te roepen. Als de verbinding is geslaagd, gebruikt de opnieuw geladen configuratie het nieuwe ClientCert1, dat is vervangen door ClientCert2. Als de verbinding is mislukt, gebruikt de opnieuw geladen configuratie ClientCert1.