CA プールに証明書発行ポリシーを追加する
このページでは、認証局(CA)プールに証明書発行ポリシーを追加する方法について説明します。
証明書発行ポリシーでは、発行された証明書に含めることができるサブジェクトとサブジェクト代替名(SAN)を指定できます。証明書発行ポリシーは、CA プールの作成時に指定できます。また、既存の CA プールを更新して発行ポリシーを追加することもできます。
詳細については、テンプレートと発行ポリシーの概要をご覧ください。
準備
CA Service オペレーション マネージャー(
roles/privateca.caManager
)または CA Service 管理者(roles/privateca.admin
)の IAM ロールがあることを確認します。プリンシパルに IAM を付与する方法については、単一のロールを付与するをご覧ください。
証明書発行ポリシー ファイルを追加する
既存の CA プールに証明書発行ポリシーを追加するには、次の操作を行います。
Console
Google Cloud コンソールの [Certificate Authority Service] ページに移動します。
[CA プール マネージャー] ページで、証明書発行ポリシーを追加する CA プールの名前をクリックします。
[CA プール] ページで、
[編集] をクリックします。
CA プールから発行された証明書にベースライン値を構成するには、次の手順を行います。
- 切り替えボタンをクリックします。
- [ベースライン値を構成] をクリックします。
この設定を使用すると、証明書に含まれる鍵の使用方法を構成できます。鍵の用途のオプションには、鍵の暗号化、データ暗号化、証明書署名、CRL 署名などがあります。
詳細については、鍵の用途をご覧ください。
鍵の基本的用途を定義するには、次の手順を行います。
- 省略可: 証明書に対する鍵の基本的用途を指定する場合は、表示されるウィンドウで切り替えボタンをクリックします。
- 鍵の使用方法のチェックボックスをオンにします。
- [次へ] をクリックします。
この設定を使用すると、証明書に含まれる鍵を使用できるより詳細なシナリオを選択できます。オプションには、サーバー認証、クライアント認証、コード署名、メール保護などがあります。
鍵の拡張的用途は、オブジェクト識別子(OID)を使用して定義されます。鍵の拡張的用途を構成しない場合は、すべての鍵の使用シナリオが許可されます。
詳細については、鍵の拡張的用途をご覧ください。
鍵の拡張的用途を定義するには、次の手順を行います。
- 省略可: CA プールが発行する証明書に対する鍵の拡張的用途を指定するには、切り替えボタンをクリックします。
- 鍵の拡張的用途のシナリオのチェックボックスをオンにします。
- [次へ] をクリックします。
証明書の証明書ポリシー拡張機能は、発行 CA のプールが従うポリシーを表します。この拡張機能には、証明書の発行前に ID を検証する方法、証明書が取り消される方法、CA プールの完全性を確保する方法に関する情報を含めることができます。この拡張機能は、CA プールが発行する証明書を検証し、証明書がどのように使用されているかを確認するのに役立ちます。
詳細については、証明書ポリシーをご覧ください。
証明書の用途を定義するポリシーを指定するには、次の手順を行います。
- 省略可: [ポリシー識別子] フィールドにポリシー識別子を追加します。
- [次へ] をクリックします。
証明書の AIA 拡張機能には次の情報が含まれます。
- 証明書の取り消しステータスを確認できる OCSP サーバーのアドレス。
- 証明書の発行元のアクセス方法。
詳しくは、認証局情報へのアクセスをご覧ください。
証明書の AIA 拡張機能フィールドに表示される OCSP サーバーを追加するには、次の手順を行います。次の手順は省略可能です。
- 省略可: [項目を追加] をクリックします。
- [サーバー URL] フィールドに、OCSP サーバーの URL を追加します。
- [完了] をクリックします。
- [次へ] をクリックします。
CA プールによって発行された証明書に含めるように追加のカスタム拡張機能を構成するには、次の手順を行います。次の手順は省略可能です。
- [項目を追加] をクリックします。
- [オブジェクト識別子] フィールドに、ドット区切りの数字の形式で有効なオブジェクト識別子を追加します。
- [値] フィールドに、識別子を base64 でエンコードした値を追加します。
- 拡張機能が重要である場合は、[Extension is critical](拡張機能は重要)を選択します。
すべてのベースライン値の構成を保存するには、[完了] をクリックします。
拡張機能の制約を構成する発行済み証明書に証明書リクエストからのすべての拡張機能を含めないようにするには、切り替えボタンをクリックします。
切り替えボタンをクリックすると、[既知の証明書拡張機能] フィールドが表示され、証明書の拡張機能を選択できます。証明書の拡張機能を選択するには、次の手順を行います。
- 省略可: [既知の証明書拡張機能] フィールドをクリックし、不要な拡張機能をメニューから削除します。
- 省略可: [カスタム拡張機能] フィールドに、CA プールが発行する証明書に含める拡張機能のオブジェクト識別子を追加します。
CA プールが発行する証明書のサブジェクトと SAN の制約を構成するには、次の手順を行います。
- 省略可: 証明書リクエストのサブジェクトが渡されないようにするには、切り替えボタンをクリックします。
- 省略可: 証明書リクエストのサブジェクト代替名が渡されないようにするには、切り替えボタンをクリックします。
- 省略可: Common Expression Language(CEL)式を追加して、証明書のサブジェクトに制限を適用します。詳しくは、CEL の使用をご覧ください。
- [次へ] をクリックします。
証明書発行ポリシーで追加のパラメータを構成する方法については、IssuancePolicy をご覧ください。
gcloud
Google Cloud CLI を使用して CA プールに証明書発行ポリシーを追加するには、CA プールが発行できる証明書の制限を記述する YAML ファイルを作成する必要があります。コンテンツは IssuancePolicy に対応していいます。
Cloud Shell エディタを使用して、次の内容のファイル
policy.yaml
を作成します。identityConstraints: allowSubjectPassthrough: true allowSubjectAltNamesPassthrough: true
ここで
allowSubjectPassthrough
フィールドは必須です。allowSubjectPassthrough
フィールドがtrue
に設定されている場合、サブジェクト フィールドは証明書リクエストから署名付き証明書にコピーされます。一致しない場合、リクエストされた Subject は破棄されます。allowSubjectAltNamesPassthrough
フィールドがtrue
に設定されている場合、SubjectAltNames 拡張機能は証明書リクエストから署名付き証明書にコピーされます。それ以外の場合、リクエストされた SubjectAltNames は無視されます。
前の手順で作成したファイルを使用して CA プールの証明書発行ポリシーを更新するには、次のコマンドを実行します。
gcloud privateca pools update POOL_NAME \ --issuance-policy FILE_PATH
次のように置き換えます。
- POOL_NAME: CA プールの名前。
- FILE_PATH:
policy.yaml
ファイルのパス。
gcloud privateca pools update
コマンドの詳細については、gcloud privateca pools update をご覧ください。
サポートされている制限
CA Service は、次の発行ポリシーの制限をサポートしています。必要に応じて、次の制限を組み合わせて、カスタム証明書発行ポリシーを作成できます。
許可される X.509 値を制限または強制する
CA プールでは、passthrough_extensions フィールドを構成することで、証明書リクエストで許可される X.509 値を制限できます。
CA プールでは、baseline_values フィールドを使用して、発行されるすべての証明書に追加する X.509 値を明示的に指定し、リクエストされた値を上書きすることもできます。
CA プールの baseline_values 値では、次のプロパティを指定できます。
これらのオプションを併用することもできます。
baseline_values
フィールドの一部を更新すると、baseline_values
フィールドの値セット全体が置き換えられます。
例: 相互 TLS(mTLS)の X.509 値を持つエンド エンティティ証明書のみを発行するように CA を制限します。
policy.yaml
baselineValues: caOptions: isCa: false keyUsage: baseKeyUsage: digitalSignature: true keyEncipherment: true extendedKeyUsage: clientAuth: true serverAuth: true
例: ベースラインの AIA OCSP URL を使用してエンド エンティティ コード署名証明書のみを発行するように CA を制限します。
policy.yaml
baselineValues: caOptions: isCa: false keyUsage: baseKeyUsage: digitalSignature: true extendedKeyUsage: codeSigning: true aiaOcspServers: - "http://foo.bar/revocation" additionalExtensions: - objectId: objectIdPath: - 1 - 2 - 3 critical: false value: "base64 encoded extension value"
エンド エンティティ mTLS の証明書プロファイルの詳細については、エンド エンティティ mTLS をご覧ください。
許可される ID フィールドを制限する
CA プールから発行される証明書の ID を制限するには、発行ポリシーの identity_constraints フィールドに Common Expression Language(CEL)式を追加します。CEL 式では、サブジェクト ドメイン名(共通名を含む)と証明書の SAN に任意の制限を設定できます。
CEL 式を使用してサブジェクトと SAN を制限する方法については、CEL の使用をご覧ください。
例: 指定したサブジェクトに一致する証明書のみを発行することを CA に許可します。
policy.yaml
identityConstraints: allowSubjectPassthrough: true allowSubjectAltNamesPassthrough: false celExpression: expression: 'subject.organization == "Example LLC" && subject.country_code in ["US", "UK"]'
celExpression
フィールドは省略可能です。証明書が署名される前に、Common Expression Language(CEL)式を使用して、解決された X.509 サブジェクトと SAN を検証します。CEL 式の使用方法については、CEL の使用をご覧ください。例: DNS 名が
us.google.org
または末尾が.google.com
の SAN のみを許可します。policy.yaml
identityConstraints: allowSubjectPassthrough: false allowSubjectAltNamesPassthrough: true celExpression: expression: 'subject_alt_names.all(san, san.type == DNS && (san.value == "us.google.org" || san.value.endsWith(".google.com")) )'
例: URI が
https://google.com/webhp
であるかspiffe://example-trust-domain-1/ns/namespace1/sa/
で始まる SAN のみを許可します。policy.yaml
identityConstraints: allowSubjectPassthrough: false allowSubjectAltNamesPassthrough: true celExpression: expression: 'subject_alt_names.all(san, san.type == URI && (san.value == "https://google.com/webhp" || san.value.startsWith("spiffe://example-trust-domain-1/ns/namespace1/sa/")) )'
例: メールアドレスが
example@google.com
または末尾が@google.org
の SAN のみを許可します。policy.yaml
identityConstraints: allowSubjectPassthrough: false allowSubjectAltNamesPassthrough: true celExpression: expression: 'subject_alt_names.all(san, san.type == EMAIL && (san.value == "example@google.com" || san.value.endsWith("@google.org")) )'
例: 特定の OID とカスタム値を持つカスタム SAN のみを許可します。
policy.yaml
identityConstraints: allowSubjectPassthrough: false allowSubjectAltNamesPassthrough: true celExpression: expression: 'subject_alt_names.all(san, san.type == CUSTOM && san.oid == [1, 2, 3, 4] && san.value == "custom-data" )'
発行される証明書の最大有効期間を制限する
発行される証明書の有効期間を制限するには、maximum_lifetime フィールドを使用します。証明書のリクエストされた存続期間が最大存続期間よりも長い場合、証明書の存続期間は明示的に切り捨てられます。
例
最大有効期間を 30 日間に設定するには、次の policy.yaml
ファイルを使用します。
policy.yaml
maximumLifetime: 2592000s
許可される証明書発行モードを制限する
証明書は、証明書署名リクエスト(CSR)またはリクエストされた値のインライン説明からリクエストできます。後者の方法では関連する秘密鍵の所有権の証明が不要であるため、使用できるオプションに制限を設けることが望ましい場合があります。こうした制限は、allowedIssuanceModes フィールドを使用して設定できます。
CA プールから証明書をリクエストできる方法を指定する方法については、IssuanceModes をご覧ください。
証明書のリクエストの詳細については、証明書リクエストを作成するをご覧ください。
例: CSR の発行のみを許可します。
policy.yaml
allowedIssuanceModes:
allowCsrBasedIssuance: True
allowConfigBasedIssuance: False
証明書リクエストの公開鍵アルゴリズムを制限する
鍵の最小長と証明書で使用できる公開鍵アルゴリズムを制限するには、証明書発行ポリシーの YAML ファイルの allowedKeyTypes フィールドを使用します。このフィールドを指定する場合、証明書リクエストの公開鍵は、YAML ファイルにリストされている鍵タイプのいずれかと一致する必要があります。このフィールドが指定されていない場合、モジュラス サイズが 2,048 ビット未満の RSA 鍵を除き、任意の鍵を使用できます。モジュラス サイズが 2,048 ビット未満の RSA 鍵を使用する場合は、証明書発行ポリシーを使用して明示的に許可する必要があります。
例: NIST P-256 曲線上のモジュラス サイズが 3,072 ビット~ 4,096 ビット(両端を含む)の RSA 鍵か、楕円曲線Digital Signature Algorithm(ECDSA)鍵を許可します。
policy.yaml
allowedKeyTypes:
- rsa:
minModulusSize: 3072
maxModulusSize: 4096
- ellipticCurve:
signatureAlgorithm: ECDSA_P256
次の楕円曲線署名アルゴリズムのいずれかを選択できます。
EC_SIGNATURE_ALGORITHM_UNSPECIFIED
- 任意の署名アルゴリズムを使用できます。ECDSA_P256
- NIST P-256 曲線を使用した楕円曲線デジタル署名。ECDSA_P384
- NIST P-384 曲線の楕円曲線デジタル署名。EDDSA_25519
- RFC 8410 で記述されている、曲線 25519 上のエドワード曲線デジタル署名アルゴリズム。
次のステップ
- 証明書プロファイルの詳細について学習する。
- 証明書のリクエストの詳細について学習する。
- IAM ポリシーの構成方法を確認する。
- Common Expression Language(CEL)の使用方法を学習する。
- さまざまなポリシー制御を管理する方法を学習する。