デバイス証明書

デバイスは、mTLSを使用してREST（ポート8443）、MQTT経由でThings Cloudに対してX.509証明書で認証できます。

各テナントは、ベースCA証明書をトラストアンカーとしてアップロードすることで、誰を信頼するかを個別に定義します。これらは{{}}インスタンス全体で一意である必要があります。証明書を使用してプラットフォームに接続するデバイスは、テナントID、ユーザー名、パスワードを提供する必要はありません。認証情報は証明書から取得されます。

HTTP

最近まで、HTTP経由でmTLSを利用したいデバイスは、X.509証明書を用いて定義されたMQTTエンドポイント（デバイスアクセス トークンAPI）で認証し、JWTセッショントークンを生成する必要がありました。このセッショントークンは、その後のHTTPリクエストでThings Cloudへの認証に使用できます。この方法も引き続きサポートされていますが、将来的には廃止予定です。ダイレクトなHTTP接続の利用を推奨します。

MQTT

デバイスは、プラットフォームのMQTTインターフェースを使用して通信できますが、WebSocket上のMQTTはサポートされていません。Things Cloudプラットフォームは、デバイスがポート8883でSSLを使用して接続することを想定しています。

前提条件

このチュートリアルを実行するために、以下の前提条件が満たされているか確認してください。

  • Things Cloudにアクセスするための有効なテナント、ユーザー、およびパスワードがあること。
  • コマンドラインツールCURLがシステムにインストールされていること。

証明書を使用してデバイスを接続するための一般的な要件

  • CA 証明書は自己署名証明書である場合もあります。
  • 証明書は X.509 バージョン 3 証明書としてアップロードする必要があります。
  • アップロードされた証明書には BasicConstraints:[CA:true] が設定されている必要があります。
  • デバイスはThings Cloudサーバー証明書を信頼する必要があります。
  • デバイスで使用される証明書には、アップロードされた CA 証明書を含む証明書チェーンが含まれている必要があります。
  • デバイス証明書のみが提供された場合、直近の発行者証明書はプラットフォームの信頼ストアにアップロードする必要があります。
  • デバイスで使用される証明書は、アップロードされた CA 証明書、またはアップロードされた CA 証明書によって署名された中間証明書によって署名される必要があります。

証明書を使用したデバイスの登録

Things Cloudでは、証明書を使って接続するデバイスを登録する方法として、以下の2つの方法をサポートしています。

自動登録

デバイス証明書が、true の値を持つ autoRegistrationEnabled フラグでThings Cloudプラットフォームにアップロードされた信頼できる証明書から派生する場合、デバイスのユーザーは最初の MQTT コール中に作成されます。 アップロードされた証明書に対して自動登録を有効にする必要があります。 自動登録が有効になっていない場合は、一括登録を使用する必要があります (下記参照)。 UIでアップロードされた証明書の自動登録フィールドを管理するには、信頼できる証明書の管理を参照してください。

device_userは、以下の条件が満たされるときにAPIが初めて呼び出されたときに作成されます。

  • 信頼できる証明書がプラットフォームにアップロードされていること。
  • 自動登録が有効になっていること。
  • デバイス証明書がThings Cloudにアップロードされた信頼される証明書から取得していること。

一括登録

デバイスのユーザーは、デバイス管理アプリケーションの標準的な一括登録からも作成することができます。

一括登録で使用するCSVファイルは、Things Cloud OpenAPI仕様仕様の一括デバイス認証情報リクエストを作成するに記載されている要件を満たしている必要があります。また、CSVファイルには、CERTIFICATES の値を持つAUTH_TYPE列が追加されており、CREDENTIALS列が存在しないか、値が空であることが必要です。

単一登録

単一登録は、認証に証明書を使用するデバイスではサポートされていません。

備考
デバイスの登録中に、デバイスとプラットフォームの通信に必要なデバイス ユーザーが作成されます。

X.509証明書の概要

X.509 は公開鍵証明書を定義する標準であり、安全な接続とデータ転送を提供するために SSL プロトコルで一般的に使用されます。 バージョン 3 が 1995 年以降の最新です。

X.509 証明書の一般的な目的は、ID を鍵のペアにバインドすることです。公開鍵は証明書の一部として公開され、秘密鍵は証明書の所有者のみが知ることができます。 このような鍵のペアは、現在では安全であると考えられている非対称鍵アルゴリズムで作成する必要があります。 このようなアルゴリズムの例として、少なくとも2,048ビットのキーサイズを持つRSAがあります。 1,024ビット以下は、もはや安全とは見なされません。 秘密鍵は、2つの方法で使用することができます。

  • メッセージが証明書の所有者によって送信されたことを証明する 所有者は、秘密鍵を使用してメッセージを暗号化して送信します。 その後、受信者は送信者の公開鍵を使用してそれを復号化できます。 復号化されたメッセージが期待通りであれば、それが証明書の所有者によって送信されたものであると確信できます。
  • 証明書所有者のみを対象としたメッセージを読む 誰かが受信者の公開鍵を使用してメッセージを暗号化した場合、秘密鍵の所有者だけがメッセージを復号化できます。 何らかの方法でメッセージを傍受した第三者はメッセージを読むことができません。

すべての証明書は自己署名することも、別の証明書で署名することもできます。 証明書が自己署名であるかどうかを確認するには、証明書の「発行者名」フィールドと「サブジェクト名」フィールドを確認します。 この2つが同じであれば自己署名証明書であることを意味し、そうでなければ、証明書は発行者によって署名されていると主張します。 発行者が本当に証明書に署名したかどうかを確認するには、証明書の「署名」フィールドを確認する必要があります。 発行者の公開鍵で復号化した後、署名は署名された証明書のデータと一致するはずです。 別の人が証明書に署名するということは、発行者の証明書が信頼できる場合は、署名された証明書も信頼できることを意味します。

例えば、プラットフォームがお客さまの証明書を信頼しており、お客さまが個別の証明書を持つ 20 台のデバイスを持っている場合、それらを 1 つずつアップロードする必要はありません。

これらのデバイス証明書がお客さまの証明書によって署名されている場合、プラットフォームはそれらも信頼する必要があります。 この場合、すべてのデバイスは、SSL ハンドシェイク中に独自の証明書だけでなく、証明書のチェーン全体 (いわゆる信頼のチェーン) を送信する必要があります。

証明書のチェーンは、デバイスに属する証明書から始まり、プラットフォームによって信頼される CA 証明書に到達するまで、使用されるすべての中間証明書を経由します。 通常、証明書のチェーンには信頼できる CA 証明書が含まれている必要はないため、CA によって直接署名された証明書で終わることができます。 しかし、Things Cloud プラットフォームでは、証明書チェーンに信頼できる CA 証明書を提供することも必要です。

証明書のチェーンを提供すると、プラットフォームはチェーン内のすべての証明書の署名を検証して、デバイス証明書が信頼された証明書によって直接または間接的に署名されていることを確認できます。 証明書のチェーンの長さは異なる場合があるため、プラットフォームが証明書 A を信頼し、証明書 B が A によって署名され、証明書 C が B によって署名されている場合、証明書 C も信頼されます。 ただし、注意すべき点がいくつかあります。

  • 別の証明書の署名に使用されるすべての証明書には、拡張の「CA:TRUE」が含まれている必要があります。
  • 証明書のチェーンの長さは、証明書の拡張「pathlen」によって制限できます。 この拡張機能は、デバイス証明書とその拡張機能を持つ証明書との間のチェーンに配置できる他の CA 証明書の量を制限します。例えば、パス長の最小値を持つ有効な証明書のチェーンは次のようになります。 「A (CA:TRUE, pathlen: 2) -> B (CA:TRUE, pathlen: 1) -> C (CA:TRUE, pathlen: 0) -> D (device with CA:FALSE)」

バージョン3のX.509証明書の構造は、以下のようになります。

  • Version - x.509 証明書のバージョン番号
  • Serial Number - 発行者が作成する証明書ごとに作成される一意のシリアル番号
  • Issuer - 発行者の識別名
  • Not Before - 証明書が有効になった日付
  • Not After - 証明書の有効期限
  • Subject - 証明書の所有者の識別名
  • Public Key Algorithm - 公開鍵の生成に使用されるアルゴリズム
  • Subject Public Key - 公開鍵の値
  • Certificate Signature Algorithm - 証明書署名の生成に使用されるアルゴリズム
  • Certificate Signature - 証明書データを発行者の秘密鍵で暗号化することにより生成される証明書署名
  • Extensions(任意) - 例として、証明書が CA である場合、別の証明書の署名に使用できることを意味するなど、さまざまな情報を提供する役割を担っています。X.509 のバージョン 3 で追加されました。
  • Issuer Unique Identifier(任意) - 発行者名の再利用の可能性に対応するため、証明書に記載することができます。
  • Subject Unique Identifier(任意) - サブジェクト名の再利用の可能性に対応するため、証明書に記載することができます。

X.509 証明書による認証がどのように機能するかを示すために、簡略化された相互 SSL ハンドシェイクの例を示します。

簡略化された相互SSLハンドシェイク

サーバーは、クライアントの公開鍵を使用してメッセージの暗号化されたコピーを復号化した後、クライアントが送信した証明書の所有者であることを認識します。 サーバーが正しいセッションキーを使用している場合、クライアントは、サーバーが秘密鍵を使用して証明書を復号化したことを意味するため、送信した証明書の所有者がサーバーであることを認識します。 ユーザー名とパスワードによる Basic 認証では、ユーザーを認証するためにパスワードをネットワーク経由で送信する必要があります。 証明書を使用する場合、秘密鍵は送信されないため、証明書の使用はユーザー名とパスワードによる Basic 認証よりもはるかに安全になります。

X.509証明書には3つの重要な用語があり、これからX.509証明書を使う人は誰もが知っておく必要があります。

  • キーストアは、相互 SSL ハンドシェイクでデバイス自体を認証するために使用するファイルです。 つまり、キーストアには、デバイスで使用される証明書のチェーンとデバイスの秘密鍵が含まれています。
  • トラストストアは、信頼できるすべての証明書が含まれるファイルです。サーバーまたはデバイスは、トラストストアからの証明書を使用するもののみと接続を確立します。 証明書のチェーンを使用する場合、接続を確立するにはチェーン内の証明書のうち 1 つだけを信頼する必要があります。
  • 最も単純な意味での認証局 (CA) は、証明書に署名する機関です。

キーストアとトラストストアは同じファイルに保存できますが、セキュリティ上の理由から、別々に保存することをお勧めします。 トラストストアには公開データが含まれ、キーストアには所有者のみが知る必要がある秘密鍵が含まれます。 これらのファイルの最も一般的な形式は次のとおりです。

  • PKCS12 (Public Key Cryptography Standards, version 12)：OpenSSL ツールキットを使用して生成できます。
  • JKS (Java KeyStore) ：Java Keytoolで生成できます。

証明書の生成と署名

証明書を生成するには、OpenSSL ツールキットを使用します。 まだインストールしていない場合は、次のWebサイトからダウンロードすることができます。
https://www.openssl.org/source/

自己署名 CA 証明書の作成

  1. ルート証明書と署名構成用のディレクトリを作成します。次に例を示します。
    mkdir /home/user/Desktop/caCertificate

  2. 作成したディレクトリに移動し、CA 証明書の構成ファイルを作成します。
    touch caConfig.cnf

  3. CAによって署名された証明書の履歴を保持するためのデータベースファイルを作成します。
    touch database.txt

  4. 署名付き証明書の識別に使用される初期シリアル番号を含むシリアルファイルを作成します。このシリアルを署名付き証明書に割り当てると、このファイル内の値が自動的に増加します。
    echo 1000 > serial

  5. 署名付き証明書と証明書失効リスト用のサブディレクトリを作成します。
    mkdir deviceCertificates crl

  6. 設定ファイルに記入します。 これは設定例であり、ディレクトリ dir を独自のディレクトリに変更した後、テストに使用することができます。本番環境で使用する場合は、まずセキュリティの専門家に相談してください。

     [ ca ]
 default_ca = CA_default
 [ CA_default ]
 # Directory and file locations.
 dir               = /home/user/Desktop/caCertificate
 certs             = $dir # directory where the CA certificate will be stored.
 crl_dir           = $dir/crl # directory where the certificate revocation list will be stored.
 new_certs_dir     = $dir/deviceCertificates # directory where certificates signed by CA certificate will be stored.
 database          = $dir/database.txt # database file, where the history of the certificates signing operations will be stored.
 serial            = $dir/serial # directory to the file, which stores next value that will be assigned to signed certificate.

 # The CA key and CA certificate for signing other certificates.
 private_key       = $dir/caKey.pem # CA private key which will be used for signing certificates.
 certificate       = $dir/caCert.pem # CA certificate, which will be the issuer of signed certificate.

 default_md        = sha256 # hash function
 default_days      = 375 # default number of days for which the certificate will be valid since the date of its generation.
 preserve          = no # if set to 'no' then it will determine the same order of the distinguished name in every signed certificate.
 policy            = signing_policy # the name of the tag in this file that specifies the fields of the certificate. The fields must be filled in or even match the CA certificate values to be signed.

 # For certificate revocation lists.
 crl               = $crl_dir/caCrl.pem # CA certificate revocation list
 crlnumber         = $crl_dir/crlnumber # serial, but for the certificate revocation list
 crl_extensions    = crl_ext # the name of the tag in this file, which specifies certificates revocation list extensions, which will be added to the certificate revocation by default.
 default_crl_days  = 30 # default number of days for which the certificate revocation list will be valid since the date of its generation. After that date it should be updated to see if there are new entries on the list.

 [ req ]
 default_bits        = 4096 # default key size in bits.
 distinguished_name  = req_distinguished_name # the name of the tag in this file, which specifies certificates fields description during certificate creation and eventually set some default values.
 string_mask         = utf8only # permitted string type mask.
 default_md          = sha256 # hash function.
 x509_extensions     = v3_ca # the name of the tag in this file, which specifies certificates extensions, which will be added to the created certificate by default.

 # descriptions and default values of the created certificate fields.
 [ req_distinguished_name ]
 countryName                     = Country Name (2 letter code)
 stateOrProvinceName             = State or Province Name
 localityName                    = Locality Name
 organizationName                = Organization Name
 organizationalUnitName          = Organizational Unit Name
 commonName                      = Common Name
 emailAddress                    = Email Address

 # A default value for each field can be set by adding an extra line with field name and postfix "_default". For example: "countryName_default = PL". If you add this line here, then leaving country name empty during certificate creation will result in the value "PL" being used. If the default value was specified there, but during certificate creation you do not want to use this value, then instead use "." as the value. It will leave the value empty and not use the default.

 # default extensions for the CA certificate.
 [ v3_ca ]
 subjectKeyIdentifier = hash # subject key value will be calculated using hash funtion. It's the recommended setting by PKIX.
 authorityKeyIdentifier = keyid:always,issuer # The subject key identifier will be copied from the parent certificate. It's the recommended setting by PKIX.
 basicConstraints = critical, CA:true, pathlen:10 # "critical" specifies that the extension is important and must be read by the platform. CA says if it is the CA certificate so it can be used to sign different certificates. "pathlen" specifies the maximum path length between this certificate and the device certificate in the chain of certificates during authentication. Path length is set here only to show how it is done. If you do not want to specify max path length, you can keep only the "basicConstraints = critical, CA:true" part here.
 keyUsage = digitalSignature, cRLSign, keyCertSign # specifies permitted key usages.

 # Default extensions for the device certificate. This tag is not used directly anywhere in this file, but will be used from the command line to create signed certificate with "-extensions v3_signed" parameter.
 [ v3_signed ]
 subjectKeyIdentifier = hash
 authorityKeyIdentifier = keyid,issuer
 basicConstraints = critical, CA:false
 keyUsage = nonRepudiation, digitalSignature, keyEncipherment

 # default extensions for certificate revocation list
 [ crl_ext ]
 authorityKeyIdentifier=keyid:always

 # Policy of certificates signing. It specifies which certificate fields must be filled in during certificate creation. There are three possible values here:
 # "optional" - field value can be empty
 # "supplied" - field value must be filled in
 # "match" - signed certificate field value must match the CA certificate value to be created
 [ signing_policy ]
 countryName             = optional
 stateOrProvinceName     = optional
 organizationName        = optional
 organizationalUnitName  = optional
 commonName              = supplied # every certificate should have a unique common name, so this value should not be changed.
 emailAddress            = optional

  7. 暗号化方式が aes256 で、長さが 2,048 ビット以上の秘密鍵を作成します。作成時には鍵のパスワードを設定するよう求められます。
    openssl genrsa -aes256 -out caKey.pem 4096

  8. 構成ファイルの仕様を使用して自己署名証明書を作成します。「days」パラメータは、この証明書が生成されてから有効期限を示すため、お好みに応じて設定してください。
    openssl req -config caConfig.cnf -key caKey.pem -new -x509 -days 7300 -sha256 -extensions v3_ca -out caCert.pem

  9. 次のコマンドを使用して、作成した証明書を印刷できます。
    openssl x509 -noout -text -in caCert.pem

中間証明書の作成

中間証明書は CA 証明書によって署名されますが、デバイス証明書の署名にも使用されます。 このステップは任意です。 すべてのデバイス証明書を1つの共通のCA証明書で署名しても問題ない場合は、このステップをスキップできます。 ただし、CA 証明書とデバイス証明書の間にいくつかの証明書が必要な場合は、このステップを実行することが適切です。Things Cloudクラウドでは、証明書のチェーンの最大長が現在10に制限されていることに注意してください。

この動作は、プラットフォーム全体の構成設定を変更し、証明書チェーンの許容最大長を 10 より長く (または短く) 増やす (または減らす) ことで、専用インストールの場合に変更できます。 長さが 2 を超えるチェーンを使用する場合は、DOS 攻撃からサービスを保護するために所有証明機能を使用することを強くお勧めします。

中間証明書を作成します。

  1. caCertificateパス内に中間証明書用の新しいディレクトリを作成します： mkdir intermediateCertificate
  2. このディレクトリに移動し、中間証明書用の構成ファイルを作成します： touch intermediateConfig.cnf
  3. 中間証明書によって署名された証明書の履歴を保持するためのデータベースファイルを作成します：touch database.txt
  4. 署名付き証明書を識別するために使用される、初期シリアル番号を含むシリアルファイルを作成します: echo 1000 > serial
  5. 署名付き証明書と証明書失効リスト用のサブディレクトリを作成します: mkdir deviceCertificates crl
  6. CA 構成と同じように構成ファイルに記入しますが、一般ディレクトリ (「dir」) をintermediateCertificate フォルダに変更することを忘れないでください。また、private_key、certificates、crlの名前を、現在の「ca」プレフィクスから「intermediate」プレフィクスに変更しなければなりません（例： caKey.pem -> intermediateKey.pem）。次のステップで、このプレフィクスを持つファイルを生成するためです。
  7. 中間証明書の秘密鍵を生成します: openssl genrsa -aes256 -out intermediateKey.pem 4096
  8. 証明書署名リクエストを生成します: openssl req -config intermediateConfig.cnf -new -sha256 -key intermediateKey.pem -out intermediateCsr.pem
  9. caCertificate ディレクトリに移動し、署名付き中間証明書を生成します。構成ファイルで指定された秘密鍵が証明書の署名に使用されるため、ここでは CA 構成を使用する必要があります: openssl ca -config caConfig.cnf -extensions v3_ca -days 3650 -notext -md sha256 -in intermediateCertificate/intermediateCsr.pem -out intermediateCertificate/intermediateCert.pem
  10. 生成された証明書が CA によって正しく署名されているかどうかを確認します: openssl verify -CAfile caCert.pem intermediateCertificate/intermediateCert.pem

CA または中間認証局によって署名されたデバイス証明書の作成

  1. デバイス証明書の署名にどちらが使用されているかに応じて、caCertificate またはintermediateCertificate のディレクトリに移動します。
  2. 新しい証明書の秘密鍵を生成します: openssl genrsa -aes256 -out deviceCertificates/deviceKey.pem 4096
  3. 証明書署名リクエストを生成します (intermediateCertificate ディレクトリにいる場合は、「caConfig.cnf」を「intermediateConfig.cnf」に変更します): openssl req -config caConfig.cnf -new -sha256 -key deviceCertificates/deviceKey.pem -out deviceCertificates/deviceCsr.pem コンソールで指定するように求められるデバイス証明書 commonNameは、接続中にデバイスのClientIdと一致する必要があることに注意してください。
  4. CA または中間認証局によって署名された証明書を生成します (intermediateCertificate ディレクトリにいる場合は、「caConfig.cnf」を「intermediateConfig.cnf」に変更します): openssl ca -config caConfig.cnf -extensions v3_signed -days 365 -notext -md sha256 -in deviceCertificates/deviceCsr.pem -out deviceCertificates/deviceCert.pem
  5. 生成された証明書が CA または中間認証局によって正しく署名されているかどうかを確認します (intermediateCertificate ディレクトリにいる場合は、「caCert.pem」を「intermediateCert.pem」に変更します): openssl verify -partial_chain -CAfile caCert.pem deviceCertificates/deviceCert.pem

証明書チェーンの作成

caCertificate ディレクトリに移動します。

CA 証明書を作成し、それを中間証明書の署名に使用し、中間証明書を使用してデバイス証明書の署名を行った場合は、次のコマンドを使用してチェーンを作成します。

cat intermediateCertificate/deviceCertificates/deviceCert.pem intermediateCertificate/intermediateCert.pem caCert.pem > intermediateCertificate/deviceCertificates/deviceCertChain.pem

中間証明書を使用しない場合のコマンドは次の通りです。

cat deviceCertificates/deviceCert.pem caCert.pem > deviceCertificates/deviceCertChain.pem

CA証明書とデバイス証明書の間に複数の中間証明書を使用する場合、チェーン作成時に正しい順序を保つ必要があることを忘れないでください（すべての証明書の後に、その証明書によって署名されている証明書が続く必要があります）。

キーストアとトラストストアの作成

  1. デバイスの秘密鍵と生成された証明書のチェーンを使用して、deviceCertificates ディレクトリに移動します。CA証明書とデバイス証明書の間に中間証明書を使用している場合は、caCertificate/intermediateCertificate/deviceCertificatesがパスになり、それ以外の場合は、caCertificate/deviceCertificatesになります。生成された証明書のチェーンとデバイスの秘密鍵を使用してキーストアを作成します: openssl pkcs12 -export -name devicekeyentry -inkey deviceKey.pem -in deviceCertChain.pem -out deviceKeystore.pkcs12
  2. キーストアを JKS 形式に変換する場合は、通常 Java Development Kit と一緒にダウンロードされる Java Keytool が必要になります: keytool -importkeystore -srckeystore deviceKeystore.pkcs12 -srcstoretype PKCS12 -destkeystore deviceKeystore.jks -deststoretype JKS
  3. サーバー証明書がない場合は、次のコマンドで取得します: openssl s_client -showcerts -connect <cumulocity url>:<mqtt mutual ssl port (currently 8883, but that can be changed in the future)> | openssl x509 -outform PEM > serverCertificate.pem
  4. これで、サーバー証明書を格納するトラストストアを作成することができます。これはJava Keytoolで作成する必要があります (opensslはトラストストアの作成をサポートしていないので、Java keytoolを使用しない場合は、すべての信頼できる証明書を別のPEMファイルに保持する必要があります)。 aliasは、すべてのキーストアまたはトラストストア エントリの一意の識別子であることに注意してください。これは、同じトラストストアに 2 番目の信頼できる証明書を追加する場合は、以下のコマンドのエイリアスを servercertificateから別の名前に変更する必要があることを意味します。
    • PKCS12 形式の場合: keytool -importcert -noprompt -keystore deviceTruststore.pkcs12 -alias servercertificate -file serverCertificate.pem
    • JKS 形式の場合: keytool -import -file serverCertificate.pem -alias servercertificate -keystore deviceTruststore.jks
  5. オプションとして、トラストストアの新しいファイルを作成する代わりに、作成したキーストアに信頼できる証明書を追加し、すべてを 1 つのファイルに保存できますが、これは推奨される解決策ではありません。
    • キーストアが PKCS12 形式の場合: keytool -importcert -noprompt -keystore deviceKeystore.pkcs12 -alias servercertificate -file serverCertificate.pem
    • キーストアが JKS 形式の場合: keytool -import -file serverCertificate.pem -alias servercertificate -keystore deviceKeystore.jks
  6. 次のコマンドを使用して、キーストア (またはトラストストア) の内容を確認できます: keytool -list -v -keystore deviceKeystore.jks

キーストアとトラストストア

まだキーストアとトラストストアを生成していない場合は、証明書の生成と署名の説明に従って行います。

CA 証明書のアップロード

CA（または中間）証明書をプラットフォームにアップロードします。この操作により、アップロードされた証明書がサーバーのトラストストアに追加されます。この操作には2つの方法があり、どちらも ROLE_TENANT_ADMIN または ROLE_TENANT_MANAGEMENT_ADMIN のいずれかのロール要件があります。

UI の場合

  1. デバイス管理アプリケーションで、ナビゲータの 管理 メニューに移動し、信頼された証明書 を選択します。
  2. 表示されるダイアログで、新しい証明書のカスタム名を入力します。
  3. CA 証明書 (caCert.pem またはintermediateCert.pem) を削除します。
  4. 自動登録 チェックボックスを選択します。
  5. トグルを 有効 に設定します。
  6. 証明書を追加 をクリックします。

その後、新しい証明書が信頼できる証明書リストに追加されます。

信頼された証明書が追加されました

REST API の場合

  1. Things Cloudプラットフォームにアップロードする CA (または中間) 証明書を表示し、その PEM 値をコピーします。この値は、「—–BEGIN CERTIFICATE—–」で始まり、「—–END CERTIFICATE—–」で終わります (ハイフン含む)。改行記号（\n）が各行の末尾に自動的に追加された場合は、それを削除します: openssl x509 -in caCert.pem -text
  2. POSTリクエストを介してプラットフォームに送信します。
    POST /tenant/tenants/<TENANT_ID>/trusted-certificates
    Host: https://<TENANT_DOMAIN>/
    Authorization: Basic <YOUR_AUTHENTICATION>
    Content-Type: application/json
    {
    	"status" :  "ENABLED",
    	"name" : "certificateName",
    	"autoRegistrationEnabled" : "true",
    	"certInPemFormat" : "<CERT_PEM_VALUE>"
    }

所有証明の実行

Things Cloudプラットフォームは、X.509 証明書を使用してエンドデバイスを認証します。 証明書は信頼の連鎖で機能します。信頼できる証明書を使用して、信頼できるサブ証明書を作成できます。 各証明書はパブリック部分とプライベート部分で構成されます。非対称暗号化も参照してください。

Things Cloudプラットフォームは、デバイス認証に使用される各証明書の公開部分を受け取ります。 各証明書は一意に割り当てる必要があるため、テナントへのデバイスの割り当ても証明書によって行われます。 所有証明の手順を実行すると、事前の所有証明のないすべての証明書がフィルタリングされ、検証済みの所有証明を持つ証明書のテナント マッピングが優先されます。

ただし、証明書 (およびサブ証明書) の公開部分は秘密ではないため、理論的にはインターネット上の誰でもアクセスできます。潜在的な攻撃者は、証明書のプライベート部分にアクセスできない (したがって証明書の所有者ではない) 場合でも、証明書のパブリック部分を Things Cloudプラットフォームにアップロードする可能性があります。 この場合、Things Cloudプラットフォームはどのアップローダーが正規のものであるかを判断できないため、プラットフォームはこの証明書への参照を有効なものとして受け入れず、DOS シナリオが発生します。

アップロード者による所有権の検証を確実にするために、プラットフォームは所有権の証明を必要とします。

所有証明の手順は以下の通りです:

  1. デバイス管理アプリケーションの管理 > 信頼された証明書に移動し、証明書が正しくアップロードされていることを確認します。
    証明書の確認

  2. 証明書の詳細の所有証明セクションで、確認コードをダウンロードします。
    検証コードのダウンロード

  3. 証明書の秘密キーを使用して検証コードを暗号化し、署名付き検証コードを生成します。 次の OpenSSL コマンドを使用します。
    openssl dgst -sha256 -sign <private.key> <verification_code.txt> | openssl base64 -A

  4. 署名された確認コードをプラットフォームにアップロードします。
    署名された検証コードをアップロード

アップロードされた署名付き検証コードが、プラットフォームが期待する署名付き検証コードと一致する場合、所有証明が確認されます。 これは、所有証明セクションで状態を「不完全」から「完了」に切り替えることで示されます。

備考
組織上の理由により管理者がこのプロセスを自分で実行できない場合は、対応する証明書の所有証明を手動でリクエストでき、Things Cloud サポート チームが合理的な検証後にバックエンドAPIにて所有証明を完了できます。