Begrijpen hoe Azure IoT Edge certificaten gebruikt
Van toepassing op: 
IoT Edge 1,1 andere versies: IOT Edge 1,2
Van toepassing op: IoT Edge 1,2 andere versies: IOT Edge 1,1
IoT Edge certificaten worden gebruikt door de modules en downstream-IoT-apparaten om de identiteit en de echtheid van de runtime-module IoT Edge hub te controleren. Deze verificaties maken een beveiligde TLS-verbinding (transportlaagbeveiliging) mogelijk tussen de runtime, de modules en de IoT-apparaten. Net als IoT Hub zelf, IoT Edge een beveiligde en versleutelde verbinding nodig vanaf IoT-downstreamapparaten (of leaf-apparaten) en IoT Edge modules. Om een beveiligde TLS-verbinding tot stand te brengen, presenteert IoT Edge hubmodule een servercertificaatketen voor het verbinden van clients om de identiteit ervan te verifiëren.
Notitie
In dit artikel worden de certificaten beschreven die worden gebruikt voor het beveiligen van verbindingen tussen de verschillende onderdelen op een IoT Edge-apparaat of tussen een IoT Edge-apparaat en eventuele leaf-apparaten. U kunt ook certificaten gebruiken om uw apparaat te IoT Edge te IoT Hub. Deze verificatiecertificaten zijn verschillend en worden niet in dit artikel besproken. Zie Create and provision an IoT Edge device using X.509 certificates(Een apparaat met X.509-certificaten maken en inrichten) voor meer informatie over het authenticeren van uw apparaat met certificaten.
In dit artikel wordt uitgelegd IoT Edge certificaten kunnen werken in productie-, ontwikkelings- en testscenario's.
Wijzigingen in versie 1.2
- De naam van het CA-certificaat van het apparaat is gewijzigd in edge CA-certificaat.
- Het CA-certificaat van de werkbelasting is afgeschaft. De IoT Edge security manager genereert nu het IoT Edge hub-servercertificaat rechtstreeks vanuit het CA-certificaat aan de rand, zonder het CA-certificaat voor tussenliggende werkbelastingen ertussen.
IoT Edge-certificaten
Er zijn twee veelvoorkomende scenario's voor het instellen van certificaten op IoT Edge apparaat. Soms koopt de eindgebruiker, of operator, van een apparaat een algemeen apparaat dat door een fabrikant is gemaakt, vervolgens zelf de certificaten. In andere gevallen werkt de fabrikant onder contract om een aangepast apparaat voor de operator te bouwen en wordt een eerste certificaatondertekening gedaan voordat het apparaat wordt aangeboden. Het IoT Edge certificaatontwerp probeert rekening te houden met beide scenario's.
In de volgende afbeelding ziet IoT Edge het gebruik van certificaten. Er kunnen nul, één of veel tussenliggende handtekeningcertificaten zijn tussen het basis-CA-certificaat en het CA-certificaat van het apparaat, afhankelijk van het aantal betrokken entiteiten. Hier laten we één case zien.
Notitie
Op dit moment voorkomt een beperking in libiothsm het gebruik van certificaten die verlopen op of na 1 januari 2038. Deze beperking geldt voor het CA-certificaat van het apparaat, alle certificaten in de vertrouwensbundel en de apparaat-id-certificaten die worden gebruikt voor X.509-inrichtingsmethoden.
Certificeringsinstantie
De certificeringsinstantie, kort gezegd CA, is een entiteit die digitale certificaten uit geeft. 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 vertrouwensrelatie werkt door in eerste instantie een basiscertificaat uit te geven. Dit is de basis voor vertrouwen in alle certificaten die door de instantie worden uitgegeven. Daarna kan de eigenaar het basiscertificaat gebruiken om aanvullende tussenliggende certificaten (leaf-certificaten) uit te geven.
Basis-CA-certificaat
Een basis-CA-certificaat is de basis van vertrouwen van het hele proces. In productiescenario's wordt dit CA-certificaat meestal gekocht 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 geval wordt de volledige certificaatketen van de IoT Edge hub naar deze hub afgegeven, zodat de leaf-IoT-apparaten het basiscertificaat moeten vertrouwen. U kunt het basis-CA-certificaat opslaan in het vertrouwde basiscertificaat van de certificeringsinstantie of de certificaatgegevens in uw toepassingscode invoeren.
Tussenliggende certificaten
In een typisch productieproces voor het maken van beveiligde apparaten worden basis-CA-certificaten zelden rechtstreeks gebruikt, voornamelijk vanwege het risico op lekken of blootstelling. Het basis-CA-certificaat maakt en ondertekent digitaal een of meer tussenliggende CA-certificaten. Er kan slechts één of een keten van deze tussenliggende certificaten zijn. Scenario's waarvoor een keten van tussenliggende certificaten nodig is, 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 basis-CA koopt en een handtekeningcertificaat aftekent voor de fabrikant 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 CA-certificaat van het apparaat te ondertekenen dat op het eindapparaat is geplaatst. Over het algemeen worden deze tussenliggende certificaten nauw bewaakt in de productiefaciliteit. Ze ondergaan strikte processen, zowel fysiek als elektronisch, voor hun gebruik.
CA-certificaat voor apparaat
Het CA-certificaat van het apparaat wordt gegenereerd op basis van en ondertekend door het uiteindelijke tussenliggende CA-certificaat in het proces. Dit certificaat wordt geïnstalleerd op IoT Edge apparaat zelf, bij voorkeur in beveiligde opslag, zoals een HSM (Hardware Security Module). Bovendien identificeert een CA-certificaat van een apparaat een uniek IoT Edge apparaat. Het CA-certificaat van het apparaat kan andere certificaten ondertekenen.
IoT Edge-CA voor workloads
De IoT Edge Security Manager genereert het CA-certificaat voor workloads, het eerste aan de operatorzijde van het proces, wanneer IoT Edge wordt gestart. Dit certificaat wordt gegenereerd op basis van en ondertekend door het CA-certificaat van het apparaat. Dit certificaat, dat gewoon een ander tussenliggend handtekeningcertificaat is, wordt gebruikt voor het genereren en ondertekenen van andere certificaten die worden gebruikt door IoT Edge runtime. Momenteel is dat voornamelijk het IoT Edge hubservercertificaat dat in de volgende sectie wordt besproken, maar in de toekomst kunnen andere certificaten voor het IoT Edge bevatten.
Het doel van dit tussenliggende workloadcertificaat is het scheiden van problemen tussen de fabrikant van het apparaat en de apparaatoperator. Imagine scenario waarin een IoT Edge apparaat wordt verkocht of overgedragen van de ene klant naar de andere. Waarschijnlijk wilt u dat het CA-certificaat van het apparaat van de fabrikant onveranderbaar is. De workloadcertificaten die specifiek zijn voor de werking van het apparaat, moeten echter worden gewist en opnieuw worden gemaakt voor de nieuwe implementatie.
Edge CA-certificaat
Het CA-certificaat aan de rand wordt gegenereerd op basis van en ondertekend door het uiteindelijke tussenliggende CA-certificaat in het proces. Dit certificaat wordt geïnstalleerd op IoT Edge apparaat zelf, bij voorkeur in beveiligde opslag, zoals een HSM (Hardware Security Module). Daarnaast identificeert een CA-certificaat aan de rand een uniek IoT Edge apparaat. Het CA-certificaat aan de rand kan andere certificaten ondertekenen.
IoT Edge hub-servercertificaat
Het IoT Edge hub-servercertificaat is het werkelijke certificaat dat wordt aangeboden aan leaf-apparaten en modules voor identiteitsverificatie tijdens het tot stand brengen van de TLS-verbinding die is vereist door IoT Edge. Dit certificaat bevat de volledige keten van handtekeningcertificaten die worden gebruikt om het certificaat te genereren tot aan het basis-CA-certificaat, dat het leaf-IoT-apparaat moet vertrouwen. Wanneer het certificaat wordt gegenereerd door IoT Edge, wordt de algemene naam (CN) van dit IoT Edge Hub-certificaat ingesteld op de eigenschap 'hostname' in het configuratiebestand na de conversie naar kleine bestanden.
Tip
Omdat het IoT Edge hub-servercertificaat de hostnaam-eigenschap van het apparaat als algemene naam gebruikt, mogen andere certificaten in de keten niet dezelfde algemene naam gebruiken.
De IoT Edge Security Manager genereert het IoT Edge hub-certificaat, het eerste aan de operatorzijde van het proces, wanneer IoT Edge wordt gestart. Dit certificaat wordt gegenereerd op basis van en ondertekend door het ca-certificaat aan de rand.
Gevolgen voor productie
Omdat productie- en bewerkingsprocessen zijn gescheiden, moet u rekening houden met de volgende implicaties bij het voorbereiden van productieapparaten:
Bij elk proces op basis van certificaten moeten het basis-CA-certificaat en alle tussenliggende CA-certificaten worden beveiligd en bewaakt tijdens het hele proces van het uitrollen van een IoT Edge apparaat. De IoT Edge apparaatfabrikant moet sterke processen hebben voor de juiste opslag en het gebruik van hun tussenliggende certificaten. Bovendien moet het CA-certificaat van het apparaat zo veilig mogelijk worden bewaard op het apparaat zelf, bij voorkeur een hardwarebeveiligingsmodule.
Het IoT Edge hub-servercertificaat wordt door IoT Edge hub gepresenteerd aan de verbindende clientapparaten en -modules. De algemene naam (CN) van het CA-certificaat van het apparaat mag niet dezelfde zijn als de 'hostnaam' die wordt gebruikt in het configuratiebestand op het IoT Edge apparaat. De naam die clients gebruiken om verbinding te maken met IoT Edge (bijvoorbeeld via de parameter GatewayHostName van de connection string of de CONNECT-opdracht in MQTT) mag niet dezelfde zijn als de algemene naam die wordt gebruikt in het CA-certificaat van het apparaat. Deze beperking is omdat de IoT Edge hub de volledige certificaatketen voor verificatie door clients presenteert. Als het IoT Edge hubservercertificaat en het CA-certificaat van het apparaat beide dezelfde CN hebben, krijgt u een verificatielus en wordt het certificaat ongeldig.
Omdat het CA-certificaat van het apparaat wordt gebruikt door de IoT Edge-beveiligingsdemon voor het genereren van de definitieve IoT Edge-certificaten, moet het zelf een handtekeningcertificaat zijn, wat betekent dat het certificaat ondertekeningsmogelijkheden heeft. Door 'V3 Basic-beperkingen CA:True' toe te passen op het CA-certificaat van het apparaat worden automatisch de vereiste eigenschappen voor sleutelgebruik instellen.
Bij elk proces op basis van certificaten moeten het basis-CA-certificaat en alle tussenliggende CA-certificaten worden beveiligd en bewaakt tijdens het hele proces van het uitrollen van een IoT Edge apparaat. De IoT Edge apparaatfabrikant moet sterke processen hebben voor de juiste opslag en het gebruik van hun tussenliggende certificaten. Bovendien moet het CA-certificaat aan de rand zo veilig mogelijk worden bewaard op het apparaat zelf, bij voorkeur een hardwarebeveiligingsmodule.
Het IoT Edge hub-servercertificaat wordt door IoT Edge hub gepresenteerd aan de verbindende clientapparaten en -modules. De algemene naam (CN) van het CA-certificaat aan de rand mag niet dezelfde zijn als de 'hostnaam' die wordt gebruikt in het configuratiebestand op het IoT Edge apparaat. De naam die clients gebruiken om verbinding te maken met IoT Edge (bijvoorbeeld via de parameter GatewayHostName van de connection string of de CONNECT-opdracht in MQTT) mag niet dezelfde zijn als de algemene naam die wordt gebruikt in het ca-certificaat aan de rand. Deze beperking is omdat de IoT Edge hub de volledige certificaatketen voor verificatie door clients presenteert. Als het IoT Edge hubservercertificaat en het edge CA-certificaat beide dezelfde CN hebben, krijgt u een verificatielus en wordt het certificaat ongeldig.
Omdat het CA-certificaat aan de rand wordt gebruikt door de IoT Edge-beveiligingsdemon voor het genereren van de definitieve IoT Edge-certificaten, moet het zelf een handtekeningcertificaat zijn, wat betekent dat het certificaat ondertekeningsmogelijkheden heeft. Door 'V3 Basic-beperkingen CA:True' toe te passen op het ca-certificaat aan de rand worden automatisch de vereiste eigenschappen voor sleutelgebruik instellen.
Gevolgen voor dev/test
Om ontwikkel- en testscenario's te gemakt Microsoft een set eenvoudige scripts voor het genereren van niet-productiecertificaten die geschikt zijn voor IoT Edge in het scenario van de transparante gateway. Zie Democertificaten maken om de functies van IoT Edge te testen voor voorbeelden van hoe de scripts werken.
Tip
Als u uw IoT leaf-apparaten en toepassingen die gebruikmaken van de SDK voor IoT-apparaten via IoT Edge wilt verbinden, moet u de optionele parameter GatewayHostName toevoegen aan het einde van de connection string. Wanneer het IoT Edge hub-servercertificaat wordt gegenereerd, is het gebaseerd op een versie met kleine bestanden van de hostnaam uit het configuratiebestand. Als de namen overeenkomen en de verificatie van het TLS-certificaat slaagt, moet u daarom in kleine gevallen de parameter GatewayHostName invoeren.
Voorbeeld van IoT Edge van een certificaathiërarchie
Ter illustratie van een voorbeeld van dit certificaatpad is de volgende schermopname afkomstig van een werkend IoT Edge is ingesteld als een transparante gateway. OpenSSL wordt gebruikt om verbinding te maken met IoT Edge hub, de certificaten te valideren en te dumpen.
In de schermopname ziet u de hiërarchie van certificaatdiepte:
| Certificaattype | Certificaatnaam |
|---|---|
| Basis-CA-certificaat | Azure IoT Hub CA-certificaat testen |
| Tussenliggend CA-certificaat | Azure IoT Hub alleen tussenliggende certificaattests |
| CA-certificaat voor apparaat | iotgateway.ca ('iotgateway' is doorgegeven als de naam van het CA-certificaat aan de gemaksscripts) |
| CA-certificaat voor workload | iotedge workload ca |
| IoT Edge Hub Server-certificaat | iotedgegw.local (komt overeen met de 'hostnaam' uit het configuratiebestand) |
In de schermopname ziet u de hiërarchie van certificaatdiepte:
| Certificaattype | Certificaatnaam |
|---|---|
| Basis-CA-certificaat | Azure IoT Hub CA-certificaat testen |
| Tussenliggend CA-certificaat | Azure IoT Hub alleen tussenliggende certificaattests |
| CA-certificaat voor apparaat | iotgateway.ca ('iotgateway' is doorgegeven als de naam van het CA-certificaat aan de gemaksscripts) |
| IoT Edge Hub Server-certificaat | iotedgegw.local (komt overeen met de 'hostnaam' uit het configuratiebestand) |
Volgende stappen
Informatie over Azure IoT Edge-modules
Een IoT Edge-apparaat configureren zodat deze werkt als een transparante gateway