Begrijpen hoe Azure IoT Edge certificaten gebruikt

  • Artikel

Van toepassing op:IoT Edge 1.5-vinkje IoT Edge 1.5 Vinkje voor IoT Edge 1.4 IoT Edge 1.4

Belangrijk

IoT Edge 1.5 LTS en IoT Edge 1.4 LTS worden ondersteund releases. IoT Edge 1.4 LTS eindigt op 12 november 2024. Raadpleeg IoT Edge bijwerken als u een eerdere versie hebt.

IoT Edge gebruikt verschillende typen certificaten voor verschillende doeleinden. In dit artikel wordt u begeleid bij de verschillende manieren waarop IoT Edge certificaten gebruikt met Azure IoT Hub- en IoT Edge-gatewayscenario's.

Belangrijk

Voor kortheid is dit artikel van toepassing op IoT Edge versie 1.2 of hoger. De certificaatconcepten voor versie 1.1 zijn vergelijkbaar, maar er zijn enkele verschillen:

  • De naam van het CA-certificaat van het apparaat in versie 1.1 is gewijzigd in een Edge CA-certificaat.
  • Het CA-certificaat van de workload in versie 1.1 is buiten gebruik gesteld. In versie 1.2 of hoger genereert de Runtime van de IoT Edge-module alle servercertificaten rechtstreeks vanuit het Edge-CA-certificaat, zonder het tussenliggende ca-certificaat van de werkbelasting ertussen in de certificaatketen.

Samenvatting

In deze kernscenario's gebruikt IoT Edge certificaten. Gebruik de koppelingen voor meer informatie over elk scenario.

Acteur Doel Certificaat
IoT Edge Zorgt ervoor dat deze communiceert met de juiste IoT Hub IoT Hub-servercertificaat
IoT Hub Zorgt ervoor dat de aanvraag afkomstig is van een legitiem IoT Edge-apparaat Id-certificaat IoT Edge
Downstream IoT-apparaat Zorgt ervoor dat deze communiceert met de juiste IoT Edge-gateway Moduleservercertificaat voor edgeHub van IoT Edge Hub, uitgegeven door Edge-CA
IoT Edge Ondertekent nieuwe moduleservercertificaten. Bijvoorbeeld edgeHub Edge CA-certificaat
IoT Edge Zorgt ervoor dat de aanvraag afkomstig is van een legitiem downstream apparaat Id-certificaat IoT-apparaat

Vereisten

Scenario met één apparaat

Om inzicht te krijgen in ioT Edge-certificaatconcepten, stelt u zich een scenario voor waarbij een IoT Edge-apparaat met de naam EdgeGateway verbinding maakt met een Azure IoT Hub met de naam ContosoIotHub. In dit voorbeeld wordt alle verificatie uitgevoerd met X.509-certificaatverificatie in plaats van symmetrische sleutels. Om een vertrouwensrelatie in dit scenario tot stand te brengen, moeten we garanderen dat het IoT Hub- en IoT Edge-apparaat authentiek zijn: 'Is dit apparaat echt en geldig?' en 'Is de identiteit van de IoT Hub juist?'. Het scenario kan als volgt worden geïllustreerd:

Statusdiagram van vertrouwensscenario met verbinding tussen IoT Edge-apparaat en IoT Hub.

We leggen de antwoorden op elke vraag uit en breiden vervolgens het voorbeeld uit in latere secties van het artikel.

Op het apparaat wordt de IoT Hub-identiteit geverifieerd

Hoe controleert EdgeGateway of deze communiceert met de legitieme ContosoIotHub? Wanneer EdgeGateway met de cloud wil praten, maakt deze verbinding met het eindpunt ContosoIoTHub.Azure-devices.NET. Om ervoor te zorgen dat het eindpunt authentiek is, heeft IoT Edge ContosoIoTHub nodig om identificatie (ID) weer te geven. De id moet worden uitgegeven door een instantie die EdgeGateway vertrouwt. Als u de IoT Hub-identiteit wilt controleren, gebruiken IoT Edge en IoT Hub het TLS-handshake-protocol om de serveridentiteit van IoT Hub te verifiëren. In het volgende diagram ziet u een TLS-handshake . Om het voorbeeld eenvoudig te houden, zijn enkele details weggelaten. Zie TLS-handshake op Wikipedia voor meer informatie over het TLS-handshakeprotocol.

Notitie

In dit voorbeeld vertegenwoordigt ContosoIoTHub de hostnaam van de IoT Hub ContosoIotHub.Azure-devices.NET.

Sequentiediagram met certificaatuitwisseling van IoT Hub naar IoT Edge-apparaat met certificaatverificatie met het vertrouwde basisarchief op het IoT Edge-apparaat.

In deze context hoeft u niet de exacte details van het cryptografische algoritme te kennen. Het is belangrijk om te begrijpen dat het algoritme ervoor zorgt dat de server beschikt over de persoonlijke sleutel die is gekoppeld aan de openbare sleutel. Er wordt gecontroleerd of de presentator van het certificaat het niet heeft gekopieerd of gestolen. Als we een foto-id als voorbeeld gebruiken, komt uw gezicht overeen met de foto op de id. Als iemand uw id steelt, kan hij deze niet gebruiken voor identificatie omdat uw gezicht uniek en moeilijk te reproduceren is. Voor cryptografische sleutels is het sleutelpaar gerelateerd en uniek. In plaats van het koppelen van een gezicht aan een foto-id, gebruikt het cryptografische algoritme het sleutelpaar om de identiteit te verifiëren.

In ons scenario toont ContosoIotHub de volgende certificaatketen:

Stroomdiagram met tussenliggende en basiscertificeringsinstantieketen voor IoT Hub.

De basiscertificeringsinstantie (CA) is het Baltimore CyberTrust-basiscertificaat . Dit basiscertificaat wordt ondertekend door DigiCert en wordt algemeen vertrouwd en opgeslagen in veel besturingssystemen. Bijvoorbeeld, zowel Ubuntu als Windows opnemen in het standaardcertificaatarchief.

Windows-certificaatarchief:

Schermopname van het Baltimore CyberTrust-basiscertificaat dat wordt vermeld in het Windows-certificaatarchief.

Ubuntu-certificaatarchief:

Schermopname van het Baltimore CyberTrust Root-certificaat dat wordt vermeld in het Ubuntu-certificaatarchief.

Wanneer een apparaat controleert op het Baltimore CyberTrust-basiscertificaat , wordt het vooraf geïnstalleerd in het besturingssysteem. Vanuit het perspectief van EdgeGateway , omdat de certificaatketen die door ContosoIotHub wordt gepresenteerd, is ondertekend door een basis-CA die het besturingssysteem vertrouwt, wordt het certificaat beschouwd als betrouwbaar. Het certificaat wordt het IoT Hub-servercertificaat genoemd. Zie Tls-ondersteuning (Transport Layer Security) in IoT Hub voor meer informatie over het IoT Hub-servercertificaat.

Kortom, EdgeGateway kan de identiteit van ContosoIotHub verifiëren en vertrouwen omdat:

  • ContosoIotHub presenteert het IoT Hub-servercertificaat
  • Het servercertificaat wordt vertrouwd in het certificaatarchief van het besturingssysteem
  • Gegevens die zijn versleuteld met de openbare sleutel van ContosoIotHub, kunnen worden ontsleuteld door ContosoIotHub, waarmee wordt aangetoond dat de persoonlijke sleutel in bezit is

IoT Hub verifieert ioT Edge-apparaatidentiteit

Hoe controleert ContosoIotHub of deze communiceert met EdgeGateway? Omdat IoT Hub wederzijdse TLS (mTLS) ondersteunt, wordt het certificaat van EdgeGateway gecontroleerd tijdens door de client geverifieerde TLS-handshake. Ter vereenvoudiging slaan we enkele stappen in het volgende diagram over.

Sequentiediagram met certificaatuitwisseling van IoT Edge-apparaat naar IoT Hub met verificatie van certificaatvingerafdruk op IoT Hub.

In dit geval biedt EdgeGateway het IoT Edge-apparaatidentiteitscertificaat. Vanuit het perspectief van ContosoIotHub wordt gecontroleerd of de vingerafdruk van het opgegeven certificaat overeenkomt met de record en EdgeGateway de persoonlijke sleutel heeft gekoppeld aan het certificaat dat wordt gepresenteerd. Wanneer u een IoT Edge-apparaat inricht in IoT Hub, geeft u een vingerafdruk op. De vingerafdruk is wat IoT Hub gebruikt om het certificaat te verifiëren.

Tip

Voor IoT Hub zijn twee vingerafdrukken vereist bij het registreren van een IoT Edge-apparaat. Een best practice is om twee verschillende apparaatidentiteitscertificaten met verschillende vervaldatums voor te bereiden. Als het ene certificaat op deze manier verloopt, is het andere nog geldig en krijgt u tijd om het verlopen certificaat te draaien. Het is echter ook mogelijk om slechts één certificaat te gebruiken voor registratie. Gebruik één certificaat door dezelfde vingerafdruk voor zowel de primaire als de secundaire vingerafdruk in te stellen bij het registreren van het apparaat.

We kunnen bijvoorbeeld de volgende opdracht gebruiken om de vingerafdruk van het identiteitscertificaat op EdgeGateway op te halen:

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

Met de opdracht wordt de SHA256-vingerafdruk van het certificaat uitgevoerd:

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

Als we de SHA256-vingerafdrukwaarde bekijken voor het EdgeGateway-apparaat dat is geregistreerd in IoT Hub, kunnen we zien dat deze overeenkomt met de vingerafdruk op EdgeGateway:

Schermopname van Azure Portal van de vingerafdruk van het EdgeGateway-apparaat in ContosoIotHub.

Kortom, ContosoIotHub kan EdgeGateway vertrouwen omdat EdgeGateway een geldig IoT Edge-apparaatidentiteitscertificaat presenteert waarvan de vingerafdruk overeenkomt met de vingerafdruk die is geregistreerd in IoT Hub.

Zie Een IoT Edge-apparaat in Linux maken en inrichten met X.509-certificaten voor meer informatie over het proces voor het bouwen van certificaten.

Notitie

In dit voorbeeld wordt niet ingegaan op Azure IoT Hub Device Provisioning Service (DPS), dat ondersteuning biedt voor X.509-CA-verificatie met IoT Edge wanneer deze is ingericht met een inschrijvingsgroep. Met DPS uploadt u het CA-certificaat of een tussenliggend certificaat, wordt de certificaatketen gecontroleerd en wordt het apparaat ingericht. Zie DPS X.509-certificaatverklaring voor meer informatie.

In Azure Portal geeft DPS de SHA1-vingerafdruk voor het certificaat weer in plaats van de SHA256-vingerafdruk.

DPS registreert of werkt de SHA256-vingerafdruk bij naar IoT Hub. U kunt de vingerafdruk controleren met behulp van de opdracht openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. Na registratie maakt Iot Edge gebruik van vingerafdrukverificatie met IoT Hub. Als het apparaat opnieuw wordt ingerichte en er een nieuw certificaat wordt uitgegeven, werkt DPS IoT Hub bij met de nieuwe vingerafdruk.

IoT Hub biedt momenteel geen ondersteuning voor X.509 CA-verificatie rechtstreeks met IoT Edge.

Certificaatgebruik voor moduleidentiteitsbewerkingen

In de certificaatverificatiediagrammen kan ioT Edge alleen het certificaat gebruiken om met IoT Hub te communiceren. IoT Edge bestaat uit verschillende modules. Als gevolg hiervan gebruikt IoT Edge het certificaat om module-id's te beheren voor modules die berichten verzenden. De modules gebruiken het certificaat niet om te verifiëren bij IoT Hub, maar gebruiken eerder SAS-sleutels die zijn afgeleid van de persoonlijke sleutel die worden gegenereerd door de Runtime van de IoT Edge-module. Deze SAS-sleutels worden niet gewijzigd, zelfs niet als het certificaat van de apparaat-id verloopt. Als het certificaat verloopt, blijft edgeHub bijvoorbeeld actief en mislukken alleen de moduleidentiteitsbewerkingen.

De interactie tussen modules en IoT Hub is veilig omdat de SAS-sleutel is afgeleid van een geheim en IoT Edge de sleutel beheert zonder het risico van menselijke tussenkomst.

Scenario voor geneste apparaathiërarchie met IoT Edge als gateway

U hebt nu een goed begrip van een eenvoudige interactie tussen IoT Edge en IoT Hub. IoT Edge kan echter ook fungeren als een gateway voor downstreamapparaten of andere IoT Edge-apparaten. Deze communicatiekanalen moeten ook worden versleuteld en vertrouwd. Vanwege de extra complexiteit moeten we ons voorbeeldscenario uitbreiden om een downstreamapparaat op te nemen.

We voegen een gewoon IoT-apparaat toe met de naam TempSensor, dat verbinding maakt met het bovenliggende IoT Edge-apparaat EdgeGateway dat verbinding maakt met IoT Hub ContosoIotHub. Net als voorheen wordt alle verificatie uitgevoerd met X.509-certificaatverificatie. Ons nieuwe scenario brengt twee nieuwe vragen met zich mee: 'Is het TempSensor-apparaat legitiem?' en 'Is de identiteit van de EdgeGateway juist?'. Het scenario kan als volgt worden geïllustreerd:

Statusdiagram van vertrouwensscenario met verbinding tussen IoT Edge-apparaat, een IoT Edge-gateway en IoT Hub.

Tip

TempSensor is een IoT-apparaat in het scenario. Het certificaatconcept is hetzelfde als TempSensor een downstream IoT Edge-apparaat van bovenliggende EdgeGateway is.

Op het apparaat wordt de gateway-id geverifieerd

Hoe controleert TempSensor of deze communiceert met de legitieme EdgeGateway? Wanneer TempSensor met de EdgeGateway wil praten, heeft TempSensor EdgeGateway nodig om een id weer te geven. De id moet worden uitgegeven door een instantie die TempSensor vertrouwt.

Sequentiediagram met certificaatuitwisseling van gatewayapparaat naar IoT Edge-apparaat met certificaatverificatie met behulp van de persoonlijke basiscertificeringsinstantie.

De stroom is hetzelfde als wanneer EdgeGateway met ContosoIotHub praat. TempSensor en EdgeGateway gebruiken het TLS-handshake-protocol om de identiteit van EdgeGateway te verifiëren. Er zijn twee belangrijke details:

  • Hostnaamspecifiekheid: het certificaat dat wordt gepresenteerd door EdgeGateway , moet worden uitgegeven aan dezelfde hostnaam (domein of IP-adres) die TempSensor gebruikt om verbinding te maken met EdgeGateway.
  • Zelfondertekende basis-CA-specificiteit: de certificaatketen die door EdgeGateway wordt gepresenteerd, bevindt zich waarschijnlijk niet in het standaard vertrouwde basisarchief van het besturingssysteem.

Als u meer wilt weten over de details, gaan we eerst de certificaatketen bekijken die door EdgeGateway wordt gepresenteerd.

Stroomdiagram met de certificeringsinstantieketen voor een IoT Edge-gateway.

Hostnaamspecifiekheid

De algemene naam van het certificaat CN = edgegateway.local wordt boven aan de keten vermeld. edgegateway.local is de algemene naam van het servercertificaat van EdgeHub. edgegateway.local is ook de hostnaam voor EdgeGateway op het lokale netwerk (LAN of VNet) waar TempSensor en EdgeGateway zijn verbonden. Het kan een privé-IP-adres zijn, zoals 192.168.1.23 of een FQDN (Fully Qualified Domain Name), zoals het diagram. Het edgeHub-servercertificaat wordt gegenereerd met behulp van de hostnaamparameter die is gedefinieerd in het IoT Edge config.toml-bestand. Verwar het EdgeHub-servercertificaat niet met het Edge CA-certificaat. Zie IoT Edge-certificaten beheren voor meer informatie over het beheren van het Edge-CA-certificaat.

Wanneer TempSensor verbinding maakt met EdgeGateway, gebruikt TempSensor de hostnaam edgegateway.local om verbinding te maken met EdgeGateway. TempSensor controleert het certificaat dat wordt gepresenteerd door EdgeGateway en controleert of de algemene naam van het certificaat edgegateway.local is. Als de algemene naam van het certificaat anders is, weigert TempSensor de verbinding.

Notitie

Ter vereenvoudiging toont het voorbeeld de algemene naam van het onderwerpcertificaat (CN) als eigenschap die wordt gevalideerd. Als een certificaat in de praktijk een alternatieve naam voor het onderwerp (SAN) heeft, wordt SAN gevalideerd in plaats van CN. Over het algemeen, omdat SAN meerdere waarden kan bevatten, heeft het zowel het hoofddomein/de hostnaam voor de certificaathouder als eventuele alternatieve domeinen.

Waarom moet EdgeGateway worden verteld over de eigen hostnaam?

EdgeGateway heeft geen betrouwbare manier om te weten hoe andere clients in het netwerk er verbinding mee kunnen maken. In een particulier netwerk kunnen er bijvoorbeeld DHCP-servers of mDNS-services zijn die EdgeGateway vermelden als 10.0.0.2 of example-mdns-hostname.local. Sommige netwerken kunnen echter DNS-servers hebben die zijn toegewezen edgegateway.local aan het IP-adres 10.0.0.2van EdgeGateway.

Om het probleem op te lossen, gebruikt IoT Edge de geconfigureerde hostnaamwaarde in config.toml en maakt er een servercertificaat voor. Wanneer een aanvraag naar de EdgeHub-module wordt verzonden, wordt het certificaat weergegeven met de juiste algemene naam van het certificaat (CN).

Waarom maakt IoT Edge certificaten?

In het voorbeeld ziet u dat er een iotedged workload ca edgegateway in de certificaatketen is. Dit is de certificeringsinstantie (CA) die bestaat op het IoT Edge-apparaat dat bekend staat als Edge-CA (voorheen apparaat-CA genoemd in versie 1.1). Net als de Baltimore CyberTrust-basis-CA in het eerdere voorbeeld kan de Edge-CA andere certificaten uitgeven. Het belangrijkste is, en ook in dit voorbeeld, geeft het servercertificaat uit aan de EdgeHub-module . Maar het kan ook certificaten uitgeven aan andere modules die worden uitgevoerd op het IoT Edge-apparaat.

Belangrijk

Standaard zonder configuratie wordt Edge-CA automatisch gegenereerd door de Runtime van de IoT Edge-module wanneer deze voor het eerst wordt gestart, ook wel quickstart Edge CA genoemd, en vervolgens een certificaat aan edgeHub-module uitgegeven. Dit proces versnelt de downstreamapparaatverbinding doordat EdgeHub een geldig certificaat kan presenteren dat is ondertekend. Zonder deze functie moet u ervoor zorgen dat uw CA een certificaat voor de EdgeHub-module moet uitgeven. Het gebruik van een automatisch gegenereerde QuickStart Edge-CA wordt niet ondersteund voor gebruik in productie. Zie Quickstart Edge CA voor meer informatie over quickstart Edge CA.

Is het niet gevaarlijk om een certificaatverlener op het apparaat te hebben?

Edge CA is ontworpen om oplossingen met beperkte, onbetrouwbare, dure of afwezige connectiviteit mogelijk te maken, maar tegelijkertijd strikte voorschriften of beleidsregels voor certificaatvernieuwingen hebben. Zonder Edge-CA kan IoT Edge, en met name edgeHub , niet werken.

De Edge-CA beveiligen in productie:

  • Plaats de Persoonlijke EdgeCA-sleutel in een TPM (Trusted Platform Module), bij voorkeur op een manier waarbij de persoonlijke sleutel tijdelijk wordt gegenereerd en nooit de TPM verlaat.
  • Gebruik een PKI (Public Key Infrastructure) waarop de Edge-CA wordt samengerold. Dit biedt de mogelijkheid om het vernieuwen van gecompromitteerde certificaten uit te schakelen of te weigeren. De PKI kan worden beheerd door klant-IT als ze weten hoe (lagere kosten) of via een commerciële PKI-provider.

Zelfondertekende basis-CA-specificiteit

De EdgeHub-module is een belangrijk onderdeel dat IoT Edge vormt door al het binnenkomende verkeer te verwerken. In dit voorbeeld wordt een certificaat gebruikt dat is uitgegeven door de Edge-CA, die op zijn beurt wordt uitgegeven door een zelfondertekende basis-CA. Omdat de basis-CA niet wordt vertrouwd door het besturingssysteem, is het alleen de enige manier waarop TempSensor het CA-certificaat op het apparaat installeert. Dit wordt ook wel het vertrouwensbundelscenario genoemd, waarbij u de hoofdmap moet distribueren naar clients die de keten moeten vertrouwen. Het scenario voor vertrouwensbundel kan lastig zijn omdat u toegang nodig hebt tot het apparaat en het certificaat moet installeren. Voor het installeren van het certificaat is planning vereist. Dit kan worden gedaan met scripts, toegevoegd tijdens de productie of vooraf geïnstalleerd in de installatiekopieën van het besturingssysteem.

Notitie

Sommige clients en SDK's maken geen gebruik van het vertrouwde basisarchief van het besturingssysteem en u moet het basis-CA-bestand rechtstreeks doorgeven.

Door al deze concepten toe te passen, kan TempSensor controleren of deze communiceert met de legitieme EdgeGateway , omdat het een certificaat heeft gepresenteerd dat overeenkomt met het adres en het certificaat is ondertekend door een vertrouwde basis.

Als u de certificaatketen wilt controleren, kunt u dit gebruiken openssl op het TempSensor-apparaat . In dit voorbeeld ziet u dat de hostnaam voor de verbinding overeenkomt met de CN van het diepte 0-certificaat en dat de basis-CA overeenkomt.

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

Zie de OpenSSL-documentatie voor meer informatie over openssl de opdracht.

U kunt ook de certificaten controleren waarin ze standaard worden opgeslagen in /var/lib/aziot/certd/certs. U vindt Edge-CA-certificaten , apparaat-id-certificaten en modulecertificaten in de map. U kunt opdrachten gebruiken openssl x509 om de certificaten te controleren. Voorbeeld:

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

Kortom, TempSensor kan EdgeGateway vertrouwen omdat:

  • In de edgeHub-module is een geldig Servercertificaat voor de IoT Edge-module voor edgegateway.local getoond
  • Het certificaat wordt uitgegeven door de Edge-CA die wordt uitgegeven door my_private_root_CA
  • Deze privé-basis-CA wordt ook opgeslagen in tempSensor als vertrouwde basis-CA eerder
  • Cryptografische algoritmen controleren of het eigendom en de uitgifteketen kunnen worden vertrouwd

Certificaten voor andere modules

Andere modules kunnen servercertificaten ophalen die zijn uitgegeven door Edge CA. Bijvoorbeeld een Grafana-module met een webinterface. Het kan ook een certificaat ophalen van de Edge-CA. Modules worden behandeld als downstreamapparaten die worden gehost in de container. Het verkrijgen van een certificaat van de Runtime van de IoT Edge-module is echter een speciale bevoegdheid. Modules roepen de workload-API aan om het servercertificaat te ontvangen dat is gekoppeld aan de geconfigureerde Edge-CA.

De gateway controleert de apparaat-id

Hoe controleert EdgeGateway of deze communiceert met TempSensor? EdgeGateway maakt gebruik van TLS-clientverificatie om TempSensor te verifiëren.

Sequentiediagram met certificaatuitwisseling van IoT Edge-apparaat naar gateway met verificatie van certificaatcontrole van IoT Hub-certificaten.

De reeks is vergelijkbaar met ContosoIotHub die een apparaat verifieert. In een gatewayscenario is EdgeGateway echter afhankelijk van ContosoIotHub als de bron van waarheid voor de record van de certificaten. EdgeGateway houdt ook een offlinekopie of cache bij als er geen verbinding met de cloud is.

Tip

In tegenstelling tot IoT Edge-apparaten zijn downstream IoT-apparaten niet beperkt tot X.509-verificatie met vingerafdruk. X.509 CA-verificatie is ook een optie. In plaats van alleen een overeenkomst op de vingerafdruk te zoeken, kan EdgeGateway ook controleren of het certificaat van TempSensor is geroot in een CA die is geüpload naar ContosoIotHub.

Kortom, EdgeGateway kan TempSensor vertrouwen omdat:

  • TempSensor heeft een geldig IoT-apparaat-id-certificaat gepresenteerd voor de naam
  • De vingerafdruk van het identiteitscertificaat komt overeen met de vingerafdruk die is geüpload naar ContosoIotHub
  • Cryptografische algoritmen controleren of het eigendom en de uitgifteketen kunnen worden vertrouwd

Waar u de certificaten en het beheer kunt ophalen

In de meeste gevallen kunt u uw eigen certificaten opgeven of gebruiken voor automatisch gegenereerde certificaten. Edge CA en het EdgeHub-certificaat worden bijvoorbeeld automatisch gegenereerd.

De aanbevolen procedure is echter om uw apparaten te configureren voor het gebruik van een INSCHRIJVING via EST-server (Secure Transport) voor het beheren van x509-certificaten. Als u een EST-server gebruikt, kunt u de certificaten handmatig afhandelen en installeren op apparaten. Zie Inschrijving configureren via Secure Transport Server voor Azure IoT Edge voor meer informatie over het gebruik van een EST-server.

U kunt ook certificaten gebruiken om te verifiëren bij de EST-server. Deze certificaten worden gebruikt om te verifiëren bij EST-servers om andere certificaten uit te geven. De certificaatservice maakt gebruik van een bootstrap-certificaat voor verificatie met een EST-server. Het bootstrap-certificaat heeft een lange levensduur. Bij de eerste verificatie doet de certificaatservice een aanvraag aan de EST-server om een identiteitscertificaat uit te geven. Dit identiteitscertificaat wordt gebruikt in toekomstige EST-aanvragen voor dezelfde server.

Als u geen EST-server kunt gebruiken, moet u certificaten aanvragen bij uw PKI-provider. U kunt de certificaatbestanden handmatig beheren in IoT Hub en uw IoT Edge-apparaten. Voor meer informatie beheert u certificaten op een IoT Edge-apparaat.

Voor het ontwikkelen van een concept kunt u testcertificaten maken. Zie Democertificaten maken om ioT Edge-apparaatfuncties te testen voor meer informatie.

Certificaten in IoT

Certificeringsinstantie

De certificeringsinstantie (CA) is een entiteit die digitale certificaten uitgeeft. Een certificeringsinstantie fungeert als een vertrouwde derde partij tussen de eigenaar en de ontvanger van het certificaat. Een digitaal certificaat certificeert het eigendom van een openbare sleutel door de ontvanger van het certificaat. De certificaatketen van vertrouwen werkt door in eerste instantie een basiscertificaat uit te geven. Dit is de basis voor vertrouwen in alle certificaten die door de instantie zijn uitgegeven. De eigenaar van het basiscertificaat kan vervolgens aanvullende tussenliggende certificaten uitgeven (downstreamapparaatcertificaten).

Basis-CA-certificaat

Een basis-CA-certificaat is de basis van vertrouwen van het hele proces. In productiescenario's wordt dit CA-certificaat aangeschaft bij een vertrouwde commerciële certificeringsinstantie zoals Baltimore, Verisign of DigiCert. Als u volledige controle hebt over de apparaten die verbinding maken met uw IoT Edge-apparaten, is het mogelijk om een certificeringsinstantie op bedrijfsniveau te gebruiken. In beide gevallen gebruikt de volledige certificaatketen van ioT Edge naar IoT Hub deze. De downstream-IoT-apparaten moeten het basiscertificaat vertrouwen. U kunt het basis-CA-certificaat opslaan in het archief van de vertrouwde basiscertificeringsinstantie of de certificaatgegevens opgeven in uw toepassingscode.

Tussenliggende certificaten

In een typisch productieproces voor het maken van beveiligde apparaten worden basis-CA-certificaten zelden rechtstreeks gebruikt, voornamelijk vanwege het risico op lekkage of blootstelling. Met het basis-CA-certificaat worden een of meer tussenliggende CA-certificaten gemaakt en digitaal ondertekend. Er kan slechts één zijn, of er kan een keten van deze tussenliggende certificaten zijn. Scenario's waarvoor een keten van tussenliggende certificaten is vereist, zijn:

  • Een hiërarchie van afdelingen binnen een fabrikant
  • Meerdere bedrijven die serieel betrokken zijn bij de productie van een apparaat
  • Een klant die een basis-CA koopt en een handtekeningcertificaat voor de fabrikant afgeeft om de apparaten te ondertekenen die ze namens die klant maken

In elk geval gebruikt de fabrikant een tussenliggend CA-certificaat aan het einde van deze keten om het edge-CA-certificaat te ondertekenen dat op het eindapparaat is geplaatst. Deze tussenliggende certificaten worden nauw bewaakt in de fabriek. Ze ondergaan strikte processen, zowel fysiek als elektronisch voor hun gebruik.

Volgende stappen