Azure IoT Edge での証明書の使用方法について理解する

適用対象: IoT Edge 1.5 IoT Edge 1.4

重要

サポートされているリリースは、IoT Edge 1.5 LTS と IoT Edge 1.4 LTS です。 IoT Edge 1.4 LTS は、2024 年 11 月 12 日にサポートが終了します。 以前のリリースの場合は、「IoT Edge を更新する」を参照してください。

IoT Edge では、さまざまな種類の証明書をさまざまな目的で使用します。 この記事では、Azure IoT Hub と IoT Edge ゲートウェイのシナリオを使用して、IoT Edge で証明書が使用されるさまざまな方法について説明します。

重要

簡潔にするため、この記事は IoT Edge バージョン 1.2 以降を対象とします。 バージョン 1.1 の証明書の概念は似ていますが、いくつかの違いがあります。

• バージョン 1.1 の デバイス CA 証明書 の名前は、Edge CA 証明書に変更されました。
• バージョン 1.1 のワークロード CA 証明書は廃止されました。 バージョン 1.2 以降は、IoT Edge モジュール ランタイムでは、証明書チェーン内の中間ワークロード CA 証明書なしで、Edge CA 証明書から直接すべてのサーバー証明書を生成します。

まとめ

これらの主要なシナリオでは、IoT Edge で証明書が使用されます。 それぞれのシナリオの詳細については、リンクを使用してください。

俳優	目的	[証明書]
IoT Edge	適切な IoT Hub と通信中であることを確認する	IoT Hub サーバー証明書
IoT Hub	要求が正当な IoT Edge デバイスから送信されていることを確認する	IoT Edge ID 証明書
ダウンストリーム IoT デバイス	適切な IoT Edge ゲートウェイと通信中であることを確認する	IoT Edge Hub edgeHub モジュール サーバー証明書 (Edge CA によって発行)
IoT Edge	新しいモジュール サーバー証明書に署名します。 例: edgeHub	Edge CA 証明書
IoT Edge	要求が正当なダウンストリーム デバイスから送信されていることを確認する	IoT デバイス ID 証明書

前提条件

• 公開キー暗号化、キーの組、公開キーと秘密キーでデータを暗号化または暗号化解除する方法についての基本的な理解が必要です。 IoT Edge で公開キー暗号化を使用する方法の詳細については、「公開キー暗号化と X.509 公開キー基盤について理解する」を参照してください。
• IoT Edge が IoT Hub とどのように関係しているかについての基本的な理解が必要です。 詳細については、「Azure IoT Edge ランタイムとそのアーキテクチャの概要」を参照してください。

単一デバイスのシナリオ

IoT Edge 証明書の概念を理解するために、EdgeGateway という名前の IoT Edge デバイスが ContosoIotHub という名前の Azure IoT Hub に接続するシナリオを想像してください。 この例では、すべての認証は対称キーではなく X.509 証明書認証で行われます。 このシナリオで信頼を確立するには、IoT Hub と IoT Edge デバイスが本物であることを保証する必要があります: 「このデバイスは本物で有効であるか?」、「IoT Hub の ID は正しいか?」。 このシナリオは次のように説明できます。

各質問に対する回答について説明し、記事の後のセクションで例を展開します。

デバイスで IoT Hub の ID が確認される

EdgeGateway では、正規の ContosoIotHub と通信中であることをどのように検証しますか? EdgeGateway は、クラウドと通信する際にエンドポイント ContosoIoTHub.Azure-devices.NET に接続します。 エンドポイントが本物であることを確認するために、IoT Edge では 識別 (ID) を表示するための ContosoIoTHub が必要です。 ID は、EdgeGateway が信頼する機関によって発行されたものである必要があります。 IoT Hub の ID を確認するために、IoT Edge と IoT Hub では TLS ハンドシェイク プロトコルを使用して IoT Hub のサーバー ID を確認します。 TLS ハンドシェイクは次の図に示されています。 この例を分かりやすくするために、一部の詳細は省略しています。 TLS ハンドシェイク プロトコルの詳細については、Wikipedia の TLS ハンドシェイクに関するページを参照してください。

Note

この例では、ContosoIoTHub は IoT Hub のホスト名 ContosoIotHub.Azure-devices.NET を表しています。

このコンテキストでは、暗号アルゴリズムの正確な詳細を知る必要はありません。 重要なのは、アルゴリズムによって、サーバーで確実に公開キーとペアになっている秘密キーが保持されるようにすることを理解することです。 証明書の提示者が証明書をコピーしたり盗んだりしていないことを確認します。 例として写真 ID を使用すると、顔は ID の写真と一致します。 誰かがあなたの ID を盗んだとしても、顔は一意で再現が難しいため、その ID を識別に使用することはできません。 暗号化キーの場合、キーの組は関連付けられており、一意です。 暗号アルゴリズムでは、顔を写真 ID と照合させる代わりに、キーの組を使用して ID を検証します。

このシナリオでは、ContosoIotHub は次の証明書チェーンを示しています。

ルート証明機関 (CA) は、Baltimore CyberTrust Root 証明書です。 このルート証明書は DigiCert によって署名され、広く信頼されており、多くのオペレーティング システムに格納されています。 たとえば、Ubuntu と Windows の両方で、既定の証明書ストアに含まれています。

Windows 証明書ストア:

Ubuntu 証明書ストア:

デバイスが Baltimore CyberTrust Root 証明書を確認すると、OS にプリインストールされています。 EdgeGateway の観点から見ると、ContosoIotHub によって提示される証明書チェーンは、OS が信頼するルート CA によって署名されているため、証明書は信頼できると見なされます。 この証明書は、IoT Hub サーバー証明書と呼ばれます。 IoT Hub サーバー証明書の詳細については、「IoT Hub でのトランスポート層セキュリティ (TLS) のサポート」をご覧ください。

まとめると、次の理由により、EdgeGateway では ContosoIotHub の ID を検証して信頼できます。

• ContosoIotHub が IoT Hub サーバー証明書を提示
• このサーバー証明書は OS 証明書ストアで信頼されている
• ContosoIotHub の公開キーで暗号化されたデータは、ContosoIotHub によって暗号化解除でき、秘密キーを保持していることが証明される

IoT Hub は IoT Edge デバイス ID を検証する

ContosoIotHub では、EdgeGateway と通信中であることをどのように確認しますか? IoT Hub では相互 TLS (mTLS) がサポートされているので、クライアント認証の TLS ハンドシェイクの際に EdgeGateway の証明書のチェックが行われます。 分かりやすくするために、次の図では一部の手順を省略します。

この場合、EdgeGateway はその IoT Edge デバイス ID 証明書を提供します。 ContosoIotHub の観点から、提供された証明書の拇印がそのレコードと一致することと、EdgeGateway が、提示した証明書とペアになっている秘密キーを持っていることの両方が確認されます。 IoT Hub で IoT Edge デバイスをプロビジョニングする場合は、拇印を提供します。 この拇印は、IoT Hub が証明書を検証するために使用します。

ヒント

IoT Hub では、IoT Edge デバイスの登録時に 2 つの拇印が必要です。 ベスト プラクティスとして、有効期限が異なる 2 つの異なるデバイス ID 証明書を準備します。 この方法では、一方の証明書が期限切れになっても、もう一方はまだ有効であり、期限切れの証明書をローテーションする時間が与えられます。 ただし、登録に 1 つの証明書のみを使用することもできます。 デバイスを登録するときに、プライマリとセカンダリの両方の拇印に同じ証明書の拇印を設定して、1 つの証明書を使用します。

たとえば、次のコマンドを使用して、EdgeGateway で ID 証明書の拇印を取得できます。

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

このコマンドによって証明書 SHA256 の拇印が出力されます。

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

IoT Hub に登録されている EdgeGateway デバイスの SHA256 拇印の値を表示すると、EdgeGateway の拇印と一致することがわかります。

まとめると、EdgeGateway が、拇印が IoT Hub に登録されているものと一致する有効な IoT Edge デバイス ID 証明書を提示しているため、ContosoIotHub は EdgeGateway を信頼できます。

証明書構築プロセスの詳細については、「X.509 証明書を使用して Linux で IoT Edge デバイスを作成およびプロビジョニングする」を参照してください。

Note

この例は、Azure IoT Hub Device Provisioning Service (DPS) には対応していません。これは、登録グループでプロビジョニングされる場合に、IoT Edge による X.509 CA 認証をサポートします。 DPS を使用して、CA 証明書または中間証明書をアップロードすると、証明書チェーンが検証され、デバイスがプロビジョニングされます。 詳細については、「DPS X.509 証明書の構成証明」をご覧ください。

Azure portal では、DPS は証明書の SHA256 拇印ではなく、SHA1 拇印を表示します。

DPS では、SHA256 拇印を IoT Hub に登録または更新します。 拇印は、コマンド openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256 を使用して確認できます。 登録されると、IoT Edge では IoT Hub による拇印認証が使用されます。 デバイスが再プロビジョニングされ、新しい証明書が発行されると、DPS では IoT Hub を新しい拇印で更新します。

IoT Hub では現在、IoT Edge による X.509 CA 認証を直接サポートしていません。

モジュール ID 操作のための証明書の使用

証明書検証の図では、IoT Edge が証明書のみを使用して IoT Hub と通信しているように見えるかもしれません。 IoT Edge は、複数のモジュールで構成されています。 その結果、IoT Edge では証明書を使用して、メッセージを送信するモジュールのモジュール ID を管理します。 モジュールは、IoT Hub に対する認証を行うのに、証明書を使用するのではなく、IoT Edge モジュール ランタイムによって生成された秘密キーから派生した SAS キーを使用します。 これらの SAS キーは、デバイス ID 証明書の有効期限が切れても変わりません。 証明書の有効期限が切れた場合、たとえば edgeHub は引き続き実行され、モジュール ID 操作のみが失敗します。

SAS キーはシークレットから派生しており、IoT Edge では人間による介入のリスクなしでキーを管理するため、モジュールと IoT Hub 間の対話は安全です。

IoT Edge をゲートウェイとして使用する入れ子になったデバイス階層のシナリオ

これで、IoT Edge と IoT Hub の間のシンプルな対話について十分に理解できました。 ただし、IoT Edge は、ダウンストリーム デバイスまたは他の IoT Edge デバイスのゲートウェイとしても機能することがあります。 これらの通信チャネルも暗号化され、信頼されている必要があります。 複雑さが増すため、ダウンストリーム デバイスを含めるようにサンプル シナリオを拡張する必要があります。

TempSensor という名前の通常の IoT デバイスを追加します。これは、IoT Hub ContosoIotHub に接続する親 IoT Edge デバイス EdgeGateway に接続します。 以前と同様に、すべての認証は X.509 証明書認証を使用して行われます。 新しいシナリオでは、「TempSensor デバイスは正当か?」と「EdgeGateway の ID は正しいか?」という 2 つの新しい疑問が生じます。 このシナリオは次のように説明できます。

ヒント

TempSensor は、このシナリオでは IoT デバイスです。 TempSensor が親 EdgeGateway のダウンストリーム IoT Edge デバイスである場合、証明書の概念は同じです。

デバイスでゲートウェイ ID が確認される

TempSensor では、正規の EdgeGateway と通信中であることがどのように検証されますか? TempSensor が EdgeGateway と通信する必要がある場合、TempSensor には ID を表示するために EdgeGateway が必要です。 ID は、TempSensor が信頼する機関によって発行されたものである必要があります。

このフローは、EdgeGateway が ContosoIotHub と通信する場合と同じです。 TempSensor と EdgeGateway は、TLS ハンドシェイク プロトコルを使用して EdgeGateway の ID を確認します。 2 つの重要な詳細があります。

• ホスト名の特殊性: EdgeGateway によって提示される証明書は、TempSensor が EdgeGateway への接続に使用するものと同じホスト名 (ドメインまたは IP アドレス) に対して発行される必要があります。
• 自己署名ルート CA の特殊性: EdgeGateway によって提示される証明書チェーンは、OS の既定の信頼されたルート ストアにない可能性があります。

詳細を理解するために、まず EdgeGateway によって提示される証明書チェーンを調べてみましょう。

ホスト名の特殊性

証明書の共通名 CN = edgegateway.local がチェーンの一番上にリストされます。 edgegateway.local は、edgeHub のサーバー証明書の共通名です。 edgegateway.local は、TempSensor と EdgeGateway が接続されているローカル ネットワーク (LAN または VNet) 上の EdgeGateway のホスト名でもあります。 192.168.1.23 などのプライベート IP アドレスまたは図のような完全修飾ドメイン名 (FQDN) の可能性があります。 edgeHub サーバー証明書は、IoT Edge config.toml ファイルで定義されている hostname パラメーターを使用して生成されます。 edgeHub サーバー証明書と Edge CA 証明書を混同しないでください。 Edge CA 証明書の管理の詳細については、IoT Edge 証明書の管理の説明を参照してください。

TempSensor が EdgeGateway に接続すると、TempSensor はホスト名 edgegateway.local を使用して EdgeGateway に接続します。 TempSensor は、EdgeGateway によって提示された証明書をチェックし、証明書の共通名が edgegateway.local であることを確認します。 証明書の共通名が異なる場合、TempSensor は接続を拒否します。

Note

分かりやすくするために、この例では、サブジェクト証明書の共通名 (CN) を、検証されるプロパティとして示しています。 実際には、証明書にサブジェクトの別名 (SAN) がある場合、CN ではなく SAN が検証されます。 通常、SAN には複数の値を含めることができるため、証明書所有者のメイン ドメインまたはホスト名と、代替ドメインの両方が含まれます。

EdgeGateway に自身のホスト名を通知する必要があるのはなぜですか?

EdgeGateway には、ネットワーク上の他のクライアントがどのように接続できるかを知るための信頼性の高い方法はありません。 たとえば、プライベート ネットワークでは、EdgeGateway を 10.0.0.2 または example-mdns-hostname.local としてリストする DHCP サーバーまたは mDNS サービスが存在する可能性があります。 ただし、ネットワークによっては、edgegateway.local を EdgeGateway の IP アドレス 10.0.0.2 にマッピングする DNS サーバーが存在する場合があります。

この問題を解決するために、IoT Edge では config.toml で構成されたホスト名の値を使用し、そのサーバー証明書を作成します。 要求が edgeHub モジュールに送信されると、適切な証明書共通名 (CN) を持つ証明書が提示されます。

IoT Edge で証明書が作成されるのはなぜですか?

この例では、証明書チェーンに iotedged workload ca edgegateway があることに注意してください。 Edge CA (以前、バージョン 1.1 では Device CA と呼ばれていました) として知られる IoT Edge デバイス上に存在する認証機関 (CA) です。 前の例の Baltimore CyberTrust Root CA と同様に、Edge CA では他の証明書を発行できます。 最も重要なのは、この例でも、サーバー証明書は edgeHub モジュールに発行されることです。 ただし、IoT Edge デバイスで実行されている他のモジュールに証明書を発行することもできます。

重要

構成されていない既定の状態では、Edge CA は IoT Edge モジュール ランタイムの初回起動時に自動的に生成され (quickstart Edge CA と呼ばれます)、証明書が edgeHub モジュールに発行されます。 このプロセスは、edgeHub が署名された有効な証明書を提示できるようにすることで、ダウンストリーム デバイスの接続が高速化されます。 この機能がない場合は、CA に edgeHub モジュールの証明書を発行してもらう必要があります。 自動生成された quickstart Edge CA の使用は、本番環境ではサポートされていません。 quickstart Edge CA の詳細については、「Quickstart Edge CA」をご覧ください。

デバイスで発行者証明書を保持するのは危険ではありませんか?

Edge CA は、制限のある、信頼性の低い、コストが高い、または接続性のないソリューションを有効にするように設計されていますが、同時に、証明書の更新に関する厳格な規制やポリシーがあります。 Edge CA がなければ、IoT Edge (特に edgeHub) は機能しません。

本番環境で Edge CA を保護するには:

• EdgeCA の秘密キーをトラステッド プラットフォーム モジュール (TPM) に配置します。できれば、秘密キーが一時的に生成され、TPM から離れない方法で行ってください。
• Edge CA がロールアップする公開キー基盤 (PKI) を使用します。 これにより、侵害された証明書の更新を無効または拒否できるようになります。 PKI は、顧客の IT 部門が方法を把握している場合は顧客の IT 部門によって (低コスト)、または商用の PKI プロバイダーによって管理できます。

自己署名ルート CA の特殊性

edgeHub モジュールは、すべての受信トラフィックを処理して IoT Edge を構成する重要なコンポーネントです。 この例では、Edge CA によって発行された証明書を使用します。これは、自己署名ルート CA によって発行されます。 このルート CA は OS によって信頼されていないため、TempSensor が信頼する唯一の方法は、CA 証明書をデバイスにインストールすることです。 これは、信頼バンドル シナリオとも呼ばれ、チェーンを信頼する必要があるクライアントにルートを配布する必要があります。 信頼バンドル シナリオは、デバイスにアクセスして証明書をインストールする必要があるため、面倒な場合があります。 証明書のインストールには計画が必要です。 スクリプトを使用して行うか、製造時に追加するか、OS イメージにプリインストールすることができます。

Note

一部のクライアントと SDK では、OS の信頼されたルート ストアを使用しないため、ルート CA ファイルを直接渡す必要があります。

これらの概念をすべて適用すると、TempSensor は本物の EdgeGateway と通信中であることを確認できます。これは、アドレスに一致する証明書を提示し、その証明書が信頼できるルートによって署名されているためです。

証明書チェーンを確認するには、TempSensor デバイスで openssl を使用します。 この例では、接続用のホスト名が depth 0 証明書の CN と一致し、ルート CA が一致していることに注目してください。

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

openssl コマンドの詳細については、OpenSSL のドキュメントをご覧ください。

既定で /var/lib/aziot/certd/certs に格納されている証明書を調べることもできます。 ディレクトリ内に、Edge CA 証明書、デバイス ID 証明書、モジュール証明書があるのを確認できます。 openssl x509 コマンドを使用して、証明書を検査できます。 次に例を示します。

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

まとめると、TempSensor が EdgeGateway を信頼できる理由は次のとおりです。

• edgeHub モジュールが、edgegateway.local の有効な IoT Edge モジュール サーバー証明書を提示した
• その証明書は、my_private_root_CA によって発行された Edge CA によって発行されている
• このプライベート ルート CA は、以前に信頼されたルート CA として TempSensor にも格納されている
• 暗号アルゴリズムは、所有権と発行チェーンが信頼できることを確認する

他のモジュールの証明書

他のモジュールは、Edge CA によって発行されたサーバー証明書を取得できます。 たとえば、Web インターフェースを持つ Grafana モジュールです。 Edge CA から証明書を取得することもできます。 モジュールは、コンテナーでホストされるダウンストリーム デバイスとして扱われます。 ただし、IoT Edge モジュール ランタイムから証明書を取得できることは特別な特権です。 モジュールは、ワークロード API を呼び出して、構成済みの Edge CA にチェーンされたサーバー証明書を受け取ります。

ゲートウェイによってデバイス ID が検証される

EdgeGateway は、TempSensor と通信中であることをどのように確認しますか? EdgeGateway は TLS クライアント認証を使用して TempSensor を認証します。

このシーケンスは、デバイスを検証する ContosoIotHub に似ています。 ただし、ゲートウェイ シナリオでは、EdgeGateway は、証明書の記録の信頼できる情報源として ContosoIotHub に依存しています。 EdgeGateway では、クラウドへの接続がない場合に備えて、オフライン コピーやキャッシュも保持します。

ヒント

IoT Edge デバイスとは異なり、ダウンストリーム IoT デバイスは拇印 X.509 認証に限定されません。 X.509 CA 認証もオプションです。 EdgeGateway では、拇印で一致を探すだけでなく、TempSensor の証明書が ContosoIotHub にアップロードされた CA にルート化されているかどうかも確認できます。

まとめると、EdgeGateway が TempSensor を信頼できる理由は次のとおりです。

• TempSensor が、その名前に対する有効な IoT デバイス ID 証明書を提示した
• ID 証明書の拇印は、ContosoIotHub にアップロードされたものと一致する
• 暗号アルゴリズムは、所有権と発行チェーンが信頼できることを確認する

証明書と管理の取得先

多くの場合、独自の証明書を提供するか、自動生成された証明書を使用します。 たとえば、Edge CA と edgeHub 証明書は自動生成されます。

ただし、ベスト プラクティスは EST (Enrollment over Secure Transport) サーバーを使用して x509 証明書を管理するようにデバイスを構成することです。 EST サーバーを使用すると、証明書を手動で処理してデバイスにインストールする必要がなくなります。 EST サーバーの使用の詳細については、「Azure IoT Edge 用に Enrollment over Secure Transport サーバーを構成する」をご覧ください。

証明書を使用して EST サーバーに対する認証を行うこともできます。 これらの証明書は、EST サーバーで認証して他の証明書を発行するために使用されます。 証明書サービスは、ブートストラップ証明書を使用して EST サーバーで認証します。 ブートストラップ証明書は有効期間が長いです。 最初の認証時に、証明書サービスは、EST サーバーに対して ID 証明書を発行するよう要求します。 この ID 証明書は、同じサーバーに対する今後の EST 要求で使用されます。

EST サーバーを使用できない場合は、PKI プロバイダーに証明書を要求する必要があります。 IoT Hub と IoT Edge デバイスで証明書ファイルを手動で管理できます。 詳細については、「IoT Edge デバイスで証明書を管理する」を参照してください。

概念実証の開発のために、テスト証明書を作成できます。 詳細については、「IoT Edge デバイスの機能をテストするためのデモ用の証明書を作成する」をご覧ください。

IoT の証明書

証明機関

証明機関 (CA) は、デジタル証明書を発行するエンティティです。 証明機関は、証明書の所有者および受信者間で信頼されたサード パーティとして機能します。 デジタル証明書では、証明書の受信者による公開キーの所有権を認定します。 最初に、証明機関によって発行されたすべての証明書の信頼の基盤となるルート証明書を発行することで、信頼の証明書チェーンが機能します。 その後、ルート証明書の所有者は追加の中間証明書 (ダウンストリーム デバイス証明書) を発行できます。

ルート CA 証明書

ルート CA 証明書は、プロセス全体の信頼のルートです。 運用環境のシナリオでは、この CA 証明書は Baltimore、Verisign、DigiCert などの信頼できる商用の証明機関から購入されます。 お使いの IoT Edge デバイスに接続されているデバイスに対して完全な制御がある場合は、企業レベルの証明機関を使用することが可能です。 いずれの場合も、それは IoT Edge から IoT Hub までの証明書チェーン全体で使用されます。 ダウンストリーム IoT デバイスは、ルート証明書を信頼する必要があります。 ルート CA 証明書を信頼されたルート証明機関のストアに格納すること、またはアプリケーション コード内で証明書の詳細を提供することが可能です。

中間証明書

セキュアなデバイスを生産する一般的な製造プロセスでは、主に漏洩や露出のリスクがあるために、ルート CA 証明書が直接使用されることは、ほとんどありません。 ルート CA 証明書は、中間 CA 証明書を 1 つ以上作成し、デジタル署名を行います。 これらの中間証明書は、1 つのみの場合も、チェーンになっている場合もあります。 次に、中間証明書のチェーンが必要になるシナリオを示します。

• 製造業者の社内部門の階層
• デバイスの生産時にシリアルに関連付けられた複数の企業
• ルート CA を購入し、製造業者が顧客の代わりにデバイスに署名するための署名証明書を取得している顧客

いずれの場合も、製造元は、エンド デバイスに配置された Edge CA 証明書に署名するために、このチェーンの末端にある中間 CA 証明書を使います。 これらの中間証明書は、製造工場で厳重に保護されます。 製造業者が、証明書の使用方法に合わせて、物理および電子の両面で、厳密なプロセスを実施します。

次のステップ

• IoT Edge デバイスに証明書をインストールし、config ファイルからそれらを参照する方法の詳細については、「IoT Edge デバイスで証明書を管理する」を参照してください。
• Azure IoT Edge モジュールについて
• 透過的なゲートウェイとして機能するように IoT Edge デバイスを構成します。
• この記事では、IoT Edge デバイス上のさまざまなコンポーネント間、または IoT Edge デバイスとダウンストリーム デバイスとの間の接続をセキュリティで保護するために使用される証明書について説明します。 また、証明書を使用して、IoT Hub に対して IoT Edge デバイスを認証することもできます。 これらの認証証明書は異なりますが、この記事では説明されません。 証明書を使用してデバイスを認証する方法の詳細については、「X.509 証明書を使用して IoT Edge デバイスを作成およびプロビジョニングする」を参照してください。