Delen via

Begrijpen hoe Azure IoT Edge certificaten gebruikt

Van toepassing op:IoT Edge 1.5-vinkje IoT Edge 1.5

Belangrijk

IoT Edge 1.5 LTS is de ondersteunde release. IoT Edge 1.4 LTS is het einde van de levensduur vanaf 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 uitgelegd hoe 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. Certificaatconcepten voor versie 1.1 zijn vergelijkbaar, maar er zijn enkele verschillen:

  • Het CA-certificaat van het apparaat in versie 1.1 wordt nu het Edge CA-certificaat genoemd.
  • Het workload-CA-certificaat in versie 1.1 is afgeschaft. In versie 1.2 of hoger genereert de IoT Edge-moduleruntime alle servercertificaten rechtstreeks vanuit het Edge CA-certificaat, zonder het tussenliggende workload-CA-certificaat in de certificaatketting.

Samenvatting

IoT Edge maakt gebruik van certificaten in deze kernscenario's. 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 u te helpen ioT Edge-certificaatconcepten te leren, stelt u zich een scenario voor waarin een IoT Edge-apparaat met de naam EdgeGateway verbinding maakt met een Azure IoT Hub met de naam ContosoIotHub. In dit voorbeeld gebruikt alle verificatie 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?'. Hier volgt een afbeelding van het scenario:

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

In dit artikel worden de antwoorden op elke vraag uitgelegd en wordt het voorbeeld in latere secties uitgebreid.

Op het apparaat wordt de IoT Hub-identiteit geverifieerd

Hoe controleert EdgeGateway of het met de echte ContosoIotHub praat? Wanneer EdgeGateway met de cloud praat, 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 controleren. In het volgende diagram ziet u een TLS-handshake. Sommige details zijn weggelaten om het eenvoudig te houden. 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 belangrijkste is dat het algoritme controleert of de server de persoonlijke sleutel bezit die is gekoppeld aan de openbare sleutel. Deze controle bewijst dat de presentator van het certificaat deze niet heeft gekopieerd of gestolen. Denk aan een foto-id waarbij uw gezicht overeenkomt met de foto. Als iemand uw id steelt, kunnen ze deze niet gebruiken omdat uw gezicht uniek is. Voor cryptografische sleutels is het sleutelpaar gerelateerd en uniek. In plaats van een gezicht aan een foto-id te koppelen, 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 . DigiCert ondertekent dit basiscertificaat 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 , is het al aanwezig in het besturingssysteem. Vanuit het perspectief van EdgeGateway , omdat de certificaatketen van ContosoIotHub is ondertekend door een basis-CA die het besturingssysteem vertrouwt, is het certificaat betrouwbaar. Dit 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 een 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 dat EdgeGateway de persoonlijke sleutel heeft die is gekoppeld aan het certificaat dat wordt weergegeven. Wanneer u een IoT Edge-apparaat inricht in IoT Hub, geeft u een vingerafdruk op. IoT Hub gebruikt de vingerafdruk om het certificaat te verifiëren.

Aanbeveling

Voor IoT Hub zijn twee vingerafdrukken vereist wanneer u een IoT Edge-apparaat registreert. U kunt het beste twee verschillende apparaatidentiteitscertificaten met verschillende vervaldatums voorbereiden. Als het ene certificaat verloopt, is het andere nog geldig en krijgt u tijd om het verlopen certificaat te draaien. Maar u kunt slechts één certificaat gebruiken voor registratie. Gebruik één certificaat door dezelfde certificaatvingerafdruk in te stellen voor zowel de primaire als de secundaire vingerafdruk wanneer u het apparaat registreert.

Gebruik bijvoorbeeld de volgende opdracht 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 u de SHA256-vingerafdrukwaarde bekijkt voor het EdgeGateway-apparaat dat is geregistreerd in IoT Hub, ziet u dat deze overeenkomt met de vingerafdruk op EdgeGateway:

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

Kortom, ContosoIotHub vertrouwt EdgeGateway omdat EdgeGateway een geldig IoT Edge-apparaatidentiteitscertificaat weergeeft met een vingerafdruk die 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

Dit voorbeeld heeft geen betrekking 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 toont DPS de SHA1-vingerafdruk voor het certificaat in plaats van de SHA256-vingerafdruk.

DPS registreert of werkt de SHA256-vingerafdruk bij in 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.

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

Certificaatgebruik voor moduleidentiteitsbewerkingen

In de certificaatverificatiediagrammen kan het lijken alsof IoT Edge alleen het certificaat gebruikt om met IoT Hub te communiceren. IoT Edge heeft verschillende modules. IoT Edge gebruikt 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 SAS-sleutels die zijn afgeleid van de persoonlijke sleutel die door ioT Edge-moduleruntime wordt gegenereerd. Deze SAS-sleutels worden niet gewijzigd, zelfs niet als het certificaat van de apparaat-id verloopt. Als het certificaat verloopt, wordt EdgeHub nog steeds uitgevoerd, maar 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 begrijpt nu een eenvoudige interactie tussen IoT Edge en IoT Hub. Maar IoT Edge kan ook fungeren als een gateway voor downstreamapparaten of andere IoT Edge-apparaten. Deze communicatiekanalen moeten worden versleuteld en vertrouwd. Vanwege de extra complexiteit gaan we het 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 gebruikt alle verificatie X.509-certificaatverificatie. In dit scenario worden twee vragen gesteld: 'Is het TempSensor-apparaat legitiem?' en 'Is de identiteit van de EdgeGateway juist?'. Het scenario wordt hier geïllustreerd:

Diagram met de verbinding tussen een IoT Edge-apparaat, een IoT Edge-gateway en IoT Hub.

Aanbeveling

TempSensor is een IoT-apparaat in dit 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 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 openssl voor meer informatie over 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.

Diagram met een certificaatuitwisseling tussen een IoT Edge-apparaat en een gateway, met certificaatcontrole op IoT Hub-certificaten.

De reeks is vergelijkbaar met contosoIotHub die een apparaat controleert. Maar in een gatewayscenario is EdgeGateway afhankelijk van ContosoIotHub als de bron van waarheid voor de certificaatrecord. EdgeGateway houdt ook een offlinekopie of cache bij als er geen verbinding met de cloud is.

Aanbeveling

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 presenteert een geldig IoT-apparaat-identiteitscertificaat voor zijn 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 geeft u uw eigen certificaten op of gebruikt u automatisch gegenereerde certificaten. Edge CA en het EdgeHub-certificaat worden bijvoorbeeld automatisch gegenereerd.

Maar de best practice is om uw apparaten in te stellen voor het gebruik van een Inschrijving via EST-server (Secure Transport) voor het beheren van x509-certificaten. Met een EST-server kunt u voorkomen dat certificaten handmatig worden verwerkt en geïnstalleerd 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 certificaten ook gebruiken om te verifiëren bij de EST-server. Deze certificaten worden geverifieerd met 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. Wanneer deze voor het eerst wordt geverifieerd, vraagt de certificaatservice een identiteitscertificaat aan bij de EST-server. Het identiteitscertificaat wordt gebruikt in toekomstige EST-aanvragen naar dezelfde server.

Als u geen EST-server kunt gebruiken, vraagt u certificaten aan bij uw PKI-provider. Beheer de certificaatbestanden handmatig in IoT Hub en uw IoT Edge-apparaten. Zie Certificaten beheren op een IoT Edge-apparaatvoor meer informatie.

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

Certificaten in IoT

Certificeringsinstantie

Een certificeringsinstantie (CA) geeft digitale certificaten uit. De CA fungeert als een vertrouwde derde partij tussen de certificaateigenaar en ontvanger van het certificaat. Een digitaal certificaat bewijst dat de ontvanger eigenaar is van een openbare sleutel. De certificaatketen van vertrouwen begint met een basiscertificaat. Dit is de basis voor vertrouwen in alle certificaten die de instantie uitgeeft. De eigenaar van het basiscertificaat kan aanvullende tussenliggende certificaten uitgeven (downstreamapparaatcertificaten).

Basis-CA-certificaat

Een basis-CA-certificaat is de basis van vertrouwen voor het proces. In productie koopt u dit CA-certificaat meestal bij een vertrouwde commerciële certificeringsinstantie zoals Baltimore, Verisign of DigiCert. Als u alle apparaten bepaalt die verbinding maken met uw IoT Edge-apparaten, kunt u een certificeringsinstantie van het bedrijf gebruiken. In beide gevallen gebruikt de certificaatketen van IoT Edge naar IoT Hub het basis-CA-certificaat. Downstream IoT-apparaten moeten het basiscertificaat vertrouwen. Sla het basis-CA-certificaat op in het archief van de vertrouwde basiscertificeringsinstantie of geef de certificaatgegevens op in de toepassingscode.

Tussenliggende certificaten

In een typisch productieproces voor beveiligde apparaten gebruiken fabrikanten zelden basis-CA-certificaten rechtstreeks 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 een of een keten van tussenliggende certificaten zijn. Scenario's waarvoor een keten van tussenliggende certificaten is vereist, zijn onder andere:

  • Een hiërarchie van afdelingen binnen een fabrikant
  • Meerdere bedrijven die serieel betrokken zijn bij de productie van een apparaat
  • Een klant die een root-CA koopt en een ondertekeningscertificaat afleidt voor de fabrikant om apparaten namens de klant te ondertekenen.

De fabrikant gebruikt een tussenliggend CA-certificaat aan het einde van deze keten om het Edge-CA-certificaat te ondertekenen dat op het eindapparaat is geplaatst. De fabriek bewaakt deze tussenliggende certificaten nauw. Strikte fysieke en elektronische processen controleren hun gebruik.

Volgende stappen