X.509 証明書

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

X.509 証明書は、ユーザー、コンピューター、サービス、またはデバイスを表すデジタルドキュメントです。証明機関 (CA)、下位 CA、または登録機関が X.509 証明書を発行します。証明書には、証明書のサブジェクトの公開キーが含まれています。サブジェクトの秘密キーは記録されていません。秘密キーは、セキュリティで保護された場所に保存する必要があります。 RFC 5280 は、フィールドと拡張機能を含む公開キー証明書を文書化したものです。公開キー証明書はデジタル署名されており、通常、次の情報が含まれます。

証明書サブジェクトに関する情報
サブジェクトの秘密キーに対応する公開キー
発行元 CA に関する情報
暗号化やデジタル署名についてサポートされているアルゴリズム
証明書の失効と有効性の状態を判断するための情報

証明書フィールド

X.509 証明書標準には次の 3 つの増分バージョンがあり、以降のバージョンごとに証明書フィールドが標準に追加されています。

1988 年に公開されたバージョン 1 (v1) は、証明書の最初の X.509 標準に従っています。
1993 年に公開されたバージョン 2 (v2) では、バージョン 1 に含まれるフィールドに 2 つのフィールドが追加されています。
2008 年に公開されたバージョン 3 (v3) は、X.509 標準の現在のバージョンを表します。このバージョンでは、証明書拡張機能のサポートが追加されています。

このセクションは、X.509 証明書で使用できる証明書フィールドと証明書拡張機能の一般的なリファレンスです。データ型、制約、その他の詳細など、証明書フィールドと証明書拡張機能の詳細については、RFC 5280 の仕様を参照してください。

バージョン 1 のフィールド

次の表に、X.509 証明書のバージョン 1 の証明書フィールドについて説明します。この表に含まれるすべてのフィールドは、以降の X.509 証明書バージョンで使用できます。

Name	説明
Version	証明書のバージョン番号を特定する整数。
Serial Number(シリアル番号)	証明機関 (CA) によって発行された各証明書の一意の番号を表す整数。
Signature	証明書に署名する CA によって使用された暗号アルゴリズムの識別子。値には、アルゴリズムの識別子と、該当する場合は、そのアルゴリズムで使用されるオプションのパラメーターの両方が含まれます。
発行者	証明書の発行元 CA の識別名 (DN)。
有効期限までの日数	証明書が有効な包括期間。
件名	証明書のサブジェクトの識別名 (DN)。
サブジェクト公開キー情報	証明書のサブジェクトが所有する公開キー。

バージョン 2 のフィールド

次の表に、証明書の発行者に関する情報を含む、バージョン 2 で追加されたフィールドについて説明します。もっとも、ここに挙げたフィールドはほとんど使われていません。この表に含まれるすべてのフィールドは、以降の X.509 証明書バージョンで使用できます。

Name	説明
発行者の一意の ID	発行元 CA で定義されている発行元 CA を表す一意識別子。
サブジェクトの一意の ID	発行元 CA で定義されている証明書のサブジェクトを表す一意識別子。

バージョン 3 のフィールド

次の表に、X.509 証明書拡張機能のコレクションを表す、バージョン 3 で追加されたフィールドについて説明します。

Name	説明
拡張機能	標準およびインターネット固有の証明書拡張機能のコレクション。 X.509 v3 証明書で使用できる証明書拡張機能の詳細については、「証明書拡張機能」を参照してください。

証明書拡張機能

バージョン 3 で導入された証明書拡張機能は、より多くの属性をユーザーまたは公開キーに関連付け、証明機関間の関係を管理するための方法を提供します。証明書拡張機能の詳細については、RFC 5280 仕様の証明書拡張機能に関するセクションを参照してください。

標準拡張機能

X.509 標準では、インターネット公開キー基盤 (PKI) で使用できるように、このセクションに含まれる拡張機能が定義されています。

Name	説明
機関キー識別子	証明書のサブジェクト、この証明書を発行した CA 証明書のシリアル番号、または発行元 CA の公開キーのハッシュのいずれかを表す識別子。
サブジェクトキー識別子	現在の証明書の公開キーのハッシュ。
キー使用法	証明書を使用できるサービスを定義するビットマップ値。
秘密キーの使用期間	キーの組のうち、秘密キーの部分の有効期間。
証明書ポリシー	証明書のサブジェクトを検証するために使用されるポリシー情報のコレクション。
ポリシーマッピング	ポリシーマッピングのコレクション。各ポリシーは、ある組織内のポリシーを別の組織のポリシーにマップします。
サブジェクトの別名	サブジェクトの代替名のコレクション。
発行者の別名	発行元 CA の代替名のコレクション。
Subject Directory Attributes (サブジェクトディレクトリ属性)	X.500 または LDAP ディレクトリからの属性のコレクション。
基本制限	証明書に、CA、ユーザー、コンピューター、デバイス、サービスのどれを対象として発行されたものであるかを指定できる、制約のコレクション。この拡張機能にはほかにも、パスの長さに関する制約が含まれており、存在できる下位 CA の数を制限できます。
名前の制限	CA で発行された証明書で許可される名前空間を指定する制約のコレクション。
ポリシー制約	CA 間のポリシーのマッピングを禁止するときに使用できる制約のコレクション。
拡張キー使用法	キー使用法の拡張機能で指定した目的のほかに、証明書の公開キーをどのように使用できるかを指定するキーの目的値のコレクション。
CRL 配布ポイント	ベース証明書失効リスト (CRL) が発行される URL のコレクション。
anyPolicy の禁止	下位の CA 証明書であらゆる発行ポリシー (OID: 2.5.29.32.0) を使用できないようにします
最新の CRL	この拡張機能 (Delta CRL 配布ポイントとも呼ばれます) には、発行元 CA の Delta CRL が発行される 1 つ以上の URL が含まれています。

非公開のインターネット拡張機能

このセクションに含まれる拡張機能は標準の拡張機能に似ています。また、アプリケーションを発行元 CA または証明書のサブジェクトに関するオンライン情報に誘導するために使用できます。

Name	説明
機関情報アクセス	発行元 CA によって提供される追加情報の形式と場所を記述したエントリのコレクション。
サブジェクト情報アクセス	証明書のサブジェクトによって提供される追加情報の形式と場所を記述したエントリのコレクション。

証明書の形式

証明書はさまざまな形式で保存できます。通常、Azure IoT Hub 認証では、Privacy-Enhanced Mail (PEM) 形式と Personal Information Exchange (PFX) 形式が使用されます。次の表に、証明書を表すために使用される一般的に使用されるファイルと形式について説明します。

フォーマット	説明
バイナリ証明書	Distinguished Encoding Rules (DER) ASN.1 エンコードを使用した未加工の形式のバイナリ証明書。
ASCII PEM 形式	PEM 証明書 (.pem) ファイルには、`-----BEGIN CERTIFICATE-----` で始まり、`-----END CERTIFICATE-----` で終わる Base64 でエンコードされた証明書が含まれています。 X.509 証明書の最も一般的な形式の 1 つである PEM 形式は、デバイスの証明書などの特定の証明書をアップロードする際に IoT Hub で必要になります。
ASCII PEM キー	Base64 でエンコードされた DER キーと、オプションで、パスワードの保護に使用したアルゴリズムに関するメタデータが含まれます。
PKCS #7 証明書	署名または暗号化されたデータを転送するために設計された形式です。これには、証明書チェーン全体を含めることができます。 RFC 2315 で、この形式が定義されています。
PKCS #8 キー	秘密キーストアの形式です。 RFC 5208 で、この形式が定義されています。
PKCS #12 キーと証明書	キーと証明書チェーン全体を格納し、保護できる複雑な形式です。一般に、.p12 または .pfx の拡張子を付けて使用します。 PKCS #12 と PFX 形式は同義です。 RFC 7292 で、この形式が定義されています。

自己署名証明書

テスト目的での IoT ハブに対するデバイスの認証は、2 つの自己署名証明書を使用して行うことができます。このタイプの認証は、"フィンガープリント" または "拇印" と呼ばれる計算されたハッシュ値によって証明書を識別するため、"拇印認証" と呼ばれることがあります。これらの計算されたハッシュ値は、IoT Hub でデバイスを認証するために使用されます。

重要

テスト目的であっても、発行元の証明機関 (CA) によって署名された証明書を使用することをお勧めします。運用環境では自己署名証明書を使用しないでください。

自己署名証明書を作成する

OpenSSL を使用して自己署名証明書を作成できます。次の手順は、bash シェルで OpenSSL コマンドを実行して自己署名証明書を作成し、IoT Hub でデバイスの認証に使用できる証明書フィンガープリントを取得する方法を示しています。

Note

テスト用に自己署名証明書を使用する場合は、デバイスごとに 2 つの証明書を作成する必要があります。

次のコマンドを実行して秘密キーを生成し、PEM でエンコードされた秘密キー (.key) ファイルを作成して、次のプレースホルダーを対応する値に置き換えます。次のコマンドで成された秘密キーは、2048 ビット暗号化の RSA アルゴリズムを使用します。

{KeyFile}. 秘密キーファイルの名前。
```
openssl genpkey -out {KeyFile} -algorithm RSA -pkeyopt rsa_keygen_bits:2048
```

次のコマンドを実行して PKCS #10 証明書署名要求 (CSR) を生成し、CSR (.csr) ファイルを作成して、次のプレースホルダーを対応する値に置き換えます。メッセージが表示されたら、自己署名証明書の IoT デバイスのデバイス ID を指定してください。

{KeyFile}. 秘密キーファイルの名前。

{CsrFile}. CSR ファイルの名前。

{DeviceID}. IoT デバイスの名前。

openssl req -new -key {KeyFile} -out {CsrFile}

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) []:{DeviceID}
Email Address []:.

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

次のコマンドを実行して CSR を確認および検証し、次のプレースホルダーを対応する値に置き換えます。

{CsrFile}. 証明書ファイルの名前。
```
openssl req -text -in {CsrFile} -verify -noout
```
次のコマンドを実行して自己署名証明書を生成し、PEM でエンコードされた証明書 (.crt) ファイルを作成して、次のプレースホルダーを対応する値に置き換えます。このコマンドは、秘密キーを使用して CSR を変換して署名し、365 日で期限切れになる自己署名証明書を生成します。

{KeyFile}. 秘密キーファイルの名前。

{CsrFile}. CSR ファイルの名前。

{CrtFile}. 証明書ファイルの名前。
```
openssl x509 -req -days 365 -in {CsrFile} -signkey {KeyFile} -out {CrtFile}
```
次のコマンドを実行して証明書のフィンガープリントを取得し、次のプレースホルダーを対応する値に置き換えます。証明書のフィンガープリントは、その証明書に固有の計算されたハッシュ値です。テスト用に IoT Hub で IoT デバイスを構成するには、フィンガープリントが必要です。

{CrtFile}. 証明書ファイルの名前。
```
openssl x509 -in {CrtFile} -noout -fingerprint
```

アップロード後に証明書の有効性を手動で確認する

ルート証明機関 (CA) 証明書または下位 CA 証明書を IoT ハブにアップロードするとき、証明書が自動的に検証されることを選択できます。アップロード中に証明書を自動的に検証することを選ばなかった場合は、証明書はその状態が [未検証] に設定された状態で表示されます。証明書を手動で検証するには、次の手順を実行する必要があります。

証明書を選択して、 [証明書の詳細] ダイアログを表示します。
ダイアログボックスの [確認コードを生成します] を選択します。
確認コードをクリップボードにコピーします。この確認コードは、後続の手順で証明書のサブジェクトとして使用する必要があります。たとえば、確認コードが 75B86466DA34D2B04C0C4C9557A119687ADAE7D4732BDDB3 の場合は、次の手順で示すように、証明書のサブジェクトとしてそれを追加します。
検証証明書を生成するには、次の 3 つの方法があります。
- Microsoft によって提供される PowerShell スクリプトを使用する場合は、New-CACertsVerificationCert "<verification code>" を実行して VerifyCert4.cer という名前の証明書を作成し、<verification code> を以前に生成した確認コードに置き換えます。詳細については、Azure IoT Hub Device SDK for C の GitHub リポジトリにある「サンプルおよびチュートリアルのためのテスト用 CA 証明書の管理」を参照してください。
- Microsoft によって提供される Bash スクリプトを使用する場合は、./certGen.sh create_verification_certificate "<verification code>" を実行して verification-code.cert.pem という名前の証明書を作成し、<verification code> を以前に生成した確認コードに置き換えます。詳細については、Azure IoT Hub Device SDK for C の GitHub リポジトリにある「サンプルおよびチュートリアルのためのテスト用 CA 証明書の管理」を参照してください。
- OpenSSL を使用して証明書を生成する場合は、まず秘密キーを生成し、次に証明書署名要求 (CSR) ファイルを生成する必要があります。次の例の <verification code> は、前に生成した確認コードに置き換えてください。
```
openssl genpkey -out pop.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048

openssl req -new -key pop.key -out pop.csr

-----
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) []:<verification code>
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
```
次に、ルート CA または下位 CA の適切な構成ファイルと、CSR ファイルを使用して証明書を作成します。次の例は、OpenSSL を使用してルート CA 構成ファイルと CSR ファイルから証明書を作成する方法を示しています。
```
openssl ca -config rootca.conf -in pop.csr -out pop.crt -extensions client_ext
```
詳細については、「チュートリアル - テスト用の証明書を作成してアップロードする」を参照してください。
[証明書の詳細] ビューで、新しい証明書を選択します。
証明書をアップロードしたら、 [確認] を選択します。証明書の状態が [検証済み] に変わります。

詳細情報

X.509 証明書の詳細と、IoT Hub での使用方法については、次の記事を参照してください。

次の方法で共有