チュートリアル: テスト用の証明書を作成してアップロードする

[アーティクル]
05/01/2023

X.509 証明書を使用して、IoT ハブに対してデバイスを認証できます。運用環境の場合、プロフェッショナルな証明書サービスベンダーから X.509 CA 証明書を購入することをお勧めします。その後、包括的な公開キー基盤 (PKI) 戦略の一環として、購入した CA 証明書にチェーンされた内部のセルフマネージド認証局 (CA) から組織内で証明書を発行できます。プロフェッショナルな証明書サービスベンダーから X.509 CA 証明書を入手する方法の詳細については、「X.509 CA 証明書を使用してデバイスを認証する」の「X.509 CA 証明書を入手する」セクションを参照してください。

ただし、テスト環境では、内部ルート CA をトラストアンカーとして使用する独自の自己管理型のプライベート CA を作成することで十分です。少なくとも 1 つの下位 CA が内部ルート CA にチェーンされているセルフマネージドプライベート CA と、下位 CA によって署名されたデバイスのクライアント証明書を使用すると、推奨される運用環境をシミュレートできます。

Note

運用環境では、自己署名証明書を使用しないことをお勧めします。このチュートリアルは、デモンストレーションのみを目的として提示されています。

次のチュートリアルでは、OpenSSL と OpenSSL Cookbook を使用して、次のタスクを実行する方法について説明します。

内部ルート証明機関 (CA) とルート CA 証明書を作成する
内部ルート CA 証明書によって署名された、内部の下位 CA と下位 CA 証明書を作成する
テスト目的で下位 CA 証明書を IoT ハブにアップロードする
下位 CA を使用して、IoT ハブでテストする IoT デバイスのクライアント証明書を作成する

Note

Microsoft では、独自の X.509 証明書を作成し、IoT ハブで認証する方法を学ぶ上で役立つ PowerShell と Bash の各スクリプトをご用意しています。スクリプトは、Azure IoT Hub Device SDK for C に含まれています。また、このスクリプトは、デモ目的でのみ提供されています。これらを使って作成した証明書は、運用環境で使用しないでください。証明書は固定のパスワード ("1234") が含まれており、30 日後に期限切れになります。運用環境では、証明書の作成と有効期間の管理について、独自のベストプラクティスを使用する必要があります。詳細については、Azure IoT Hub Device SDK for C の GitHub リポジトリにある「サンプルおよびチュートリアルのためのテスト用 CA 証明書の管理」を参照してください。

前提条件

Azure サブスクリプション。 Azure サブスクリプションをお持ちでない場合は、開始する前に無料アカウントを作成してください。
Azure サブスクリプション内の IoT ハブ。ハブがまだない場合は、「IoT ハブの作成」の手順に従うことができます。
最新バージョンの Git。コマンドウィンドウからアクセスできる環境変数に Git が追加されていることを確認します。 Git Bash (ローカル Git リポジトリとやりとりする際に使用できるコマンドラインアプリ) を含む、インストールする git ツールの最新バージョンについては、Software Freedom Conservancy の Git クライアントツールに関するページを参照してください。
OpenSSL のインストール。 Windowsでは、Git のインストールに OpenSSL のインストールが含まれています。 OpenSSL には、Git Bash プロンプトからアクセスできます。 OpenSSL がインストールされていることを確認するには、Git Bash プロンプトを開いて、openssl version と入力します。

注意

OpenSSL に精通していて、既に Windows コンピューターにインストールしている場合を除き、Git Bash プロンプトから OpenSSL を使用することをお勧めします。または、ソースコードをダウンロードして OpenSSL をビルドすることもできます。詳細については、「OpenSSL のダウンロード」ページをご覧ください。または、事前構築済み OpenSSL をサードパーティからダウンロードすることもできます。詳細については、OpenSSL Wiki を参照してください。 Microsoft は、サードパーティからダウンロードされたパッケージの有効性について何ら保証しません。 OpenSSL をビルドまたはダウンロードする場合は、パスで OpenSSL バイナリにアクセスできること、および OPENSSL_CNF 環境変数が openssl.cnf ファイルのパスに設定されていることを確認してください。

ルート CA を作成する

最初に、テスト用の他の証明書を作成できるトラストアンカーとして機能する、内部ルート認証局 (CA) と自己署名ルート CA 証明書を作成する必要があります。内部ルート CA の作成と保守に使用されるファイルは、フォルダー構造に格納され、このプロセスの一部として初期化されます。次の手順を実行します。

ルート CA で使用されるフォルダーとファイルを作成して初期化する
ルート CA とルート CA で作成された証明書を構成するために OpenSSL で使用される構成ファイルを作成する
ルート CA 証明書として機能する自己署名 CA 証明書を要求して作成する

Git Bash ウィンドウを起動し、次のコマンドを実行して、{base_dir} をルート CA を作成する目的のディレクトリに置き換えます。
```
cd {base_dir}
```

Git Bash ウィンドウで、次のコマンドを一度に 1 つずつ実行します。この手順では、ルート CA の次のディレクトリ構造とサポートファイルを作成します。

ディレクトリまたはファイル	説明
rootca	ルート CA のルートディレクトリ。
rootca/certs	ルート CA の CA 証明書が作成および格納されるディレクトリ。
rootca/db	ルート CA の証明書データベースとサポートファイルが格納されているディレクトリ。
rootca/db/index	ルート CA の証明書データベース。 `touch` コマンドは、後で使用するためにコンテンツを含まないファイルを作成します。証明書データベースは、発行された証明書に関する情報を含む OpenSSL によって管理されるプレーンテキストファイルです。証明書データベースの詳細については、OpenSSL ドキュメントの openssl-ca マニュアルページを参照してください。
rootca/db/serial	ルート CA 用に作成される次の証明書のシリアル番号を格納するために使用されるファイル。 `openssl` コマンドは、16 バイトの乱数を 16 進形式で作成し、このファイルに格納して、ルート CA 証明書を作成するためのファイルを初期化します。
rootca/db/crlnumber	ルート CA によって発行された失効した証明書のシリアル番号を格納するために使用されるファイル。 `echo` コマンドは、サンプルのシリアル番号 1001 をファイルにパイプします。
rootca/private	秘密キーを含むルート CA の非公開ファイルが格納されるディレクトリ。このディレクトリ内のファイルは、セキュリティで保護されている必要があります。

mkdir rootca
cd rootca
mkdir certs db private
chmod 700 private
touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber

前の手順で作成した rootca ディレクトリに rootca.conf という名前のテキストファイルを作成します。テキストエディターでそのファイルを開き、次の OpenSSL 構成設定をコピーしてそのファイルに保存し、次のプレースホルダーを対応する値に置き換えます。

プレースホルダー	説明
{rootca_name}	ルート CA の名前。たとえば、「 `rootca` 」のように入力します。
{domain_suffix}	ルート CA のドメイン名のサフィックス。たとえば、「 `example.com` 」のように入力します。
{rootca_common_name}	ルート CA の共通名。たとえば、「 `Test Root CA` 」のように入力します。

このファイルは、テストルート CA を構成するために必要な値を OpenSSL に提供します。この例では、ファイルは、前の手順で作成したディレクトリとファイルを使用してルート CA を構成します。ファイルには、次の構成設定も用意されています。

ルート CA によって証明書の識別名 (DN) フィールドに使用される CA ポリシー
ルート CA によって作成された証明書要求
ルート CA 証明書、下位 CA 証明書、ルート CA によって発行されたクライアント証明書に適用される X.509 拡張機能

注意

この構成ファイルは、下位 CA の証明書を作成するときにも使用されるため、ca_default セクションの home 属性は、../rootca に設定されます。指定した相対パスを使用すると、OpenSSL は、そのプロセス中に下位 CA フォルダーからルート CA フォルダーに移動できます。

OpenSSL 構成ファイルの構文の詳細については、OpenSSL ドキュメントの構成のマニュアルページを参照してください。

[default]
name                     = {rootca_name}
domain_suffix            = {domain_suffix}
aia_url                  = http://$name.$domain_suffix/$name.crt
crl_url                  = http://$name.$domain_suffix/$name.crl
default_ca               = ca_default
name_opt                 = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
commonName               = "{rootca_common_name}"

[ca_default]
home                     = ../rootca
database                 = $home/db/index
serial                   = $home/db/serial
crlnumber                = $home/db/crlnumber
certificate              = $home/$name.crt
private_key              = $home/private/$name.key
RANDFILE                 = $home/private/random
new_certs_dir            = $home/certs
unique_subject           = no
copy_extensions          = none
default_days             = 3650
default_crl_days         = 365
default_md               = sha256
policy                   = policy_c_o_match

[policy_c_o_match]
countryName              = optional
stateOrProvinceName      = optional
organizationName         = optional
organizationalUnitName   = optional
commonName               = supplied
emailAddress             = optional

[req]
default_bits             = 2048
encrypt_key              = yes
default_md               = sha256
utf8                     = yes
string_mask              = utf8only
prompt                   = no
distinguished_name       = ca_dn
req_extensions           = ca_ext

[ca_ext]
basicConstraints         = critical,CA:true
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[sub_ca_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:true,pathlen:0
extendedKeyUsage         = clientAuth,serverAuth
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[client_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:false
extendedKeyUsage         = clientAuth
keyUsage                 = critical,digitalSignature
subjectKeyIdentifier     = hash

Git Bash ウィンドウで、次のコマンドを実行し、rootca ディレクトリに証明書署名要求 (CSR) を生成し、rootca/private ディレクトリに秘密キーを生成します。 OpenSSL req コマンドの詳細については、OpenSSL ドキュメントの openssl-req のマニュアルページを参照してください。

Note

このルート CA はテスト目的であり、公開キーインフラストラクチャ (PKI) の一部として公開されることはありませんが、秘密キーをコピーまたは共有しないことをお勧めします。
- Windows
- Linux
```
winpty openssl req -new -config rootca.conf -out rootca.csr \
  -keyout private/rootca.key
```
```
openssl req -new -config rootca.conf -out rootca.csr \
  -keyout private/rootca.key
```
次の例に示すように、秘密キーファイルの PEM パスフレーズを入力するように求められます。パスフレーズを入力して確認し、秘密キーと CSR を生成します。
```
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
```
続行する前に、CSR ファイル rootca.csr が rootca ディレクトリに存在し、秘密キーファイル rootca.key が private サブディレクトリに存在することを確認します。 CSR ファイルと秘密キーファイルの形式の詳細については、「X.509 証明書」を参照してください。
Git Bash ウィンドウで、次のコマンドを実行して、自己署名ルート CA 証明書を作成します。このコマンドにより、ca_ext 構成ファイル拡張子が証明書に適用されます。これらの拡張子は、証明書がルート CA のものであり、証明書と証明書失効リスト (CRL) の署名に利用できることを示しています。 OpenSSL ca コマンドの詳細については、OpenSSL ドキュメントの openssl-ca のマニュアルページを参照してください。
- Windows
- Linux
```
winpty openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt \
  -extensions ca_ext
```
```
openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt \
  -extensions ca_ext
```
次の例に示すように、秘密キーファイルの PEM パスフレーズを提供するように求められます。パスフレーズを指定すると、OpenSSL によって証明書が生成され、ルート CA の証明書に署名してコミットするように求められます。両方のプロンプトで y を指定して、ルート CA の自己署名証明書を生成します。
```
Using configuration from rootca.conf
Enter pass phrase for ../rootca/private/rootca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:51:41 2033 GMT (3650 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated
```
OpenSSL が証明書データベースを更新した後、証明書ファイル rootca.crt が rootca ディレクトリに存在し、証明書の PEM 証明書 (.pem) ファイルが rootca/certs ディレクトリに存在することを確認します。 .pem ファイルのファイル名は、ルート CA 証明書のシリアル番号と一致します。証明書ファイルの形式の詳細については、「X.509 証明書」を参照してください。

下位 CA を作成する

内部ルート CA を作成したら、デバイスのクライアント証明書に署名するための中間 CA として使用する下位 CA を作成する必要があります。理論的には、下位 CA を作成する必要はありません。ルート CA 証明書を IoT ハブにアップロードし、ルート CA からクライアント証明書に直接署名できます。ただし、下位 CA を中間 CA として使用し、クライアント証明書に署名すると、ルート CA がオフラインに保たれ、推奨される運用環境をより厳密にシミュレートできます。また、下位 CA を使用して別の下位 CA に署名し、その下位 CA が別の下位 CA に署名することもできます。下位 CA を使用して他の下位 CA に署名すると、証明書の信頼チェーン の一部として中間 CA の階層が作成されます。運用環境では、証明書の信頼チェーンによって、署名デバイスに対する信頼の委任が可能になります。デバイスを証明書の信頼チェーンに署名する方法について詳しくは、「X.509 CA 証明書を使用してデバイスを認証する」をご覧ください。

ルート CA と同様に、下位 CA の作成と保守に使用されるファイルはフォルダー構造に格納され、このプロセスの一部として初期化されます。次の手順を実行します。

下位 CA で使用されるフォルダーとファイルを作成して初期化する
下位 CA と下位 CA で作成された証明書を構成するために OpenSSL で使用される構成ファイルを作成する
下位 CA 証明書として機能するルート CA によって署名された CA 証明書を要求して作成する

Git Bash ウィンドウを起動し、次のコマンドを実行します。{base_dir} は、以前に作成したルート CA を含むディレクトリに置き換えます。この例では、ルート CA と下位 CA の両方が同じベースディレクトリに存在します。
```
cd {base_dir}
```
Git Bash ウィンドウで、次のコマンドを一度に 1 つずつ実行し、次のプレースホルダーを対応する値に置き換えます。

プレースホルダー説明

{subca_dir} 下位 CA のディレクトリの名前。たとえば、「 subca 」のように入力します。

この手順では、[ルート CA の作成] でルート CA 用に作成したフォルダー構造およびファイルと同様に、下位 CA のディレクトリ構造とサポートファイルを作成します。
```
mkdir {subca_dir}
cd {subca_dir}
mkdir certs db private
chmod 700 private
touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber
```

前の手順で作成した下位 CA に対して、{subca_dir} で指定したディレクトリに subca.conf という名前のテキストファイルを作成します。テキストエディターでそのファイルを開き、次の OpenSSL 構成設定をコピーしてそのファイルに保存し、次のプレースホルダーを対応する値に置き換えます。

プレースホルダー	説明
{subca_name}	下位 CA の名前。たとえば、「 `subca` 」のように入力します。
{domain_suffix}	下位 CA のドメイン名のサフィックス。たとえば、「 `example.com` 」のように入力します。
{subca_common_name}	下位 CA の共通名。たとえば、「 `Test Subordinate CA` 」のように入力します。

テストルート CA の構成ファイルと同様に、このファイルには、テスト下位 CA を構成するために必要な値が OpenSSL に用意されています。テストシナリオまたは環境を管理するために、複数の下位 CA を作成できます。

OpenSSL 構成ファイルの構文の詳細については、OpenSSL ドキュメントの構成のマスターマニュアルページを参照してください。

[default]
name                     = {subca_name}
domain_suffix            = {domain_suffix}
aia_url                  = http://$name.$domain_suffix/$name.crt
crl_url                  = http://$name.$domain_suffix/$name.crl
default_ca               = ca_default
name_opt                 = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
commonName               = "{subca_common_name}"

[ca_default]
home                     = ../{subca_name}
database                 = $home/db/index
serial                   = $home/db/serial
crlnumber                = $home/db/crlnumber
certificate              = $home/$name.crt
private_key              = $home/private/$name.key
RANDFILE                 = $home/private/random
new_certs_dir            = $home/certs
unique_subject           = no
copy_extensions          = copy
default_days             = 365
default_crl_days         = 90
default_md               = sha256
policy                   = policy_c_o_match

[policy_c_o_match]
countryName              = optional
stateOrProvinceName      = optional
organizationName         = optional
organizationalUnitName   = optional
commonName               = supplied
emailAddress             = optional

[req]
default_bits             = 2048
encrypt_key              = yes
default_md               = sha256
utf8                     = yes
string_mask              = utf8only
prompt                   = no
distinguished_name       = ca_dn
req_extensions           = ca_ext

[ca_ext]
basicConstraints         = critical,CA:true
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[sub_ca_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:true,pathlen:0
extendedKeyUsage         = clientAuth,serverAuth
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[client_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:false
extendedKeyUsage         = clientAuth
keyUsage                 = critical,digitalSignature
subjectKeyIdentifier     = hash

Git Bash ウィンドウで、次のコマンドを実行して、下位 CA ディレクトリに秘密キーと証明書署名要求 (CSR) を生成します。
- Windows
- Linux
```
winpty openssl req -new -config subca.conf -out subca.csr \
  -keyout private/subca.key
```
```
openssl req -new -config subca.conf -out subca.csr \
  -keyout private/subca.key
```
次の例に示すように、秘密キーファイルの PEM パスフレーズを入力するように求められます。パスフレーズを入力して確認し、秘密キーと CSR を生成します。
```
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
```
続行する前に、CSR ファイル subca.csr が下位 CA ディレクトリに、秘密キーファイル subca.key が private サブディレクトリに存在することを確認します。 CSR ファイルと秘密キーファイルの形式の詳細については、「X.509 証明書」を参照してください。
Git Bash ウィンドウで、次のコマンドを実行して、下位 CA ディレクトリに下位 CA 証明書を作成します。このコマンドにより、sub_ca_ext 構成ファイル拡張子が証明書に適用されます。これらの拡張子は、証明書が下位 CA のものであり、証明書と証明書失効リスト (CRL) の署名にも利用できることを示しています。ルート CA 証明書とは異なり、この証明書は自己署名されていません。代わりに、下位 CA 証明書はルート CA 証明書で署名され、公開キーインフラストラクチャ (PKI) に使用するのと同様の証明書チェーンが確立されます。その後、下位 CA 証明書を使用して、デバイスをテストするためのクライアント証明書に署名します。
- Windows
- Linux
```
winpty openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt \
  -extensions sub_ca_ext
```
```
openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt \
  -extensions sub_ca_ext
```
次の例に示すように、ルート CA の秘密キーファイルのパスフレーズを入力するように求められます。パスフレーズを入力すると、OpenSSL によって証明書の詳細が生成されて表示され、下位 CA の証明書に署名してコミットするように求められます。下位 CA の証明書を生成する両方のプロンプトに y を指定します。
```
Using configuration from rootca.conf
Enter pass phrase for ../rootca/private/rootca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:55:00 2024 GMT (365 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated
```
OpenSSL が証明書データベースを更新した後、証明書ファイル subca.crt が下位の CA ディレクトリに存在し、証明書の PEM 証明書 (.pem) ファイルが rootca/certs ディレクトリに存在することを確認します。 .pem ファイルのファイル名は、下位 CA 証明書のシリアル番号と一致します。証明書ファイルの形式の詳細については、「X.509 証明書」を参照してください。

下位 CA 証明書を IoT ハブに登録する

下位 CA 証明書を作成したら、下位 CA 証明書を IoT ハブに登録する必要があります。IoT ハブはこの証明書を使用して、登録および接続中にデバイスを認証します。証明書の登録は 2 段階のプロセスであり、証明書ファイルのアップロードと、その後の所有証明の確立で構成されます。下位 CA 証明書を IoT ハブにアップロードするときに、所有証明を手動で確立する必要がないように、下位 CA 証明書を自動的に検証するように設定できます。次の手順では、下位 CA 証明書を IoT ハブにアップロードして自動的に検証する方法について説明します。

Azure portal で IoT ハブに移動し、リソースメニューの [セキュリティの設定] で [証明書] を選びます。
コマンドバーから [追加] を選んで、新しい CA 証明書を追加します。
[証明書名] フィールドに下位 CA 証明書の表示名を入力します。
rootca/certs ディレクトリから下位 CA 証明書の PEM 証明書 (.pem) ファイルを選択し、[証明書 .pem または .cer ファイル] フィールドに追加します。
[証明書の状態をアップロード時に確認済みに設定する] の横のチェックボックスをオンにします。
[保存] を選択します。

アップロードされた下位 CA 証明書は、作業ペインの [証明書] タブにその状態が [検証済み] に設定された状態で表示されます。

デバイスのクライアント証明書を作成する

下位 CA を作成したら、デバイスのクライアント証明書を作成できます。下位 CA 用に作成されたファイルとフォルダーは、クライアント証明書の CSR、秘密キー、および証明書ファイルを格納するために使用されます。

クライアント証明書では、サブジェクト共通名 (CN) フィールドの値が、対応するデバイスを Azure IoT Hub に登録するときに使用されたデバイス ID の値に設定されている必要があります。証明書フィールドの詳細については、「X.509 証明書」の「証明書フィールド」セクションを参照してください。

次の手順を実行します。

クライアント証明書の秘密キーと証明書署名要求 (CSR) を作成する
下位 CA 証明書によって署名されたクライアント証明書を作成する

Git Bash ウィンドウを起動し、次のコマンドを実行します。{base_dir} は、以前に作成したルート CA および下位 CA を含むディレクトリに置き換えます。
```
cd {base_dir}
```

Git Bash ウィンドウで、次のコマンドを一度に 1 つずつ実行し、次のプレースホルダーを対応する値に置き換えます。この手順では、クライアント証明書の秘密キーと CSR を作成します。

プレースホルダー	説明
{subca_dir}	下位 CA のディレクトリの名前。たとえば、「 `subca` 」のように入力します。
{device_name}	IoT デバイスの名前。たとえば、「 `testdevice` 」のように入力します。

この手順では、クライアント証明書の 2048 ビット RSA 秘密キーを作成し、その秘密キーを使用して証明書署名要求 (CSR) を生成します。

Windows
Linux

cd {subca_dir}
winpty openssl genpkey -out private/{device_name}.key -algorithm RSA \
  -pkeyopt rsa_keygen_bits:2048
winpty openssl req -new -key private/{device_name}.key -out {device_name}.csr

cd {subca_dir}
openssl genpkey -out private/{device_name}.key -algorithm RSA \
  -pkeyopt rsa_keygen_bits:2048
openssl req -new -key private/{device_name}.key -out {device_name}.csr

次の例に示すように、証明書の詳細を指定するように求められます。次のプレースホルダーを対応する値に置き換えます。

プレースホルダー	説明
{device_id}*	IoT デバイスの識別子。たとえば、「 `testdevice` 」のように入力します。この値は、デバイスの IoT ハブ内の対応するデバイス ID に指定されたデバイス ID と一致する必要があります。

必要に応じて、Country Name や Organization Name など、他のフィールドに独自の値を入力できます。チャレンジパスワードやオプションの会社名を入力する必要はありません。証明書の詳細を指定すると、OpenSSL によって証明書の詳細が生成されて表示され、下位 CA の証明書に署名してコミットするように求められます。下位 CA の証明書を生成する両方のプロンプトに y を指定します。

-----
Country Name (2 letter code) [XX]:.
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:.
Organization Name (eg, company) [Default Company Ltd]:.
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server hostname) []:'{device_id}'
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

続行する前に、CSR ファイルが下位 CA ディレクトリに存在し、秘密キーファイルが private サブディレクトリに存在することを確認します。 CSR ファイルと秘密キーファイルの形式の詳細については、「X.509 証明書」を参照してください。

Git Bash ウィンドウで、次のコマンドを実行し、次のプレースホルダーを対応する値に置き換えます。この手順では、下位 CA ディレクトリにクライアント証明書を作成します。このコマンドにより、client_ext 構成ファイル拡張子が証明書に適用されます。これらの拡張機能は、証明書がクライアント証明書用であり、CA 証明書として使用できないことを示します。クライアント証明書は、下位 CA 証明書で署名されます。
- Windows
- Linux
```
winpty openssl ca -config subca.conf -in {device_name}.csr -out {device_name}.crt \
  -extensions client_ext
```
```
openssl ca -config subca.conf -in {device_name}.csr -out {device_name}.crt \
  -extensions client_ext
```
次の例に示すように、下位 CA の秘密キーファイルのパスフレーズを入力するように求められます。パスフレーズを入力すると、OpenSSL によって証明書の詳細が生成されて表示され、デバイスのクライアント証明書に署名してコミットするように求められます。クライアント証明書を生成する両方のプロンプトに y を指定します。
```
Using configuration from subca.conf
Enter pass phrase for ../subca/private/subca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:51:41 2024 GMT (365 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated
```
OpenSSL が証明書データベースを更新した後、クライアント証明書の証明書ファイルが下位 CA ディレクトリに存在し、クライアント証明書の PEM 証明書 (.pem) ファイルが下位 CA ディレクトリの certs サブディレクトリに存在することを確認します。 .pem ファイルのファイル名は、クライアント証明書のシリアル番号と一致します。証明書ファイルの形式の詳細については、「X.509 証明書」を参照してください。

次のステップ

デバイスを IoT ハブに登録して、そのデバイス用に作成したクライアント証明書をテストできます。デバイスの登録の詳細については、「Azure Portal を使用して IoT Hub を作成する」の「IoT ハブに新しいデバイスを登録する」セクションを参照してください。

テストする関連デバイスが複数ある場合は、Azure IoT Hub Device Provisioning Service を使用して、登録グループ内の複数のデバイスをプロビジョニングできます。 Device Provisioning Service での登録グループの使用の詳細については、「チュートリアル: 登録グループを使って複数の X.509 デバイスをプロビジョニングする」を参照してください。