Principy používání certifikátů ve službě Azure IoT Edge

Platí pro: IoT Edge 1.5 IoT Edge 1.4

Důležité

Podporované verze ioT Edge 1.5 LTS a IoT Edge 1.4 LTS. IoT Edge 1.4 LTS je konec životnosti 12. listopadu 2024. Pokud používáte starší verzi, podívejte se na článek Aktualizace IoT Edge.

IoT Edge pro různé účely používá různé typy certifikátů. Tento článek vás provede různými způsoby, jak IoT Edge používá certifikáty ve scénářích brány Azure IoT Hub a IoT Edge.

Důležité

Pro stručnost platí tento článek pro IoT Edge verze 1.2 nebo novější. Koncepty certifikátů pro verzi 1.1 jsou podobné, ale existují některé rozdíly:

• Certifikát certifikační autority zařízení ve verzi 1.1 byl přejmenován na certifikát certifikační autority Edge.
• Certifikát certifikační autority úlohy ve verzi 1.1 byl vyřazen. Modul runtime modulu IoT Edge ve verzi 1.2 nebo novější generuje všechny certifikáty serveru přímo z certifikátu certifikační autority Edge bez certifikátu certifikační autority zprostředkující úlohy mezi nimi v řetězu certifikátů.

Shrnutí

V těchto základních scénářích IoT Edge používá certifikáty. Další informace o jednotlivých scénářích se dozvíte z odkazů.

Actor (Herec/herečka)	Účel	Certifikát
IoT Edge	Zajišťuje komunikaci se správnými IoT Hub	certifikát serveru IoT Hub
IoT Hub	Zajišťuje, že žádost přišla z legitimního zařízení IoT Edge	IoT Edge certifikát identity
Podřízené zařízení IoT	Zajišťuje, že žádost přišla z legitimního zařízení IoT Edge	Certifikát serveru modulu IoT Edge edgeHub vydaný certifikační autoritou Edge
IoT Edge	Podepíše nové certifikáty serveru modulu. Například edgeHub	Certifikát certifikační autority Edge
IoT Edge	Zajišťuje, že požadavek pochází z legitimního podřízeného zařízení	Certifikát identity zařízení IoT

Požadavky

• Měli byste mít základní znalosti o kryptografii veřejného klíče, párech klíčů a o tom, jak může veřejný klíč a privátní klíč šifrovat nebo dešifrovat data. Další informace o tom, jak IoT Edge používá kryptografii veřejného klíče, najdete v tématu Principy kryptografie veřejného klíče a infrastruktury veřejného klíče X.509.
• Měli byste mít základní znalosti o tom, jak IoT Edge souvisí se službou IoT Hub. Další informace najdete v tématu Vysvětlení modulu runtime Azure IoT Edge a jeho architektury.

Scénář s jedním zařízením

Abyste porozuměli konceptům certifikátů IoT Edge, představte si scénář, ve kterém se zařízení IoT Edge s názvem EdgeGateway připojuje ke službě Azure IoT Hub s názvem ContosoIotHub. V tomto příkladu se veškeré ověřování provádí s ověřováním certifikátu X.509 místo symetrických klíčů. Abychom v tomto scénáři vytvořili důvěru, musíme zaručit, že zařízení IoT Hub a IoT Edge jsou autentické: "Je toto zařízení originální a platné?" a "Je identita ioT Hubu správná?". Scénář lze znázorní takto:

Vysvětlíme odpovědi na každou otázku a pak tento příklad rozbalíme v dalších částech článku.

Zařízení ověřuje identitu služby IoT Hub.

Jak EdgeGateway ověří, že komunikuje s originálním ContosoIotHubem? Když edgeGateway chce komunikovat s cloudem, připojí se ke koncovému bodu ContosoIoTHub.Azure-devices.NET. Aby se zajistilo, že je koncový bod autentický, potřebuje IoT Edge k zobrazení identifikace (ID) ContosoIoTHub . ID musí vydat autorita, která EdgeGateway důvěřuje. Pokud chcete ověřit identitu služby IoT Hub, IoT Edge a IoT Hub k ověření identity serveru služby IoT Hub, použijte protokol handshake protokolu TLS. Handshake protokolu TLS je znázorněno v následujícím diagramu. Aby byl příklad jednoduchý, některé podrobnosti byly vynechány. Další informace o protokolu handshake protokolu TLS najdete v tématu handshake protokolu TLS na Wikipedii.

Poznámka:

V tomto příkladu ContosoIoTHub představuje název hostitele služby IoT Hub ContosoIotHub.Azure-devices.NET.

V tomto kontextu nemusíte znát přesné podrobnosti kryptografického algoritmu. Je důležité pochopit, že algoritmus zajišťuje, aby server měl privátní klíč spárovaný s veřejným klíčem. Ověřuje, že prezentující certifikátu ho nezkopíroval nebo ukradl. Pokud jako příklad použijeme ID fotky, bude vaše tvář odpovídat fotce na ID. Pokud někdo vaše ID ukradne, nemůže ho použít k identifikaci, protože vaše tvář je jedinečná a obtížně se reprodukuje. U kryptografických klíčů souvisí pár klíčů a je jedinečný. Místo odpovídající tváře s ID fotky kryptografický algoritmus k ověření identity použije dvojici klíčů.

V našem scénáři contosoIotHub zobrazuje následující řetěz certifikátů:

Kořenová certifikační autorita (CA) je kořenový certifikát Baltimore CyberTrust Root . Tento kořenový certifikát je podepsaný společností DigiCert a je široce důvěryhodný a uložený v mnoha operačních systémech. Například Ubuntu i Windows ho zahrňte do výchozího úložiště certifikátů.

Úložiště certifikátů Systému Windows:

Úložiště certifikátů Ubuntu:

Když zařízení zkontroluje certifikát Baltimore CyberTrust Root , je předinstalovaný v operačním systému. Z pohledu EdgeGateway , protože řetěz certifikátů, který contosoIotHub prezentuje, je podepsaný kořenovou certifikační autoritou, že operační systém důvěřuje, považuje se certifikát za důvěryhodný. Certifikát se označuje jako certifikát serveru Služby IoT Hub. Další informace o certifikátu serveru služby IoT Hub najdete v tématu Podpora protokolu TLS (Transport Layer Security) ve službě IoT Hub.

V souhrnu může EdgeGateway ověřit a důvěřovat identitě ContosoIotHubu , protože:

• ContosoIotHub prezentuje svůj certifikát serveru IoT Hub
• Certifikát serveru je důvěryhodný v úložišti certifikátů operačního systému.
• Data zašifrovaná pomocí veřejného klíče ContosoIotHubu můžou být dešifrována společností ContosoIotHub, což potvrzuje jeho vlastnictví privátního klíče.

IoT Hub ověřuje identitu zařízení IoT Edge.

Jak ContosoIotHub ověří, že komunikuje s EdgeGatewayem? Vzhledem k tomu, že IoT Hub podporuje vzájemné tls (mTLS), zkontroluje certifikát EdgeGateway během ověřování metodou handshake protokolu TLS ověřeného klientem. Pro zjednodušení přeskočíme některé kroky v následujícím diagramu.

V tomto případě EdgeGateway poskytuje svůj certifikát identity zařízení IoT Edge. Z pohledu ContosoIotHub zkontroluje, jestli kryptografický otisk poskytnutého certifikátu odpovídá jeho záznamu, a EdgeGateway má privátní klíč spárovaný s certifikátem, který prezentuje. Při zřizování zařízení IoT Edge ve službě IoT Hub zadáte kryptografický otisk. Kryptografický otisk je to, co IoT Hub používá k ověření certifikátu.

Tip

IoT Hub vyžaduje při registraci zařízení IoT Edge dva kryptografické otisky. Osvědčeným postupem je připravit dva různé certifikáty identity zařízení s různými daty vypršení platnosti. Pokud vyprší platnost jednoho certifikátu, druhý je stále platný a máte čas otočit certifikát, jehož platnost vypršela. Pro registraci je ale také možné použít pouze jeden certifikát. Jeden certifikát použijte nastavením stejného kryptografického otisku certifikátu pro primární i sekundární kryptografické otisky při registraci zařízení.

K získání kryptografického otisku certifikátu identity na EdgeGateway můžeme například použít následující příkaz:

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

Příkaz vypíše kryptografický otisk SHA256 certifikátu:

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

Pokud zobrazíme hodnotu kryptografického otisku SHA256 pro zařízení EdgeGateway zaregistrované ve službě IoT Hub, uvidíme, že odpovídá kryptografickému otisku na Hraničnígateway:

ContosoIotHub může důvěřovat EdgeGateway, protože EdgeGateway představuje platný certifikát identity zařízení IoT Edge, jehož kryptografický otisk odpovídá certifikátu registrovanému ve službě IoT Hub.

Další informace o procesu sestavování certifikátů najdete v tématu Vytvoření a zřízení zařízení IoT Edge v Linuxu pomocí certifikátů X.509.

Poznámka:

Tento příklad neřeší službu Azure IoT Hub Device Provisioning Service (DPS), která má podporu ověřování ca X.509 s IoT Edge při zřizování ve skupině registrací. Pomocí DPS nahrajete certifikát certifikační autority nebo zprostředkující certifikát, ověří se řetěz certifikátů a pak se zařízení zřídí. Další informace najdete v tématu Ověření certifikátu DPS X.509.

Na webu Azure Portal zobrazí SLUŽBA DPS kryptografický otisk SHA1 pro certifikát místo kryptografického otisku SHA256.

DPS zaregistruje nebo aktualizuje kryptografický otisk SHA256 na IoT Hub. Kryptografický otisk můžete ověřit pomocí příkazu openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. Po registraci používá Iot Edge ověřování kryptografickým otiskem ve službě IoT Hub. Pokud se zařízení znovu vytvoří a vystaví se nový certifikát, služba DPS aktualizuje IoT Hub novým kryptografickým otiskem.

IoT Hub v současné době nepodporuje ověřování ca X.509 přímo se službou IoT Edge.

Použití certifikátu pro operace identit modulů

V diagramech ověření certifikátu se může zobrazit, že IoT Edge používá k komunikaci se službou IoT Hub jenom certifikát. IoT Edge se skládá z několika modulů. V důsledku toho IoT Edge používá certifikát ke správě identit modulů pro moduly, které odesílají zprávy. Moduly nepoužívají certifikát k ověření ve službě IoT Hub, ale používají klíče SAS odvozené od privátního klíče, které jsou generovány modulem runtime modulu IoT Edge. Tyto klíče SAS se nemění ani v případě, že vyprší platnost certifikátu identity zařízení. Pokud vyprší platnost certifikátu, edgeHub například pokračuje ve spuštění a pouze operace identit modulu selžou.

Interakce mezi moduly a IoT Hubem je zabezpečená, protože klíč SAS je odvozený z tajného klíče a IoT Edge klíč spravuje bez rizika lidského zásahu.

Scénář hierarchie vnořených zařízení s IoT Edge jako bránou

Teď dobře rozumíte jednoduché interakci IoT Edge mezi ioT Hubem a IoT Hubem. IoT Edge ale může také fungovat jako brána pro podřízená zařízení nebo jiná zařízení IoT Edge. Tyto komunikační kanály musí být také šifrované a důvěryhodné. Kvůli větší složitosti musíme rozšířit náš ukázkový scénář tak, aby zahrnoval podřízené zařízení.

Přidáme běžné zařízení IoT s názvem TempSensor, které se připojí k nadřazené zařízení IoT Edge Edge EdgeGateway , které se připojí ke službě IoT Hub ContosoIotHub. Podobně jako předtím se veškeré ověřování provádí s ověřováním certifikátu X.509. Náš nový scénář vyvolává dvě nové otázky: "Je zařízení TempSensor legitimní?" a "Je identita EdgeGateway správná?". Scénář lze znázorní takto:

Tip

TempSensor je zařízení IoT ve scénáři. Koncept certifikátu je stejný, pokud je tempSensor podřízeným zařízením IoT Edge nadřazeného EdgeGateway.

Zařízení ověřuje identitu brány.

Jak tempSensor ověří, že komunikuje s originální hraniční bránou? Když tempSensor chce mluvit s EdgeGateway, tempSensor potřebuje EdgeGateway k zobrazení ID. ID musí vydat autorita, která důvěřuje tempSensoru .

Tok je stejný jako když EdgeGateway mluví s ContosoIotHubem. TempSensor a EdgeGateway používají k ověření identity EdgeGateway protokol handshake protokolu TLS. Existují dva důležité podrobnosti:

• Specificita názvu hostitele: Certifikát, který prezentuje EdgeGateway , musí být vystavený stejnému názvu hostitele (doméně nebo IP adrese), který nástroj TempSensor používá pro připojení k EdgiGateway.
• Specificita kořenové certifikační autority podepsané svým držitelem: Řetěz certifikátů, který představuje EdgeGateway , pravděpodobně není ve výchozím důvěryhodném kořenovém úložišti operačního systému.

Abychom pochopili podrobnosti, nejprve se podíváme na řetěz certifikátů, který představuje EdgeGateway.

Specificita názvu hostitele

Běžný název certifikátu CN = edgegateway.local je uveden v horní části řetězce. edgegateway.local je běžný název certifikátu serveru edgeHubu. edgegateway.local je také název hostitele pro EdgeGateway v místní síti (LAN nebo virtuální síť), kde jsou připojeny tempSensor a EdgeGateway . Může to být privátní IP adresa, například 192.168.1.23 nebo plně kvalifikovaný název domény (FQDN), jako je diagram. Certifikát serveru EdgeHub se vygeneruje pomocí parametru názvu hostitele definovaného v souboru IoT Edge config.toml. Nezaměňujte certifikát serveru EdgeHub s certifikátem certifikační autority Edge. Další informace o správě certifikátu certifikační autority Edge najdete v tématu Správa certifikátů IoT Edge.

Když se tempSensor připojí k EdgeGateway, tempSensor použije název hostitele edgegateway.local pro připojení k EdgeGateway. TempSensor zkontroluje certifikát, který představuje EdgeGateway , a ověří, že běžný název certifikátu je edgegateway.local. Pokud se běžný název certifikátu liší, TempSensor připojení odmítne.

Poznámka:

Pro zjednodušení příklad ukazuje běžný název certifikátu subjektu (CN) jako vlastnost, která je ověřena. V praxi platí, že pokud má certifikát alternativní název subjektu (SAN), ověří se místo CN síť SAN. Obecně platí, že síť SAN může obsahovat více hodnot, a proto má hlavní doménu nebo název hostitele pro držitele certifikátu i všechny alternativní domény.

Proč je potřeba edgeGateway říct o vlastním názvu hostitele?

EdgeGateway nemá spolehlivý způsob, jak se k němu můžou připojit ostatní klienti v síti. Například v privátní síti můžou existovat servery DHCP nebo služby mDNS, které uvádějí EdgeGateway jako 10.0.0.2 nebo example-mdns-hostname.local. Některé sítě ale můžou mít servery DNS, které se mapovaly edgegateway.local na IP adresu 10.0.0.2EdgeGateway .

K vyřešení problému ioT Edge použije nakonfigurovanou hodnotu config.toml názvu hostitele a vytvoří pro něj certifikát serveru. Když požadavek přijde na modul EdgeHub , zobrazí certifikát se správným běžným názvem certifikátu (CN).

Proč IoT Edge vytváří certifikáty?

V tomto příkladu si všimněte, že v řetězu certifikátů existuje hraniční cesta k sadě úloh iotedged. Je to certifikační autorita (CA), která existuje na zařízení IoT Edge označované jako certifikační autorita Edge (dříve označovaná jako certifikační autorita zařízení ve verzi 1.1). Podobně jako kořenový certifikační autorita Baltimore CyberTrust v předchozím příkladu může certifikační autorita Edge vydávat další certifikáty. Nejdůležitější je, a také v tomto příkladu vydává certifikát serveru pro modul EdgeHub . Může ale také vydávat certifikáty jiným modulům spuštěným na zařízení IoT Edge.

Důležité

Ve výchozím nastavení bez konfigurace se certifikační autorita Edge při prvním spuštění automaticky vygeneruje modulem runtime modulu IoT Edge, kterému se říká certifikační autorita Pro rychlý start, a pak vydá certifikát modulu EdgeHub . Tento proces zrychluje připojení podřízeného zařízení tím, že edgeHubu umožní prezentovat platný certifikát podepsaný. Bez této funkce byste museli získat certifikační autoritu k vydání certifikátu pro modul EdgeHub . Použití automaticky vygenerované certifikační autority Edge pro rychlý start není podporované pro použití v produkčním prostředí. Další informace o certifikační autoritě Edge pro rychlý start najdete v tématu Rychlý start certifikační autority edge.

Není nebezpečné mít na zařízení certifikát vystavitele?

Certifikační autorita Edge je navržená tak, aby umožňovala řešení s omezeným, nespolehlivým, nákladným nebo chybějícím připojením, ale současně mají přísné předpisy nebo zásady pro obnovení certifikátů. Bez certifikační autority Edge nemůže IoT Edge (a zejména edgeHub ) fungovat.

Zabezpečení certifikační autority Edge v produkčním prostředí:

• Privátní klíč EdgeCA umístěte do důvěryhodného modulu platformy (TPM), nejlépe v podobě dočasného vygenerování privátního klíče a nikdy neopustí čip TPM.
• Použijte infrastrukturu veřejných klíčů (PKI), do které se certifikační autorita Edge zahrne. To umožňuje zakázat nebo odmítnout obnovení ohrožených certifikátů. Infrastruktura veřejných klíčů může být spravovaná oddělením IT zákazníka, pokud má znalosti o tom, jak (nižší náklady) nebo prostřednictvím komerčního poskytovatele infrastruktury veřejných klíčů.

Specificita kořenové certifikační autority podepsané svým držitelem

Modul EdgeHub je důležitou komponentou, která tvoří IoT Edge tím, že zpracovává veškerý příchozí provoz. V tomto příkladu používá certifikát vystavený certifikační autoritou Edge, který zase vydává kořenová certifikační autorita podepsaná svým držitelem. Vzhledem k tomu, že kořenový certifikační autorita není systémem důvěryhodná, jediný způsob, jak by nástroj TempSensor důvěřoval, je nainstalovat certifikát certifikační autority do zařízení. To se také označuje jako scénář sady důvěryhodnosti, kdy potřebujete distribuovat kořenový adresář klientům, kteří potřebují důvěřovat řetězu. Scénář sady důvěryhodných prostředků může být problémový, protože potřebujete přístup k zařízení a nainstalovat certifikát. Instalace certifikátu vyžaduje plánování. Můžete ho provést pomocí skriptů, přidat během výroby nebo předinstalovat v imagi operačního systému.

Poznámka:

Někteří klienti a sady SDK nepoužívají důvěryhodné kořenové úložiště operačního systému a musíte předat soubor kořenové certifikační autority přímo.

Když použijete všechny tyto koncepty, tempSensor může ověřit, že komunikuje s originální hraniční bránou EdgeGateway, protože zobrazil certifikát, který odpovídal adrese a certifikát je podepsaný důvěryhodným kořenovým adresářem.

K ověření řetězu certifikátů můžete použít openssl na zařízení TempSensor . V tomto příkladu si všimněte, že název hostitele pro připojení odpovídá CN certifikátu hloubky 0 a že kořenová certifikační autorita odpovídá.

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

Další informace o příkazu najdete v openssl dokumentaci k OpenSSL.

Můžete také zkontrolovat certifikáty, ve /var/lib/aziot/certd/certskterých jsou ve výchozím nastavení uložené . Certifikáty certifikační autority Edge, certifikáty identit zařízení a certifikáty modulů najdete v adresáři. Ke kontrole certifikátů můžete použít openssl x509 příkazy. Příklad:

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

Stručně řečeno, TempSensor může důvěřovat EdgeGateway , protože:

• Modul EdgeHub ukázal platný certifikát serveru modulu IoT Edge pro edgegateway.local.
• Certifikát vydává certifikační autorita Edge, která je vystavenamy_private_root_CA
• Tato privátní kořenová certifikační autorita je také uložena v databázi TempSensor jako důvěryhodná kořenová certifikační autorita dříve.
• Kryptografické algoritmy ověřují, že je možné důvěřovat vlastnictví a řetězu vystavování.

Certifikáty pro jiné moduly

Jiné moduly můžou získat certifikáty serveru vydané certifikační autoritou Edge. Například modul Grafana , který má webové rozhraní. Může také získat certifikát od certifikační autority Edge. Moduly se považují za podřízená zařízení hostovaná v kontejneru. Schopnost získat certifikát z modulu runtime modulu IoT Edge je ale speciální oprávnění. Moduly volají rozhraní API pro úlohy pro příjem certifikátu serveru zřetězenýho s nakonfigurovanou certifikační autoritou Edge.

Brána ověřuje identitu zařízení.

Jak EdgeGateway ověří, že komunikuje s tempSensorem? EdgeGateway používá ověřování klientů TLS k ověření tempSensoru.

Sekvence je podobná jako ContosoIotHub , která ověřuje zařízení. Ve scénáři brány ale EdgeGateway spoléhá na ContosoIotHub jako zdroj pravdy pro záznam certifikátů. EdgeGateway také udržuje offline kopii nebo mezipaměť v případě, že neexistuje připojení ke cloudu.

Tip

Na rozdíl od zařízení IoT Edge nejsou podřízená zařízení IoT omezena na ověřování X.509 kryptografického otisku. Možnost je také ověřování certifikační autority X.509. Místo pouhého vyhledání shody na kryptografickém otisku může EdgeGateway také zkontrolovat, jestli je certifikát TempSensor rootovaný v certifikační autoritě, která byla nahraná do ContosoIotHubu.

V souhrnu může EdgeGateway důvěřovat tempSensoru , protože:

• TempSensor představil platný certifikát identity zařízení IoT pro jeho název.
• Kryptografický otisk certifikátu identity odpovídá kryptografickému otisku nahranému do ContosoIotHubu.
• Kryptografické algoritmy ověřují, že je možné důvěřovat vlastnictví a řetězu vystavování.

Kde získat certifikáty a správu

Ve většině případů můžete zadat vlastní certifikáty nebo použít u automaticky generovaných certifikátů. Například certifikační autorita Edge a certifikát EdgeHubu se generují automaticky.

Osvědčeným postupem je ale nakonfigurovat zařízení tak, aby ke správě certifikátů x509 používala server EST (Secure Transport). Pomocí serveru EST můžete ručně zpracovávat certifikáty a instalovat je na zařízení. Další informace o použití serveru EST najdete v tématu Konfigurace registrace přes zabezpečený transportní server pro Azure IoT Edge.

Certifikáty můžete použít i k ověření na serveru EST. Tyto certifikáty slouží k ověřování u serverů EST k vydávání dalších certifikátů. Certifikační služba používá k ověření pomocí serveru EST certifikát bootstrap. Certifikát bootstrap je dlouhodobý. Po počátečním ověření služba certifikát odešle na server EST žádost o vydání certifikátu identity. Tento certifikát identity se používá v budoucích požadavcích EST na stejný server.

Pokud nemůžete použít server EST, měli byste požádat o certifikáty od svého poskytovatele PKI. Soubory certifikátů můžete spravovat ručně ve službě IoT Hub a na zařízeních IoT Edge. Další informace potřebujete ke správě certifikátů na zařízení IoT Edge.

Pro testování konceptu vývoje můžete vytvořit testovací certifikáty. Další informace najdete v tématu Vytvoření ukázkových certifikátů pro testování funkcí zařízení IoT Edge.

Certifikáty v IoT

Certifikační autorita

Certifikační autorita (CA) je entita, která vydává digitální certifikáty. Certifikační autorita funguje jako důvěryhodná třetí strana mezi vlastníkem a příjemcem certifikátu. Digitální certifikát certifikuje vlastnictví veřejného klíče příjemcem certifikátu. Řetěz certifikátů důvěryhodnosti funguje tím, že zpočátku vydává kořenový certifikát, což je základ pro vztah důvěryhodnosti ve všech certifikátech vydaných autoritou. Vlastník kořenového certifikátu pak může vydávat další zprostředkující certifikáty (podřízené certifikáty zařízení).

Kořenový certifikát certifikační autority

Kořenový certifikát certifikační autority je kořenem důvěryhodnosti celého procesu. V produkčních scénářích je tento certifikát certifikační autority zakoupen od důvěryhodné komerční certifikační autority, jako je Baltimore, Verisign nebo DigiCert. Pokud máte úplnou kontrolu nad zařízeními, která se připojují k zařízením IoT Edge, je možné použít certifikační autoritu na podnikové úrovni. V obou událostech ho používá celý řetěz certifikátů z IoT Edge do IoT Hubu. Podřízená zařízení IoT musí důvěřovat kořenovému certifikátu. Kořenový certifikát certifikační autority můžete uložit buď v úložišti důvěryhodných kořenových certifikačních autorit, nebo zadat podrobnosti o certifikátu v kódu aplikace.

Zprostředkující certifikáty

V typickém výrobním procesu pro vytváření zabezpečených zařízení se certifikáty kořenové certifikační autority zřídka používají přímo, především kvůli riziku úniku nebo vystavení. Kořenový certifikát certifikační autority vytvoří a digitálně podepíše jeden nebo více zprostředkujících certifikátů certifikační autority. Může existovat pouze jeden nebo může existovat řetěz těchto zprostředkujících certifikátů. Mezi scénáře, které by vyžadovaly řetěz zprostředkujících certifikátů, patří:

• Hierarchie oddělení v rámci výrobce
• Více společností zapojených sériově do výroby zařízení
• Zákazník, který si koupí kořenovou certifikační autoritu a odvozuje podpisový certifikát pro výrobce, aby podepisoval zařízení, která jménem daného zákazníka provede

V každém případě výrobce použije certifikát zprostředkující certifikační autority na konci tohoto řetězu k podepsání certifikátu certifikační autority Edge umístěného na koncovém zařízení. Tyto zprostředkující certifikáty jsou úzce chráněny ve výrobní závodu. Procházejí přísnými procesy, a to jak fyzickou, tak elektronickou pro jejich použití.

Další kroky

• Další informace o tom, jak nainstalovat certifikáty na zařízení IoT Edge a odkazovat na ně z konfiguračního souboru, najdete v tématu Správa certifikátu na zařízení IoT Edge.
• Principy modulů Azure IoT Edge
• Konfigurace zařízení IoT Edge tak, aby fungovalo jako transparentní brána
• Tento článek popisuje certifikáty, které slouží k zabezpečení připojení mezi různými komponentami na zařízení IoT Edge nebo mezi zařízením IoT Edge a všemi podřízenými zařízeními. Certifikáty můžete použít také k ověření zařízení IoT Edge ve službě IoT Hub. Tyto ověřovací certifikáty se liší a nejsou popsány v tomto článku. Další informace o ověřování zařízení pomocí certifikátů najdete v tématu Vytvoření a zřízení zařízení IoT Edge pomocí certifikátů X.509.