シナリオ: mTLS証明書を使用するデジタル・ツイン・インスタンスの作成

デバイスからデータを受信する場合は、デジタル・ツイン・インスタンスで認証を使用する必要があります。このシナリオでは、証明書を使用してデバイスのデジタル・ツイン・インスタンスを認証する方法について説明します。

相互TLS (mTLS)は、クライアントとサーバーの両方が通信中に互いのアイデンティティを認証することを保証するセキュリティ・プロトコルです。サーバーのみを認証する標準のTLSとは異なり、mTLSは、クライアントとサーバーの両方に有効な証明書を提示するように要求することで、信頼の層を追加します。または、テスト環境を設定している場合は、シークレットを使用してデジタル・ツイン・インスタンスを認証できます。
  1. キーの作成
  2. 認証局を作成します。
  3. 新規プライベート・キーの生成
  4. 外部で管理される証明書の作成
  5. 証明書を使用するデジタル・ツイン・インスタンスの作成
  6. デジタル・ツインのインスタンスの詳細の取得
  7. MQTTxを使用したトピックへのサブスクライブ
  8. APEXでのデバイス・データの表示
  9. デジタル・ツイン・インスタンスの証明書のローテーション

ベストプラクティス

開始する前に

必要な権限があることを確認してください。管理者は、必要なポリシーを作成してアクセス権を付与します。詳細は、証明書に必要なポリシーについては前提条件を、IoTリソースに必要なポリシーについてはInternet of Things (IoT)プラットフォームのポリシー詳細を参照してください。

証明書ポリシー

認証に証明書を使用する場合は、デジタル・ツイン・インスタンスを作成するときに、IoTドメインが証明書を読み取ることができるように、次のポリシーが必要です。

IoTユーザーは、IoTドメインの特定のコンパートメント内の証明書を読み取ります:
Allow any-user to {CERTIFICATE_BUNDLE_READ, CERTIFICATE_READ} in compartment <compartment-name> where request.principal.type = 'iotdomain'
Allow any-user to {CERTIFICATE_AUTHORITY_BUNDLE_READ, CERTIFICATE_AUTHORITY_READ} in compartment <compartment-name> where request.principal.type = 'iotdomain'
Allow any-user to {CABUNDLE_READ} in compartment <compartment-name> where request.principal.type = 'iotdomain'

ステップ1: キーの作成

Oracle Cloud Infrastructure (OCI)には、ハードウェアで保護された対称暗号化キーが存在する必要があります。マスター暗号化キーがあるかどうかを確認するか、新しいキーを作成するには:

  1. 「アイデンティティとセキュリティ」に移動し、「Vault」を選択します。
  2. IoTリソースに使用するコンパートメントを選択します。
  3. キーを作成するには、「キーの作成」を選択し、マスター暗号化キーの作成の手順に従います。
  4. または、「Vaults」のリストから、使用するVaultの横にある「Actions」メニューを選択し、「View Vault Details」を選択します。
  5. 「マスター暗号化キー」を選択して、「キー」を表示します。「キー詳細の表示」を選択して「保護モード」を検索し、それがHSM (ハードウェア・セキュリティ・モジュール)であることを確認します。

ステップ2: 認証局の作成

証明書サービスを使用して、ルート認証局(CA)または下位CAを作成します。詳細は、認証局の作成を参照してください。

このタスク例では、下位CAを使用して外部で管理する秘密キーを使用して証明書を発行する方法について説明します。

従属CAを作成するには、すでにルートCAが必要です。

  1. 適切なポリシーを使用して管理者としてログインし、これらのアクションを実行します。CAを作成するには、適切なレベルのセキュリティ・アクセス権が必要です。
  2. 「認証局」リスト・ページで、「認証局の作成」を選択します。リスト・ページの検索に関するヘルプが必要な場合は、認証局のリストを参照してください。
  3. 「コンパートメント」を選択し、CAを作成するコンパートメントを選択します。
  4. 「認証局タイプ」で、「下位認証局」タイプ(他のCAを含む階層内のルートCAではないCA)を選択します。
  5. (オプション) CAの一意の表示名前を入力します。この名前を使用すると、管理目的でCAを識別できますが、CA証明書の一部として表示されません。機密情報を入力しないでください。
    ノート

    テナンシ内の2つのCAは、削除保留中のCAを含め、同じ名前を共有できません。
  6. (オプション)タグを適用するには、「タグ付けオプションの表示」を選択します。タグの詳細は、リソース・タグを参照してください。
  7. 「次へ」を選択します。
  8. 件名情報を入力します。サブジェクト情報には、少なくともCA証明書の所有者を識別するための共通名(CN)が含まれます。証明書の使用目的に応じて、サブジェクトは個人、組織、コンピュータ・エンドポイントまたはデバイスを識別します。サブジェクト情報の形式は、RFC 5280標準に準拠している必要があります。ワイルドカードを使用して、複数のドメイン名またはサブドメイン名の証明書を発行できます。
  9. 「次へ」を選択します。
  10. 「認可構成」で、CA証明書に使用する暗号化キーを含むボールトを確認または選択します。オプションで、「コンパートメントの変更」を選択して別のコンパートメントを指定します。ボールトの作成と管理の詳細は、「ボールトの管理」を参照してください。
  11. 「キー」で、使用するボールト内のキーをクリックします。証明書では非対称キーのみがサポートされるため、リストにはボールト内の非対称キーのみが含まれます。Rivest-Shamir-Adleman(RSA)キーから、2,048ビットまたは4,096ビットを選択できます。また、楕円曲線IDがNIST_P384の楕円曲線暗号デジタル署名アルゴリズム(ECDSA)キーを選択することもできます。具体的に言うと、このリストには、ハードウェア・セキュリティ・モジュール(HSM)によって保護されているこれらのタイプの非対称キーのみが含まれます。証明書では、ソフトウェア保護されたキーの使用はサポートされません。キーの作成および管理の詳細は、キーの管理を参照してください。
  12. 「署名アルゴリズム」で、キー・アルゴリズム・ファミリに応じて、次のいずれかのオプションを選択します。
    • SHA256_WITH_RSA: SHA-256ハッシュ関数を使用したRSSAキー
    • SHA384_WITH_RSA: SHA-384ハッシュ関数を使用したRSSAキー
    • SHA512_WITH_RSA: SHA-512ハッシュ関数を使用したRSSAキー
    • SHA256_WITH_ECDSA: SHA-256ハッシュ関数を使用したECDSAキー
    • SHA384_WITH_ECDSA: SHA-384ハッシュ関数を使用したECDSAキー
    • SHA512_WITH_ECDSA: SHA-512ハッシュ関数を使用したECDSAキー
  13. 「次へ」を選択します。
  14. 有効期限ルールを構成します。「証明書の最大有効期間(日数)」で、このCAによって発行された証明書を有効化できる最大日数を指定します。有効期間は90日以内にすることを強くお薦めします。
  15. 「失効構成」ページで、証明書失効リスト(CRL)を構成しない場合は、「失効のスキップ」チェック・ボックスを選択します。
  16. 「次へ」を選択します。
  17. 情報が正しいことを確認し、「認証局の作成」を選択します。証明書関連のリソースの作成には数分かかる場合があります。
  18. 認証局が正常に作成された場合は、サマリーの詳細が表示されます。

ステップ3: 新規秘密キーの生成

OpenSSLを使用して、秘密キーと証明書署名リクエスト(CSR)を作成します。

ノート

セキュリティのため、キーを非公開にし、外部でキーを共有しないように、デバイスでこのステップを実行することを検討してください。
  1. このコマンドを使用して、新しい秘密キーprivate.pemと、RSA 2048ビット暗号化を使用した証明書署名リクエストcsr.pemを生成します。この例では、パスワード保護なしで指定し、v3_req拡張子を使用する-nodesパラメータの使用方法を示します。
    openssl req -nodes -newkey rsa:2048 -keyout private.pem -out csr.pem -extensions v3_req
    ノート

    Linuxを使用している場合、デフォルトでは、OpenSSL.cnfファイルが拡張子をコメント・アウトします。たとえば、OpenSSL構成ファイルに次のようなものが表示された場合: /etc/pki/tls/openssl.cnf
     # req_extensions = v3_req # The extensions to add to a certificate request
    次に、#を削除して拡張子をコメント・アウトし、ファイルは次のようになります。
    req_extensions = v3_req  # The extensions to add to a certificate request
    OpenSSLがextensions v3_reqを使用していることを確認するために、出力に次が含まれていることを確認できます。
    X509v3 extensions:
        X509v3 Basic Constraints: critical
            CA:FALSE
  2. この例は、証明書リクエストの入力フィールドと値の例を示しています。証明書レポートに組み込む情報を識別名(DN)として入力します。

    共通名を入力します。共通名は、「証明書の詳細」ページの「サブジェクト情報」タブ、ステップ8の「認証局の作成」を参照するか、証明書の詳細ページの検索方法については、「証明書のリスト」を参照してください。
    Country Name (2 letter code) []: US
    State or Province Name (full name) [Some-State]:
    Locality Name (eg, city) []:
    Organization Name (eg, company) []:
    Organizational Unit Name (eg, section) []:
    Common Name (Enter common name from the certificate details.) []:common-name
    Email Address [your@email.com]:
    
    Please enter the following 'extra' attributes
    to be sent with your certificate request
    A challenge password []:
    An optional company name []:

ステップ4: 外部で管理される証明書の作成

証明書をインストールする予定のサーバーで証明書署名リクエスト(CSR)と秘密キーを生成してから、そのCSLをCAに送信し、証明書を発行することもできます。この場合、秘密キーは外部で管理します。

このタスクでは、外部で管理する秘密キーを持つ証明書を発行する方法について説明します。証明書を使用するその他の方法の詳細は、「外部で管理する証明書の作成」および「証明書の管理」を参照してください。
  1. コンソールで、ナビゲーション・メニューを開き、「アイデンティティとセキュリティ」を選択します。
  2. 「証明書」リスト・ページに、特定のコンパートメントの認証局のリストが表示されます。
  3. 作業する証明書を検索し、行の最後にある「アクション」メニューを選択します。
  4. 「発行証明書」を選択します。
  5. 「証明書タイプ」で、外部のサード・パーティCAによって管理される証明書サービスのCAから証明を発行するには、「内部CAによって発行され、外部に管理」を選択します。
  6. 証明書の一意の表示名前を入力します。機密情報を入力しないでください。
    ノート

    テナンシ内の2つの証明書が同じ名前(削除保留中の証明書を含む)を共有することはできません。
  7. (オプション) 説明を入力して、証明書を識別しやすくします。機密情報を入力しないでください。
  8. サードパーティCAが管理する証明書の場合、サブジェクト情報を指定する必要はありません。かわりに、「次へ」を選択します。
  9. 「証明書署名リクエスト」で、「ファイルのアップロード」を選択して証明書の内容を指定し、「1つ選択」を選択して証明書をPEM形式のファイルとしてのアップロードします。
  10. または、「コンテンツの貼付け」を選択し、テキスト・ボックスを選択して証明書の内容を直接貼り付けます。
  11. 「次へ」を選択します。
  12. 証明書サービスで管理されない証明書の自動更新は構成できません。「次へ」を選択して続行します。
  13. サマリー情報が正しいことを確認し、「証明書の作成」を選択します。
  14. 「証明書の詳細」ページがオープンします。「バージョン」で、表示する証明書の名前を検索し、行の最後にある「アクション」メニューに移動して、「コンテンツの表示」を選択します。詳細は、証明書の詳細の表示を参照してください。
  15. 「ダウンロード」を選択し、「証明書PEM」ファイルを「保存」します。
  16. 証明書の詳細ページで、「サブジェクト情報」タブに移動し、次のステップで使用する証明書の「共通名」をコピーします。

ステップ5: 証明書を使用するデジタル・ツイン・インスタンスの作成

データを送信するデバイスを認証するには、前のステップで作成した--auth-idパラメータおよび<certificate-OCID>を使用して、デジタル・ツイン・インスタンスを作成します。

このコマンドおよびパラメータを使用して、デジタル・ツイン・インスタンスを作成します。<common-name-for-the-certificate>を置き換えます。<certificate-OCID>を環境の証明書OCIDに置き換えます。証明書の詳細でこれらの値を検索します。詳細は、証明書の詳細の表示を参照してください:

oci iot digital-twin-instance create --iot-domain-id <iot-domain-OCID> --auth-id <certificate-OCID> --external-key <common-name-from-certificate-details>

CLIパラメータの完全なリストは、oci iot digital-twin-instance createを参照し、詳細はデジタル・ツイン・インスタンスの作成を参照してください。

オプションのステップ6: デジタル・ツインのインスタンス詳細の取得

このコマンドを使用して、デジタル・ツイン・インスタンスの詳細を表示します。レスポンスには、デジタル・ツインのインスタンスOCID、認証IDおよび外部キーが含まれます。
oci iot digital-twin-instance get --digital-twin-instance-id <digital-twin-instance-OCID>
詳細は、デジタル・ツインのインスタンス詳細の取得を参照してください。

ステップ7: データの送信

シナリオに応じて、MQTTS、HTTPSまたはWebSocketを使用してデジタル・ツイン・インスタンスに接続できます。シナリオの例は、Connecting a Deviceを参照してください。

  • Curlの使用

    POSIXスタイルのシェル: このcurlコマンドは、Windowsでbash、zsh、macOS Terminal、LinuxまたはGit Bashを使用して、接続をテストするサンプル・プレーン・テキスト・メッセージを送信する場合に使用します。device-cert.pemおよびdevice-key.pemを、使用している環境のファイルへのパスに置き換えます。
    curl --cert /path/device-cert.pem --key /path/device-key.pem \
    -H "Content-Type: text/plain" \
    -d "sample data 1" \
    "https://<iot-domain-short-id>.device.iot.<region>.oci.oraclecloud.com/sampletopic"

    Windows Powershell: このcurlコマンドを使用して、device-cert.pemおよびdevice-key.pemを環境の値に置き換えます。

    curl.exe --cert /path/device-cert.pem --key /path/device-key.pem \
    -H "Content-Type: text/plain" \
    -d "sample data 1" \
    "https://<iot-domain-short-id>.device.iot.<region>.oci.oraclecloud.com/sampletopic"

    「ステップ5: 証明書を使用するデジタル・ツイン・インスタンスの作成」に格納されている外部キーを使用します。シェルの引用符は、その値の一部として意図的に格納されていないかぎり、外部キーの一部ではありません。認証チェックについては、Troubleshooting Certificate Rotationを参照してください。

  • 任意のMQTTクライアントを使用して、MQTTSを使用してトピックにサブスクライブします。この例では、MQTTxを使用します。

    サンプル・データを送信し、接続をテストするには:

    1. 次のように、ホストとしてデバイスホストを入力します。
      mqtts://<domain-short-id>.device.iot.<region>.oci.oraclecloud.com
    2. ポート8883を入力します。
    3. クライアントID: your-client-ID
    4. クリーン・スタート: True
    5. トグルをオンにすると、TLSが有効になります。
    6. オプション「CAまたは自己署名証明書」を選択します。
    7. 「外部で管理される証明書の作成」のステップ15から、クライアント証明書ファイルの場所を入力します: your-certificate.pem
    8. 「新規秘密キーの生成」のステップ1から、クライアント・キー・ファイルの場所を入力します: your-private-key.pem
    9. 「接続」を選択します。

      MQTTx

      MQTTxを使用して接続します。

    10. デバイスからデータを受信するには、「新規サブスクリプション」を選択します。
    11. 「トピック」としてエンドポイントを入力します。
    12. 次の例は、Quality of Service (QoS)レベル1の/endpoints/4321トピックにパブリッシュされたメッセージを示しています。トピック:
      {
        "pulse": 300,
        "s02": 400
      }
      {
        "test": 100
      }

      MQTTxのトピックにサブスクライブします

オプションのステップ8: APEXでのIoTデータの監視

APEXでデータを表示するための構成済アクセス権で、デバイスからRAWデータが送信された場合は、このSQL文を使用して、APEXでデジタル・ツイン・インスタンスのRAWデータ・レスポンスを表示できます。
select * from <domain-short-id-from-device-host>__IOT.RAW_DATA
where digital_twin_instance_id = '<digital-twin-instance-ocid>'

デジタル・ツイン・インスタンスの証明書のローテーション

デジタル・ツイン・インスタンスが認証に下位認証局(CA)を使用する場合は、同じCAリソースOCIDでバージョンをローテーションして、インスタンスの認証ID (authId)を変更しないままにします。サポートされるローテーションのオーバーラップ中に、IoTは現在の下位CAバージョンと以前の下位CAバージョンの両方によって発行されたデバイス証明書を認証できます。

ルートCAは、デジタル・ツイン・インスタンスの認証IDとして使用できません。

証明書の変更を使用するデバイスと調整し、以前の資格証明をリタイアする前に、置換資格証明を使用して認証およびデータ取込みを検証します。

認証IDと一致するプロシージャとして、「デバイス認証に使用される下位CAのローテーション」または「デバイス認証に使用されるインポート済証明書のローテーション」を選択します。個々の証明書を更新すると、デバイス資格証明が置き換えられます。下位CAを更新すると、デバイス証明書に対して信頼できる発行者が変更されます。

デバイス認証に使用される下位CAのローテーション

デジタル・ツイン・インスタンスの認証IDを変更せずに、下位CAを更新し、デバイスを置換証明書に移行します。

この手順は、デジタル・ツイン・インスタンスの認証ID (authId)が証明書サービスの下位CAを参照する場合に適用されます。個々の証明書またはCAバンドルを参照する認証IDは対象外です。ルートCAは認証IDとして使用できません。

CAとその証明書を管理する権限があり、IoTドメインに読取り権限が保持されていることを確認します。前提条件およびこのトピックの証明書ポリシーを参照してください。

CAを変更する前にデバイス・ハンドオーバーを計画します。以前の資格情報に依存するすべてのデバイスを識別し、交換資格情報の安全な配布を整理し、移行されていないデバイスに必要な資格情報を保持します。証明書の有効性および失効は、サポートされているローテーションの重複中に引き続き適用されます。

  1. 影響を受ける各デジタル・ツイン・インスタンスで使用される下位CA OCIDを確認します。

    認証IDを確認するには、「デジタル・ツイン・インスタンスの取得」を使用します。このIDは、プロシージャ全体で変更しないでください。別のCAを作成してそのOCIDを置換するのではなく、同じ下位CAリソースでバージョンを更新します。

  2. 証明書サービスの更新手順を使用して、交換用のCAバージョンを準備します。

    新しいキー・マテリアルが必要な場合のCAのVaultキーのローテーションに関するガイダンスを含む、認証局の更新を参照してください。キーを使用する他のリソースへの影響を確認してから変更してください。交換バージョンの有効期間を設定して、計画された引渡しをカバーします。

  3. 引渡しを開始する準備が整ったら、置換下位CAバージョンを最新にします。

    バージョンを保留中としてステージングした場合は、「認証局バージョンを最新にする」を使用します。目的のバージョンがCURRENTで、前のバージョンがPREVIOUSであることを確認します。保留中のバージョンがデバイスを認証できるとは想定しないでください。

  4. 現在の下位CAバージョンを使用して交換用デバイス証明書を発行し、デバイスにセキュアにプロビジョニングします。

    このトピックの外部管理の秘密キーの例については、「新規秘密キーの生成」および「外部で管理される証明書の作成」に従います。各デバイスの証明書IDと、目的のデジタルツインインスタンスへのマッピングを保持します。交換用証明書の発行者と有効性を検証します。秘密キーを保護し、ログや共有例には含めないでください。

  5. 制御されたデバイスのセットを交換用の資格情報に切り替え、新しい接続を使用して各デバイスを確認します。

    該当する「データの送信」の例を使用して、テスト・メッセージを認証および送信します。データが目的のデジタル・ツイン・インスタンスに到達したことを確認します。既存の接続は、置換資格証明が認証できるという証拠ではありません。検証に失敗した場合は、より多くのデバイスを切り替える前に調査してください。

  6. 前の資格証明をリタイアする前に、残りのデバイスを移行し、認証および取込みを確認します。

    以前の証明書をまだ使用しているデバイスを追跡します。サポートされている重複内および証明書の有効期限前に移行を完了してください。デバイスが依然として依存している間は、証明書または発行者を取り消したり削除したりしないでください。このハンドオーバーが完了するまで、同じCAの別のローテーションを開始しないでください。

  7. 影響を受けるすべてのデバイスが交換用の資格情報で検証されたあとで、以前のデバイス資格をリタイアします。

    組織の資格証明リタイア・ポリシーに従って、デバイスおよびプロビジョニング・システムから古い資格証明を削除します。以前のCAバージョンを取り消すか削除する前に、それに依存している証明書またはリソースがないことを確認します。漏洩した資格証明を処理するには、別の緊急レスポンスが必要です。ローテーションの重複は、取り消された資格証明を引き続き信頼する理由ではありません。

デバイスは置換証明書を使用し、デジタル・ツイン・インスタンスは同じ下位CA認証OCIDを保持します。

デバイス認証に使用されるインポートされた証明書のローテーション

同じ証明書OCIDで、デバイス証明書とそれに対応する秘密キーを置き換えます。

この手順は、デジタル・ツイン・インスタンスの認証ID (authId)が証明書サービスでインポートされた個々の証明書を参照する場合に適用されます。下位CAを参照する認証IDの場合は、「デバイス認証に使用される下位CAのローテーション」を使用します。CAバンドルは、どちらのプロシージャでもカバーされません。

証明書を更新できること、およびIoTドメインがそれを読み取ることができることを確認します。アクティブ・バージョンを変更する前に、置換資格証明のセキュアな分散を計画します。

  1. デジタル・ツイン・インスタンスの認証IDおよび外部キーを確認します。

    「デジタル・ツイン・インスタンスの取得」を使用して、既存の証明書OCIDを確認します。引き渡し中は、この認証IDは変更されません。

  2. 交換デバイス証明書、その一致する秘密鍵、および必要な発行者チェーンを取得します。

    証明書の共通名は変更せず、インスタンスの外部キーと一致したままにします。交換用証明書の発行者と有効期間を確認します。ストレージおよび配布時に秘密キーを保護します。

  3. 既存のインポート済証明書リソースを置換PEMファイルで更新します。

    「証明書PEMの更新」に従います。別のOCIDを持つ別の証明書をインポートするのではなく、同じリソースを更新します。置換証明書、一致する秘密キーおよび必要なチェーンを指定します。

  4. デバイス上でアクティブ化する前に、交換用証明書のバージョンが最新であることを確認します。

    置換が最新でない場合は、Making a Certificate Version Currentに従います。目的のバージョンがCURRENTで、前のバージョンがPREVIOUSであることを確認します。バージョンをステージングしても、認証できるかどうかは確認されません。

  5. 交換用の証明書と一致する秘密キーをプロビジョニングし、新しいデバイス接続およびデータ取込みを検証します。

    テスト・クライアントの既存のセッションを切断し、両方の置換ファイルを構成します。TLSサーバー証明書検証を有効なままにします。該当する「データの送信」の例を使用し、テスト・メッセージが目的のデジタル・ツイン・インスタンスに到達することを確認します。コネクテッド・クライアントのみでは、取込みが成功した証明ではありません。

  6. 前の資格証明をリタイアする前に、ハンドオーバーを完了してください。

    サポートされるオーバーラップ期間および証明書の有効期間内に置換資格を持つ、影響を受けるすべてのデバイスを確認します。以前のバージョンに依存しているデバイスを追跡します。移行後、組織のリタイア・ポリシーに従います。証明書バージョンを取り消すか削除する前に、依存関係を確認してください。ハンドオーバーが完了するまで、同じ証明書の別のローテーションを開始しないでください。

デバイスは置換証明書と秘密キーを使用し、デジタル・ツイン・インスタンスは同じ証明書認証OCIDを保持します。

証明書のローテーションに関するFAQ

OCI証明書は、CURRENT、PREVIOUS、PENDINGなどのローテーション状態を証明書バージョンに割り当てます。これらの状態とバージョン昇格の背景については、Certificate Versions and Rotation Statesを参照してください。IoT認証は、ここで説明する重複および妥当性の要件にも依存します。

subordinate-CAプロシージャは認証IDを変更しますか。
番号このプロシージャは、同じ下位CAのバージョンをローテーションし、そのリソースOCIDをauthIdに保持します。そのリソースを別のCA OCIDで置き換える操作は同じではありません。「デバイス認証に使用される下位CAのローテーション」を参照してください。
認証IDとしてルートCAを使用できますか。
番号ルートCAは発行者階層の一部にできますが、デジタル・ツイン・インスタンスのauthIdにすることはできません。下位CAまたはデバイス認証に使用される証明書にルートCA OCIDを置換しないでください。
CAを更新すると、デバイスの資格証明が更新されますか。
番号交換デバイス証明書とその対応する秘密キーを安全にプロビジョニングしてから、新しい接続および正常な取込みを検証します。CAバージョンの変更のみでは、デバイス資格証明は配布されません。
認証IDが証明書OCIDの場合、どの手順が適用されますか。
インポートされた個々の証明書については、Rotating an Imported Certificate Used for Device Authenticationを参照してください。このプロシージャは、同じ証明書OCIDの証明書およびそれと一致する秘密キーを更新します。下位CAプロシージャは、かわりに、デバイス証明書の認証に使用される発行者を更新します。どちらの手順もCAバンドルには対応していません。
以前の資格証明はいつリタイアできますか。
サポートされる重複期間および証明書の有効期間内に、リタイア前に、影響を受けるすべてのデバイスと交換用の資格を確認してください。発行者を取消しまたは削除する前に、依存関係を確認してください。オーバーラップによって、期限切れの資格証明または失効した資格証明が有効になることはなく、既存の接続では置換資格証明が機能することを証明していません。

共通の質問は、「資格証明のローテーションに関するFAQ」を参照してください。

証明書のローテーションのトラブルシューティング

デバイスは、資格証明または発行者バージョンの変更後に証明書認証に失敗します。

認証ID、アクティブな発行者バージョン、デバイス・アイデンティティ、証明書チェーンまたはクライアント資格証明が一致しない場合があります。

  1. authIdが下位CAを参照するか、個々の証明書を参照するかを確認します。そのリソースタイプの手順に従います。ルートCAは有効な認証IDではありません。
  2. 下位CAプロシージャの場合は、置換CAバージョンがCURRENTであり、置換デバイス証明書が目的のバージョンによって発行されたことを確認します。証明書の有効性、失効ステータスおよび必要な発行者チェーンを確認します。
  3. クライアントが、失効したファイルではなく、置換証明書とそれと一致する秘密キーをロードすることを確認します。証明書の共通名をインスタンスの外部キーと照合し、目的のドメイン・エンドポイントを確認します。証明書を使用するデジタル・ツイン・インスタンスの作成を参照してください。
  4. 新規接続をテストし、「データの送信」を使用してデータを送信します。TLS検証を有効なままにします。既存のセッションまたは繰り返し行われる自動再接続を、資格証明の正常なハンドオーバーの証明として扱わないでください。
  5. 前の資格証明のみが失敗した場合は、その有効性、失効ステータス、発行者バージョンおよびサポートされている重複を確認してください。これ以上資格証明を削除しないか、再度ローテーションして調査してください。

永続的な障害の場合は、Troubleshooting Device Credential Rotationのエビデンスチェックリストを使用します。診断出力に秘密キーを含めないでください。