Förstå hur Azure IoT Edge använder certifikat
Gäller för: 
IoT Edge 1,1 andra versioner: IoT Edge 1,2
Gäller för: IoT Edge 1,2 andra versioner: IoT Edge 1,1
IoT Edge certifikat används av modulerna och nedströmsenheterna i IoT för att verifiera identiteten och IoT Edge hub runtime-modulen. Dessa verifieringar möjliggör en säker TLS-anslutning (transport layer security) mellan körningen, modulerna och IoT-enheterna. Precis IoT Hub kräver IoT Edge en säker och krypterad anslutning från IoT-nedströmsenheter (eller lövenheter) och IoT Edge moduler. För att upprätta en säker TLS-anslutning presenterar IoT Edge Hub-modulen en servercertifikatkedja för att ansluta klienter för att de ska kunna verifiera sin identitet.
Anteckning
Den här artikeln beskriver de certifikat som används för att skydda anslutningar mellan olika komponenter på en IoT Edge-enhet eller mellan en IoT Edge-enhet och lövenheter. Du kan också använda certifikat för att autentisera IoT Edge till IoT Hub. Dessa autentiseringscertifikat är olika och beskrivs inte i den här artikeln. Mer information om hur du autentiserar enheten med certifikat finns i Skapa och etablera en IoT Edge enhet med X.509-certifikat.
Den här artikeln förklarar IoT Edge certifikat kan fungera i produktions-, utvecklings- och testscenarier.
Ändringar i version 1.2
- Enhetens CA-certifikat har bytt namn till certifikatutfärdarcertifikat på gränsen.
- CA-certifikatet för arbetsbelastningen är inaktuellt. Nu genererar IoT Edge-säkerhetshanteraren IoT Edge certifikat för hubbservern direkt från edge CA-certifikatet, utan ca-certifikatet mellan de mellanliggande arbetsbelastningarna.
IoT Edge-certifikat
Det finns två vanliga scenarier för att konfigurera certifikat på en IoT Edge enhet. Ibland köper slutanvändaren, eller operatören, en enhet en allmän enhet som tillverkats av en tillverkare och hanterar sedan själva certifikaten. Vid andra tillfällen arbetar tillverkaren under kontrakt för att skapa en anpassad enhet för operatören och gör viss inledande certifikatsignering innan den lämnar över enheten. Den IoT Edge certifikatdesignen försöker ta hänsyn till båda scenarierna.
Följande bild visar IoT Edge användning av certifikat. Det kan finnas noll, ett eller flera mellanliggande signeringscertifikat mellan rotcertifikatutfärdarcertifikatet och enhetens CA-certifikat, beroende på antalet berörda entiteter. Här visar vi ett fall.
Anteckning
För närvarande förhindrar en begränsning i bibliotek användningen av certifikat som upphör att gälla den 1 januari 2038 eller senare. Den här begränsningen gäller enhetens CA-certifikat, certifikat i förtroendepaketet och de enhets-ID-certifikat som används för X.509-etableringsmetoder.
Certifikatutfärdare
Certifikatutfärdaren, eller "CA", är en enhet som utfärdar digitala certifikat. En certifikatutfärdare fungerar som en betrodd tredje part mellan ägaren och mottagaren av certifikatet. Ett digitalt certifikat certifierar ägarskapet för en offentlig nyckel av mottagaren av certifikatet. Certifikatkedjan för förtroende fungerar genom att först utfärda ett rotcertifikat, vilket utgör grunden för förtroende i alla certifikat som utfärdats av utfärdaren. Därefter kan ägaren använda rotcertifikatet för att utfärda ytterligare mellanliggande certifikat (lövcertifikat).
Rotcertifikatutfärdarcertifikat
Ett rotcertifikatutfärdarcertifikat är roten av förtroendet för hela processen. I produktionsscenarier köps detta CA-certifikat vanligtvis från en betrodd kommersiell certifikatutfärdare som Baltimore, Verisign eller DigiCert. Om du har fullständig kontroll över de enheter som ansluter IoT Edge dina enheter kan du använda en certifikatutfärdare på företagsnivå. I båda fall återställs hela certifikatkedjan från IoT Edge-hubben till den, så löv-IoT-enheterna måste lita på rotcertifikatet. Du kan lagra rotcertifikatutfärdarcertifikatet antingen i arkivet för betrodda rotcertifikatutfärdare eller ange certifikatinformationen i programkoden.
Mellanliggande certifikat
I en typisk tillverkningsprocess för att skapa säkra enheter används rotcertifikatutfärdarcertifikat sällan direkt, främst på grund av risken för läckage eller exponering. Rotcertifikatutfärdarcertifikatet skapar och signerar digitalt ett eller flera mellanliggande CA-certifikat. Det kan bara finnas ett, eller så kan det finnas en kedja av dessa mellanliggande certifikat. Scenarier som kräver en kedja av mellanliggande certifikat är:
En hierarki med avdelningar inom en tillverkare.
Flera företag som är inblandade i serie i produktionen av en enhet.
En kund som köper en rotcertifikatutfärdare och härledar ett signeringscertifikat för tillverkaren för att signera de enheter som de gör för kundens räkning.
I vilket fall som helst använder tillverkaren ett mellanliggande CA-certifikat i slutet av den här kedjan för att signera enhetens CA-certifikat som placerats på slutenheten. I allmänhet är dessa mellanliggande certifikat nära övervakade på tillverkningsfabriken. De genomgår strikta processer, både fysiska och elektroniska för deras användning.
Ca-certifikat för enhet
Enhetens CA-certifikat genereras från och signeras av det sista mellanliggande CA-certifikatet i processen. Det här certifikatet installeras på IoT Edge enhet, helst i säker lagring, till exempel en maskinvarusäkerhetsmodul (HSM). Dessutom identifierar ett ca-certifikat för enheten en unik IoT Edge enhet. Enhetens CA-certifikat kan signera andra certifikat.
IoT Edge Ca för arbetsbelastning
Den IoT Edge Security Manager genererar CA-certifikatet för arbetsbelastningen, det första på "operatörssidan" av processen när IoT Edge startar. Det här certifikatet genereras från och signeras av enhetens CA-certifikat. Det här certifikatet, som bara är ett mellanliggande signeringscertifikat, används för att generera och signera andra certifikat som används IoT Edge körningen. Idag är det främst det IoT Edge hub-servercertifikat som beskrivs i följande avsnitt, men i framtiden kan det finnas andra certifikat för att autentisera IoT Edge komponenter.
Syftet med det mellanliggande certifikatet för "arbetsbelastning" är att separera problem mellan enhetstillverkaren och enhetsoperatören. Imagine ett scenario där en IoT Edge enhet säljs eller överförs från en kund till en annan. Du vill förmodligen att enhetens CA-certifikat som tillhandahålls av tillverkaren ska vara oföränderligt. "Arbetsbelastningscertifikaten" som är specifika för driften av enheten bör dock rensas och återskapas för den nya distributionen.
Edge CA-certifikat
Edge CA-certifikatet genereras från och signeras av det sista mellanliggande CA-certifikatet i processen. Det här certifikatet installeras på IoT Edge enhet, helst i säker lagring, till exempel en maskinvarusäkerhetsmodul (HSM). Dessutom identifierar ett edge CA-certifikat en unik identifierare IoT Edge enhet. Edge CA-certifikatet kan signera andra certifikat.
IoT Edge hub-servercertifikat
Det IoT Edge hub-servercertifikatet är det faktiska certifikatet som presenteras för lövenheter och moduler för identitetsverifiering vid upprättandet av den TLS-anslutning som krävs av IoT Edge. Det här certifikatet visar den fullständiga kedjan av signeringscertifikat som används för att generera det till rotcertifikatutfärdaren, som löv-IoT-enheten måste lita på. När det här IoT Edge av IoT Edge anges det allmänna namnet (CN) för det här IoT Edge-hubbcertifikatet till egenskapen "hostname" i konfigurationsfilen efter konverteringen till gemener.
Tips
Eftersom IoT Edge-hubbserverns certifikat använder enhetens värdnamnsegenskap som eget namn, bör inga andra certifikat i kedjan använda samma eget namn.
Den IoT Edge Security Manager genererar IoT Edge certifikat, det första på "operator"-sidan av processen, när IoT Edge startar. Det här certifikatet genereras från och signeras av edge CA-certifikatet.
Produktionskonsekvenser
Eftersom tillverknings- och driftsprocesser separeras bör du tänka på följande när du förbereder produktionsenheter:
Med alla certifikatbaserade processer bör rotcertifikatutfärdarcertifikatet och alla mellanliggande CA-certifikat skyddas och övervakas under hela processen med att distribuera en IoT Edge enhet. Enhetstillverkaren IoT Edge ha starka processer för korrekt lagring och användning av mellanliggande certifikat. Dessutom bör CA-certifikatet för enheten förvaras så säker lagring som möjligt på själva enheten, helst en maskinvarusäkerhetsmodul.
Certifikatet IoT Edge hubbservern presenteras av IoT Edge till de anslutande klientenheterna och modulerna. Eget namn (CN) för enhetens CA-certifikat får inte vara samma som det "värdnamn" som ska användas i konfigurationsfilen på den IoT Edge enheten. Det namn som används av klienter för att ansluta till IoT Edge (till exempel via parametern GatewayHostName i anslutningssträngen eller kommandot CONNECT i MQTT) kan inte vara samma som det gemensamma namn som används i enhetens CA-certifikat. Den här begränsningen beror på IoT Edge visar hela certifikatkedjan för verifiering av klienter. Om IoT Edge hubbservercertifikatet och enhetens CA-certifikat båda har samma CN, får du i en verifieringsloop och certifikatet ogiltigförklaras.
Eftersom ca-enhetscertifikatet används av IoT Edge-säkerhetsdaemonen för att generera de slutliga IoT Edge-certifikaten måste det själv vara ett signeringscertifikat, vilket innebär att det har funktioner för certifikatsignering. Om du tillämpar "V3 Grundläggande begränsningar CA:True" på enhetens CA-certifikat konfigureras de nödvändiga nyckelanvändningsegenskaperna automatiskt.
Med alla certifikatbaserade processer bör rotcertifikatutfärdarcertifikatet och alla mellanliggande CA-certifikat skyddas och övervakas under hela processen med att distribuera en IoT Edge enhet. Enhetstillverkaren IoT Edge ha starka processer för korrekt lagring och användning av mellanliggande certifikat. Dessutom bör edge CA-certifikatet förvaras i så säker lagring som möjligt på själva enheten, helst en maskinvarusäkerhetsmodul.
Certifikatet IoT Edge hubbservern presenteras av IoT Edge till de anslutande klientenheterna och modulerna. Det gemensamma namnet (CN) för edge CA-certifikatet får inte vara samma som det "värdnamn" som ska användas i konfigurationsfilen på den IoT Edge enheten. Det namn som används av klienter för att ansluta till IoT Edge (till exempel via parametern GatewayHostName i anslutningssträngen eller kommandot CONNECT i MQTT) kan inte vara samma som det gemensamma namn som används i edge CA-certifikatet. Den här begränsningen beror på IoT Edge visar hela certifikatkedjan för verifiering av klienter. Om IoT Edge hubbservercertifikatet och edge CA-certifikatet båda har samma CN, får du i en verifieringsloop och certifikatet ogiltigförklaras.
Eftersom edge CA-certifikatet används av IoT Edge-säkerhetsdaemonen för att generera de slutliga IoT Edge-certifikaten måste det själv vara ett signeringscertifikat, vilket innebär att det har funktioner för certifikatsignering. Om du tillämpar "V3 Grundläggande begränsningar CA:True" på edge CA-certifikatet konfigureras automatiskt nödvändiga nyckelanvändningsegenskaper.
Effekter av utveckling/testning
För att underlätta utvecklings- och testscenarier tillhandahåller Microsoft en uppsättning praktiska skript för att generera icke-produktionscertifikat som är lämpliga för IoT Edge i scenariot med transparent gateway. Exempel på hur skripten fungerar finns i Skapa democertifikat för att testa IoT Edge-enhetsfunktioner.
Tips
Om du vill ansluta enhetens IoT-"lövenheter" och program som använder vår IoT-enhets-SDK via IoT Edge måste du lägga till den valfria GatewayHostName-parametern i slutet av enhetens anslutningssträng. När IoT Edge-hubbserverns certifikat genereras baseras det på en gemen version av värdnamnet från konfigurationsfilen. För att namnen ska matcha och TLS-certifikatverifieringen ska lyckas bör du därför ange parametern GatewayHostName med gemener.
Exempel på IoT Edge certifikathierarki
För att illustrera ett exempel på den här certifikatsökvägen är följande skärmbild från en fungerande IoT Edge som har ställts in som en transparent gateway. OpenSSL används för att ansluta IoT Edge, validera och dumpa certifikaten.
Hierarkin för certifikatdjup visas på skärmbilden:
| Certifikattyp | Certifikatnamn |
|---|---|
| Rotcertifikatutfärdarcertifikat | Azure IoT Hub certifikatutfärdartest |
| Mellanliggande CA-certifikat | Azure IoT Hub test av mellanliggande certifikat |
| Ca-certifikat för enhet | iotgateway.ca ("iotgateway" skickades som certifikatutfärdarnamn till bekvämlighetsskripten) |
| Ca-certifikat för arbetsbelastning | iotedge workload ca |
| IoT Edge Hub-servercertifikat | iotedgegw.local (matchar "värdnamnet" från konfigurationsfilen) |
Hierarkin för certifikatdjup visas på skärmbilden:
| Certifikattyp | Certifikatnamn |
|---|---|
| Rotcertifikatutfärdarcertifikat | Azure IoT Hub certifikatutfärdartest |
| Mellanliggande CA-certifikat | Azure IoT Hub test av mellanliggande certifikat |
| Ca-certifikat för enhet | iotgateway.ca ("iotgateway" skickades som certifikatutfärdarnamn till bekvämlighetsskripten) |
| IoT Edge Hub-servercertifikat | iotedgegw.local (matchar "värdnamnet" från konfigurationsfilen) |
Nästa steg
Konfigurera en IoT Edge-enhet till att fungera som en transparent gateway