プライベート証明書の作成の準備

プライベート証明書エンジンを構成することで、IBM Cloud® Secrets Manager サービス・インスタンスがプライベート証明書を生成できるようにすることができます。

Secrets Manager では、プライベート証明書エンジンがprivate_certシークレット・タイプのバックエンドとして機能します。プライベート証明書は、サービスで署名、発行、および管理できる SSL/TLS 証明書です。プライベート証明書を作成する前に、認証局(CA)A trusted third-party organization or company that issues the digital certificates. The certificate authority typically verifies the identity of the individuals who are granted the unique certificate. と証明書の有効な信頼チェーンを作成して、サービス・インスタンスを有効にする必要があります。

証明書階層についての学習

Secrets Manager を使用すると、署名して SSL/TLS 証明書をアプリケーションに発行できる認証局 (CA) を作成することにより、独自の公開鍵インフラストラクチャー (PKI) システムを構築できます。証明書チェーンを配置すると、Secrets Manager インスタンスを使用して、クライアント・アプリケーションおよびサーバー・アプリケーション用のプライベート証明書を作成できます。

有効な証明書チェーンは、トラステッド・ルート CA から始まり、1 つ以上の従属 CA を通過し、エンド・エンティティー・アプリケーションに発行されるリーフ証明書で終わります。例えば、以下の単純な CA 階層をチェックアウトします。

この図は、第 1 レベルのルート認証局で始まる証明書の 3 レベルの階層を示しています。 — 図 1. 3 レベル CA 階層の例

ルート CA は、証明書チェーン全体のトラスト・アンカーとして機能します。
レベル 2 の従属 CA は、ルート CA によって署名され、発行されます。これらの従属 CA は、他の従属 CA 証明書に署名します。
最後に、レベル 3 の従属 CA 証明書に署名し、エンド・エンティティー・アプリケーションにリーフ証明書を発行します。

Secrets Manager では、リーフ証明書は、作成してアプリケーションにデプロイするプライベート証明書です。

CA 階層の設計

Secrets Managerを使用して、複数のブランチと階層を含む最大 10 個のルート CA と 10 個の中間 CA をサービス・インスタンスに作成できます。

表 1. 認証局オプション
権限タイプ	説明
ルート認証局	証明書チェーンのトラスト・アンカー。証明書の階層では、ルート CA は証明書チェーンの最上部にあります。この CA は、CA に従属する CA (例えば、中間 CA) の証明書に署名するために使用されます。
中間認証局	他の中間 CA 証明書に署名して発行する従属または下位の認証局。中間 CA は、クライアント・アプリケーションやサーバー・アプリケーションなどのエンド・エンティティーにリーフ証明書を発行するためにも使用されます。 Secrets Manager では、内部または外部で署名されたの中間 CA を作成できます。

CA 階層の構造の計画

ベスト・プラクティスとして、組織の構造に対応する認証局の階層を計画します。通常、以下の共通 CA 構造のいずれかを実装できます。

2 つのレベル: ルート CA と従属 CA

このオプションは、ワークロードが最も単純な CA 構造を必要とする場合に使用します。このシナリオでは、単一のトラステッド・ルート CA を作成します。次に、中間 CA などの従属 CA を作成して、アプリおよびサービスにリーフ証明書を発行します。

この図は、第 1 レベルのルート認証局で始まる証明書の 2 レベル階層を示しています。 — 図 2。 2 レベル認証局階層

3 つのレベル: ルート CA と 2 つの従属 CA

このオプションは、ワークロードでルート CA 操作と下位 CA 操作の間に追加の層が必要な場合に使用します。このシナリオでは、中央の従属 CA は、アプリにリーフ証明書を発行する従属 CA に署名するためにのみ使用されます。

CA 階層の深さの設定

Secrets Manager で認証局を作成する場合、最大パス長パラメーターを設定して、その認証局チェーンに存在できる CA 証明書の数を決定できます。この値は、CA の認証パスに存在できる CA 証明書の数を強制します。

一般的に、認証パスで作成できる従属 CA の数を制限しないルート CA を構成することができます。ただし、従属 CA に最大パス長を定義することは、CA の構成の誤りを避けるための重要なセキュリティー・ステップです。階層内の従属 CA の配置に応じて、最大パス長を指定して、その署名権限が意図された深さのみに制限されるようにしてください。

この図は、第 1 レベルのルート認証局で始まる 4 レベルの証明書階層を示しています。 — 図 3. 3 レベルの認証局階層

定義する最大パス長には、リーフ証明書は含まれません。前の例では、レベル 4 の従属 CA はリーフ証明書を発行できますが、そのパスにそれ以上の CA 証明書を持つことはできません。

証明書の有効期間の選択

X.509 証明書の有効期間は、証明書が信頼されて有効である期間を決定する必須フィールドです。 CA 階層を計画する際には、アプリケーションに対して発行するリーフ証明書の優先存続期間からさかのぼって作業します。次に、CA 証明書の有効期間を判別します。

証明書の有効期間は、その証明書を発行した CA の有効期間以下でなければなりません。例えば、存続時間 (TTL) が 10 年のルート CA を作成する場合、その CA に従属するすべての中間 CA は、10 年以下の TTL を持つ必要があります。同様に、中間 CA の TTL が 3 年である場合、すべてのリーフ証明書の TTL は 3 年以下でなければなりません。

ユース・ケースに適したリーフ証明書の有効期間を選択します。

Secrets Manager で作成できるプライベート証明書は、クライアント・アプリケーションやサーバー・アプリケーションなどのエンド・エンティティーに発行できるリーフ証明書と見なされます。 Secrets Manager では、最大有効期間が 3 年または 36 カ月の証明書を作成できます。リーフ証明書の TTL または有効期間を決定した後、新しいリーフ証明書が生成されるたびに優先 TTL が適用されるように、証明書テンプレートを使用して値を設定します。

リーフ証明書の TTL が短くなるほど、不注意による証明書とその秘密鍵の漏えいや漏えいに対する保護が強化されます。証明書の有効期間を短くすることは、暗号漏えいの可能性を減らすことを意味しますが、証明書が有効であることを確認するために、証明書をより頻繁にローテーションする必要があります。不注意による停止を回避するために、プライベート証明書の自動ローテーションをスケジュールに入れることができます。
従属 CA の有効期間を選択します。

ベスト・プラクティスとして、従属 CA 証明書に対して、発行する証明書の有効期間よりかなり長い有効期間を設定します。親 CA の有効期間を、それが発行する子 CA 証明書またはリーフ証明書の期間の 2 倍から 5 倍に定義します。例えば、2 レベル CA 階層があり、1 年の TTL を持つリーフ証明書を発行する場合は、3 年の TTL を持つ従属発行 CA を構成します。ルート CA 証明書を置き換えることなく、常に従属 CA 証明書を更新できます。
ルート CA の有効期間を選択します。

ルート CA 証明書を更新すると、その変更は公開鍵インフラストラクチャー全体に影響します。影響を最小限に抑えるために、ルート CA 証明書の有効期間を長く設定することをお勧めします。 Secrets Manager では、ルート証明書のデフォルト TTL は 10 年です。

鍵を生成するためのアルゴリズムの選択

Secrets Manager で認証局を作成する前に、CA の公開鍵と秘密鍵を生成するための鍵アルゴリズムを選択する必要があります。公開鍵と秘密鍵のペアは、SSL/TLS 接続を認証するために使用されます。どこから開始すればかわからない場合は、以下の推奨ガイドを使用して鍵アルゴリズムを選択できます。

アルゴリズム・ファミリーを選択します。

選択した鍵アルゴリズムによって、鍵を生成して証明書に署名するために使用する暗号化アルゴリズムと鍵サイズが決まります。ベスト・プラクティスとして、証明書チェーンに属するすべての証明書に同じアルゴリズム・ファミリーを使用してください。Secrets Manager は、以下のアルゴリズム・ファミリーをサポートしています。

表 2. サポートされるアルゴリズム・ファミリーおよび鍵サイズ
アルゴリズム・ファミリー	説明	サポートされる鍵サイズ
RSA	ほとんどのブラウザーおよびサーバーで広く使用され、互換性がある RSA は、公開鍵暗号方式の業界標準です。	2048 ビット 4096 ビット
楕円曲線 (EC)	より強力な鍵とより小さい証明書を生成します。例えば、256 ビットの EC 鍵は、暗号化強度が 3072 ビットの RSA 鍵と同等です。	224 ビット 256 ビット 384 ビット 521 ビット

鍵サイズを選択します。

選択した鍵のサイズまたは長さによって、暗号化強度が決まります。アルゴリズム・ファミリーの鍵サイズが大きいほど、ブレークするのが難しくなります。鍵の長さが長いほど、保管および送信するデータが多くなり、証明書のパフォーマンスに影響を与える可能性があることに注意してください。ベスト・プラクティスとして、証明書の TTL または有効期間に適した鍵サイズを選択してください。

より長い証明書の場合は、より長い鍵の長さを使用して、より多くの暗号化保護を提供することをお勧めします。

認証局非認証エンドポイントの使用

アプリケーション用に Secrets Manager で CA によって発行されたリーフ証明書を使用している場合は、以下の API 呼び出しを使用して、発行元の CA 証明書失効リスト (CRL) および CA 証明書にアクセスできるようにします。

証明書失効リストの読み取り

このエンドポイントを使用すると、現在の CRL を未加工の DER エンコード形式で取得できます。 /pem がエンドポイントに追加されると、CRL は PEM 形式で返されます。

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/crl(/pem)

Response 200 OK
<binary DER-encoded CRL>

リーフ証明書または中間 CA 証明書がリーフ証明書のコンテキストから取り消されていないことを検証するために、 "crl_distribution_points_encoded": true プロパティーを使用して CA を構成できます。この構成では、発行元 CA CRL をダウンロードするために使用される URL が、各リーフまたは中間 CA 証明書の X509v3 CRL Distribution Points などのプロパティーにエンコードされます。その後、CA バリデーターは、リーフ CA 証明書または中間 CA 証明書が失効しているかどうかを検査できます。

CA 証明書の読み取り

このエンドポイントを使用すると、未加工の DER エンコード形式の CA 証明書を取得できます。 /pem がエンドポイントに追加された場合、CA 証明書は PEM 形式で返されます。

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca(/pem)

Response 200 OK
<binary DER-encoded certificate >

CA 証明書チェーンの読み取り

このエンドポイントを使用して、PEM 形式の CA を含む CA 証明書チェーンを取得できます。このエンドポイントはベアです。標準の Vault データ構造は返されず、Vault CLI は読み取ることができません。

GET v1/ibmcloud/private_cert/config/certificate_authorities/:ca-name/ca_chain

Response 200 OK
<PEM-encoded certificate chain>

CA チェーンがリーフ証明書のコンテキストからのものであることを確認するには、プロパティー "issuing_certificates_urls_encoded": true を使用して Secrets Manager で CA を構成します。各リーフ CA 証明書または中間 CA 証明書では、この構成により、発行元 CA 証明書をダウンロードするために使用される URL がプロパティー Authority Information Access/CA Issuers にエンコードされます。その後、CA バリデーターは各 CA 証明書を検証できます。

次のステップ

これで、インスタンスの認証局を作成する準備ができました。