Freigeben über

Verstehen, wie Azure IoT Edge Zertifikate verwendet

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

Wichtig

IoT Edge 1.5 LTS ist das unterstützte Release. IoT Edge 1.4 LTS wurde am 12. November 2024 eingestellt. 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. In diesem Artikel wird erläutert, wie IoT Edge Zertifikate mit Azure IoT Hub- und IoT Edge-Gatewayszenarien verwendet.

Wichtig

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

  • Das Geräte-CA-Zertifikat in Version 1.1 wird jetzt als Edge-CA-Zertifikat bezeichnet.
  • Das Workload-CA-Zertifikat in Version 1.1 wird eingestellt. 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 vorhanden ist.

Zusammenfassung

IoT Edge verwendet Zertifikate in diesen Kernszenarien. Ü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

Um Ihnen dabei zu helfen, IoT Edge-Zertifikatkonzepte kennenzulernen, stellen Sie sich ein Szenario vor, in dem ein IoT Edge-Gerät namens EdgeGateway eine Verbindung mit einem Azure IoT Hub namens ContosoIotHub herstellt. In diesem Beispiel verwendet alle Authentifizierung die X.509-Zertifikatauthentifizierung anstelle symmetrischer Schlüssel. 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?“. Hier sehen Sie eine Abbildung des Szenarios:

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

In diesem Artikel werden die Antworten auf jede Frage erläutert und dann das Beispiel in späteren Abschnitten erweitert.

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

Wie überprüft EdgeGateway , ob es mit dem echten ContosoIotHub spricht? Wenn EdgeGateway mit der Cloud spricht, wird eine Verbindung mit dem Endpunkt ContosoIoTHub.Azure-devices.NET hergestellt. 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. Um die IoT Hub-Identität zu überprüfen, verwenden IoT Edge und IoT Hub das TLS-Handshake-Protokoll , um die Serveridentität von IoT Hub zu überprüfen. Das folgende Diagramm zeigt einen TLS-Handshake. Einige Details sind ausgelassen, um es einfach zu halten. Weitere Informationen zum TLS-Handshake-Protokoll 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. Der Schlüssel besteht darin, dass der Algorithmus überprüft, ob der Server über den privaten Schlüssel verfügt, der mit seinem öffentlichen Schlüssel gekoppelt ist. Diese Überprüfung beweist, dass der Präsentierer des Zertifikats es nicht kopiert oder gestohlen hat. Stellen Sie sich eine Foto-ID vor, in der Ihr Gesicht mit dem Foto übereinstimmt. Wenn jemand Ihren Ausweis stiehlt, kann er ihn nicht verwenden, weil Ihr Gesicht einzigartig ist. Bei kryptografischen Schlüsseln ist das Schlüsselpaar verwandt und eindeutig. Anstatt ein Gesicht mit einer Foto-ID abzugleichen, verwendet der kryptografische Algorithmus das Schlüsselpaar, um die Identität zu überprüfen.

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. DigiCert unterzeichnet dieses Stammzertifikat, und es ist weithin als vertrauenswürdig anerkannt und in vielen der Betriebssysteme 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 auf das Baltimore CyberTrust Root-Zertifikat überprüft, befindet es sich bereits im Betriebssystem. Aus EdgeGateway-Perspektive ist das Zertifikat vertrauenswürdig, da die Zertifikatkette von ContosoIotHub von einer Stammzertifizierungsstelle signiert ist, der das Betriebssystem vertraut. Dieses Zertifikat wird als IoT Hub-Serverzertifikat bezeichnet. Weitere Informationen zum IoT Hub-Serverzertifikat finden Sie unter Tls-Unterstützung (Transport Layer Security) 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 (mTLS) unterstützt, überprüft es das Zertifikat von EdgeGateway während eines clientauthentifizierungsfähigen TLS-Handshakes. Der Einfachheit halber überspringen wir einige Schritte im folgenden Diagramm.

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 der Perspektive von ContosoIotHub überprüft er, ob der Fingerabdruck des bereitgestellten Zertifikats mit seinem Datensatz übereinstimmt und ob EdgeGateway den privaten Schlüssel besitzt, der zu dem Zertifikat gehört, das es vorlegt. Wenn Sie ein IoT Edge-Gerät in IoT Hub bereitstellen, stellen Sie auch einen Fingerabdruck bereit. IoT Hub verwendet den Fingerabdruck, um das Zertifikat zu überprüfen.

Tipp

IoT Hub erfordert zwei Fingerabdrucke, wenn Sie ein IoT Edge-Gerät registrieren. Es ist am besten, zwei verschiedene Geräteidentitätszertifikate mit unterschiedlichen Ablaufdaten vorzubereiten. Wenn ein Zertifikat abläuft, ist das andere noch gültig und Sie haben Zeit, das abgelaufene Zertifikat zu ersetzen. Sie können jedoch nur ein Zertifikat für die Registrierung verwenden. Verwenden Sie ein einzelnes Zertifikat, indem Sie beim Registrieren des Geräts denselben Zertifikatfingerabdruck für die primären und sekundären Fingerabdrucke festlegen.

Verwenden Sie beispielsweise den folgenden Befehl, um den Fingerabdruck des Identitätszertifikats auf EdgeGateway abzurufen:

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 SHA256-Fingerabdruckwert für das EdgeGateway-Gerät anzeigen, das in IoT Hub registriert ist, sehen Sie, dass er mit dem Fingerabdruck auf EdgeGateway übereinstimmt.

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

Zusammenfassend vertraut ContosoIotHubEdgeGateway , da EdgeGateway ein gültiges IoT Edge-Geräteidentitätszertifikat mit einem Fingerabdruck darstellt, der dem im IoT Hub registrierten entspricht.

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

In diesem Beispiel wird der Azure IoT Hub Device Provisioning Service (DPS) nicht behandelt, der die X.509-Ca-Authentifizierung mit IoT Edge unterstützt, wenn sie mit einer Registrierungsgruppe bereitgestellt wird. Mit DPS laden Sie das Zertifizierungsstellenzertifikat oder ein Zwischenzertifikat hoch, die Zertifikatkette wird überprüft, dann wird das Gerät bereitgestellt. Weitere Informationen finden Sie unter DPS X.509-Zertifikatnachweis.

Im Azure-Portal zeigt DPS den SHA1-Fingerabdruck für das Zertifikat anstelle des SHA256-Fingerabdrucks an.

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

Derzeit unterstützt IoT Hub die X.509 CA-Authentifizierung nicht direkt mit IoT Edge.

Zertifikatverwendung bei Modulidentitätsvorgängen

In den Zertifikatüberprüfungsdiagrammen kann es so aussehen, als ob IoT Edge nur das Zertifikat verwendet, um mit IoT Hub zu sprechen. IoT Edge verfügt über mehrere Module. IoT Edge verwendet das Zertifikat zum Verwalten von Modulidentitäten für Module, die Nachrichten senden. Die Module verwenden das Zertifikat nicht zum Authentifizieren bei IoT Hub, sondern verwenden SAS-Schlüssel, die vom privaten Schlüssel abgeleitet sind, den ioT Edge-Modullaufzeit generiert. Diese SAS-Schlüssel ändern sich auch nicht beim Ablauf des Geräteidentitätszertifikats. Wenn das Zertifikat abläuft, wird EdgeHub weiterhin ausgeführt, aber nur die Modulidentitätsvorgänge schlagen fehl.

Die Interaktion zwischen Modulen und IoT Hub ist sicher, da der SAS-Schlüssel von einem geheimen Schlüssel abgeleitet wird, und IoT Edge verwaltet den Schlüssel ohne das Risiko eines menschlichen Eingreifens.

Szenario einer geschachtelten Gerätehierarchie mit IoT Edge als Gateway

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

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. Wie zuvor verwendet alle Authentifizierung die X.509-Zertifikatauthentifizierung. In diesem Szenario werden zwei Fragen gestellt: "Ist das TempSensor-Gerät legitim?" und "Ist die Identität des EdgeGateway richtig?". Das Szenario wird hier veranschaulicht:

Diagramm, das die Verbindung zwischen einem IoT Edge-Gerät, einem IoT Edge-Gateway und IoT Hub zeigt.

Tipp

TempSensor ist ein IoT-Gerät in diesem 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 von 10.0.0.2 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 , um TempSensor zu authentifizieren.

Diagramm, das einen Zertifikataustausch zwischen einem IoT Edge-Gerät und einem Gateway mit Zertifikatüberprüfung auf IoT Hub-Zertifikate zeigt.

Die Sequenz ähnelt dem Überprüfen eines Geräts von ContosoIotHub . In einem Gatewayszenario basiert EdgeGateway jedoch auf ContosoIotHub als Wahrheitsquelle für den Zertifikatdatensatz. EdgeGateway behält auch eine Offlinekopie oder einen Cache bei, wenn keine Verbindung mit der Cloud besteht.

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 stellt ein gültiges IoT-Geräteidentitätszertifikat für seinen Namen dar.
  • 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 stellen Sie Eigene Zertifikate bereit oder verwenden automatisch generierte Zertifikate. Beispielsweise werden die Edge-Zertifizierungsstelle und das edgeHub-Zertifikat automatisch generiert.

Die bewährte Methode besteht jedoch darin, Ihre Geräte so einzurichten, dass sie einen Registrierungsserver über secure Transport (EST) zum Verwalten von x509-Zertifikaten verwenden. Ein EST-Server ermöglicht es Ihnen, Zertifikate auf Geräten automatisch zu verwalten und zu installieren, ohne dies manuell tun zu müssen. 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 verwenden, um sich auch beim EST-Server zu authentifizieren. Diese Zertifikate authentifizieren sich bei EST-Servern, um andere Zertifikate auszustellen. Der Zertifikatdienst verwendet ein Bootstrap-Zertifikat zum Authentifizieren bei einem EST-Server. Das Bootstrap-Zertifikat ist langlebig. Beim ersten Authentifizieren fordert der Zertifikatdienst ein Identitätszertifikat vom EST-Server an. Das Identitätszertifikat wird in zukünftigen EST-Anforderungen an denselben Server verwendet.

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

Zur Machbarkeitsentwicklung erstellen Sie Testzertifikate. Weitere Informationen finden Sie unter Erstellen von Demozertifikaten zum Testen der Features von IoT Edge-Geräten.

Zertifikate in IoT

Zertifizierungsstelle

Eine Zertifizierungsstelle stellt digitale Zertifikate aus. Die Zertifizierungsstelle fungiert als vertrauenswürdiger Drittanbieter zwischen dem Zertifikatbesitzer und dem Empfänger des Zertifikats. Ein digitales Zertifikat beweist, dass der Empfänger einen öffentlichen Schlüssel besitzt. Die Zertifikatkette der Vertrauensstellung beginnt mit einem Stammzertifikat, das die Grundlage für die Vertrauensstellung in allen Zertifikaten ist, die von der Zertifizierungsstelle ausgestellt werden. Der Stammzertifikatbesitzer kann zusätzliche Zwischenzertifikate (nachgeschaltete Gerätezertifikate) ausstellen.

Zertifikat der Stammzertifizierungsstelle

Ein Zertifikat der Stammzertifizierungsstelle ist die Vertrauensgrundlage für den Prozess. In der Produktion kaufen Sie dieses CA-Zertifikat in der Regel von einer vertrauenswürdigen kommerziellen Zertifizierungsstelle wie Baltimore, Verisign oder DigiCert. Wenn Sie alle Geräte steuern, die mit Ihren IoT Edge-Geräten verbunden sind, können Sie eine Unternehmenszertifizierungsstelle verwenden. In beiden Fällen verwendet die Zertifikatkette von IoT Edge bis IoT Hub das Stamm-CA-Zertifikat. Nachgeschaltete IoT-Geräte müssen dem Stammzertifikat vertrauen. Legen Sie das Stamm-CA-Zertifikat im Speicher der vertrauenswürdigen Stammzertifizierungsstellen ab oder geben Sie die Zertifikatdetails im Anwendungscode an.

Zwischenzertifikate

In einem typischen Herstellungsprozess für sichere Geräte verwenden Hersteller selten Stammzertifizierungsstellenzertifikate direkt aufgrund des Risikos von Lecks oder Exposition. Das Zertifikat der Stammzertifizierungsstelle erstellt ein oder mehrere Zertifizierungsstellen-Zwischenzertifikate und signiert diese digital. Es kann eine oder eine Kette von Zwischenzertifikaten geben. Szenarien, die eine Kette von Zwischenzertifikaten erfordern, umfassen:

  • Eine Hierarchie von Abteilungen innerhalb eines Herstellers
  • Mehrere Unternehmen sind nacheinander an der Produktion eines Geräts beteiligt.
  • Ein Kunde erwirbt eine Root-CA und leitet ein Signierzertifikat für den Hersteller ab, damit dieser im Namen des Kunden Geräte signieren kann.

Der Hersteller verwendet am Ende dieser Kette ein Zwischenzertifizierungsstellenzertifikat, um das auf dem Endgerät platzierte Edgezertifizierungsstellenzertifikat zu signieren. Das Fertigungswerk schützt diese Zwischenzertifikate eng. Strenge physische und elektronische Prozesse steuern ihre Nutzung.

Nächste Schritte