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 デバイスは、証明書を使用して、デバイス上で実行されるランタイムと任意のモジュール間の安全な接続を作成します。 ゲートウェイとして機能している IoT Edge デバイスは、これらの同じ証明書を使用してダウンストリームのデバイスに接続します。

Note

この記事全体で使用されている "ルート CA" という用語は、IoT ソリューションの証明書チェーンにおいて最上位の証明機関の証明書を指します。 シンジケート証明機関の証明書ルートや、組織の証明機関のルートを使用する必要はありません。 多くの場合、これは実際には中間 CA 証明書です。

前提条件

• 「Azure IoT Edge での証明書の使用方法について理解する」の概念 (特に IoT Edge が証明書を使う方法) を理解しておく必要があります。

• IoT Edge デバイス。

  IoT Edge デバイスがセットアップされていない場合は、Azure 仮想マシンで作成できます。 こうしたクイックスタートの記事のいずれかの手順に従って、仮想 Linux デバイスを作成するか、仮想 Windows デバイスを作成します。

• 構成テンプレートに従って IoT Edge 構成ファイル config.toml を編集できること。

• 使用する config.toml がテンプレートに基づいていない場合は、テンプレートを開き、コメントに示されたガイダンスを使用して、テンプレートの構造に従って構成セクションを追加します。

• 構成されていない新しい IoT Edge インストールがある場合は、テンプレートをコピーして構成を初期化します。 既存の構成がある場合は、このコマンドを使用しないでください。 ファイルが上書きされます。

  sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
  

形式の要件

ヒント

• 証明書は、DER (Distinguished Encoding Rules) というバイナリ表現、または PEM (Privacy Enhanced Mail) というテキスト表現でエンコードできます。 PEM 形式は、-----BEGIN CERTIFICATE----- ヘッダーの後に base64 でエンコードされた DER、その後に -----END CERTIFICATE----- フッターが続く形式です。
• 証明書と同様に、秘密キーはバイナリの DER またはテキスト表現の PEM でエンコードできます。
• PEM は明確に区切られているため、同じファイル内で CERTIFICATE と PRIVATE KEY の両方を順番に組み合わせた PEM を構成することもできます。
• 最後に、証明書と秘密キーを PKCS#12 と呼ばれるバイナリ表現で一緒にエンコードできます。それをオプションのパスワードで暗号化します。

ファイル拡張子は任意であり、file コマンドを実行するかファイルを表示して種類を確認する必要があります。 一般に、ファイルの拡張子には次の規則が使用されます。

• .cer は DER または PEM 形式の証明書です。
• .pem は PEM 形式の証明書、秘密キー、またはその両方のいずれかです。
• .pfx は PKCS#12 ファイルです。

IoT Edge を使用するための証明書と秘密キーの要件は次のとおりです。

• PEM 形式
• 個別のファイル
• ほとんどの場合、チェーン全体を含む

PKI プロバイダーから .pfx ファイルを取得した場合、1 つのファイル内に証明書と秘密キーが一緒にエンコードされている可能性があります。 file コマンドを使用して、そのファイルの種類が PKCS#12 であることを確認します。 openssl pkcs12 コマンドを使用して、PKCS#12 の .pfx ファイルを PEM ファイルに変換できます。

.cer ファイルが PKI プロバイダーから提供された場合、それは .pfx と同じ証明書を含むものであるか、PKI プロバイダーの発行元 (ルート) 証明書である可能性があります。 確認するには、openssl x509 コマンドを使用してファイルを調べます。 発行元の証明書である場合:

• DER (バイナリ) 形式である場合は、openssl x509 -in cert.cer -out cert.pem を使用して PEM に変換します。
• その PEM ファイルを信頼バンドルとして使用します。 信頼バンドルの詳細については、次のセクションを参照してください。

重要

PKI インフラストラクチャは、RSA-2048 ビット キーと EC P-256 キーをサポートする必要があります。 たとえば、EST サーバーはこれらのキーの種類をサポートしている必要があります。 他の種類のキーを使うこともできますが、テストするのは RSA-2048 ビット キーと EC P-256 キーのみです。

権限の要件

次の表に、IoT Edge 証明書に必要なファイルとディレクトリのアクセス許可を示します。 証明書に推奨されるディレクトリは、キーには /var/aziot/certs/ と /var/aziot/secrets/ です。

ファイルまたはディレクトリ	アクセス許可	所有者
/var/aziot/certs/ 証明書ディレクトリ	drwxr-xr-x (755)	aziotcs
/var/aziot/certs/ 内の証明書ファイル	-wr-r--r-- (644)	aziotcs
/var/aziot/secrets/ キー ディレクトリ	drwx------ (700)	aziotks
/var/aziot/secrets/ 内のキー ファイル	-wr------- (600)	aziotks

ディレクトリの作成、アクセス許可の設定、所有者の設定を行うには、次のコマンドを実行します。

# If the certificate and keys directories don't exist, create, set ownership, and set permissions
sudo mkdir -p /var/aziot/certs
sudo chown aziotcs:aziotcs /var/aziot/certs
sudo chmod 755 /var/aziot/certs

sudo mkdir -p /var/aziot/secrets
sudo chown aziotks:aziotks /var/aziot/secrets
sudo chmod 700 /var/aziot/secrets

# Give aziotcs ownership to certificates
# Read and write for aziotcs, read-only for others
sudo chown -R aziotcs:aziotcs /var/aziot/certs
sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;

# Give aziotks ownership to private keys
# Read and write for aziotks, no permission for others
sudo chown -R aziotks:aziotks /var/aziot/secrets
sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;

# Verify permissions of directories and files
sudo ls -Rla /var/aziot

正しい所有権とアクセス許可が含まれている一覧の出力は、次の出力のようになります。

azureUser@vm:/var/aziot$ sudo ls -Rla /var/aziot
/var/aziot:
total 16
drwxr-xr-x  4 root    root    4096 Dec 14 00:16 .
drwxr-xr-x 15 root    root    4096 Dec 14 00:15 ..
drwxr-xr-x  2 aziotcs aziotcs 4096 Jan 14 00:31 certs
drwx------  2 aziotks aziotks 4096 Jan 23 17:23 secrets

/var/aziot/certs:
total 20
drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 .
drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
-rw-r--r-- 1 aziotcs aziotcs 1984 Jan 14 00:24 azure-iot-test-only.root.ca.cert.pem
-rw-r--r-- 1 aziotcs aziotcs 5887 Jan 14 00:27 iot-edge-device-ca-devicename-full-chain.cert.pem

/var/aziot/secrets:
total 16
drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 .
drwxr-xr-x 4 root    root    4096 Dec 14 00:16 ..
-rw------- 1 aziotks aziotks 3243 Jan 14 00:28 iot-edge-device-ca-devicename.key.pem

信頼されたルート CA (信頼バンドル) を管理する

IoT Edge とモジュールでの信頼のルートとして証明機関 (CA) の自己署名証明書を使用することは、"信頼バンドル" と呼ばれます。 信頼バンドルは、IoT Edge およびモジュールとサーバーとの通信に使用できます。 信頼バンドルを構成するには、そのファイル パスを IoT Edge 構成ファイル内に指定します。

1. PKI プロバイダーからルート CA 証明書を取得します。

2. 証明書が形式の要件を満たしていることを確認します。

3. PEM ファイルをコピーし、IoT Edge の証明書サービスのアクセス権を付与します。 たとえば、/var/aziot/certs ディレクトリを使用する場合は次のようになります。

   # Make the directory if doesn't exist
   sudo mkdir /var/aziot/certs -p
   
   # Change cert directory user and group ownership to aziotcs and set permissions
   sudo chown aziotcs:aziotcs /var/aziot/certs
   sudo chmod 755 /var/aziot/certs
   
   # Copy certificate into certs directory
   sudo cp root-ca.pem /var/aziot/certs
   
   # Give aziotcs ownership to certificate and set read and write permission for aziotcs, read-only for others
   sudo chown aziotcs:aziotcs /var/aziot/certs/root-ca.pem
   sudo chmod 644 /var/aziot/certs/root-ca.pem
   

4. IoT Edge 構成ファイル config.toml で、Trust bundle cert セクションを見つけます。 このセクションがない場合は、構成テンプレート ファイルからコピーできます。

   ヒント

   構成ファイルがデバイスにまだ存在しない場合は、/etc/aziot/config.toml.edge.template をテンプレートとして使用して作成します。

5. trust_bundle_cert キーは、証明書ファイルの場所に設定します。

   trust_bundle_cert = "file:///var/aziot/certs/root-ca.pem"
   

6. 構成を適用します。

   sudo iotedge config apply
   

ルート CA を OS 証明書ストアにインストールする

証明書は、信頼バンドル ファイルにインストールすると、コンテナー モジュールで使用できるようになりますが、Azure Device Update や Defender などのモジュールをホストすることはできません。 ホスト レベルのコンポーネントを使用する場合、または TLS に関する他の問題が発生した場合は、オペレーティング システム証明書ストアへのルート CA 証明書のインストールも行います。

Debian / Ubuntu

sudo cp /var/aziot/certs/my-root-ca.pem /usr/local/share/ca-certificates/my-root-ca.pem.crt

sudo update-ca-certificates

EFLOW / RHEL

sudo cp /var/aziot/certs/my-root-ca.pem /etc/pki/ca-trust/source/anchors/my-root-ca.pem.crt

sudo update-ca-trust

証明書と秘密キーのファイルをインポートする

IoT Edge で既存の証明書と秘密キーのファイルを使用して、Azure の認証または証明、新しいモジュール サーバー証明書の発行、EST サーバーへの認証を行うことができます。 そのインストール手順は次のとおりです。

1. 証明書と秘密キーのファイルが形式の要件を満たしていることを確認します。

2. IoT Edge デバイスの、IoT Edge モジュールからアクセスできる場所に PEM ファイルをコピーします。 たとえば、/var/aziot/ ディレクトリです。

   # If the certificate and keys directories don't exist, create, set ownership, and set permissions
   sudo mkdir -p /var/aziot/certs
   sudo chown aziotcs:aziotcs /var/aziot/certs
   sudo chmod 755 /var/aziot/certs
   
   sudo mkdir -p /var/aziot/secrets
   sudo chown aziotks:aziotks /var/aziot/secrets
   sudo chmod 700 /var/aziot/secrets
   
   # Copy certificate and private key into the correct directory
   sudo cp my-cert.pem /var/aziot/certs
   sudo cp my-private-key.pem /var/aziot/secrets
   

3. IoT Edge の証明書サービス aziotcs とキー サービス aziotks に、証明書と秘密キーの所有権をそれぞれ付与します。

   # Give aziotcs ownership to certificate
   # Read and write for aziotcs, read-only for others
   sudo chown aziotcs:aziotcs /var/aziot/certs/my-cert.pem
   sudo chmod 644 /var/aziot/certs/my-cert.pem
   
   # Give aziotks ownership to private key
   # Read and write for aziotks, no permission for others
   sudo chown aziotks:aziotks /var/aziot/secrets/my-private-key.pem
   sudo chmod 600 /var/aziot/secrets/my-private-key.pem
   

4. config.toml で、構成する証明書の種類に関連するセクションを見つけます。 たとえば、キーワード cert を検索できます。

5. 構成テンプレートの例を使用して、デバイス ID 証明書または Edge CA ファイルを構成します。 パターンの例を次に示します。

   cert = "file:///var/aziot/certs/my-cert.pem"
   pk = "file:///var/aziot/secrets/my-private-key.pem"
   

6. 構成を適用する

   sudo iotedge config apply
   

証明書が有効期限切れになったときのエラーを防ぐには、証明書の有効期限が切れる前に、忘れずにファイルと構成を手動で更新してください。

例: PKI プロバイダーからのデバイス ID 証明書ファイルを使用する

PKI プロバイダーに TLS クライアント証明書と秘密キーを要求します。

デバイス ID 証明書の要件:

• 標準クライアント証明書拡張機能: extendedKeyUsage = clientAuth keyUsage = critical, digitalSignature
• CA 証明書のローテーションで同じ CN を使用する発行元 CA を区別するのに役立つキー識別子。
  • subjectKeyIdentifier = hash
  • authorityKeyIdentifier = keyid:always,issuer:always

共通名 (CN) が、IoT Hub に登録されている IoT Edge デバイス ID または DPS での登録 ID と一致していることを確認します。 たとえば、次のデバイス ID 証明書では、Subject: CN = my-device が、一致する必要がある重要なフィールドです。

デバイス ID 証明書の例:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 48 (0x30)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN = myPkiCA
        Validity
            Not Before: Jun 28 21:27:30 2022 GMT
            Not After : Jul 28 21:27:30 2022 GMT
        Subject: CN = my-device
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:ad:b0:63:1f:48:19:9e:c4:9d:91:d1:b0:b0:e5:
                    ...
                    80:58:63:6d:ab:56:9f:90:4e:3f:dd:df:74:cf:86:
                    04:af
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Subject Key Identifier:
                C7:C2:DC:3C:53:71:B8:42:15:D5:6C:4B:5C:03:C2:2A:C5:98:82:7E
            X509v3 Authority Key Identifier:
                keyid:6E:57:C7:FC:FE:50:09:75:FA:D9:89:13:CB:D2:CA:F2:28:EF:9B:F6

    Signature Algorithm: ecdsa-with-SHA256
         30:45:02:20:3c:d2:db:06:3c:d7:65:b7:22:fe:df:9e:11:5b:
         ...
         eb:da:fc:f1:6a:bf:31:63:db:5a:16:02:70:0f:cf:c8:e2
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----

ヒント

PKI によって提供される証明書ファイルにアクセスせずにテストするには、デバイスの機能をテストするためのデモ用の証明書の作成に関するページを参照して、有効期間が短く運用環境用ではないデバイス ID 証明書と秘密キーを生成します。

IoT Hub を使用してプロビジョニングする場合の構成例:

[provisioning]
source = "manual"
# ...
[provisioning.authentication]
method = "x509"

identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"

DPS を使用してプロビジョニングする場合の構成例:

[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"

identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"

手動での証明書管理によるオーバーヘッドは、リスクを伴い、間違いが発生しやすくなります。 運用環境では、証明書の自動管理ができる IoT Edge を使用することをお勧めします。

Edge CA を管理する

Edge CA には、2 つの異なるモードがあります。

• "クイックスタート" は既定の動作です。 クイックスタートはテスト用であり、運用環境には適していません。
• "運用" モードでは、Edge CA 証明書と秘密キーの独自のソースを指定する必要があります。

クイックスタート Edge CA

作業を開始しやすいように、IoT Edge を初めて起動したとき、既定により Edge CA 証明書が自動的に生成されます。 この自己署名証明書は、運用環境ではなく、開発およびテスト シナリオのみを対象としています。 既定では、証明書は 90 日後に有効期限切れになります。 有効期限は構成できます。 この動作は、"クイックスタート Edge CA" と呼ばれます。

"クイックスタート Edge CA" を使用すると、IoT Edge を最初に構成なしでインストールしたときに、edgeHub および他の IoT Edge モジュールで有効なサーバー証明書を取得できます。 証明書は、edgeHub で必要になります。これは、モジュールまたはダウンストリーム デバイスで、セキュリティで保護された通信チャネルを確立する必要があるためです。 クイックスタート Edge CA がない場合は、PKI プロバイダーから、または openssl などのツールを使用して、有効なサーバー証明書を提供する必要があるため、作業開始が大幅に困難になります。

重要

Edge CA は運用環境に使用しないでください。その中のローカルに生成された証明書は PKI に接続されていないからです。

証明書ベースの ID のセキュリティは、証明書 (ドキュメント) が単なるコンポーネントである適切に運用された PKI (インフラストラクチャ) から派生します。 適切に運用された PKI で可能なセキュリティ ポリシーの定義、応用、管理、適用の対象には、証明書の発行、失効、ライフサイクル管理が含まれますが、これらに限定されません。

クイックスタート Edge CA の有効期間をカスタマイズする

証明書の有効期限を既定値の 90 日以外に構成するには、構成ファイルの Edge CA 証明書 (クイックスタート) セクションに日数の値を追加します。

[edge_ca]
auto_generated_edge_ca_expiry_days = 180

以前に生成された証明書を削除するために、/var/lib/aziot/certd/certs および /var/lib/aziot/keyd/keys フォルダーの内容を削除してから、構成を適用します。

クイックスタート Edge CA を更新する

IoT Edge の既定では、証明書の有効期間の 80% に達したときにクイックスタート Edge CA 証明書が自動的に更新されます。 たとえば、証明書の有効期間が 90 日の場合、発行から 72 日目に IoT Edge によって Edge CA 証明書が自動的に再生成されます。

自動更新ロジックを変更するには、config.toml の Edge CA certificate セクションに次の設定を追加します。 次に例を示します。

[edge_ca.auto_renew]
rotate_key = true
threshold = "70%"
retry = "2%"

運用環境の Edge CA

運用環境のシナリオへの移行後、またはゲートウェイ デバイスを作成する場合は、クイックスタート Edge CA を使用できなくなります。

1 つのオプションは、独自の証明書を用意し、手動で管理することです。 ただし、リスクがあって間違いが発生しやすい手動での証明書管理プロセスを避けるために、可能な限り EST サーバーを使用してください。

注意事項

Edge CA 証明書の共通名 (CN) は、デバイスの構成ファイル config.toml で定義されているデバイスのホスト名パラメーター、または IoT Hub に登録されているデバイス ID と同じにすることはできません。

Edge CA の更新を計画する

Edge CA 証明書が更新されると、モジュール サーバー証明書のように、発行されたすべての証明書が再生成されます。 モジュールに新しいサーバー証明書を適用するために、Edge CA 証明書の更新時に IoT Edge によってすべてのモジュールが再起動されます。

モジュールの再起動による潜在的な悪影響を最小限に抑えるには、特定の時刻 (たとえば threshold = "10d") に Edge CA 証明書を更新し、ダウンタイムについてソリューションの依存ユーザーに通知することを計画します。

例: PKI プロバイダーからの Edge CA 証明書ファイルを使用する

PKI プロバイダーに次のファイルを要求します。

• PKI のルート CA 証明書
• 発行元または CA 証明書と、関連付けられた秘密キー

発行元 CA 証明書を Edge CA にするには、次の拡張部分が必要です。

subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, digitalSignature, keyCertSign

結果としての Edge CA 証明書の例:

openssl x509 -in my-edge-ca-cert.pem -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 4098 (0x1002)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = myPkiCA
        Validity
            Not Before: Aug 27 00:00:50 2022 GMT
            Not After : Sep 26 00:00:50 2022 GMT
        Subject: CN = my-edge-ca.ca
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (4096 bit)
                Modulus:
                    00:e1:cb:9c:c0:41:d2:ee:5d:8b:92:f9:4e:0d:3e:
                    ...
                    25:f5:58:1e:8c:66:ab:d1:56:78:a5:9c:96:eb:01:
                    e4:e3:49
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                FD:64:48:BB:41:CE:C1:8A:8A:50:9B:2B:2D:6E:1D:E5:3F:86:7D:3E
            X509v3 Authority Key Identifier:
                keyid:9F:E6:D3:26:EE:2F:D7:84:09:63:84:C8:93:72:D5:13:06:8E:7F:D1
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
            X509v3 Key Usage: critical
                Digital Signature, Certificate Sign
    Signature Algorithm: sha256WithRSAEncryption
         20:c9:34:41:a3:a4:8e:7c:9c:6e:17:f5:a6:6f:e5:fc:6e:59:
         ...
         7c:20:5d:e5:51:85:4c:4d:f7:f8:01:84:87:27:e3:76:65:47:
         9e:6a:c3:2e:1a:f0:dc:9d
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----

最新のファイルを受け取ったら、信頼バンドルを更新します。

trust_bundle_cert = "file:///var/aziot/root-ca.pem"

次に、証明書と秘密キーのファイルを使用するように IoT Edge を構成します。

[edge_ca]
cert = "file:///var/aziot/my-edge-ca-cert.pem"
pk = "file:///var/aziot/my-edge-ca-private-key.key.pem"

以前にデバイスで IoT Edge に対して他の証明書を使用したことがある場合は、/var/lib/aziot/certd/certs 内のファイルと、/var/lib/aziot/keyd/keys 内の証明書に関連付けられた秘密キー (すべてのキーでは "ない") を削除します。 それらは IoT Edge によって、指定した新しい CA 証明書を使用して再作成されます。

この方法を使用する場合、証明書の有効期限が切れたときにファイルを手動で更新する必要があります。 この問題を回避するには、自動管理に EST を使用することを検討してください。

EST サーバーを使用した証明書の自動管理

IoT Edge を使用すると、Enrollment over Secure Transport (EST) サーバーとのインターフェイスを経由して、自動で証明書の発行と更新を行うことができます。 運用環境では EST を使用することをお勧めします。これは、リスクがあって間違いが発生しやすい、手動での証明書管理に代わるものです。 グローバルに構成し、証明書の種類ごとにオーバーライドできます。

このシナリオでは、ブートストラップ証明書と秘密キーは有効期間が長く、製造時にデバイスにインストールされている可能性があります。 IoT Edge でブートストラップ資格情報を使用して、最初の要求の EST サーバーに対する認証を行い、後続の要求の ID 証明書を発行します。また、DPS または IoT Hub に対する認証も行います。

1. EST サーバーへのアクセス権を取得します。 EST サーバーがない場合は、次のいずれかのオプションを使用してテストを開始します。

   • 「チュートリアル: Azure IoT Edge 用に Enrollment over Secure Transport サーバーを構成する」の手順を使用して、テスト EST サーバーを作成します。

   • Microsoft では、GlobalSign と提携してデモ アカウントを提供しています。

2. IoT Edge デバイス構成ファイル config.toml で、EST サーバーの TLS 証明書を検証するために IoT Edge で使用される、信頼されたルート証明書へのパスを構成します。 公的に信頼されたルート TLS 証明書が EST サーバーに存在する場合、この手順は省略可能です。

   [cert_issuance.est]
   trusted_certs = [
      "file:///var/aziot/root-ca.pem",
   ]
   

3. EST サーバーの既定の URL を指定します。 config.toml で、EST サーバーの URL を含む次のセクションを追加します。

   [cert_issuance.est.urls]
   default = "https://example.org/.well-known/est"
   

4. 認証用に EST 証明書を構成するには、証明書と秘密キーへのパスを含む次のセクションを追加します。

   [cert_issuance.est.auth]
   bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem"
   bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem"
   
   [cert_issuance.est.identity_auto_renew]
   rotate_key = true
   threshold = "80%"
   retry = "4%"
   

5. 構成の変更を適用します。

   sudo iotedge config apply
   

[cert_issuance.est.identity_auto_renew] での設定については、次のセクションで説明します。

ユーザー名とパスワードの認証

証明書を使用した EST サーバーへの認証ができない場合は、代わりに共有シークレットまたはユーザー名とパスワードを使用できます。

[cert_issuance.est.auth]
username = "username"
password = "password"

自動更新パラメーターを構成する

IoT Edge には、証明書ファイルを手動で管理する代わりに、有効期限が切れる前に証明書を取得および更新する機能が組み込まれています。 証明書の更新には、IoT Edge で管理できる発行方法が必要です。 Enrollment over Secure Transport (EST) サーバーは 1 つの発行方法ですが、IoT Edge では自動的に既定でクイックスタート CA を更新することもできます。 証明書の更新は、証明書の種類ごとに構成します。

1. config.toml で、構成する証明書の種類に関連するセクションを見つけます。 たとえば、キーワード auto_renew を検索できます。

2. 構成テンプレートの例を使用して、デバイス ID 証明書、Edge CA、または EST ID 証明書を構成します。 パターンの例を次に示します。

   [REPLACE_WITH_CERT_TYPE]
   # ...
   method = "est"
   # ...
   
   [REPLACE_WITH_CERT_TYPE.auto_renew]
   rotate_key = true
   threshold = "80%" 
   retry = "4%"
   

3. 構成を適用する

   sudo iotege config apply
   

次の表は、auto_renew の各オプションで何が行われるかを示しています。

パラメーター	説明
rotate_key	IoT Edge による証明書の更新時に秘密キーをローテーションするかどうかを制御します。
threshold	IoT Edge が証明書の更新を開始するタイミングを設定します。 次のように指定できます。 - 割合: 0 から 100 の間の整数とそれに続く %。 更新は、証明書の有効期間に相対して開始されます。 たとえば、80% に設定すると、100 日間有効な証明書は、有効期限の 20 日前に更新が開始されます。 - 絶対時間: 整数とそれに続く min (分) または day (日)。 更新は、証明書の有効期限に相対して開始されます。 たとえば、4day を 4 日、または 10min を 10 分に設定した場合、有効期限前のその指定時間に証明書の更新が開始されます。 threshold が証明書の有効期間よりも長いという意図しない構成の誤りを避けるために、可能な限り代わりに "割合" を使うことをお勧めします。
retry	更新が失敗した場合に再試行する頻度を制御します。 threshold と同様に、同じ形式を使って "割合" または "絶対時間" として指定できます。

例: EST を使用してデバイス ID 証明書を自動的に更新する

運用環境で推奨されるデバイス ID 証明書の自動的な発行と更新に EST と IoT Edge を使用するには、IoT Edge によるプロビジョニングを DPS CA ベースの登録グループの一部として行う必要があります。 次に例を示します。

## DPS provisioning with X.509 certificate
[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"

[provisioning.attestation.identity_cert]
method = "est"
common_name = "my-device"

[provisioning.attestation.identity_cert.auto_renew]
rotate_key = true
threshold = "80%"
retry = "4%"

発行方法が EST に設定されている場合、Edge CA の自動更新を有効にする必要があります。 Edge CA の有効期限は、多くの IoT Edge 機能を中断するため、回避する必要があります。 Edge CA 証明書のライフサイクルを完全に制御する必要がある状況にある場合は、代わりに手動での Edge CA 管理の方法を使用してください。

EST や auto_renew を他のプロビジョニング方法 (IoT Hub を使用した手動の X.509 プロビジョニングや、個別登録による DPS など) と一緒に使用しないでください。 IoT Edge での証明書の更新時、Azure の証明書の拇印を更新できないため、IoT Edge の再接続ができなくなります。

例: EST を使用した Edge CA の自動管理

運用環境では、EST の自動的な Edge CA の発行と更新を使用します。 EST サーバーを構成したら、グローバル設定を使用するか、次の例のようにオーバーライドできます。

[edge_ca]
method = "est"

common_name = "my-edge-CA"
url = "https://ca.example.org/.well-known/est"

bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem"
bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem"

[edge_ca.auto_renew]
rotate_key = true
threshold = "90%"
retry = "2%"

モジュール サーバー証明書

Edge デーモンによって、Edge モジュールで使用するためのモジュール サーバーおよび ID 証明書が発行されます。 必要に応じて ID とサーバーの証明書を更新する責任は、Edge モジュールにあります。

更新

サーバー証明書は、Edge CA 証明書から発行される場合があります。 発行方法に関係なく、これらの証明書はモジュールによって更新される必要があります。 カスタム モジュールを開発する場合は、モジュールに更新ロジックを実装する必要があります。

edgeHub モジュールは証明書の更新機能をサポートしています。 次の環境変数を使って、edgeHub モジュールのサーバー証明書の更新を構成できます。

• ServerCertificateRenewAfterInMs: 証明書の有効期限に関係なく、edgeHub サーバー証明書が更新される期間をミリ秒単位で設定します。
• MaxCheckCertExpiryInMs: edgeHub サービスが edgeHub サーバー証明書の有効期限を確認する時間をミリ秒単位で設定します。 この変数を設定すると、証明書の有効期限に関係なくチェックが行われます。

環境変数の詳細については、EdgeHub と EdgeAgent の環境変数のページを参照してください。

1.2 以降の変更点

• デバイス CA 証明書は、Edge CA 証明書という名前に変わりました。
• ワークロード CA 証明書は、非推奨になりました。 IoT Edge セキュリティ マネージャーは、IoT Edge ハブ edgeHub サーバー証明書を Edge CA 証明書から直接生成するようになりました。その中間のワークロード CA 証明書は生成されません。
• 既定の構成ファイルの名前と場所が新しくなり、既定では /etc/iotedge/config.yaml から /etc/aziot/config.toml になっています。 iotedge config import コマンドを使用すると、構成情報を以前の場所と構文から新しいものへと移行できます。

次のステップ

証明書を IoT Edge デバイス上にインストールするステップは、ソリューションを運用環境にデプロイする前に必ず実行する必要があります。 詳細については、「IoT Edge ソリューションを運用環境にデプロイするための準備を行う」を参照してください。