Share via


Certifikatanvändning med Azure Sphere

Det här avsnittet innehåller en översikt över Azure Sphere-certifikatet "landskap": de typer av certifikat som de olika Azure Sphere-komponenterna använder, var de kommer ifrån, var de lagras, hur de uppdateras och hur du kommer åt dem när det behövs. Dessutom beskrivs hur Azure Sphere OS, SDK och tjänster gör certifikathantering enklare för dig. Vi förutsätter att du har grundläggande kunskaper om certifikatutfärdare och förtroendekedjan.

Azure Sphere-enheter

Alla Azure Sphere-enheter använder Trusted Root-butiken, som är en del av Azure Sphere-operativsystemet. Det betrodda rotarkivet innehåller en lista med rotcertifikat som används för att verifiera identiteten för Azure Sphere-säkerhetstjänsten när enheten ansluts för enhetsautentisering och attestation (DAA), OTA-uppdatering (over-the-air) eller felrapportering. Dessa certifikat tillhandahålls med operativsystemet.

När det dagliga certifikatet lyckas får enheten två certifikat: ett uppdateringscertifikat och ett kundcertifikat. Med uppdateringscertifikatet kan enheten ansluta till Azure Sphere Update Service för att hämta programuppdateringar och ladda upp felrapporter. den är inte tillgänglig för program eller via kommandoraden. Kundcertifikatet, som ibland kallas DAA-certifikatet, kan användas av program för att ansluta till tredjepartstjänster som wolfSSL som använder TLS (Transport Layer Security). Certifikatet är giltigt i 24 timmar. Program kan hämta den programmässigt genom att anropa funktionen DeviceAuth_GetCertificatePath.

Enheter som ansluter till Azure-baserade tjänster som Azure IoT Hub, Azure IoT Central och Azure IoT Edge måste presentera sitt CERTIFIKAT för Azure Sphere-katalogen för att autentisera azure-sfärkatalogen. Kommandot az sphere ca-certificate download i CLI returnerar katalogen CA-certifikatet för sådana användningsområden.

EAP-TLS-nätverksanslutningar

Enheter som ansluter till ett EAP-TLS-nätverk behöver certifikat för att autentisera med nätverkets RADIUS-server. Om du vill autentisera som klient måste enheten överföra ett klientcertifikat till RADIUS. För att kunna utföra ömsesidig autentisering måste enheten också ha ett rotcertifikatutfärdarcertifikat för RADIUS-servern så att den kan autentisera servern. Microsoft tillhandahåller inte något av dessa certifikat. du eller nätverksadministratören ansvarar för att fastställa rätt certifikatutfärdare för nätverkets RADIUS-server och sedan skaffa nödvändiga certifikat från utfärdaren.

För att få certifikaten för RADIUS-servern måste du autentisera till certifikatutfärdare. Du kan använda DAA-certifikatet, som tidigare nämnts, för detta ändamål. När du har skaffat certifikaten för RADIUS-servern bör du lagra dem i enhetscertifikatarkivet. Lagring av enhetscertifikat är endast tillgängligt för autentiserande i ett skyddat nätverk med EAP-TLS. (DAA-certifikatet förvaras inte i enhetscertifikatarkivet, det förvaras säkert i operativsystemet.) Med kommandot az sphere device certificate i CLI kan du hantera certifikatarkivet från kommandoraden. Azure Sphere-program kan använda CertStore-API: et för att lagra, hämta och hantera certifikat i enhetscertifikatarkivet. CertStore API innehåller också funktioner för att returnera information om enskilda certifikat så att appar kan förbereda för förfallodatum och förnyelse av certifikat.

Mer information finns i Använda EAP-TLS för en fullständig beskrivning av de certifikat som används i EAP-TLS-nätverk och mer information finns i Säker Wi-Fi åtkomst för företag: EAP-TLS på Azure Sphere på Microsoft Tech Community.

Azure Sphere-program

Azure Sphere-program behöver certifikat för att autentiseras för webbtjänster och vissa nätverk. Beroende på kraven för tjänsten eller slutpunkten kan en app använda antingen DAA-certifikatet eller ett certifikat från en extern certifikatutfärdare.

Appar som ansluter till en tredjepartstjänst med wolfSSL eller ett liknande bibliotek kan anropa funktionen DeviceAuth_GetCertificatePath för att få DAA-certifikatet för autentisering. Den här funktionen introducerades i rubriken deviceauth.h i SDK:20.10.

Det Azure IoT-bibliotek som är inbyggt i Azure Sphere litar redan på den nödvändiga rot-CERTIFIKATutfärdare, så appar som använder det här biblioteket för att komma åt Azure IoT-tjänster (Azure IoT Hub, Azure IoT Central, enhetsetableringstjänst) kräver inga ytterligare certifikat.

Om dina appar använder andra Azure-tjänster kontrollerar du i dokumentationen för dessa tjänster vilka certifikat som krävs.

Azure Sphere REST API

Azure Sphere REST API är en uppsättning tjänstslutpunkter som stöder HTTP-åtgärder för att skapa och hantera Azure Sphere-resurser som kataloger, produkter, distributioner och enhetsgrupper. Azure Sphere REST API använder HTTP-protokollet REST (REpresentational State Transfer) för att skicka åtgärdsförfrågningar och svar. De data som returneras i åtgärdssvaret formateras i JSON (JavaScript Object Notation). Tillgängliga åtgärder dokumenteras i AZURE Sphere REST API-referensen.

Azure Sphere-säkerhetstjänst

Azure Sphere-molntjänster i allmänhet, och säkerhetstjänsten i synnerhet, hanterar många certifikat som används i säker service-till-tjänst-kommunikation. De flesta av certifikaten är interna för tjänsterna och deras klienter, så Microsoft samordnar uppdateringar efter behov. Förutom att uppdatera det offentliga API TLS-certifikatet i oktober har Azure Sphere Security Service till exempel även uppdaterat sina TLS-certifikat för DAA-tjänsten och uppdateringstjänsten. Före uppdateringen fick enheterna en OTA-uppdatering till Trusted Root-arkivet som innehöll det nya obligatoriska rotcertifikatet. Ingen kundåtgärd behövdes för att upprätthålla enhetskommunikation med säkerhetstjänsten.

Hur gör Azure Sphere certifikatändringar enklare för kunder?

Förfallodatum för certifikat är en vanlig orsak till fel för IoT-enheter som Azure Sphere kan förhindra.

Eftersom Azure Sphere-produkten innehåller både operativsystemet och säkerhetstjänsten hanteras certifikaten som används av båda dessa komponenter av Microsoft. Enheter får uppdaterade certifikat via DAA-processen, os- och programuppdateringar och felrapportering utan ändringar i program. När Microsoft lade till DigiCert Global Root G2-certifikatet behövdes inga kundändringar för att fortsätta DAA, uppdateringar eller felrapportering. Enheter som var offline vid tidpunkten för uppdateringen fick uppdateringen så snart de återanslutit till Internet.

Azure Sphere OS innehåller också Azure IoT-biblioteket, så om Microsoft gör ytterligare ändringar i certifikat som Azure IoT-biblioteken använder uppdaterar vi biblioteket i operativsystemet så att dina program inte behöver ändras. Vi meddelar dig också via ytterligare blogginlägg om edge-fall eller särskilda omständigheter som kan kräva ändringar i dina appar eller skript.

Båda dessa fall visar hur Azure Sphere förenklar programhantering genom att ta bort behovet av underhållsuppdateringar för program för att hantera certifikatändringar. Eftersom varje enhet får ett uppdateringscertifikat som en del av sitt dagliga intyg kan du enkelt hantera uppdateringen av lokalt hanterade certifikat som dina enheter och program använder. Om programmet till exempel verifierar identiteten för din verksamhetsspecifika server (som det ska) kan du distribuera ett uppdaterat program avbildningspaket som innehåller uppdaterade certifikat. Programuppdateringstjänster som tillhandahålls av Azure Sphere-plattformen levererar dessa uppdateringar, vilket tar bort oron för att själva uppdateringstjänsten kommer att ådra sig ett problem med förfallodatum för certifikat.

Mer information

Azure Sphere Device Authentication and Attestation Service

Ytterligare certifikatuppdateringar för Azure Sphere

Ändringar i Azure TLS-certifikat

Azure IoT TLS: Ändringar kommer! (... och varför du bör bry dig)