Teilen über

Verstehen, wie Azure IoT Edge Zertifikate verwendet

  • Artikel

Gilt für: Häkchen für IoT Edge 1.5 IoT Edge 1.5 IoT Edge 1.4 Häkchen IoT Edge 1.4

Wichtig

IoT Edge 1.5 LTS und IoT Edge 1.4 LTS sind unterstützte Releases. Das Ende der Lebensdauer von IoT Edge 1.4 LTS wird am 12. November 2024 erreicht. Wenn Sie ein früheres Release verwenden, finden Sie weitere Informationen unter Aktualisieren von IoT Edge.

IoT Edge verwendet verschiedene Arten von Zertifikaten für unterschiedliche Zwecke. Dieser Artikel führt Sie durch die verschiedenen Möglichkeiten, wie IoT Edge Zertifikate bei Azure IoT Hub- und IoT Edge-Gateway-Szenarien verwendet.

Wichtig

Der Kürze halber gilt dieser Artikel für IoT Edge, Version 1.2 oder höher. Die Zertifikatkonzepte für Version 1.1 sind ähnlich, aber es gibt einige Unterschiede:

  • Das Zertifikat der Zertifizierungsstelle in Version 1.1 wurde in Zertifikat der Edge-Zertifizierungsstelle umbenannt.
  • Das Zertifikat der Workload-Zertifizierungsstelle in Version 1.1 wurde außer Kraft gesetzt. In Version 1.2 oder höher generiert die IoT Edge-Modullaufzeit alle Serverzertifikate direkt aus dem Zertifikat der Edge-Zertifizierungsstelle, ohne dass das Zwischenstellenzertifikat der Workload in der Zertifikatkette dazwischen vorhanden ist.

Zusammenfassung

In diesen Schlüsselszenarien verwendet IoT Edge Zertifikate. Über die Links können Sie mehr zu jedem einzelnen Szenario erfahren.

Actor (Schauspieler) Zweck Zertifikat
IoT Edge Stellt sicher, dass es mit dem richtigen IoT Hub kommuniziert IoT Hub-Serverzertifikat
IoT Hub Stellt sicher, dass die Anforderung von einem berechtigten IoT Edge-Gerät stammt IoT Edge-Identitätszertifikat
Nachgeschaltetes IoT-Gerät Stellt sicher, dass es mit dem richtigen IoT Edge-Gateway kommuniziert Serverzertifikat des IoT Edge Hub-Moduls edgeHub, das von der Edge-Zertifizierungsstelle ausgestellt wurde
IoT Edge Signiert neue Modulserverzertifikate. Beispiel: edgeHub Zertifikat der Edgezertifizierungsstelle
IoT Edge Stellt sicher, dass die Anforderung von einem berechtigten nachgeschalteten Gerät stammt IoT-Geräteidentitätszertifikat

Voraussetzungen

Szenario mit einem einzelnen Gerät

Damit Sie IoT Edge-Zertifikatkonzepte verstehen, stellen Sie sich ein Szenario vor, in dem das IoT Edge-Gerät EdgeGateway eine Verbindung mit dem Azure IoT-Hub ContosoIotHub herstellt. In diesem Beispiel wird die gesamte Authentifizierung mit der X.509-Zertifikatauthentifizierung und nicht mit symmetrischen Schlüsseln durchgeführt. Um in diesem Szenario Vertrauen aufzubauen, müssen wir sicherstellen, dass der IoT Hub und das IoT Edge-Gerät authentisch sind: „Ist dieses Gerät echt und gültig?“ und „Ist die Identität des IoT Hubs korrekt?“. Das Szenario kann so dargestellt werden:

Statusdiagramm des Vertrauensszenarios, das die Verbindung zwischen IoT Edge-Gerät und IoT Hub zeigt

Wir erläutern die Antworten auf jede einzelne Frage und erweitern dann das Beispiel in späteren Abschnitten des Artikels.

Gerät überprüft IoT Hub-Identität

Wie überprüft EdgeGateway, ob es mit dem echten ContosoIotHub kommuniziert? Wenn EdgeGateway mit der Cloud kommunizieren möchte, stellt es eine Verbindung mit dem Endpunkt ContosoIoTHub.Azure-devices.NET her. Um sicherzustellen, dass der Endpunkt authentisch ist, benötigt IoT Edge ContosoIoTHub zum Anzeigen der Identifizierung (ID). Die ID muss von einer Autorität ausgestellt werden, der EdgeGateway vertraut. Zur Überprüfung der IoT Hub-Identität verwenden IoT Edge und IoT Hub das Protokoll TLS-Handshake, um die Serveridentität von IoT Hub zu überprüfen. Ein TLS-Handshake ist im folgenden Diagramm dargestellt. Zur Vereinfachung des Beispiels wurden einige Details weggelassen. Weitere Informationen zum Protokoll TLS-Handshake finden Sie unter TLS-Handshake in Wikipedia.

Hinweis

In diesem Beispiel stellt ContosoIoTHub den IoT Hub-Hostnamen ContosoIotHub.Azure-devices.NET dar.

Sequenzdiagramm, das den Zertifikataustausch von IoT Hub auf ein IoT Edge-Gerät mit Zertifikatüberprüfung beim vertrauenswürdigen Stammspeicher auf dem IoT Edge Gerät zeigt

In diesem Kontext müssen Sie die genauen Details des Kryptografiealgorithmus nicht kennen. Es ist wichtig, Folgendes zu verstehen: Der Algorithmus stellt sicher, dass der Server den mit seinem öffentlichen Schlüssel gekoppelten privaten Schlüssel besitzt. Er überprüft, ob der Einreicher des Zertifikats es nicht kopiert oder gestohlen hat. Wenn Sie beispielsweise einen Lichtbildausweis verwenden, stimmt Ihr Gesicht mit dem Foto auf dem Ausweis überein. Wenn jemand Ihren Ausweis stiehlt, kann er ihn nicht zur Identifizierung verwenden, weil Ihr Gesicht eindeutig und schwer zu reproduzieren ist. Bei kryptografischen Schlüsseln ist das Schlüsselpaar verwandt und eindeutig. Statt ein Gesicht mit einem Lichtbildausweis abzugleichen, verwendet der Kryptografiealgorithmus das Schlüsselpaar zur Überprüfung der Identität.

In unserem Szenario zeigt ContosoIotHub die folgende Zertifikatkette:

Flussdiagramm der Kette von Zwischen- und Stammzertifizierungsstelle für IoT Hub

Die Stammzertifizierungsstelle (ZS) ist das Zertifikat Baltimore CyberTrust Root. Dieses Stammzertifikat wird von DigiCert signiert. Es ist in vielen Betriebssystemen allgemein vertrauenswürdig und wird darin gespeichert. So ist es beispielsweise sowohl unter Ubuntu als auch unter Windows im Standardzertifikatspeicher enthalten.

Windows-Zertifikatspeicher:

Screenshot des Zertifikats „Baltimore CyberTrust Root“, das im Windows-Zertifikatspeicher aufgeführt ist

Ubuntu-Zertifikatspeicher:

Screenshot des Zertifikats „Baltimore CyberTrust Root“, das im Ubuntu-Zertifikatspeicher aufgeführt ist

Wenn ein Gerät das Zertifikat Baltimore CyberTrust Root sucht, ist es im Betriebssystem vorinstalliert. Aus EdgeGateway-Sicht gilt das Zertifikat als vertrauenswürdig, da die von ContosoIotHub bereitgestellte Zertifikatkette von einer Stammzertifizierungsstelle signiert wurde, der das Betriebssystem vertraut. Das Zertifikat wird als IoT Hub-Serverzertifikat bezeichnet. Weitere Informationen zum IoT Hub-Serverzertifikat finden Sie unter Transport Layer Security (TLS)-Unterstützung in IoT Hub.

Kurz gesagt kann EdgeGateway die Identität von ContosoIotHub aus folgenden Gründen überprüfen und ihr vertrauen:

  • ContosoIotHub stellt sein IoT Hub-Serverzertifikat bereit.
  • Das Serverzertifikat wird im Zertifikatspeicher des Betriebssystems als vertrauenswürdig eingestuft.
  • Daten, die mit dem öffentlichen Schlüssel von ContosoIotHub verschlüsselt wurden, können von ContosoIotHub entschlüsselt werden. Das beweist den Besitz des privaten Schlüssels.

IoT Hub überprüft IoT Edge-Geräteidentität

Wie überprüft ContosoIotHub, ob es mit EdgeGateway kommuniziert? Da IoT Hub gegenseitiges TLS (mutual TLS, mTLS) unterstützt, überprüft der Hub das EdgeGateway-Zertifikat während des clientseitig authentifizierten TLS-Handshakes. Der Einfachheit halber überspringen wir im folgenden Diagramm einige Schritte.

Sequenzdiagramm, das den Zertifikataustausch vom IoT Edge-Gerät zu IoT Hub mit Überprüfung des Zertifikatfingerabdrucks auf IoT Hub zeigt

In diesem Fall stellt EdgeGateway das zugehörige IoT Edge-Geräteidentitätszertifikat bereit. Aus ContosoIotHub-Perspektive wird überprüft, ob der Fingerabdruck des bereitgestellten Zertifikats mit dem entsprechenden Datensatz übereinstimmt und ob EdgeGateway über den privaten Schlüssel verfügt, der mit dem bereitgestellten Zertifikat gekoppelt ist. Wenn Sie ein IoT Edge-Gerät in IoT Hub bereitstellen, stellen Sie auch einen Fingerabdruck bereit. Den Fingerabdruck verwendet IoT Hub zum Überprüfen des Zertifikats.

Tipp

IoT Hub erfordert bei der Registrierung eines IoT Edge-Geräts zwei Fingerabdrücke. Eine bewährte Methode ist es, zwei verschiedene Geräteidentitätszertifikate mit unterschiedlichen Ablaufdaten zu erstellen. Dann ist beim Ablauf eines Zertifikats das andere weiterhin gültig und bietet Ihnen Zeit, das abgelaufene Zertifikat zu rotieren. Es ist jedoch auch möglich, nur ein Zertifikat für die Registrierung zu verwenden. Sie verwenden ein einziges Zertifikat, indem Sie bei der Registrierung des Geräts denselben Zertifikatfingerabdruck für den primären und den sekundären Fingerabdruck festlegen.

So können Sie beispielsweise mit dem folgenden Befehl den Fingerabdruck des Identitätszertifikats in EdgeGateway abrufen:

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

Der Befehl gibt den SHA-256-Fingerabdruck des Zertifikats aus:

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

Wenn Sie den SHA-256-Fingerabdruck für das in IoT Hub registrierte EdgeGateway-Gerät anzeigen, stellen Sie fest, dass er mit dem Fingerabdruck auf EdgeGateway übereinstimmt:

Screenshot aus dem Azure-Portal: Der Fingerabdruck des EdgeGateway-Geräts in „ContosoIotHub“

Kurz gesagt kann ContosoIotHub EdgeGateway vertrauen, weil EdgeGateway ein gültiges IoT Edge-Geräteidentitätszertifikat bereitstellt, dessen Fingerabdruck mit dem in IoT Hub registrierten übereinstimmt.

Weitere Informationen zum Erstellen von Zertifikaten finden Sie unter Erstellen und Bereitstellen eines IoT Edge-Geräts unter Linux mithilfe von X.509-Zertifikaten.

Hinweis

Dieses Beispiel befasst sich nicht mit dem Azure IoT Hub Device Provisioning Service (DPS), der die Authentifizierung per X.509-Zertifizierungsstelle mit IoT Edge unterstützt, wenn sie mit einer Registrierungsgruppe bereitgestellt wird. Mithilfe von DPS laden Sie das ZS-Zertifikat oder ein Zwischenzertifikat hoch, die Zertifikatkette wird überprüft und dann das Gerät bereitgestellt. Weitere Informationen finden Sie unter DPS X.509-Zertifikatnachweis.

Im Azure-Portal zeigt DPS den SHA-1-Fingerabdruck für das Zertifikat anstelle des SHA-256-Fingerabdrucks an.

DPS registriert oder aktualisiert den SHA256-Fingerabdruck in IoT Hub. Sie können den Fingerabdruck mit dem Befehl openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256 überprüfen. Nach der Registrierung verwendet IoT Edge die Fingerabdruckauthentifizierung bei IoT Hub. Wenn das Gerät erneut bereitgestellt und ein neues Zertifikat ausgestellt wird, aktualisiert DPS IoT Hub mit dem neuen Fingerabdruck.

IoT Hub unterstützt zurzeit die X.509-ZS-Authentifizierung nicht direkt bei IoT Edge.

Zertifikatverwendung bei Modulidentitätsvorgängen

In den Zertifikatüberprüfungsdiagrammen kann es vorkommen, dass IoT Edge das Zertifikat nur zum Kommunizieren mit IoT Hub verwendet. IoT Edge besteht aus mehreren Modulen. Deshalb verwendet IoT Edge das Zertifikat zum Verwalten von Modulidentitäten für Module, die Nachrichten senden. Die Module verwenden das Zertifikat nicht für ihre Authentifizierung bei IoT Hub. Stattdessen verwenden sie SAS-Schlüssel, die von den privaten Schlüsseln abgeleitet wurden, die von der IoT Edge-Modullaufzeit generiert werden. Diese SAS-Schlüssel ändern sich auch nicht beim Ablauf des Geräteidentitätszertifikats. Beim Zertifikatablauf wird edgeHub beispielsweise weiterhin ausgeführt, und nur die Modulidentitätsvorgänge schlagen fehl.

Die Interaktion zwischen Modulen und IoT Hub ist sicher, weil der SAS-Schlüssel von einem Geheimnis abgeleitet wird und IoT Edge den Schlüssel ohne das Risiko von menschlichem Eingreifen verwaltet.

Szenario einer geschachtelten Gerätehierarchie mit IoT Edge als Gateway

Sie verstehen jetzt eine einfache Interaktion zwischen IoT Edge und IoT Hub. IoT Edge kann aber auch als Gateway für nachgeschaltete Geräte oder andere IoT Edge-Geräte fungieren. Diese Kommunikationskanäle müssen ebenfalls verschlüsselt werden und vertrauenswürdig sein. Aufgrund der zusätzlichen Komplexität müssen Sie unser Beispielszenario um ein nachgeschaltetes Gerät erweitern.

Sie fügen das reguläre IoT-Gerät TempSensor hinzu, das eine Verbindung mit seinem übergeordneten IoT Edge-Gerät EdgeGateway herstellt, das wiederum eine Verbindung mit dem IoT Hub ContosoIotHub herstellt. Ähnlich wie zuvor erfolgt die gesamte Authentifizierung mit der X.509-Zertifikatauthentifizierung. Dieses neue Szenario wirft zwei neue Fragen auf: „Ist das TempSensor-Gerät legitim?“ und „Ist die Identität des EdgeGateway korrekt?“. Das Szenario kann so dargestellt werden:

Statusdiagramm des Vertrauensszenarios, das die Verbindung zwischen dem IoT Edge-Gerät, einem IoT Edge-Gateway und IoT Hub zeigt

Tipp

TempSensor ist ein IoT-Gerät im Szenario. Das Zertifikatkonzept ist identisch, wenn TempSensor ein nachgeschaltetes IoT Edge-Gerät des übergeordneten EdgeGateway ist.

Gerät überprüft Gatewayidentität

Wie überprüft TempSensor, dass es mit dem originalen EdgeGateway kommuniziert? Wenn TempSensor mit dem EdgeGateway kommunizieren möchte, benötigt TempSensor das EdgeGateway zum Anzeigen einer ID. Die ID muss von einer Autorität ausgestellt werden, der TempSensor vertraut.

Sequenzdiagramm, das den Zertifikataustausch vom Gatewaygerät zum IoT Edge-Gerät mit Zertifikatüberprüfung mithilfe der privaten Stammzertifizierungsstelle zeigt

Der Flow ist identisch mit demjenigen, wenn EdgeGateway mit ContosoIotHub kommuniziert. TempSensor und EdgeGateway verwenden das Protokoll TLS-Handshake zum Überprüfen der Identität von EdgeGateway. Es gibt zwei wichtige Details:

  • Hostnamengenauigkeit: Das von EdgeGateway bereitgestellte Zertifikat muss für denselben Hostnamen (Domäne oder IP-Adresse) ausgestellt werden, den TempSensor zum Herstellen einer Verbindung mit EdgeGateway verwendet.
  • Genauigkeit der selbstsignierten Stammzertifizierungsstelle: Die von EdgeGateway bereitgestellte Zertifikatkette befindet sich wahrscheinlich nicht im standardmäßigen vertrauenswürdigen Stammspeicher des Betriebssystems.

Wenn Sie die Details verstehen möchten, sehen Sie sich zuerst die von EdgeGateway bereitgestellte Zertifikatkette an.

Flussdiagramm der Zertifizierungsstellenkette für ein IoT Edge-Gateway

Genauigkeit des Hostnamens

Der allgemeine Zertifikatname CN = edgegateway.local wird am Anfang der Kette aufgeführt. edgegateway.local ist der allgemeine Name des Serverzertifikats von edgeHub. edgegateway.local ist auch der Hostname für EdgeGateway im lokalen Netzwerk (LAN oder VNet), in dem TempSensor und EdgeGateway verbunden sind. Er könnte eine private IP-Adresse wie 192.168.1.23 oder ein vollqualifizierter Domänenname (FQDN) ähnlich der Abbildung sein. Das edgeHub-Serverzertifikat wird mithilfe des hostname-Parameters generiert, der in der IoT Edge-Datei config.toml definiert ist. Verwechseln Sie das edgeHub-Serverzertifikat nicht mit dem Edge-Zertifizierungsstellenzertifikat. Weitere Informationen zum Verwalten des Edge-Zertifizierungsstellenzertifikats finden Sie unter Verwalten von IoT Edge-Zertifikaten.

Wenn TempSensor eine Verbindung mit EdgeGateway herstellt, verwendet TempSensor den Hostnamen edgegateway.local, um eine Verbindung mit EdgeGateway herzustellen. TempSensor überprüft das von EdgeGateway bereitgestellte Zertifikat, ob der allgemeine Name des Zertifikats edgegateway.local lautet. Wenn der allgemeine Name des Zertifikats abweicht, lehnt TempSensor die Verbindung ab.

Hinweis

Der Einfachheit halber wird im Beispiel der allgemeine Name (Common Name, CN) des Antragstellerzertifikats als überprüfte Eigenschaft gezeigt. Wenn ein Zertifikat in der Praxis einen alternativen Antragstellernamen (Subject Alternative Name, SAN) hat, wird der SAN statt dem CN überprüft. Weil SAN mehrere Werte enthalten kann, verfügt er normalerweise sowohl über die Hauptdomäne bzw. den Hostnamen für den Zertifikatinhaber als auch über alle alternativen Domänen.

Warum muss EdgeGateway über seinen eigenen Hostnamen informiert werden?

EdgeGateway verfügt über keine zuverlässige Möglichkeit zu erkennen, wie andere Clients im Netzwerk eine Verbindung mit ihm herstellen können. In einem privaten Netzwerk könnte es beispielsweise DHCP-Server oder mDNS-Dienste geben, die EdgeGateway als 10.0.0.2 oder example-mdns-hostname.local auflisten. In einigen Netzwerken könnten aber DNS-Server enthalten sein, die edgegateway.local der IP-Adresse 10.0.0.2 von EdgeGateway zuordnen.

Zur Behebung dieses Problems verwendet IoT Edge den konfigurierten Hostnamenwert in config.toml und erstellt dafür ein Serverzertifikat. Wenn eine Anforderung an das edgeHub-Modul eingeht, stellt es das Zertifikat mit dem richtigen allgemeinen Zertifikatnamen (Common Name, CN) bereit.

Warum erstellt IoT Edge Zertifikate?

Beachten Sie im Beispiel, dass die Zertifikatkette ein iotedged workload ca edgegateway enthält. Es ist die Zertifizierungsstelle (ZS), die auf dem IoT Edge-Gerät vorhanden ist, das als Edge-Zertifizierungsstelle (Edge-ZS) (früher in Version 1.1 als Gerätezertifizierungsstelle (Geräte-ZS) bezeichnet) bekannt ist. So wie die Stammzertifizierungsstelle „Baltimore CyberTrust Root“ im vorhergehenden Beispiel kann die Edge-Zertifizierungsstelle andere Zertifikate ausstellen. Am wichtigsten und auch in diesem Beispiel: Sie stellt das Serverzertifikat für das edgeHub-Modul aus. Sie kann aber auch Zertifikate für andere Module ausstellen, die auf dem IoT Edge-Gerät ausgeführt werden.

Wichtig

Standardmäßig ohne Konfiguration wird die Edge-Zertifizierungsstelle von der IoT Edge-Modullaufzeit bei ihrem ersten Start automatisch generiert (bekannt als Schnellstart-Edge-Zertifizierungsstelle) und stellt dann ein Zertifikat für das edgeHub-Modul aus. Dieser Prozess beschleunigt die nachgeschaltete Geräteverbindung, indem er edgeHub ermöglicht, ein gültiges signiertes Zertifikat zu bereitzustellen. Ohne dieses Feature müssten Sie Ihre Zertifizierungsstelle dazu bringen, dass sie ein Zertifikat für das edgeHub-Modul ausstellt. Die Verwendung einer automatisch generierten Schnellstart-Edge-Zertifizierungsstelle wird bei einem Einsatz in der Produktion nicht unterstützt. Weitere Informationen zur Schnellstart-Edge-Zertifizierungsstelle finden Sie unter Schnellstart-Edge-Zertifizierungsstelle.

Ist es nicht gefährlich, ein Ausstellerzertifikat auf dem Gerät zu speichern?

Die Edge-Zertifizierungsstelle ist so konzipiert, dass sie Lösungen mit eingeschränkter, unzuverlässiger, teurer oder fehlender Konnektivität ermöglicht, gleichzeitig aber strenge Vorschriften oder Richtlinien für Zertifikatverlängerungen hat. Ohne Edge-Zertifizierungsstelle kann IoT Edge – und insbesondere edgeHub – nicht funktionieren.

So sichern Sie die Edge-Zertifizierungsstelle in der Produktion:

  • Legen Sie den privaten EdgeCA-Schlüssel in einem TPM (Trusted Platform Module) ab – vorzugsweise so, dass der private Schlüssel kurzzeitig flüchtig generiert wird und das TPM niemals verlässt.
  • Verwenden Sie eine Public Key-Infrastruktur (PKI), für die ein Rollup der Edge-Zertifizierungsstelle ausgeführt wird. Dies bietet die Möglichkeit, eine Verlängerung von kompromittierten Zertifikaten zu deaktivieren oder abzulehnen. Die PKI kann von der Kunden-IT, wenn sie das Know-how (geringere Kosten) hat, oder über einen kommerziellen PKI-Anbieter verwaltet werden.

Selbstsignierte Stammzertifizierungsstelle – spezifische Merkmale

Das edgeHub-Modul ist eine wichtige Komponente, die IoT Edge durch die Verarbeitung des gesamten eingehenden Datenverkehrs erstellt. In diesem Beispiel verwendet es ein von der Edge-Zertifizierungsstelle ausgestelltes Zertifikat, das wiederum von einer selbstsignierten Stammzertifizierungsstelle ausgestellt wird. Weil die Stammzertifizierungsstelle vom Betriebssystem nicht als vertrauenswürdig eingestuft wird, würde TempSensor ihr nur vertrauen, wenn das Zertifizierungsstellenzertifikat auf dem Gerät installiert wird. Dies wird auch als Vertrauensbündel-Szenario bezeichnet, bei dem Sie den Stamm an Clients verteilen müssen, die der Kette vertrauen müssen. Das „Vertrauensbündel“-Szenario kann problematisch sein, weil Sie auf das Gerät zugreifen und das Zertifikat installieren müssen. Die Installation des Zertifikats erfordert eine Planung. Sie kann mit Skripts erfolgen, während der Herstellung hinzugefügt werden oder im Betriebssystemimage vorinstalliert sein.

Hinweis

Einige Clients und SDKs verwenden nicht den vertrauenswürdigen Stammspeicher des Betriebssystems, und Sie müssen die Datei der Stammzertifizierungsstelle direkt übergeben.

Durch Anwendung aller dieser Konzepte kann TempSensor überprüfen, ob es mit dem originalen EdgeGateway kommuniziert, weil es ein mit der Adresse übereinstimmendes Zertifikat bereitgestellt hat und das Zertifikat von einem vertrauenswürdigen Stamm signiert wurde.

Zum Überprüfen der Zertifikatkette könnten Sie openssl auf dem Gerät TempSensor verwenden. Beachten Sie in diesem Beispiel, dass der Hostname für die Verbindung mit dem CN des Zertifikats depth 0 übereinstimmt und dass die Stammzertifizierungsstelle übereinstimmt.

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

Weitere Informationen zum Befehl openssl finden Sie in der OpenSSL-Dokumentation.

Sie könnten auch die Zertifikate überprüfen, in denen sie standardmäßig in /var/lib/aziot/certd/certs gespeichert sind. Sie können Zertifikate der Edge-Zertifizierungsstelle, Geräteidentitätszertifikate und Modulzertifikate im Verzeichnis finden. Mithilfe von openssl x509-Befehlen können Sie die Zertifikate überprüfen. Zum Beispiel:

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

Kurz gesagt kann TempSensor aus folgenden Gründen EdgeGateway vertrauen:

  • Das Modul edgeHub hat ein gültiges IoT Edge-Modulserverzertifikat für edgegateway.local angezeigt.
  • Das Zertifikat wird von der Edge-Zertifizierungsstelle ausgestellt, die wiederum von my_private_root_CA ausgestellt wird.
  • Diese private Stammzertifizierungsstelle wird auch früher als vertrauenswürdige Stammzertifizierungsstelle im TempSensor gespeichert.
  • Kryptografiealgorithmen überprüfen, ob die Besitz- und Ausstellungskette vertrauenswürdig ist.

Zertifikate für andere Module

Andere Module können Serverzertifikate abrufen, die von der Edge-Zertifizierungsstelle ausgestellt wurden. Beispiel: ein Grafana-Modul mit einer Webschnittstelle. Es kann auch ein Zertifikat aus der Edge-Zertifizierungsstelle abrufen. Module werden als nachgeschaltete Geräte behandelt, die im Container gehostet werden. Die Möglichkeit, ein Zertifikat aus der IoT Edge-Modullaufzeit abzurufen, ist jedoch ein besonderes Privileg. Module rufen die Workload-API auf, um das Serverzertifikat zu erhalten, das mit der konfigurierten Edge-Zertifizierungsstelle verkettet ist.

Gateway überprüft Geräteidentität

Wie überprüft EdgeGateway, ob es mit TempSensor kommuniziert? EdgeGateway verwendet die TLS-Clientauthentifizierung zum Authentifizieren von TempSensor.

Sequenzdiagramm, das den Zertifikataustausch vom IoT Edge-Gerät zum Gateway mit Zertifikatüberprüfung aus IoT Hub-Zertifikaten zeigt

Die Sequenz ist ähnlich wie ContosoIotHub beim Überprüfen eines Geräts. In einem Gatewayszenario basiert EdgeGateway jedoch auf ContosoIotHub als Quelle der Wahrheit (Source of Truth) für den Datensatz der Zertifikate. EdgeGateway behält auch eine Offlinekopie oder einen Offlinecache bei, falls es keine Verbindung mit der Cloud gibt.

Tipp

Im Gegensatz zu IoT Edge-Geräten sind nachgeschaltete IoT-Geräte nicht auf die X.509-Fingerabdruckauthentifizierung begrenzt. Die Authentifizierung per X.509-Zertifizierungsstelle ist ebenfalls eine Option. Statt nur nach einer Übereinstimmung auf dem Fingerabdruck zu suchen, kann EdgeGateway auch überprüfen, ob der Stamm des Zertifikats von TempSensor eine in ContosoIotHub hochgeladene Zertifizierungsstelle ist.

Kurz gesagt kann EdgeGateway aus folgenden Gründen TempSensor vertrauen:

  • TempSensor hat ein gültiges IoT-Geräteidentitätszertifikat für seinen Namen bereitgestellt.
  • Der Fingerabdruck des Identitätszertifikats stimmt mit dem in ContosoIotHub hochgeladenen Fingerabdruck überein.
  • Kryptografiealgorithmen überprüfen, ob die Besitz- und Ausstellungskette vertrauenswürdig ist.

Orte zum Abrufen der Zertifikate und der Verwaltung

In den meisten Fällen können Sie Ihre eigenen Zertifikate bereitstellen oder automatisch generierte Zertifikate verwenden. Beispielsweise werden die Edge-Zertifizierungsstelle und das edgeHub-Zertifikat automatisch generiert.

Die bewährte Methode besteht jedoch darin, Ihre Geräte so zu konfigurieren, dass sie einen Enrollment over Secure Transport (EST)-Server zum Verwalten von X.509-Zertifikaten verwenden. Wenn Sie einen EST-Server verwenden, müssen Sie die Zertifikate nicht manuell behandeln und auf Geräten installieren. Weitere Informationen zur Verwendung eines EST-Servers finden Sie unter Konfigurieren der Registrierung über Secure Transport Server für Azure IoT Edge.

Sie können Zertifikate auch zum Authentifizieren beim EST-Server verwenden. Diese Zertifikate werden verwendet, um sich bei EST-Servern zum Ausstellen anderer Zertifikate zu authentifizieren. Der Zertifikatdienst verwendet ein Bootstrap-Zertifikat zum Authentifizieren bei einem EST-Server. Das Bootstrap-Zertifikat ist langlebig. Bei der ersten Authentifizierung sendet der Zertifikatdienst eine Anforderung an den EST-Server, um ein Identitätszertifikat ausstellen zu können. Dieses Identitätszertifikat wird in zukünftigen EST-Anforderungen an denselben Server verwendet.

Wenn Sie keinen EST-Server verwenden können, sollten Sie Zertifikate bei Ihrem PKI-Anbieter anfordern. Sie können die Zertifikatdateien in IoT Hub und Ihren IoT Edge-Geräten manuell verwalten. Weitere Informationen finden Sie unter Verwalten von Zertifikaten auf einem IoT Edge-Gerät.

Für die Proof of Concept-Entwicklung können Sie Testzertifikate erstellen. Weitere Informationen finden Sie unter Erstellen von Demozertifikaten zum Testen der Features von IoT Edge-Geräten.

Zertifikate in IoT

Zertifizierungsstelle

Die Zertifizierungsstelle (ZS), ist eine Entität, die digitale Zertifikate ausstellt. Eine Zertifizierungsstelle fungiert als vertrauenswürdige dritte Partei zwischen Besitzer und Empfänger des Zertifikats. Ein digitales Zertifikat zertifiziert den Empfänger des Zertifikats als Besitzer eines öffentlichen Schlüssels. Die Zertifikatsvertrauenskette stellt zunächst ein Stammzertifikat aus, das in allen von der Zertifizierungsstelle ausgestellten Zertifikaten als Grundlage der Vertrauensstellung gilt. Der Besitzer des Stammzertifikats kann dann zusätzliche Zwischenzertifikate (Zertifikate für nachgeschaltete Geräte) ausstellen.

Zertifikat der Stammzertifizierungsstelle

Ein Zertifikat der Stammzertifizierungsstelle ist der Vertrauensanker des gesamten Prozesses. In Produktionsszenarien wird dieses Zertifikat der Zertifizierungsstelle (ZS-Zertifikat) normalerweise bei einer vertrauenswürdigen kommerziellen Zertifizierungsstelle wie Baltimore, Verisign oder DigiCert erworben. Wenn Sie vollständige Kontrolle über die Geräte haben, die mit Ihren IoT Edge-Geräten verbunden sind, kann eine Zertifizierungsstelle auf Unternehmensebene verwendet werden. In beiden Fällen wird es von der gesamten Zertifikatkette vom IoT Edge bis zum IoT Hub genutzt. Die nachgeschalteten IoT-Geräte müssen dem Stammzertifikat vertrauen. Sie können das Zertifikat der Stammzertifizierungsstelle im Speicher der vertrauenswürdigen Stammzertifizierungsstelle speichern oder die Details des Zertifikats in Ihrem Anwendungscode bereitstellen.

Zwischenzertifikate

In einem typischen Fertigungsprozess zum Erstellen sicherer Geräte werden die Zertifikate der Stammzertifizierungsstelle selten direkt verwendet – in erster Linie wg. des Risikos von Datenlecks oder Offenlegung. Das Zertifikat der Stammzertifizierungsstelle erstellt ein oder mehrere Zertifizierungsstellen-Zwischenzertifikate und signiert diese digital. Es kann nur ein einzelnes Zwischenzertifikat oder eine Kette dieser Zwischenzertifikate vorhanden sein. Folgende Szenarien erfordern z.B. eine Kette von Zwischenzertifikaten:

  • Eine Hierarchie von Abteilungen innerhalb eines Herstellers
  • Mehrere Unternehmen sind nacheinander an der Produktion eines Geräts beteiligt.
  • Ein Kunde erwirbt ein Zertifikat einer Stammzertifizierungsstelle und leitet ein Signaturzertifikat für den Hersteller zum Signieren der Geräte ab, die er im Auftrag des Kunden herstellt.

In jedem Fall verwendet der Hersteller am Ende dieser Kette ein Zwischenzertifizierungsstellenzertifikat, um das auf dem Endgerät platzierte Edgezertifizierungsstellenzertifikat zu signieren. Diese Zwischenzertifikate werden in der Fertigungsanlage streng geheim gehalten. Zur Verwendung durchlaufen sie strenge, sowohl physische als auch elektronische Prozesse.

Nächste Schritte