Så här används certifikat i Azure IoT Edge

Gäller för: IoT Edge 1.4

Viktigt!

IoT Edge 1.4 är den version som stöds. Om du har en tidigare version läser du Uppdatera IoT Edge.

IoT Edge använder olika typer av certifikat för olika syften. Den här artikeln beskriver de olika sätt som IoT Edge använder certifikat med Azure IoT Hub- och IoT Edge-gatewayscenarier.

Viktigt!

För korthet gäller den här artikeln för IoT Edge version 1.2 eller senare. Certifikatbegreppen för version 1.1 liknar varandra, men det finns vissa skillnader:

• Certifikatet för enhetscertifikatutfärdare i version 1.1 har bytt namn till Edge CA-certifikat.
• Ca-certifikatet för arbetsbelastning i version 1.1 drogs tillbaka. I version 1.2 eller senare genererar IoT Edge-modulens körningstid alla servercertifikat direkt från Edge CA-certifikatet, utan mellanliggande ca-certifikat för arbetsbelastning mellan dem i certifikatkedjan.

Sammanfattning

Dessa kärnscenarier är där IoT Edge använder certifikat. Använd länkarna om du vill veta mer om varje scenario.

Skådespelare	Syfte	Certifikat
IoT Edge	Säkerställer att den kommunicerar till rätt IoT Hub	IoT Hub servercertifikat
IoT Hub	Säkerställer att begäran kom från en legitim IoT Edge enhet	IoT Edge identitetscertifikat
Nedströms IoT-enhet	Ser till att den kommunicerar till rätt IoT Edge gateway	IoT Edge Hub edgeHub-modulservercertifikat, utfärdat av Edge CA
IoT Edge	Signerar nya modulservercertifikat. Till exempel edgeHub	Edge CA-certifikat
IoT Edge	Säkerställer att begäran kom från en legitim nedströmsenhet	IoT-enhetsidentitetscertifikat

Förutsättningar

• Du bör ha en grundläggande förståelse för kryptering av offentliga nycklar, nyckelpar och hur en offentlig nyckel och privat nyckel kan kryptera eller dekryptera data. Mer information om hur IoT Edge använder kryptering med offentliga nycklar finns i Förstå kryptering av offentliga nycklar och X.509 Offentlig nyckelinfrastruktur.
• Du bör ha en grundläggande förståelse för hur IoT Edge relaterar till IoT Hub. Mer information finns i Förstå Azure IoT Edge-körningen och dess arkitektur.

Scenario med en enskild enhet

För att förstå IoT Edge-certifikatbegrepp kan du tänka dig ett scenario där en IoT Edge-enhet med namnet EdgeGateway ansluter till en Azure IoT Hub med namnet ContosoIotHub. I det här exemplet görs all autentisering med X.509-certifikatautentisering i stället för symmetriska nycklar. För att skapa förtroende för det här scenariot måste vi garantera att IoT Hub- och IoT Edge-enheten är äkta: "Är den här enheten äkta och giltig?" och "Är identiteten för IoT Hub korrekt?". Scenariot kan illustreras på följande sätt:

Vi förklarar svaren på varje fråga och expanderar sedan exemplet i senare avsnitt i artikeln.

Enheten verifierar IoT Hub-identitet

Hur verifierar EdgeGateway att det kommunicerar med den äkta ContosoIotHub? När EdgeGateway vill prata med molnet ansluter det till slutpunkten ContosoIoTHub.Azure-devices.NET. För att se till att slutpunkten är giltig behöver IoT Edge ContosoIoTHub för att visa identifiering (ID). ID:t måste utfärdas av en utfärdare som EdgeGateway litar på. För att verifiera IoT Hub-identiteten använder IoT Edge och IoT Hub TLS-handskakningsprotokollet för att verifiera IoT Hubs serveridentitet. En TLS-handskakning illustreras i följande diagram. För att hålla exemplet enkelt har viss information utelämnats. Mer information om TLS-handskakningsprotokollet finns i TLS-handskakning på Wikipedia.

Kommentar

I det här exemplet representerar ContosoIoTHub IoT Hub-värdnamnet ContosoIotHub.Azure-devices.NET.

I det här sammanhanget behöver du inte känna till den exakta informationen om den kryptografiska algoritmen. Det är viktigt att förstå att algoritmen ser till att servern har den privata nyckeln som är kopplad till dess offentliga nyckel. Det verifierar att presentatören av certifikatet inte kopierade eller stal det. Om vi använder ett foto-ID som exempel matchar ditt ansikte fotot på ID:t. Om någon stjäl ditt ID kan de inte använda det för identifiering eftersom ditt ansikte är unikt och svårt att återskapa. För kryptografiska nycklar är nyckelparet relaterat och unikt. I stället för att matcha ett ansikte med ett foto-ID använder den kryptografiska algoritmen nyckelparet för att verifiera identiteten.

I vårt scenario visar ContosoIotHub följande certifikatkedja:

Rotcertifikatutfärdare (CA) är Baltimore CyberTrust Root-certifikatet . Det här rotcertifikatet är signerat av DigiCert och är allmänt betrott och lagras i många operativsystem. Till exempel inkluderar både Ubuntu och Windows det i standardcertifikatarkivet.

Windows-certifikatarkiv:

Ubuntu-certifikatarkiv:

När en enhet söker efter Baltimore CyberTrust Root-certifikatet är den förinstallerad i operativsystemet. Eftersom certifikatkedjan som presenteras av ContosoIotHub är signerad av en rotcertifikatutfärdare som operativsystemet litar på, anses certifikatet vara tillförlitligt från EdgeGateway-perspektivet. Certifikatet kallas för IoT Hub-servercertifikat. Mer information om IoT Hub-servercertifikatet finns i TLS-stöd (Transport Layer Security) i IoT Hub.

Sammanfattningsvis kan EdgeGateway verifiera och lita på ContosoIotHubs identitet eftersom:

• ContosoIotHub presenterar sitt IoT Hub-servercertifikat
• Servercertifikatet är betrott i OS-certifikatarkivet
• Data som krypteras med ContosoIotHubs offentliga nyckel kan dekrypteras av ContosoIotHub, vilket bevisar dess innehav av den privata nyckeln

IoT Hub verifierar IoT Edge-enhetsidentitet

Hur verifierar ContosoIotHub att det kommunicerar med EdgeGateway? Eftersom IoT Hub stöder ömsesidig TLS (mTLS) kontrollerar det EdgeGateways certifikat under klientautentiserad TLS-handskakning. För enkelhetens skull hoppar vi över några steg i följande diagram.

I det här fallet tillhandahåller EdgeGateway sitt IoT Edge-enhetsidentitetscertifikat. Från ContosoIotHub-perspektiv kontrollerar det både att tumavtrycket för det angivna certifikatet matchar dess post och att EdgeGateway har den privata nyckeln i par med det certifikat som visas. När du etablerar en IoT Edge-enhet i IoT Hub anger du ett tumavtryck. Tumavtrycket är vad IoT Hub använder för att verifiera certifikatet.

Dricks

IoT Hub kräver två tumavtryck när du registrerar en IoT Edge-enhet. Bästa praxis är att förbereda två olika enhetsidentitetscertifikat med olika förfallodatum. På så sätt, om ett certifikat upphör att gälla, är det andra fortfarande giltigt och ger dig tid att rotera det utgångna certifikatet. Men det är också möjligt att bara använda ett certifikat för registrering. Använd ett enda certifikat genom att ange samma tumavtryck för både det primära och det sekundära tumavtrycket när enheten registreras.

Vi kan till exempel använda följande kommando för att hämta identitetscertifikatets tumavtryck på EdgeGateway:

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

Kommandot matar ut certifikatets SHA256-tumavtryck:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

Om vi visar tumavtrycksvärdet SHA256 för EdgeGateway-enheten som registrerats i IoT Hub kan vi se att den matchar tumavtrycket på EdgeGateway:

Sammanfattningsvis kan ContosoIotHub lita på EdgeGateway eftersom EdgeGateway visar ett giltigt IoT Edge-enhetsidentitetscertifikat vars tumavtryck matchar det som registrerats i IoT Hub.

Mer information om processen för att skapa certifikat finns i Skapa och etablera en IoT Edge-enhet i Linux med X.509-certifikat.

Kommentar

Det här exemplet behandlar inte Azure IoT Hub Device Provisioning Service (DPS), som har stöd för X.509 CA-autentisering med IoT Edge när det etableras med en registreringsgrupp. Med DPS laddar du upp CA-certifikatet eller ett mellanliggande certifikat, certifikatkedjan verifieras och sedan etableras enheten. Mer information finns i DPS X.509-certifikatattestering.

I Azure-portalen visar DPS SHA1-tumavtrycket för certifikatet i stället för SHA256-tumavtrycket.

DPS registrerar eller uppdaterar SHA256-tumavtrycket till IoT Hub. Du kan verifiera tumavtrycket med hjälp av kommandot openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. När Iot Edge har registrerats använder det tumavtrycksautentisering med IoT Hub. Om enheten återskapas och ett nytt certifikat utfärdas uppdaterar DPS IoT Hub med det nya tumavtrycket.

IoT Hub stöder för närvarande inte X.509 CA-autentisering direkt med IoT Edge.

Certifikatanvändning för modulidentitetsåtgärder

I diagrammen för certifikatverifiering kan det visas att IoT Edge endast använder certifikatet för att prata med IoT Hub. IoT Edge består av flera moduler. Därför använder IoT Edge certifikatet för att hantera modulidentiteter för moduler som skickar meddelanden. Modulerna använder inte certifikatet för att autentisera till IoT Hub, utan använder i stället SAS-nycklar som härleds från den privata nyckel som genereras av IoT Edge-modulkörning. Dessa SAS-nycklar ändras inte även om enhetsidentitetscertifikatet upphör att gälla. Om certifikatet upphör att gälla fortsätter till exempel edgeHub att köras och endast modulidentitetsåtgärderna misslyckas.

Interaktionen mellan moduler och IoT Hub är säker eftersom SAS-nyckeln härleds från en hemlighet och IoT Edge hanterar nyckeln utan risk för mänsklig inblandning.

Scenario med kapslad enhetshierarki med IoT Edge som gateway

Nu har du en god förståelse för en enkel interaktion i IoT Edge mellan och IoT Hub. Men IoT Edge kan också fungera som en gateway för underordnade enheter eller andra IoT Edge-enheter. Dessa kommunikationskanaler måste också vara krypterade och betrodda. På grund av den extra komplexiteten måste vi utöka vårt exempelscenario för att inkludera en nedströmsenhet.

Vi lägger till en vanlig IoT-enhet med namnet TempSensor, som ansluter till den överordnade IoT Edge-enheten EdgeGateway som ansluter till IoT Hub ContosoIotHub. På samma sätt som tidigare görs all autentisering med X.509-certifikatautentisering. Vårt nya scenario väcker två nya frågor: "Är TempSensor-enheten legitim?" och "Är identiteten för EdgeGateway korrekt?". Scenariot kan illustreras på följande sätt:

Dricks

TempSensor är en IoT-enhet i scenariot. Certifikatkonceptet är detsamma om TempSensor är en underordnad IoT Edge-enhet för överordnade EdgeGateway.

Enheten verifierar gatewayidentiteten

Hur verifierar TempSensor att det kommunicerar med den äkta EdgeGateway? När TempSensor vill prata med EdgeGateway behöver TempSensor EdgeGateway för att visa ett ID. ID:t måste utfärdas av en utfärdare som TempSensor litar på.

Flödet är detsamma som när EdgeGateway pratar med ContosoIotHub. TempSensor och EdgeGateway använder TLS-handskakningsprotokollet för att verifiera EdgeGateways identitet. Det finns två viktiga detaljer:

• Värdnamnsspecifikitet: Certifikatet som visas av EdgeGateway måste utfärdas till samma värdnamn (domän eller IP-adress) som TempSensor använder för att ansluta till EdgeGateway.
• Självsignerad rotcertifikatutfärdarspecifikitet: Certifikatkedjan som presenteras av EdgeGateway finns troligen inte i operativsystemets betrodda standardrotarkiv.

För att förstå informationen ska vi först undersöka certifikatkedjan som presenteras av EdgeGateway.

Värdnamnsspecifikitet

Certifikatets gemensamma namn CN = edgegateway.local visas överst i kedjan. edgegateway.local är edgeHubs vanliga namn på servercertifikatet. edgegateway.local är också värdnamnet för EdgeGateway i det lokala nätverket (LAN eller VNet) där TempSensor och EdgeGateway är anslutna. Det kan vara en privat IP-adress som 192.168.1.23 eller ett fullständigt domännamn (FQDN) som diagrammet. EdgeHub-servercertifikatet genereras med hjälp av parametern värdnamn som definierats i filen IoT Edge config.toml. Blanda inte ihop edgeHub-servercertifikatet med Edge CA-certifikatet. Mer information om hur du hanterar Edge CA-certifikat finns i Hantera IoT Edge-certifikat.

När TempSensor ansluter till EdgeGateway använder TempSensor värdnamnet edgegateway.local för att ansluta till EdgeGateway. TempSensor kontrollerar certifikatet som visas av EdgeGateway och verifierar att certifikatets gemensamma namn är edgegateway.local. Om certifikatets gemensamma namn är annorlunda avvisar TempSensor anslutningen.

Kommentar

För enkelhetens skull visar exemplet certifikatets eget namn (CN) som en egenskap som verifieras. I praktiken verifieras SAN i stället för CN om ett certifikat har ett alternativt ämnesnamn (SAN). Eftersom SAN kan innehålla flera värden har det vanligtvis både huvuddomänen/värdnamnet för certifikatinnehavaren och eventuella alternativa domäner.

Varför behöver EdgeGateway få information om sitt eget värdnamn?

EdgeGateway har inget tillförlitligt sätt att veta hur andra klienter i nätverket kan ansluta till det. I ett privat nätverk kan det till exempel finnas DHCP-servrar eller mDNS-tjänster som listar EdgeGateway som 10.0.0.2 eller example-mdns-hostname.local. Men vissa nätverk kan ha DNS-servrar som mappar edgegateway.local till EdgeGateways IP-adress 10.0.0.2.

För att lösa problemet använder IoT Edge det konfigurerade värdnamnsvärdet i config.toml och skapar ett servercertifikat för det. När en begäran kommer till edgeHub-modulen visas certifikatet med rätt namn på certifikatet (CN).

Varför skapar IoT Edge certifikat?

Observera i exemplet att det finns en iotedged arbetsbelastning ca edgegateway i certifikatkedjan. Det är certifikatutfärdare (CA) som finns på IoT Edge-enheten som kallas Edge CA (tidigare känd som Enhetscertifikatutfärdare i version 1.1). Precis som Baltimore CyberTrust-rotcertifikatutfärdare i det tidigare exemplet kan Edge CA utfärda andra certifikat. Viktigast av allt, och även i det här exemplet, utfärdar det servercertifikatet till edgeHub-modulen . Men det kan också utfärda certifikat till andra moduler som körs på IoT Edge-enheten.

Viktigt!

Som standard utan konfiguration genereras Edge CA automatiskt av IoT Edge-modulkörningen när den startas för första gången, vilket kallas snabbstartscertifikatutfärdare för Edge, och utfärdar sedan ett certifikat till edgeHub-modulen . Den här processen påskyndar underordnad enhetsanslutning genom att tillåta edgeHub att presentera ett giltigt certifikat som är signerat. Utan den här funktionen måste du få certifikatutfärdaren att utfärda ett certifikat för edgeHub-modulen . Med hjälp av en automatiskt genererad snabbstart stöds inte Edge CA för användning i produktion. Mer information om snabbstarten för Edge CA finns i Snabbstart Edge CA.

Är det inte farligt att ha ett utfärdarcertifikat på enheten?

Edge CA är utformat för att möjliggöra lösningar med begränsad, otillförlitlig, dyr eller frånvarande anslutning men har samtidigt strikta regler eller principer för certifikatförnyelser. Utan Edge CA kan IoT Edge – och i synnerhet edgeHub – inte fungera.

Så här skyddar du Edge CA i produktion:

• Placera den privata EdgeCA-nyckeln i en betrodd plattformsmodul (TPM), helst på ett sätt där den privata nyckeln genereras tillfälliga och aldrig lämnar TPM.
• Använd en PKI (Public Key Infrastructure) som Edge CA samlar in. Detta ger möjlighet att inaktivera eller neka förnyelse av komprometterade certifikat. PKI kan hanteras av kund-IT om de vet hur (lägre kostnad) eller via en kommersiell PKI-provider.

Självsignerad rotcertifikatutfärdarspecifikitet

EdgeHub-modulen är en viktig komponent som utgör IoT Edge genom att hantera all inkommande trafik. I det här exemplet använder den ett certifikat utfärdat av Edge CA, som i sin tur utfärdas av en självsignerad rotcertifikatutfärdare. Eftersom rotcertifikatutfärdare inte är betrodd av operativsystemet är det enda sättet som TempSensor skulle lita på det att installera CA-certifikatet på enheten. Detta kallas även för scenariot med förtroendepaket , där du behöver distribuera roten till klienter som behöver lita på kedjan. Scenariot med säkerhetspaket kan vara besvärligt eftersom du behöver åtkomst till enheten och installera certifikatet. Att installera certifikatet kräver planering. Det kan göras med skript, läggs till under tillverkning eller förinstalleras i OS-avbildningen.

Kommentar

Vissa klienter och SDK:er använder inte det betrodda rotarkivet för operativsystemet och du måste skicka rot-CA-filen direkt.

Genom att tillämpa alla dessa begrepp kan TempSensor kontrollera att det kommunicerar med den äkta EdgeGateway eftersom det visade ett certifikat som matchade adressen och certifikatet signeras av en betrodd rot.

För att verifiera certifikatkedjan kan du använda openssl på TempSensor-enheten. I det här exemplet ser du att värdnamnet för anslutningen matchar CN för djup 0-certifikatet och att rotcertifikatutfärdarcertifikatutfärdartypen matchar.

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

Mer information om openssl kommandot finns i OpenSSL-dokumentationen.

Du kan också kontrollera certifikaten där de lagras som standard i /var/lib/aziot/certd/certs. Du hittar Edge CA-certifikat , enhetsidentitetscertifikat och modulcertifikat i katalogen. Du kan använda openssl x509 kommandon för att inspektera certifikaten. Till exempel:

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

Sammanfattningsvis kan TempSensor lita på EdgeGateway eftersom:

• EdgeHub-modulen visade ett giltigt IoT Edge-modulservercertifikat för edgegateway.local
• Certifikatet utfärdas av Edge CA som utfärdas av my_private_root_CA
• Den här privata rotcertifikatutfärdare lagras också i TempSensor som betrodd rotcertifikatutfärdare tidigare
• Kryptografiska algoritmer kontrollerar att ägarskaps- och utfärdandekedjan kan vara betrodd

Certifikat för andra moduler

Andra moduler kan hämta servercertifikat som utfärdats av Edge CA. Till exempel en Grafana-modul som har ett webbgränssnitt. Det kan också hämta ett certifikat från Edge CA. Moduler behandlas som underordnade enheter som finns i containern. Att kunna hämta ett certifikat från IoT Edge-modulens körning är dock ett särskilt privilegium. Moduler anropar arbetsbelastnings-API:et för att ta emot servercertifikatet som är kopplat till den konfigurerade Edge CA:n.

Gateway verifierar enhetsidentitet

Hur verifierar EdgeGateway att det kommunicerar med TempSensor? EdgeGateway använder TLS-klientautentisering för att autentisera TempSensor.

Sekvensen liknar ContosoIotHub som verifierar en enhet. Men i ett gatewayscenario förlitar sig EdgeGateway på ContosoIotHub som sanningskälla för certifikatens post. EdgeGateway behåller också en offlinekopia eller cache om det inte finns någon anslutning till molnet.

Dricks

Till skillnad från IoT Edge-enheter är underordnade IoT-enheter inte begränsade till X.509-autentisering med tumavtryck. X.509 CA-autentisering är också ett alternativ. I stället för att bara söka efter en matchning på tumavtrycket kan EdgeGateway också kontrollera om TempSensors certifikat är rotat i en certifikatutfärdare som har laddats upp till ContosoIotHub.

Sammanfattningsvis kan EdgeGateway lita på TempSensor eftersom:

• TempSensor visade ett giltigt IoT-enhetsidentitetscertifikat för dess namn
• Identitetscertifikatets tumavtryck matchar det som laddats upp till ContosoIotHub
• Kryptografiska algoritmer kontrollerar att ägarskaps- och utfärdandekedjan kan vara betrodd

Var du kan hämta certifikaten och hanteringen

I de flesta fall kan du ange egna certifikat eller använda på automatiskt genererade certifikat. Till exempel genereras Edge CA och edgeHub-certifikatet automatiskt.

Bästa praxis är dock att konfigurera dina enheter så att de använder en EST-server (Enrollment over Secure Transport) för att hantera x509-certifikat. Om du använder en EST-server kan du hantera certifikaten manuellt och installera dem på enheter. Mer information om hur du använder en EST-server finns i Konfigurera registrering via säker transportserver för Azure IoT Edge.

Du kan även använda certifikat för att autentisera till EST-servern. Dessa certifikat används för att autentisera med EST-servrar för att utfärda andra certifikat. Certifikattjänsten använder ett bootstrap-certifikat för att autentisera med en EST-server. Bootstrap-certifikatet är långlivat. Vid den första autentiseringen skickar certifikattjänsten en begäran till EST-servern om att utfärda ett identitetscertifikat. Det här identitetscertifikatet används i framtida EST-begäranden till samma server.

Om du inte kan använda en EST-server bör du begära certifikat från PKI-providern. Du kan hantera certifikatfilerna manuellt i IoT Hub och dina IoT Edge-enheter. Mer information finns i Hantera certifikat på en IoT Edge-enhet.

För konceptbevisutveckling kan du skapa testcertifikat. Mer information finns i Skapa democertifikat för att testa IoT Edge-enhetsfunktioner.

Certifikat i IoT

Certifikatutfärdare

Certifikatutfärdare (CA) är en entitet som utfärdar digitala certifikat. En certifikatutfärdare fungerar som en betrodd tredje part mellan ägaren och certifikatmottagaren. Ett digitalt certifikat certifierar ägarskapet för en offentlig nyckel av certifikatmottagaren. Certifikatkedjan för förtroende fungerar genom att först utfärda ett rotcertifikat, vilket är grunden för förtroende för alla certifikat som utfärdats av utfärdaren. Rotcertifikatägaren kan sedan utfärda ytterligare mellanliggande certifikat (underordnade enhetscertifikat).

Rotcertifikatutfärdarcertifikat

Ett rotcertifikatutfärdarcertifikat är roten av förtroende för hela processen. I produktionsscenarier köps ca-certifikatet från en betrodd certifikatutfärdare som Baltimore, Verisign eller DigiCert. Om du har fullständig kontroll över de enheter som ansluter till dina IoT Edge-enheter kan du använda en certifikatutfärdare på företagsnivå. I båda fall använder hela certifikatkedjan från IoT Edge till IoT Hub den. De underordnade IoT-enheterna måste lita på rotcertifikatet. Du kan lagra rotcertifikatutfärdarcertifikatet antingen i det betrodda rotcertifikatutfärdararkivet 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 ett eller flera mellanliggande CA-certifikat digitalt. Det kan bara finnas ett eller så kan det finnas en kedja med dessa mellanliggande certifikat. Scenarier som skulle kräva en kedja av mellanliggande certifikat är:

• En hierarki med avdelningar inom en tillverkare
• Flera företag deltar seriellt i produktionen av en enhet
• En kund som köper en rotcertifikatutfärdare och härleder 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 edge CA-certifikatet som placerats på slutenheten. Dessa mellanliggande certifikat är noggrant skyddade vid tillverkningsanläggningen. De genomgår strikta processer, både fysiska och elektroniska för sin användning.

Nästa steg

• Mer information om hur du installerar certifikat på en IoT Edge-enhet och refererar till dem från konfigurationsfilen finns i Hantera certifikat på en IoT Edge-enhet.
• Förstå Azure IoT Edge-moduler
• Konfigurera en IoT Edge-enhet till att fungera som en transparent gateway
• I den här artikeln beskrivs de certifikat som används för att skydda anslutningar mellan de olika komponenterna på en IoT Edge-enhet eller mellan en IoT Edge-enhet och eventuella underordnade enheter. Du kan också använda certifikat för att autentisera din IoT Edge-enhet till IoT Hub. Dessa autentiseringscertifikat skiljer sig åt 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.