Certifikatanvändning med Azure Sphere
Det här avsnittet innehåller en översikt över Azure Sphere-certifikatets "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 de kommer åt dem vid behov. Den beskriver också hur Azure Sphere OS, SDK och tjänster gör certifikathantering enklare för dig. Vi antar att du har grundläggande kunskaper om certifikatutfärdare och förtroendekedjan.
Azure Sphere-enheter
Varje Azure Sphere-enhet förlitar sig på det betrodda rotarkivet, som är en del av Azure Sphere OS. Det betrodda rotarkivet innehåller en lista över rotcertifikat som används för att verifiera identiteten för Azure Sphere Security Service när enheten ansluter för enhetsautentisering och attestering (DAA), OTA-uppdatering (over-the-air) eller felrapportering. Dessa certifikat tillhandahålls med operativsystemet.
När den dagliga attesteringen lyckas tar enheten emot 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 tjänster från tredje part, till exempel wolfSSL som använder TLS (Transport Layer Security). Det här certifikatet är giltigt i 24 timmar. Program kan hämta den programmatiskt 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 Azure Sphere-katalog-CA-certifikat för att autentisera sin Azure Sphere-katalog. Kommandot az sphere ca-certificate download i CLI returnerar katalogcertifikatutfärdarcertifikatet 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 en klient måste enheten skicka 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 hämta nödvändiga certifikat från utfärdaren.
För att hämta 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 hämtat certifikaten för RADIUS-servern bör du lagra dem i enhetscertifikatarkivet. Enhetscertifikatarkivet är endast tillgängligt för användning vid autentisering till ett skyddat nätverk med EAP-TLS. (DAA-certifikatet sparas 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:et innehåller även funktioner för att returnera information om enskilda certifikat så att appar kan förbereda sig för förfallodatum och förnyelse av certifikat.
Mer information finns i Använda EAP-TLS för en fullständig beskrivning av certifikaten som används i EAP-TLS-nätverk. Mer information finns i Säker wi-fi-åtkomst för företag: EAP-TLS på Azure Sphere i Microsoft Tech Community.
Azure Sphere-program
Azure Sphere-program behöver certifikat för att autentisera till 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 tjänst från tredje part med hjälp av wolfSSL eller ett liknande bibliotek kan anropa funktionen DeviceAuth_GetCertificatePath för att hämta DAA-certifikatet för autentisering. Den här funktionen introducerades i deviceauth.h-huvudet i SDK:n 20.10.
Azure IoT-biblioteket som är inbyggt i Azure Sphere litar redan på den nödvändiga rotcertifikatutfärdare, så appar som använder det här biblioteket för att få åtkomst till Azure IoT-tjänster (Azure IoT Hub, Azure IoT Central, enhetsetableringstjänsten) kräver inga ytterligare certifikat.
Om dina appar använder andra Azure-tjänster kontrollerar du med dokumentationen för dessa tjänster för att avgöra 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ärdsbegäranden och svar. De data som returneras i åtgärdssvaret formateras i JSON (JavaScript Object Notation). De tillgängliga åtgärderna dokumenteras i AZURE Sphere REST API-referensen.
Azure Sphere Security Service
Azure Sphere-molntjänster i allmänhet, och säkerhetstjänsten i synnerhet, hanterar många certifikat som används i säker tjänst-till-tjänst-kommunikation. De flesta av dessa certifikat är interna för tjänsterna och deras klienter, så Microsoft samordnar uppdateringar efter behov. Förutom att uppdatera TLS-certifikatet för offentligt API i oktober uppdaterade Azure Sphere Security Service även sina TLS-certifikat för DAA-tjänsten och uppdateringstjänsten. Före uppdateringen mottog enheterna en OTA-uppdatering till det betrodda rotarkivet som innehöll det nya nödvändiga rotcertifikatet. Ingen kundåtgärd behövde vidtas för att upprätthålla enhetskommunikationen med Säkerhetstjänsten.
Hur gör Azure Sphere certifikatändringar enklare för kunder?
Certifikatets giltighetstid ä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 de certifikat som används av båda dessa komponenter av Microsoft. Enheter får uppdaterade certifikat via DAA-processen, os- och programuppdateringar och felrapportering utan att kräva ändringar i program. När Microsoft lade till DigiCert Global Root G2-certifikatet krävdes inga kundändringar för att fortsätta DAA, uppdateringar eller felrapportering. Enheter som var offline vid tidpunkten för uppdateringen tog emot uppdateringen så snart de återanslutit till Internet.
Azure Sphere OS innehåller även 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 eventuella gränsfall 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 programhanteringen genom att ta bort behovet av underhållsuppdateringar för program för att hantera certifikatändringar. Eftersom varje enhet tar emot ett uppdateringscertifikat som en del av sin dagliga attestering kan du enkelt hantera uppdateringen av alla lokalt hanterade certifikat som dina enheter och program använder. Om ditt program till exempel verifierar identiteten för din verksamhetsspecifika server (som det ska) kan du distribuera ett uppdaterat programavbildningspaket som innehåller uppdaterade certifikat. Programuppdateringstjänsterna som tillhandahålls av Azure Sphere-plattformen levererar dessa uppdateringar, vilket tar bort oron för att själva uppdateringstjänsten kommer att medföra ett problem med certifikatets upphörande.
Mer information
Azure Sphere-enhetsautentisering och attesteringstjänst
Ytterligare certifikatuppdateringar för Azure Sphere
Ändringar i Azure TLS-certifikat
Azure IoT TLS: Ändringar kommer! (… och varför du bör bry dig)