このガイドラインは、Key Vault での証明書管理の開始に役立ちます。
ここで説明するシナリオの一覧:
- 最初の Key Vault 証明書の作成
- Key Vault と提携する証明機関を使用した証明書の作成
- Key Vault と提携していない証明機関を使用した証明書の作成
- 証明書のインポート
証明書は複雑なオブジェクトです
証明書は、Key Vault 証明書としてリンクされた 3 つの相互に関連するリソースで構成されます。証明書メタデータ、キー、シークレット。
最初の Key Vault 証明書の作成
Key Vault (KV) で証明書を作成する前に、前提条件の手順 1 と 2 が正常に完了し、このユーザー/組織に対してキー コンテナーが存在している必要があります。
手順 1: 証明機関 (CA) プロバイダー
- 特定の会社 (Contoso など) の IT 管理者、PKI 管理者、または CA を使用してアカウントを管理するユーザーとしてオンボーディングすることは、Key Vault 証明書を使用するための前提条件です。
次の CA は、Key Vault を使用する現在のパートナー プロバイダーです。 詳細 については、こちらを参照してください。- DigiCert - Key Vault では、DigiCert で OV TLS/SSL 証明書が提供されます。
- GlobalSign - Key Vault は、GlobalSign を使用して OV TLS/SSL 証明書を提供します。
手順 2: CA プロバイダーのアカウント管理者は、Key Vault を介して TLS/SSL 証明書を登録、更新、および使用するために Key Vault によって使用される資格情報を作成します。
手順 3a: Contoso 管理者は、CA に応じて証明書を所有する Contoso 従業員 (Key Vault ユーザー) と共に、管理者から証明書を取得することも、CA を持つアカウントから直接証明書を取得することもできます。
- 証明書発行者リソースを設定して、キー コンテナーへの資格情報の追加操作を開始します。 証明書の発行者は、Azure Key Vault (KV) で CertificateIssuer リソースとして表示されるエンティティです。 これは、KV 証明書のソースに関する情報 (発行者名、プロバイダー、資格情報、その他の管理ための詳細情報) の提供に使用されます。
例: MyDigiCertIssuer
- プロバイダー
- 資格情報 – CA アカウントの資格情報。 各 CA には、独自の特定のデータがあります。
CA プロバイダーを使用してアカウントを作成する方法の詳細については、 Key Vault ブログの関連記事を参照してください。
手順 3b: 通知用 の証明書の連絡先 を設定します。 これは、Key Vault ユーザーの連絡先です。 Key Vault では、この手順は適用されません。
注 - このプロセスは、 手順 3b で 1 回限りの操作です。
Key Vault と提携している CA を使用して証明書を作成する
手順 4: 次の説明は、前の図の緑色の番号付き手順に対応しています。
上の図では、あなたのアプリケーションは、キーの保管庫にキーを作成することから内部作業を始め、証明書を作成しています。
(2) - Key Vault は、TLS/SSL 証明書要求を CA に送信します。
(3) - アプリケーションは、ループおよび待機プロセスで Key Vault に証明書の完了をポーリングします。 Key Vault が CA の応答で x509 証明書を受信すると、証明書の作成が完了します。
(4) - CA は、X509 TLS/SSL 証明書を使用して Key Vault の TLS/SSL 証明書要求に応答します。
(5) - CA の X509 証明書の合併により、新しい証明書の作成が完了します。
Key Vault ユーザー - ポリシーを指定して証明書を作成する
必要に応じて繰り返します
ポリシーの制約
- X509 のプロパティ
- 重要なプロパティ
- プロバイダー参照 - 例 > 。 MyDigiCertIssure
- 更新情報 - > 例有効期限まで 90 日
証明書の作成プロセスは通常、非同期プロセスであり、証明書の作成操作の状態についてキー コンテナーをポーリングする必要があります。
証明書の取得操作- 状態: 完了、エラー情報で失敗、または取り消されました
- 作成に遅延があるため、キャンセル操作を開始できます。 キャンセルは有効な場合と無効な場合があります。
統合 CA に関連付けられているネットワーク セキュリティとアクセス ポリシー
Key Vault サービスは、CA (送信トラフィック) に要求を送信します。 そのため、ファイアウォールが有効なキー ボールトと完全に互換性があります。 Key Vault は CA とアクセス ポリシーを共有しません。 CA は、署名要求を個別に受け入れるように構成する必要があります。 信頼できる CA の統合に関するガイド
証明書のインポート
または、証明書を Key Vault (PFX または PEM) にインポートすることもできます。
証明書のインポート – PEM または PFX がディスク上にあり、秘密キーを持っている必要があります。
コンテナー名と証明書名を指定する必要があります (ポリシーは省略可能)
PEM/PFX ファイルには、KV が解析して証明書ポリシーを設定するために使用できる属性が含まれています。 証明書ポリシーが既に指定されている場合、KV は PFX/PEM ファイルからのデータの照合を試みます。
インポートが最後になると、後続の操作で新しいポリシー (新しいバージョン) が使用されます。
それ以上の操作がない場合、Key Vault が最初に行うことは有効期限の通知を送信することです。
また、ユーザーはインポート時に機能するポリシーを編集できますが、インポート時に情報が指定されなかった既定値が含まれています。例: 発行者情報なし
サポートするインポートの形式
Azure Key Vault では、証明書を Key Vault にインポートするための .pem 証明書ファイルと .pfx 証明書ファイルがサポートされています。 PEM ファイル形式では、次の種類のインポートがサポートされています。 1 つの PEM でエンコードされた証明書と、PKCS#8 でエンコードされた暗号化されていないキー。形式は次のとおりです。
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
証明書をインポートするときは、キーがファイル自体に含まれていることを確認する必要があります。 秘密キーの形式が異なる場合は、キーと証明書を組み合わせる必要があります。 一部の証明機関では異なる形式の証明書が提供されるため、証明書をインポートする前に、証明書が .pem または .pfx 形式であることを確認してください。
注
証明書ファイルに他のメタデータが存在せず、秘密キーが暗号化済みとして表示されていないことを確認します。
サポートされているマージ CSR の形式
Azure Key Vault では、以下のヘッダーを含む PKCS#8 でエンコードされた証明書がサポートされています。
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
注
P7B (PKCS#7) 署名付き証明書チェーンは、証明機関 (CA) によって一般的に使用され、base64 でエンコードされている限りサポートされます。 certutil -encode を使用して、サポートされている形式に変換できます。
Key Vault と提携していない CA を使用して証明書を作成する
この方法では、Key Vault のパートナープロバイダー以外の CA を操作できます。つまり、組織は選択した CA を操作できます。
次の手順の説明は、前の図の緑色の文字付き手順に対応しています。
(1) - 上の図では、アプリケーションが証明書を作成しています。証明書は、内部的にはキー コンテナーにキーを作成することから始まります。
(2) - Key Vault が証明書署名要求 (CSR) をアプリケーションに返します。
(3) - アプリケーションは、選択した CA に CSR を渡します。
(4) - 選択した CA が X509 証明書で応答します。
(5) - アプリケーションは、CA からの X509 証明書の合併を使用して新しい証明書の作成を完了します。