管理ガイド

Red Hat Certificate System 9

Red Hat Certificate System 9.7 向けに更新

概要

本書では、&CRTS; サブシステムのインストール、設定、および管理のあらゆる側面を説明します。また、ユーザーの追加、証明書の要求、更新、および失効、CRL の公開、スマートカードの管理などの管理タスクも説明します。本ガイドは、&CRTS; 管理者用です。

第1章 Red Hat Certificate Systemnbsp;Hat Certificate Red Hat Certificate Systemnbsp;System サブシステムの概要

証明書の発行、更新、失効、鍵のアーカイブと復元、CRL の発行、証明書の状態の検証など、一般的な PKI 操作はすべて RedRed Hat Certificate Systemnbsp;Hat CertificateRed Hat Certificate Systemnbsp;System 内の相互運用サブシステムによって実行されます。この章では、個々のサブシステムの機能と、それらが連携して堅牢でローカルな PKI を確立する方法を説明します。

1.1. 証明書に使用

証明書の目的は、信頼を確立することです。その使用法は、それが保証するために使用される信頼の種類によって異なります。提示した者の ID を確認するために、いくつかの種類の証明書が使用されたり、オブジェクトまたはアイテムが改ざんされていないことを確認したりするために使用されます。
証明書の使用方法、証明書の種類、または証明書の ID と関係の確立方法は、『Red Hat Certificate System 9 計画、インストール、およびデプロイメントのガイド』の『証明書および認証』セクションを参照してください。

1.2. 証明書システムに関するレビュー;システムサブシステム

RedRed Hat Certificate Systemnbsp;Hat CertificateRed Hat Certificate Systemnbsp;System は 5 つの異なるサブシステムを提供し、それぞれが PKI 展開の異なる側面に焦点を当てます。これらのサブシステムは連携して、公開鍵インフラストラクチャー (PKI) を作成します。インストールされているサブシステムに応じて、PKI はトークン管理システム (TMS) または非トークン管理システムとして機能できます。サブシステム、TMS、および TMS 以外の環境の説明は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『Certificate System サブシステムのレビュー』セクションを参照してください。

Enterprise Security Client

Enterprise Security Client は、証明書、鍵、またはトークンで操作を実行しないため、サブシステムではありません。Enterprise Security Client は、ユーザーがスマートカードで証明書を簡単に管理できるようにするユーザーインターフェイスです。Enterprise Security Client は、証明書要求などのすべてのトークン操作をトークン処理システム (TPS) に送信し、認証局 (CA) に送信します。詳細については、『Red Hat Certificate System 9 エンタープライズセキュリティークライアントでスマートカードの管理』を参照してください。

1.3. 証明書管理の概観 (非 TMS)

従来の PKI 環境は、ソフトウェアデータベースに保存されている証明書を管理する基本的なフレームワークを提供します。これは、スマートカードで証明書を管理しないため、TMS 以外 の環境です。少なくとも、TMS 以外の環境では CA のみが必要ですが、TMS 以外の環境では OCSP レスポンダー と KRA インスタンスも使用できます。
このトピックに関する詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の以下のセクションを参照してください。

1.4. Token Management System (TMS) の概観

CertificateCertificate Systembsp;System は、証明書の作成、管理、更新、失効、また鍵のアーカイブと回復を行います。スマートカードを使用する組織のために、Certificate System は、鍵の生成とスマートカードに使用する証明書の要求と受領のためのトークン管理システム (関係が確立されたサブシステムの集合体) を持っています。
このトピックに関する詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の以下のセクションを参照してください。

1.5. RedRed Hat Certificate Systemnbsp;Hat CertificateRed Hat Certificate Systemnbsp;System services

ユーザータイプ (管理者、エージェント、監査ユーザー、エンドユーザー) に応じて、証明書やサブシステムの管理にはさまざまなインターフェイスがあります。各インターフェイスで実行されるさまざまな機能の概要は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『Red Hat Certificate System 9 のユーザーインターフェイス』のセクションを参照してください。

パート I. Red Hat Certificate System ユーザーインターフェイス

第2章 ユーザーインターフェイス

ユーザーロール (管理者、エージェント、監査ユーザー、エンドユーザー) に応じて、証明書やサブシステムの管理にはさまざまなインターフェイスがあります。

2.1. ユーザーインターフェイスの概要

管理者は、以下のインターフェイスを使用して、完全な Certificate System インストールと安全に対話できます。
  • PKI コマンドラインインターフェイスおよびその他のコマンドラインユーティリティー
  • PKI コンソールのグラフィカルインターフェイス
  • Certificate System Web インターフェイス
これらのインターフェイスには、TLS による Certificate System サーバーとの安全な通信に使用する前に設定が必要です。適切な設定なしでこれらのクライアントを使用することはできません。これらのツールの一部は、TLS クライアント認証を使用します。必要に応じて、必要な初期化手順にこれの設定が含まれます。使用するインターフェイスは、管理者の設定と機能によって異なります。これらのインターフェイスを使用する一般的なアクションは、本章の後半の残りのガイドに記載されています。
デフォルトでは、PKI コマンドラインインターフェイスは、ユーザーの ~/.dogtag/nssdb/ ディレクトリーにある NSS データベースを使用します。「pki CLI の初期化」では、NSS データベースを管理者の証明書およびキーで初期化する詳細な手順を説明します。PKI コマンドラインユーティリティーの使用例は、「pki CLI の使用」に記載されています。その他の例を以下に示します。
(他のユーザーロールの管理者として) 証明書システムとの干渉は、さまざまなコマンドラインユーティリティーを使用して、CMC 要求の送信、生成された証明書の管理などを行うことができます。これらについては、「AtoB」など、「コマンドラインインターフェイス」で簡単に説明します。これらのユーティリティーは、「PKCS10Client を使用した CSR の作成」 などの後のセクションで使用されています。
-- Certificate System の PKI コンソールインターフェイスは、グラフィカルインターフェイスです。「pkiconsole の初期化」 は、初期化方法を説明します。「CA、OCSP、KRA、および TKS サブシステムに対する pkiconsole の使用」 では、コンソールインターフェイスの使用の概要を説明します。「Java ベースの管理コンソールを使用した証明書の登録プロファイルの管理」 などの後のセクションでは、特定の操作について詳しく説明します。
Certificate System Web インターフェイスを使用すると、Firefox Web ブラウザーから管理アクセスが可能になります。「ブラウザーの初期化」 は、クライアント認証の設定手順を説明します。「Web インターフェイス」 の他のセクションでは、証明書システムの Web インターフェイスの使用を説明します。
注記
PKI コンソールセッションを終了するには、Exit ボタンをクリックします。Web ブラウザーセッションを終了するには、ブラウザーを閉じます。コマンドラインユーティリティーは、アクションを実行してプロンプトに返すとすぐにそれ自身を終了するため、セッションを終了するには、管理者の部分でアクションは必要ありません。

2.2. クライアント NSS データベースの初期化

Red Hat Certificate System では、特定のインターフェイスが TLS クライアント証明書認証 (通常は認証) を使用してサーバーにアクセスしないといけない場合があります。サーバー側の管理タスクを実行する前に、以下を行う必要があります。
  1. クライアント用の NSS データベースを準備します。これは、新規データベースか、または既存のデータベースにすることができます。
  2. CA 証明書チェーンをインポートして信頼します。
  3. 証明書と対応するキーがあります。NSS データベースで生成したり、PKCS #12 ファイルから他の場所からインポートしたりできます。
ユーティリティーに基づいて、NSS データベースを適宜初期化する必要があります。以下を参照してください。

2.3. グラフィカルインターフェイス

pkiconsole は、Administrator ロール権限を持つユーザー向けにサブシステム自体を管理するためのグラフィカルインターフェイスです。これには、ユーザーの追加、ログの設定、プロファイルおよびプラグインの管理、および内部データベースなどの多くの機能が含まれます。このユーティリティーは、クライアント認証を使用して TLS 経由で Certificate System サーバーと通信し、リモートでサーバーを管理するために使用できます。

2.3.1. pkiconsole の初期化

pkiconsole インターフェイスを初めて使用するには、新しいパスワードを指定し、以下のコマンドを使用します。 
$ pki -c password -d ~/.redhat-idm-console client-init
このコマンドは、~/.redhat-idm-console/ ディレクトリーに新しいクライアントの NSS データベースを作成します。
CA 証明書を PKI クライアント NSS データベースにインポートするには、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『NSS データベースへの証明書のインポート』を参照してください。
新しいクライアント証明書を要求するには、5章証明書の要求、登録、および管理を参照してください。
以下のコマンドを実行して、.p12 ファイルから管理クライアント証明書を抽出します。 
$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt
『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『証明書/キー暗号化トークンの管理』セクションに記載の手順に従って、管理クライアント証明書の検証およびインポートを行います。 
$ PKICertImport -d ~/.redhat-idm-console -n "nickname" -t ",," -a -i file.crt -u C
重要
CA 管理クライアント証明書をインポートする前に、中間証明書とルート CA 証明書がインポートされていることを確認します。
既存のクライアント証明書とそのキーをクライアント NSS データベースにインポートするには、次を実行します。 
$ pki -c password -d ~/.redhat-idm-console pkcs12-import --pkcs12-file file --pkcs12-password pkcs12-password
以下のコマンドを使用して、クライアント証明書を確認します。 
$ certutil -V -u C -n "nickname" -d ~/.redhat-idm-console

2.3.2. CA、OCSP、KRA、および TKS サブシステムに対する pkiconsole の使用

Java コンソールは、CA、OCSP、KRA、および TKS の 4 つのサブシステムで使用されます。コンソールには、ローカルにインストールされた pkiconsole ユーティリティーを使用してアクセスできます。コマンドにはホスト名、サブシステムの管理 TLS ポート、特定のサブシステムタイプが必要なため、あらゆるサブシステムにアクセスできます。 
pkiconsole https://server.example.com:admin_port/subsystem_type
DNS が設定されていない場合は、IPv4 アドレスまたは IPv6 アドレスを使用して、コンソールに接続できます。たとえば、以下のようになります。 
https://192.0.2.1:8443/ca
https://[2001:DB8::1111]:8443/ca
これにより、図2.1「Certificate System コンソール」 にあるようにコンソールが開きます。

図2.1 Certificate System コンソール

Certificate System コンソール
Configuration タブは、名前が示すように、サブシステムのすべての設定を制御します。このセクションで利用可能な選択肢は、インスタンスがどのサブシステムタイプであるかによって異なります。CA にはジョブ、通知、および証明書登録認証の追加設定があるため、CA にはほとんどのオプションがあります。
すべてのサブシステムには 4 つの基本的なオプションがあります。
  • ユーザーおよびグループ
  • アクセス制御リスト
  • ログ設定
  • サブシステム証明書 (セキュリティードメインや監査署名など、サブシステムに発行した証明書)
Status タブには、サブシステムによってメンテナーンスされるログが表示されます。

2.4. Web インターフェイス

2.4.1. ブラウザーの初期化

本セクションでは、Firefox が PKI サービスにアクセスするためのブラウザーの初期化を説明します。

CA 証明書のインポート

  1. Menu → Preferences → Privacy & Security → View certificatesをクリックします。
  2. Authorities タブを選択し、Import ボタンをクリックします。
  3. ca.crt ファイルを選択し、Import をクリックします。

クライアント証明書のインポート

  1. Options → Preferences → Privacy & Security → View certificates をクリックします。
  2. Your Certificates タブを選択します。
  3. Import をクリックして、ca_admin_cert.p12 などのクライアント p12 ファイルを選択します。
  4. プロンプトにクライアント証明書のパスワードを入力します。
  5. OK をクリックします。
  6. Your Certificates の下にエントリーが追加されていることを確認します。

Web コンソールへのアクセス

ブラウザーで、https://host_name:port を開くと、PKI サービスにアクセスできます。

2.4.2. 管理インターフェイス

すべてのサブシステムは HTML ベースの管理インターフェイスを使用します。ホスト名を入力し、URL としてセキュアなポートを入力し、管理者の証明書で認証し、適切な Administrators リンクをクリックします。
注記
管理者およびエージェントサービスの両方に使用されるすべてのサブシステムには、1 つの TLS ポートがあります。これらのサービスへのアクセスは、証明書ベースの認証により制限されます。
HTML 管理インターフェイスは Java コンソールよりもはるかに制限されています。プライマリー管理機能はサブシステムユーザーを管理します。
TPS では、操作は TPS サブシステムのユーザー管理のみを許可します。ただし、TPS 管理ページでは、トークンを一覧表示し、TPS で実行しているすべてのアクティビティー (通常は非表示管理アクションを含む) をすべて表示できます。

図2.2 TPS 管理ページ

TPS 管理ページ

2.4.3. エージェントインターフェイス

エージェントサービスページは、証明書およびトークン管理タスクがほぼすべて実行されます。これらのサービスは HTML ベースのもので、エージェントは特別なエージェント証明書を使用してサイトに対して認証されます。

図2.3 Certificate Manager のエージェントサービスページ

Certificate Manager のエージェントサービスページ
操作はサブシステムによって異なります。
  • Certificate Manager エージェントサービスには、(証明書を発行する) 証明書要求の承認、証明書の失効、ならびに証明書および CRL の公開が含まれます。CA が発行するすべての証明書は、そのエージェントサービスページで管理できます。
  • TPS エージェントサービスは、CA エージェントサービスと同様、フォーマットされ、TPS を介して証明書が発行されたすべてのトークンを管理します。トークンはエージェントで登録、一時停止、および削除できます。他の 2 つのロール (operator および admin) は Web サービスページでトークンを表示できますが、トークンに対するアクションを実行できません。
  • KRA エージェントサービスページは、キーリカバリー要求を処理します。キーリカバリー要求は、証明書が失われた場合に既存のキーペアを再利用して証明書を発行できるようにするかどうかを設定します。
  • OCSP エージェントサービスページを使用すると、エージェントは CRL を OCSP に公開し、CRL を手動で OCSP に読み込み、クライアント OCSP 要求の状態を表示するように CA を設定します。
TKS は、エージェントサービスページのない唯一のサブシステムです。

2.4.4. エンドユーザーページ

CA と TPS の両方は、ある方法で直接ユーザー要求を処理します。つまり、エンドユーザーにはこれらのサブシステムに接続する方法が必要です。CA にはエンドユーザーまたは エンドエンティティー の HTML サービスがあります。TPS は、Enterprise Security Client を使用します。
エンドユーザーサービスは、サーバーのホスト名と標準のポート番号を使用して標準の HTTP 経由でアクセスします。また、サーバーのホスト名および特定のエンドエンティティー TLS ポートを使用して、HTTPS 経由でもアクセスできます。
CA の場合、各タイプの TLS 証明書は、プロファイル と呼ばれる特定のオンライン送信フォームで処理されます。CA には約 20 ダースの証明書プロファイルがあり、証明書の種類 (ユーザー TLS 証明書、サーバー TLS 証明書、ログおよびファイル署名証明書、電子メール証明書、電子メール証明書、およびあらゆる種類のサブシステム証明書) に対応しています。カスタムプロファイルもあります。

図2.4 Certificate Manager のエンドエンティティーページ

Certificate Manager のエンドエンティティーページ
エンドユーザーは、証明書の発行時に CA ページから証明書を取得します。また、CA チェーンと CRL をダウンロードし、それらのページから証明書を取り消したり更新したりすることもできます。

2.5. コマンドラインインターフェイス

本セクションでは、コマンドラインユーティリティーを説明します。

2.5.1. pkiCLI

pki コマンドラインインターフェイス (CLI) は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『REST インターフェイス』を参照してください。CLI は以下のように呼び出すことができます。 
$ pki [CLI options] <command> [command parameters]
CLI オプションは、コマンドの前に配置する必要があり、コマンドの後にコマンドパラメーターを指定する必要があることに注意してください。

2.5.1.1. pki CLI の初期化

コマンドラインインターフェイスを初めて使用するには、新しいパスワードを指定し、以下のコマンドを使用します。 
$ pki -c <password> client-init
これにより、~/.dogtag/nssdb ディレクトリーに新しいクライアント NSS データベースが作成されます。パスワードは、クライアントの NSS データベースを使用するすべての CLI 操作に指定する必要があります。または、パスワードがファイルに保存されている場合は、-C オプションを使用してファイルを指定できます。以下に例を示します。 
$ pki -C password_file client-init
クライアントの NSS データベースに CA 証明書をインポートするには、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『NSS データベースへの証明書のインポート』セクションを参照してください。
コマンドによっては、クライアント証明書の認証が必要な場合があります。既存のクライアント証明書とその鍵をクライアント NSS データベースにインポートするには、PKCS #12 ファイルとパスワードを指定して、以下のコマンドを実行します。
以下のコマンドを実行して、.p12 ファイルから管理クライアント証明書を抽出します。 
$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt
『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『証明書/キー暗号化トークンの管理』セクションに記載の手順に従って、管理クライアント証明書の検証およびインポートを行います。 
$ PKICertImport -d ~/.dogtag/nssdb -n "nickname" -t ",," -a -i file.crt -u C
重要
CA 管理クライアント証明書をインポートする前に、中間証明書とルート CA 証明書がインポートされていることを確認します。
既存のクライアント証明書とその鍵をクライアント NSS データベースにインポートするには、PKCS #12 ファイルとパスワードを指定して、以下のコマンドを実行します。 
$ pki -c <password> pkcs12-import --pkcs12-file <file> --pkcs12-password <password>
以下のコマンドを使用して、クライアント証明書を確認します。 
certutil -V -u C -n "nickname" -d ~/.dogtag/nssdb

2.5.1.2. pki CLI の使用

コマンドラインインターフェイスは、階層構造で多数のコマンドをサポートします。トップレベルのコマンドを一覧表示するには、追加のコマンドまたはパラメーターを指定せずに pki コマンドを実行します。 
$ pki
コマンドにはサブコマンドがあります。一覧を表示するには、コマンド名 pki で、追加のオプションを指定せずに実行します。以下に例を示します。 
$ pki ca
$ pki ca-cert
コマンドの使用情報を表示するには --help オプションを使用します。 
$ pki --help
$ pki ca-cert-find --help
man ページを表示するには、コマンドラインで help コマンドを指定します。 
$ pki help
$ pki help ca-cert-find
認証を必要としないコマンドを実行するには、コマンドとそのパラメーター (必要な場合) を指定します。以下に例を示します。 
$ pki ca-cert-find
クライアント証明書の認証を必要とするコマンドを実行するには、証明書のニックネーム、クライアント NSS データベースのパスワード、および任意のサーバーの URL を指定します。 
$ pki -U <server URL> -n <nickname> -c <password> <command> [command parameters]
以下に例を示します。 
$ pki -n jsmith -c password ca-user-find ...
デフォルトでは、CLI は http://local_host_name:8080 でサーバーと通信します。別の場所でサーバーと通信するには、URL を -U オプションで指定します。以下に例を示します。 
$ pki -U https://server.example.com:8443 -n jsmith -c password ca-user-find

2.5.2. AtoB

AtoB ユーティリティーは、Base64 でエンコードされた証明書を、同等のバイナリーにデコードします。以下に例を示します。 
$ AtoB input.ascii output.bin
詳細情報、その他のオプション、およびその他の例は、AtoB(1) の man ページを参照してください。

2.5.3. AuditVerify

AuditVerify ユーティリティーは、ログエントリーの署名を検証して、監査ログの整合性を検証します。
たとえば、以下のようになります。 
$ AuditVerify -d ~jsmith/auditVerifyDir -n Log Signing Certificate -a ~jsmith/auditVerifyDir/logListFile -P "" -v
この例では、~jsmith/auditVerifyDir NSS データベース (-d) の Log Signing Certificate (-n) を使用して監査ログを検証します (-d)。検証するログの一覧 (-a) は、コンマ区切りで時系列で、~jsmith/auditVerifyDir/logListFile ファイルにあります。証明書の先頭に接頭辞 (-P) を追加し、キーデータベースのファイル名を空にします。出力は詳細です (-v)。
詳細、その他のオプション、およびその他の例は、AuditVerify(1) の man ページまたは「署名監査ログの使用」を参照してください。

2.5.4. BtoA

BtoA ユーティリティーは、バイナリーデータを Base64 でエンコードします。以下に例を示します。 
$ BtoA input.bin output.ascii
詳細情報、その他のオプション、およびその他の例は、BtoA(1) の man ページを参照してください。

2.5.5. CMCRequest

CMCRequest ユーティリティーは、証明書の発行または失効要求を作成します。以下に例を示します。 
$ CMCRequest example.cfg
注記
CMCRequest ユーティリティーのオプションはすべて、このユーティリティーに渡される設定ファイルの一部として指定されます。設定ファイルのオプションと詳細は、CMCRequest(1) の man ページを参照してください。4.3 も参照してください。CMC および 「CMCRequest を使用した証明書の取り消し」 を使用した証明書の要求と受け取り

2.5.6. CMCRevoke

レガシー。使用しないでください。

2.5.7. CMCSharedToken

CMCSharedToken ユーティリティーは、共有秘密の CMC リクエストのユーザーパスフレーズを暗号化します。以下に例を示します。 
$ CMCSharedToken -d . -p myNSSPassword -s "shared_passphrase" -o cmcSharedTok2.b64 -n "subsystemCert cert-pki-tomcat"
共有パスフレーズ (-s) は、現在のディレクトリー (-d) にある NSS データベースにある subsystemCert cert-pki-tomcat (-n) という名前の証明書を使用して、cmcSharedtok2.b64 ファイル (-o) に暗号化され、保存されます。デフォルトのセキュリティートークン internal が使用され (-h が指定されていない)、myNSSPassword トークンのパスワードは、トークンへのアクセスに使用されます。
詳細、その他のオプション、およびその他の例は、CMCSharedtoken(1) の man ページまたは「CMCRequest を使用した証明書の取り消し」を参照してください。

2.5.8. CRMFPopClient

CRMFPopClient ユーティリティーは、NSS データベースを使用する Certificate Request Message Format (CRMF) クライアントであり、Possession の Proof を提供します。
たとえば、以下のようになります。 
$ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -t false -v -o /user_or_entity_database_directory/example.csr
この例では、cn=subject_name サブジェクト DN (-n)、現在のディレクトリー (-d) の NSS データベース (-b)、トランスポート (kra.transport) (-b) に使用する証明書、AES/CBC/PKCS5Padding キーをラップする証明書で新しい CSR を作成します (-v)。また、生成される CSR が /user_or_entity_database_directory/example.csr ファイル (-o) に書き込まれます。
詳細情報、その他のオプション、およびその他の例は、CRMFPopClient --help コマンドの出力と 「CMCRequest を使用した証明書の取り消し」 を参照してください。

2.5.9. HttpClient

HttpClient ユーティリティーは、CMC 要求を送信するための NSS 対応の HTTP クライアントです。
たとえば、以下のようになります。 
$ HttpClient request.cfg
注記
HttpClient ユーティリティーへのすべてのパラメーターは request.cfg ファイルに保存されます。詳細は、HttpClient --help コマンドの出力を参照してください。

2.5.10. OCSPClient

証明書失効リストのステータスを確認する Online Certificate Status Protocol (OCSP) クライアント。
たとえば、以下のようになります。 
$ OCSPClient -h server.example.com -p 8080 -d /etc/pki/pki-tomcat/alias -c "caSigningCert cert-pki-ca" --serial 2
この例では、ポート 8080 (-p) の server.example.com OCSP サーバー (-h) に対してクエリーを実行し、シリアル番号 2 (--serial) を持つ caSigningcet cert-pki-ca (-c) が署名した証明書を確認します。/etc/pki/pki-tomcat/alias ディレクトリーの NSS データベースが使用されます。
詳細情報、その他のオプション、およびその他の例は、OCSPClient --help コマンドの出力を参照してください。

2.5.11. PKCS10Client

PKCS10Client ユーティリティーは、必要に応じて HSM 上に RSA キーおよび EC キーの CSR を PKCS10 形式で作成します。
たとえば、以下のようになります。 
$ PKCS10Client -d /etc/dirsrv/slapd-instance_name/ -p password -a rsa -l 2048 -o ~/ds.csr -n "CN=$HOSTNAME"
この例では、/etc/dirsrv/slapd-instance_name/ ディレクトリー (-d) に 2048 ビット (-l) で、新しい RSA (-a) キーを、データベースパスワード (password) (-p) で作成します。出力の CSR は ~/ds.cfg ファイル (-o) に保存され、証明書 DN は CN=$HOSTNAME (-n) になります。
詳細情報、その他のオプション、およびその他の例は、PKCS10Client(1) の man ページを参照してください。

2.5.12. PrettyPrintCert

PrettyPrintCert ユーティリティーは、人間が判読可能な形式で証明書の内容を表示します。
たとえば、以下のようになります。 
$ PrettyPrintCert ascii_data.cert
このコマンドは、ascii_data.cert) ファイルの出力を解析し、その内容を人間が読める形式で表示します。出力には、署名アルゴリズム、指数、モジュール、証明書拡張などの情報が含まれます。
詳細情報、その他のオプション、およびその他の例は、PrettyPrintCert(1) の man ページを参照してください。

2.5.13. PrettyPrintCrl

PrettyPrintCrl ユーティリティーは、CRL ファイルの内容を人間が判読できる形式で表示します。
たとえば、以下のようになります。 
$ PrettyPrintCrl ascii_data.crl
このコマンドは、ascii_data.crt ファイルの出力を解析し、その内容を人間が読める形式で表示します。出力には、失効署名アルゴリズム、失効の発行者、取り消された証明書とその理由が一覧になったものなどが含まれます。
詳細情報、その他のオプション、およびその他の例は、PrettyPrintCrl(1) の man ページを参照してください。

2.5.14. TokenInfo

TokenInfo ユーティリティーは、NSS データベース内のトークンを一覧表示します。
たとえば、以下のようになります。 
$ TokenInfo ./nssdb/
このコマンドは、指定のデータベースディレクトリーに登録されたすべてのトークン (HSM、ソフトトークンなど) を表示します。
詳細情報、その他のオプション、およびその他の例は、TokenInfo の出力を参照してください。

2.5.15. tkstool

tkstool ユーティリティーは、トークンキーサービス (TKS) サブシステムと対話します。
たとえば、以下のようになります。 
$ tkstool -M -n new_master -d /var/lib/pki/pki-tomcat/alias -h token_name
このコマンドは、HSM token_name の /var/lib/pki/pki-tomcat/alias NSS データベースに new_master (-n) という名前の新しいマスターキー (-M) を作成します。
詳細情報、その他のオプション、およびその他の例は、tkstool -H の出力を参照してください。

2.6. Enterprise Security Client

Enterprise Security Client は、スマートカードの管理を簡素化する Red Hat Certificate System のツールです。エンドユーザーは、セキュリティートークン (スマートカード) を使用して、シングルサインオンアクセスやクライアント認証などのアプリケーションのユーザー証明書を保存できます。エンドユーザーには、署名、暗号化、およびその他の暗号化機能に必要な証明書および鍵が含まれるトークンが発行されます。
Enterprise Security Client は、Certificate System の完全なトークン管理システムの 3 番目の部分です。2 つのサブシステム (Token Key Service(TKS) および Token Processing System(TPS)) は、トークン関連の操作を処理するために使用されます。Enterprise Security Client は、スマートカードとユーザーがトークン管理システムにアクセスできるようにするインターフェイスです。
トークンの登録後、Mozilla Firefox や Thunderbird などのアプリケーションは、トークンを認識して、クライアント認証や S/MIME メールなどのセキュリティー操作に使用するように設定できます。Enterprise Security Client は、以下の機能を提供します。
  • Safenet の 330J スマートカードなどの JavaCard 2.1 以降のカードと Global Platform 2.01 準拠のスマートカードをサポートします。
  • スマートカードと GemPCKey USB フォームファクターキーの両方である Gemalto TOP IM FIPS CY2 トークンをサポートします。
  • SafeNet Smart Card 650 (SC650) をサポートします。
  • セキュリティートークンを登録して、TPS で認識されるようにします。
  • TPS でトークンを再登録するなど、セキュリティートークンを維持します。
  • 管理対象トークンの現在のステータスに関する情報を提供します。
  • トークンが失われた場合に別のトークンで鍵をアーカイブおよび復元できるように、サーバー側の鍵生成をサポートします。
Enterprise Security Client は、エンドユーザーがスマートカードまたはトークンで鍵と証明書を登録および管理するためのクライアントです。これは、Certificate System トークン管理システムの最終コンポーネントで、Token Processing System (TPS) および Token Key Service (TKS) です。
Enterprise Security Client は、トークン管理システムのユーザーインターフェイスを提供します。エンドユーザーは、署名、暗号化、およびその他の暗号化機能に必要な証明書および鍵が含まれるセキュリティートークンを発行できます。トークンを使用するには、TPS がトークンを認識して通信できるようにする必要があります。Enterprise Security Client は、トークンを登録する方法です。
Enterprise Security Client は、SSL/TLS HTTP チャンネル上で TPS のバックエンドと通信します。これは、ユーザーインターフェイスで拡張可能な Mozilla XULRunner フレームワークに基づいていますが、単純な HTML ベースの UI ではレガシー Web ブラウザーコンテナーを維持します。
トークンを適切に登録した後、Web ブラウザーはトークンを認識し、セキュリティー操作に使用するように設定できます。Enterprise Security Client は、以下の機能を提供します。
  • ユーザーがセキュリティートークンを登録して、TPS によって認識されるようにします。
  • ユーザーがセキュリティートークンを管理できるようにします。たとえば、Enterprise Security Client を使用すると、TPS でトークンを再登録できます。
  • デフォルトおよびカスタムトークンプロファイルを使用したさまざまなトークンのサポートを提供します。デフォルトでは、TPS はユーザーキー、デバイスキー、およびセキュリティー担当者キーを自動的に登録できます。これにより、適切なプロファイルに従って (トークン CUID などの属性によって認識される) さまざまな使用に大してトークンが自動的に自動的に登録されるように、追加のプロファイルを追加できます。
  • 管理対象トークンの現在のステータスに関する情報を提供します。

パート II. 証明書サービスの設定

第3章 証明書を発行するルール (証明書プロファイル) の作成

CertificateCertificate Systemnbsp;システムは、受信する証明書要求に対してポリシーを適用し、入力要求タイプおよび出力証明書タイプを制御するためのカスタマイズ可能なフレームワークを提供します。これらは、証明書プロファイル と呼ばれるものです。証明書プロファイルは、Certificate Manager のエンドエンティティーページで証明書登録フォームに必要な情報を設定します。本章では、証明書プロファイルの設定方法を説明します。

3.1. 証明書プロファイルの概要

証明書プロファイルは、認証方法、認可方法、証明書のデフォルトの内容、内容の値の制約、証明書プロファイルの入力と出力の内容など、特定の種類の証明書の発行に関連するすべてを定義します。登録要求および更新要求は証明書プロファイルに送信され、その証明書プロファイルで設定されたデフォルトと制約の対象となります。これらの制約は、要求が証明書プロファイルに関連付けられた入力フォームを介して送信されるか、他の手段を介して送信されるかに関係なく適用されます。証明書プロファイル要求から発行される証明書には、デフォルトで必要なコンテンツと、デフォルトのパラメーターで必要な情報が含まれています。制約は、証明書で許可されるコンテンツに対するルールを提供します。
証明書プロファイルの使用およびカスタマイズの詳細は、「証明書プロファイルの設定」 を参照してください。
Certificate System には、デフォルトのプロファイルのセットが含まれています。デフォルトのプロファイルは、ほとんどのデプロイメントを満たすために作成されますが、すべてのデプロイメントは独自の新規証明書プロファイルを追加するか、既存のプロファイルを変更することができます。
  • 認証。すべての認証プロファイルで認証方法を指定できます。
  • 認可。すべての認定プロファイルで承認方法を指定できます。
  • プロファイル入力。プロファイルの入力は、証明書が要求されたときに CA に送信されるパラメーターおよび値です。プロファイル入力には、証明書要求の公開鍵と、証明書の終了エンティティーによって要求される証明書のサブジェクト名が含まれます。
  • プロファイルの出力。プロファイルの出力は、エンドエンティティーに証明書を提供する形式を指定するパラメーターおよび値です。プロファイルの出力は、要求が成功したときに PKCS#7 証明書チェーンが含まれる CMC の応答です。
  • 証明書の内容。各証明書は、割り当てられたエンティティーの名前 (サブジェクト名)、署名アルゴリズム、有効期間などのコンテンツ情報を定義します。証明書に含まれるものは、X.509 標準で定義されます。X509 標準のバージョン 3 では、証明書に拡張機能を含めることもできます。証明書エクステンションの詳細は、「標準仕様の X.509 v3 証明書拡張機能リファレンス」 を参照してください。
    証明書プロファイルに関する情報はすべて、プロファイルの設定ファイルのプロファイルポリシーの set エントリーで定義されます。複数の証明書が同時に要求される可能性がある場合は、各証明書のニーズを満たすためにプロファイルポリシーに複数のセットエントリーを定義できます。各ポリシーセットは多数のポリシールールで設定され、各ポリシールールは証明書コンテンツのフィールドを記述します。ポリシールールには、以下の内容を含めることができます。
    • プロファイルのデフォルトです。これらは、証明書内に含まれる情報に対する事前定義済みのパラメーターおよび許可される値です。プロファイルのデフォルトには、証明書の有効期間と、発行する証明書のタイプにどの証明書拡張機能が表示されるかが含まれます。
    • プロファイルの制約。制約は、証明書を発行するルールまたはポリシーを設定します。また、プロファイル制約には、証明書のサブジェクト名に少なくとも 1 つの CN コンポーネントを含める必要があるルールが含まれ、証明書の有効性を最大 360 日に設定し、更新を許可する猶予期間を定義するルール、または subjectaltname 拡張が常に true に設定される必要があるというルールが含まれます。

3.1.1. 登録プロファイル

入力、出力、およびポリシーセットを定義する各プロファイルのパラメーターは、Table 11.1 に詳細に記載されています。Red Hat Certificate System 計画、インストールガイド、およびデプロイメントのガイドのプロファイル設定ファイルのパラメーター
プロファイルには、例3.1「caCMCUserCert プロファイルの例」 の caUserCert プロファイルで説明されているように、通常、入力、ポリシーセット、および出力が含まれます。

例3.1 caCMCUserCert プロファイルの例

証明書プロファイルの最初の部分は説明です。これは、名前、長い説明、有効かどうか、および有効であるかを表示します。 
desc=This certificate profile is for enrolling user certificates by using the CMC certificate request with CMC Signature authentication.
visible=true
enable=true
enableBy=admin
name=Signed CMC-Authenticated User Certificate Enrollment
注記
このプロファイルにない auth.instance_id= エントリーは、このプロファイルを使用した登録リクエストの送信に認証は必要ありません。ただし、保証を取得するには、承認された CA エージェントによる手動承認が必要です。
次に、プロファイルはプロファイルに必要なすべての入力を一覧表示します。 
input.list=i1
input.i1.class_id=cmcCertReqInputImp
caCMCUserCert プロファイルの場合、これは、証明書要求タイプ (CMC) を定義します。
次に、プロファイルは出力 (最終証明書の形式) を定義する必要があります。唯一利用できるのは certOututlcmpl で、成功すると、CMC 応答が要求元に戻ります。 
output.list=o1
output.o1.class_id=certOutputImpl
最後の (最大の) 設定ブロックは、プロファイルに設定されたポリシーです。ポリシーは、有効期間、更新設定、証明書が使用できるアクションなど、最終的な証明書に適用されるすべての設定一覧を設定します。policyset.list パラメーターは、1 つの証明書に適用されるポリシーのブロック名を識別します。適用する個々のポリシーが policyset.userCertSet.list により一覧表示されます。
たとえば、6 番目のポリシーは、ポリシーの設定に従って、証明書に Key Usage Extension を自動的に入力します。これは、デフォルトを設定し、制約を設定して証明書でそれらのデフォルトを使用するようにする必要があります。 
policyset.list=userCertSet
policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9
...
policyset.userCertSet.6.constraint.class_id=keyUsageExtConstraintImpl
policyset.userCertSet.6.constraint.name=Key Usage Extension Constraint
policyset.userCertSet.6.constraint.params.keyUsageCritical=true
policyset.userCertSet.6.constraint.params.keyUsageDigitalSignature=true
policyset.userCertSet.6.constraint.params.keyUsageNonRepudiation=true
policyset.userCertSet.6.constraint.params.keyUsageDataEncipherment=false
policyset.userCertSet.6.constraint.params.keyUsageKeyEncipherment=true
policyset.userCertSet.6.constraint.params.keyUsageKeyAgreement=false
policyset.userCertSet.6.constraint.params.keyUsageKeyCertSign=false
policyset.userCertSet.6.constraint.params.keyUsageCrlSign=false
policyset.userCertSet.6.constraint.params.keyUsageEncipherOnly=false
policyset.userCertSet.6.constraint.params.keyUsageDecipherOnly=false
policyset.userCertSet.6.default.class_id=keyUsageExtDefaultImpl
policyset.userCertSet.6.default.name=Key Usage Default
policyset.userCertSet.6.default.params.keyUsageCritical=true
policyset.userCertSet.6.default.params.keyUsageDigitalSignature=true
policyset.userCertSet.6.default.params.keyUsageNonRepudiation=true
policyset.userCertSet.6.default.params.keyUsageDataEncipherment=false
policyset.userCertSet.6.default.params.keyUsageKeyEncipherment=true
policyset.userCertSet.6.default.params.keyUsageKeyAgreement=false
policyset.userCertSet.6.default.params.keyUsageKeyCertSign=false
policyset.userCertSet.6.default.params.keyUsageCrlSign=false
policyset.userCertSet.6.default.params.keyUsageEncipherOnly=false
policyset.userCertSet.6.default.params.keyUsageDecipherOnly=false
...

3.1.2. 証明書拡張: デフォルトおよび制約

拡張機能は、証明書の使用方法に関する証明書またはルールに含める追加情報を設定します。これらの拡張機能は、証明書要求に指定するか、プロファイルのデフォルト定義から取得した後、制約によって適用できます。
証明書拡張機能がプロファイルで追加または識別されるには、拡張機能に対応する デフォルト を追加し、証明書拡張機能が要求で設定されていない場合にデフォルト値を設定します。たとえば、Basic Constraints Extension は、証明書が CA 署名証明書であるかどうか、CA の下で設定できる従属 CA の最大数、および拡張機能が重要 (必須) であるかどうかを識別します。 
policyset.caCertSet.5.default.name=Basic Constraints Extension Default
policyset.caCertSet.5.default.params.basicConstraintsCritical=true
policyset.caCertSet.5.default.params.basicConstraintsIsCA=true
policyset.caCertSet.5.default.params.basicConstraintsPathLen=-1
拡張機能は、constraints と呼ばれる証明書要求に必要な値を設定することもできます。リクエストの内容がセット制約と一致しない場合、リクエストは拒否されます。制約は通常、拡張機能のデフォルトに対応しますが、常にそうとは限りません。以下に例を示します。 
policyset.caCertSet.5.constraint.class_id=basicConstraintsExtConstraintImpl
policyset.caCertSet.5.constraint.name=Basic Constraint Extension Constraint
policyset.caCertSet.5.constraint.params.basicConstraintsCritical=true
policyset.caCertSet.5.constraint.params.basicConstraintsIsCA=true
policyset.caCertSet.5.constraint.params.basicConstraintsMinPathLen=-1
policyset.caCertSet.5.constraint.params.basicConstraintsMaxPathLen=-1
注記
ユーザーが指定する拡張機能を証明書要求に組み込むのを許可し、プロファイルでシステム定義のデフォルトを無視するには、プロファイルに、「User Supplied Extension Default」 で説明されているユーザー Supplied Extension Default を含める必要があります。

3.1.3. 入力および出力

証明書を受信するために送信する必要がある入力セット情報。これは、要求側の情報、証明書要求の特定の形式、または組織情報のいずれかになります。
プロファイルで設定された出力では、発行された証明書の形式を定義します。
Certificate System では、エンドエンティティーページを介してアクセスされる 登録フォーム を使用して、ユーザーがプロファイルにアクセスします。TPS などのクライアントも、これらの形式を介して登録リクエストを送信します。 その後、入力は登録フォームのフィールドに対応します。この出力は、証明書取得ページに含まれる情報に対応します。

3.2. 証明書プロファイルの設定

証明書システムでは、登録プロファイルを追加、削除、および変更できます。
  • PKI コマンドラインインターフェイスの使用
  • Java ベースの管理コンソールの使用
本セクションでは、各メソッドに関する情報を提供します。

3.2.1. PKI コマンドラインインターフェイスを使用した証明書の登録プロファイルの管理

本セクションでは、pki ユーティリティーを使用して証明書プロファイルを管理する方法を説明します。詳細は、pki-ca-profile(1) の man ページを参照してください。
注記
RAW 形式の使用が推奨されます。プロファイルの各属性およびフィールドの詳細は、Red Hat Certificate System 計画、インストール、およびデプロイメントガイドの証明書プロファイルの作成および編集を参照してください。

3.2.1.1. 証明書プロファイルの有効化および無効化

証明書プロファイルを編集する前に、無効にする必要があります。変更が完了したら、プロファイルを再度有効にできます。
注記
CA エージェントのみが、証明書プロファイルを有効化および無効化できます。
たとえば、caCMCECserverCert 証明書プロファイルを無効にするには、次のコマンドを実行します。 
# pki -c password -n caagent ca-profile-disable caCMCECserverCert
たとえば、caCMCECserverCert 証明書プロファイルを有効にするには、次のコマンドを実行します。 
# pki -c password -n caagent ca-profile-enable caCMCECserverCert

3.2.1.2. Raw 形式の証明書プロファイルの作成

新規プロファイルを raw 形式で作成するには、次のコマンドを実行します。 
# pki -c password -n caadmin ca-profile-add profile_name.cfg --raw
注記
raw 形式で、以下のように新しいプロファイル ID を指定します。 
profileId=profile_name

3.2.1.3. RAW 形式での証明書プロファイルの編集

CA 管理者は、設定ファイルを手動でダウンロードせずに、RAW 形式で証明書プロファイルを編集できます。
たとえば、caCMCECserverCert プロファイルを編集するには、次のコマンドを実行します。 
# pki -c password -n caadmin ca-profile-edit caCMCECserverCert
このコマンドは、プロファイル設定を RAW 形式で自動的にダウンロードし、VI エディターで開きます。エディターを閉じると、サーバーでプロファイル設定が更新されます。
プロファイルの編集後に CA を再起動する必要はありません。
重要
プロファイルを編集する前に、プロファイルを無効にします。詳細は、「証明書プロファイルの有効化および無効化」 を参照してください。

例3.2 RAW 形式での証明書プロファイルの編集

たとえば、caCMCserverCert プロファイルを編集して、ユーザーが提供する複数の拡張機能を許可するには、次を行います。
  1. CA エージェントであるプロファイルを無効にします。 
    # pki -c password -n caagemt ca-profile-disable caCMCserverCert
  2. プロファイルを CA 管理者として編集します。
    1. VI エディターでプロファイルをダウンロードして開きます。 
      # pki -c password -n caadmin ca-profile-edit caCMCserverCert
    2. 設定を更新して、拡張機能を受け入れます。詳細は、例B.3「CSR の Multiple User Supplied Extension」を参照してください。
  3. プロファイルを CA エージェントとして有効にします。 
    # pki -c password -n caagent ca-profile-enable caCMCserverCert

3.2.1.4. 証明書プロファイルの削除

証明書プロファイルを削除するには、次のコマンドを実行します。 
# pki -c password -n caadmin ca-profile-del profile_name
重要
プロファイルを削除する前に、プロファイルを無効にします。詳細は、「証明書プロファイルの有効化および無効化」 を参照してください。

3.2.2. Java ベースの管理コンソールを使用した証明書の登録プロファイルの管理

3.2.2.1. CA コンソールを使用した証明書プロファイルの作成

セキュリティー上の理由から、Certificate System は、ロールの分離を強制します。これにより、既存の証明書プロファイルは、エージェントによって許可された後にのみ管理者が編集できます。新しい証明書プロファイルを追加するか、既存の証明書プロファイルを変更するには、管理者として以下の手順を実施します。
  1. CertificateCertificate Systemnbsp;System CA サブシステムのコンソールにログインします。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで Certificate Manager を選択し、Certificate Profiles を選択します。
    設定した証明書プロファイルを一覧表示する Certificate Profile Instances Management タブが開きます。
  3. 新しい証明書プロファイルを作成するには、Add をクリックします。
    Select Certificate Profile Plugin Implementation ウィンドウで、プロファイルが作成される証明書のタイプを選択します。
  4. Certificate Profile Instance Editor にプロファイル情報を入力します。
    • Certificate Profile Instance ID。この ID は、システムがプロファイルの特定に使用する ID です。
    • Certificate Profile Name。これは、ユーザーが分かりやすいプロファイルの名前です。
    • Certificate Profile Description。
    • End User Certificate Profile。これにより、リクエストがプロファイルの入力フォームを介して行われる必要があるかどうかが設定されます。通常、これは true に設定されます。これを false に設定すると、証明書プロファイルの入力ページではなく、Certificate Manager の証明書プロファイルフレームワークを介して署名済みリクエストが処理できるようになります。
    • Certificate Profile Authentication。これにより、認証方法が設定されます。認証インスタンスのインスタンス ID を指定して、自動認証が設定されます。このフィールドが空の場合、認証方法はエージェントで承認される登録になります。要求はエージェントサービスインターフェイスの要求キューに送信されます。
      TMS サブシステム用でない限り、管理者は次の認証プラグインのいずれかを選択する必要があります。
      • CMCAuth: CA エージェントが登録要求を承認し、送信する必要がある場合に、このプラグインを使用します。
      • CMCUserSignedAuth: このプラグインを使用して、エージェント以外のユーザーが独自の証明書を登録できるようにします。
  5. OK をクリックします。プラグインエディターが閉じられ、新しいプロファイルが profiles タブに一覧表示されます。
  6. 新規プロファイルのポリシー、入力、および出力を設定します。一覧から新しいプロファイルを選択し、Edit/View をクリックします。
  7. Certificate Profile Rule Editor ウィンドウの Policies タブでポリシーを設定します。Policies タブには、プロファイルタイプに対してデフォルトで設定されているポリシーが一覧表示されます。
    1. ポリシーを追加するには、Add をクリックします。
    2. Default フィールドからデフォルトを選択し、Constraints フィールドでそのポリシーに関連付けられた制約を選択し、OK をクリックします。
    3. ポリシー設定 ID を入力します。デュアルキーペアを発行する場合には、個別のポリシーセットで、各証明書に関連付けられたポリシーを定義します。次に、証明書プロファイルポリシー ID と、証明書プロファイルポリシーの名前または識別子を入力します。
    4. Defaults タブおよび Constraints タブでパラメーターを設定します。
      Defaults は、証明書要求に設定する属性を定義します。これにより、証明書の内容が決定されます。これらは、拡張、有効期間、または証明書に含まれるその他のフィールドのいずれかになります。Constraints は、デフォルト値の有効な値を定義します。
      各デフォルトまたは制約の詳細は、「デフォルトの参照」 および 「制約の参照」 を参照してください。
    既存のポリシーを変更するには、ポリシーを選択し、Edit をクリックします。次に、そのポリシーのデフォルトおよび制約を編集します。
    ポリシーを削除するには、ポリシーを選択し、Delete をクリックします。
  8. Certificate Profile Rule Editor ウィンドウの Inputs タブに入力を設定します。プロファイルには複数の入力タイプが存在します。
    注記
    TMS サブシステムにプロファイルを設定しない場合は、cmcCertReqInput のみを選択して Delete ボタンをクリックし、他のプロファイルを削除します。
    1. 入力を追加するには、Add をクリックします。
    2. 一覧から入力を選択し、OK をクリックします。デフォルト入力の完全な詳細については、「入力の参照」 を参照してください。
    3. New Certificate Profile Editor ウィンドウが開きます。入力 ID を設定し、OK をクリックします。
    入力は追加および削除が可能です。入力の編集を選択することは可能ですが、入力にはパラメーターやその他の設定がないため、設定するものはありません。
    入力を削除するには、入力を選択し、Delete をクリックします。
  9. Certificate Profile Rule Editor ウィンドウの Outputs タブで、出力を設定します。
    自動認証方式を使用する証明書プロファイルには、出力を設定する必要があります。エージェントが承認した認証を使用する証明書プロファイルには、出力を設定する必要はありません。Certificate Output タイプはすべてのプロファイルでデフォルトで設定され、カスタムプロファイルに自動的に追加されます。
    TMS サブシステムにプロファイルを設定しない限り、certOutput のみを選択します。
    出力を追加または削除できます。出力の編集を選択することは可能ですが、出力にはパラメーターやその他の設定がないため、設定するものはありません。
    1. 出力を追加するには、Add をクリックします。
    2. 一覧から出力を選択し、OK をクリックします。
    3. 出力の名前または識別子を指定して、OK をクリックします。
      この出力は出力タブに一覧表示されます。これを編集して、この出力のパラメーターに値を指定できます。
    出力を削除するには、一覧から出力を選択して Delete をクリックします。
  10. CA を再起動して、新規プロファイルを適用します。 
    systemctl restart pki-tomcatd-nuxwdog@instance_name.service
  11. プロファイルを管理者として作成したら、CA エージェントはエージェントサービスページでプロファイルを承認してプロファイルを有効にする必要があります。
    1. CA のサービスページを開きます。 
      https://server.example.com:8443/ca/services
    2. 証明書プロファイルの管理 リンクをクリックします。このページには、アクティブと非アクティブの両方で、管理者によって設定されたすべての証明書プロファイルが一覧表示されます。
    3. 承認する証明書プロファイルの名前をクリックします。
    4. ページの下部で、Enable ボタンをクリックします。
注記
このプロファイルを TPS で使用する場合は、プロファイルタイプを認識するように TPS を設定する必要があります。これは 11.1.4. にあります。Red Hat Certificate System の計画、インストール、およびデプロイメントガイドのスマートカード CA プロファイルの管理
プロファイルの承認方法は、Red Hat Certificate System の計画、インストール、およびデプロイメントガイドのファイルシステムの証明書プロファイルの作成および編集のセクションで説明されているように、コマンドラインでのみプロファイルに追加できます。

3.2.2.2. コンソールでの証明書プロファイルの編集

たとえば、既存の証明書プロファイルを修正するには、以下の手順に従います。
  1. エージェントサービスページにログインし、プロファイルを無効にします。
    エージェントで証明書プロファイルを有効にすると、その証明書プロファイルは Certificate Profile Instance Management タブで有効とマークされ、コンソールを介して証明書プロファイルはいつでも編集できません。
  2. CertificateCertificate Systemnbsp;System CA サブシステムのコンソールにログインします。 
    pkiconsole https://server.example.com:8443/ca
  3. Configuration タブで Certificate Manager を選択し、Certificate Profiles を選択します。
  4. 証明書のプロファイルを選択し、Edit/View をクリックします。
  5. Certificate Profile Rule Editor ウィンドウが表示されます。多くのデフォルト、制約、入力、または出力が変更されています。
    注記
    プロファイルインスタンス ID は変更しないでください。
    必要に応じて、ウィンドウの隅の 1 つを引っ張って、ウィンドウを拡大します。
  6. CA を再起動して変更を適用します。
  7. エージェントサービスページで、プロファイルを再度有効にします。
注記
エージェントによって承認されない証明書プロファイルを削除します。Certificate Profile Instance Management タブに表示される証明書プロファイルも、エージェントサービスインターフェイスに表示されます。プロファイルがすでに有効になっている場合は、プロファイルリストから削除する前に、エージェントによって無効にする必要があります。

3.2.3. 証明書の登録プロファイルの一覧表示

この環境では、CertificateCertificate Systemnbsp;System CA をインストールすると、以下の定義済み証明書プロファイルがすぐに使用設定できるようになります。これらの証明書プロファイルは、最も一般的なタイプの証明書用に設計されており、一般的なデフォルト、制約、認証方法、入力、および出力を提供します。
コマンドラインで利用可能なプロファイルを一覧表示するには、pki ユーティリティーを使用します。以下に例を示します。 
# pki -c password -n caadmin ca-profile-find
------------------
59 entries matched
------------------
  Profile ID: caCMCserverCert
  Name: Server Certificate Enrollment using CMC
  Description: This certificate profile is for enrolling server certificates using CMC.

  Profile ID: caCMCECserverCert
  Name: Server Certificate wth ECC keys Enrollment using CMC
  Description: This certificate profile is for enrolling server certificates with ECC keys using CMC.

  Profile ID: caCMCECsubsystemCert
  Name: Subsystem Certificate Enrollment with ECC keys using CMC
  Description: This certificate profile is for enrolling subsystem certificates with ECC keys using CMC.

  Profile ID: caCMCsubsystemCert
  Name: Subsystem Certificate Enrollment using CMC
  Description: This certificate profile is for enrolling subsystem certificates using CMC.

  ...
-----------------------------
Number of entries returned 20
詳細は、pki-ca-profile(1) の man ページを参照してください。追加の情報は、『Red Hat Certificate System 計画、インストール、およびデプロイメントガイド』を参照してください。

3.2.4. 証明書登録プロファイルの詳細表示

たとえば、caECFullCMCUserSignedCert などの特定の証明書プロファイルを表示するには、次のコマンドを実行します。 
$ pki -c password -n caadmin ca-profile-show caECFullCMCUserSignedCert
-----------------------------------
Profile "caECFullCMCUserSignedCert"
-----------------------------------
  Profile ID: caECFullCMCUserSignedCert
  Name: User-Signed CMC-Authenticated User Certificate Enrollment
  Description: This certificate profile is for enrolling user certificates with EC keys by using the CMC certificate request with non-agent user CMC authentication.

  Name: Certificate Request Input
  Class: cmcCertReqInputImpl

    Attribute Name: cert_request
    Attribute Description: Certificate Request
    Attribute Syntax: cert_request

  Name: Certificate Output
  Class: certOutputImpl

    Attribute Name: pretty_cert
    Attribute Description: Certificate Pretty Print
    Attribute Syntax: pretty_print

    Attribute Name: b64_cert
    Attribute Description: Certificate Base-64 Encoded
    Attribute Syntax: pretty_print
たとえば、caECFullCMCUserSignedCert などの特定の証明書プロファイルを表示するには、次のコマンドを raw 形式で実行します。 
$ pki -c password -n caadmin ca-profile-show caECFullCMCUserSignedCert --raw
#Wed Jul 25 14:41:35 PDT 2018
auth.instance_id=CMCUserSignedAuth
policyset.cmcUserCertSet.1.default.params.name=
policyset.cmcUserCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl
policyset.cmcUserCertSet.6.default.params.keyUsageKeyCertSign=false
policyset.cmcUserCertSet.10.default.class_id=noDefaultImpl
policyset.cmcUserCertSet.10.constraint.name=Renewal Grace Period Constraint
output.o1.class_id=certOutputImpl

...
詳細は、pki-ca-profile(1) の man ページを参照してください。

3.3. プロファイルでの鍵のデフォルトの定義

証明書プロファイルの作成時に サブジェクトキー識別子のデフォルトの前にキーのデフォルトを追加する必要があります。CertificateCertificate Systemnbsp;System は、Subject Key Identifier Default の作成または適用前に Key Default のキー制約を処理するので、キーがまだ処理されていない場合、サブジェクト名へのキー設定は失敗します。
たとえば、object-signing プロファイルでは両方のデフォルト値を定義できます。 
policyset.set1.p3.constraint.class_id=noConstraintImpl
policyset.set1.p3.constraint.name=No Constraint
policyset.set1.p3.default.class_id=subjectKeyIdentifierExtDefaultImpl
policyset.set1.p3.default.name=Subject Key Identifier Default
...
policyset.set1.p11.constraint.class_id=keyConstraintImpl
policyset.set1.p11.constraint.name=Key Constraint
policyset.set1.p11.constraint.params.keyType=RSA
policyset.set1.p11.constraint.params.keyParameters=1024,2048,3072,4096
policyset.set1.p11.default.class_id=userKeyDefaultImpl
policyset.set1.p11.default.name=Key Default
policyset リストでは、サブジェクトキー識別子のデフォルト (p3) の前にキーのデフォルト (p11) を指定する必要があります。 
policyset.set1.list=p1,p2,p11,p3,p4,p5,p6,p7,p8,p9,p10

3.4. 更新を有効にするためのプロファイルの設定

本セクションでは、証明書更新にプロファイルを設定する方法を説明します。証明書の更新方法は、「証明書の更新」 を参照してください。
更新を許可するプロファイルは、updateGracePeriodConstraint エントリーで頻繁に発生します。以下に例を示します。 
policyset.cmcUserCertSet.10.constraint.class_id=renewGracePeriodConstraintImpl
policyset.cmcUserCertSet.10.constraint.name=Renewal Grace Period Constraint
policyset.cmcUserCertSet.10.constraint.params.renewal.graceBefore=30
policyset.cmcUserCertSet.10.constraint.params.renewal.graceAfter=30
policyset.cmcUserCertSet.10.default.class_id=noDefaultImpl
policyset.cmcUserCertSet.10.default.name=No Default

3.4.1. 同じ鍵を使用した更新

更新に同じキーの送信を可能にするプロファイルで、uniqueKeyConstraint エントリーの allowSameKeyRenewal パラメーターが true に設定されています。以下に例を示します。 
policyset.cmcUserCertSet.9.constraint.class_id=uniqueKeyConstraintImpl
policyset.cmcUserCertSet.9.constraint.name=Unique Key Constraint
policyset.cmcUserCertSet.9.constraint.params.allowSameKeyRenewal=true
policyset.cmcUserCertSet.9.default.class_id=noDefaultImpl
policyset.cmcUserCertSet.9.default.name=No Default

3.4.2. 新しい鍵を使用した更新

新しい鍵で証明書を更新するには、新しいキーで同じプロファイルを使用します。Certificate System は、新しい証明書の要求の署名に使用されるユーザー署名証明書の subjectDN を使用します。

3.5. 証明書の署名アルゴリズムの設定

CA の署名証明書は、CA でサポートされる公開鍵アルゴリズムに問題がある証明書に署名できます。たとえば、ECC 署名証明書は、ECC アルゴリズムと RSA アルゴリズムの両方が CA でサポートされている限り、ECC 証明書要求と RSA 証明書要求の両方に署名できます。RSA 署名証明書は EC キーを使用して PKCS # 10 要求に署名できますが、CA が CRMF 所有証明 (POP) を検証するために ECC モジュールを使用できない場合は、EC キーを使用して CRMF 証明書要求に署名できない場合があります。
ECC および RSA は、公開鍵の暗号化と署名アルゴリズムです。両方の公開鍵アルゴリズムは、異なる暗号スイートをサポートします。これは、データの暗号化と復号に使用されるアルゴリズムです。CA 署名証明書の機能には、対応している暗号スイートのいずれかを使用して、証明書を発行し、署名することです。
各プロファイルは、CA がそのプロファイルで処理される証明書の署名に使用する暗号化スイートを定義できます。署名アルゴリズムが設定されていない場合、プロファイルはデフォルトの署名アルゴリズムを使用します。

3.5.1. CA のデフォルト署名アルゴリズムの設定

  1. CA コンソールを開きます。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、Certificate Manager ツリーを展開します。
  3. General Settings タブで、Algorithm ドロップダウンメニューで使用するアルゴリズムを設定します。

3.5.2. プロファイルでの署名アルゴリズムのデフォルトの設定

各プロファイルには、Signing Algorithm Default 拡張が定義されています。デフォルトには、デフォルトのアルゴリズムと、証明書要求で別のアルゴリズムが指定されている場合に許可されるアルゴリズムのリストの 2 つの設定があります。署名アルゴリズムが指定されていない場合、プロファイルは CA のデフォルトとして設定されているものを使用します。
プロファイルの .cfg ファイルで、アルゴリズムは 2 つのパラメーターで設定されます。 
policyset.cmcUserCertSet.8.constraint.class_id=signingAlgConstraintImpl
policyset.cmcUserCertSet.8.constraint.name=No Constraint
policyset.cmcUserCertSet.8.constraint.params.signingAlgsAllowed=SHA256withRSA,SHA512withRSA,SHA256withEC,SHA384withRSA,SHA384withEC,SHA512withEC
policyset.cmcUserCertSet.8.default.class_id=signingAlgDefaultImpl
policyset.cmcUserCertSet.8.default.name=Signing Alg
policyset.cmcUserCertSet.8.default.params.signingAlg=-
コンソールから Signing Algorithm Default を設定するには、以下を行います。
注記
プロファイルを編集する前に、エージェントにより最初に無効にする必要があります。
  1. CA コンソールを開きます。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、Certificate Manager ツリーを展開します。
  3. Certificate Profiles 項目をクリックします。
  4. Policies タブをクリックします。
  5. Signing Alg ポリシー を選択し、Edit ボタンをクリックします。
  6. デフォルトの署名アルゴリズムを設定するには、Defaults タブで値を設定します。これが - に設定されている場合、プロファイルは CA のデフォルトを使用します。
  7. 証明書要求で許可される署名アルゴリズムの一覧を設定するには、Constraints タブを開き、singiningAlgsAllowed の Value フィールドでアルゴリズムの一覧を設定します。
    制約に使用できる値は、「アルゴリズム制約の署名」 に記載されています。

3.7. サブジェクト名およびサブジェクト代替名の管理

証明書の サブジェクト名 は、証明書を発行するエンティティーの ID 情報が含まれる識別名 (DN) です。このサブジェクト名は、共通名や組織単位などの標準の LDAP ディレクトリーコンポーネントから構築できます。これらのコンポーネントは X.500 に定義されます。サブジェクト名の他に、証明書には サブジェクト代替名 があります。これは、X.500 に定義されていない追加情報が含まれる証明書の拡張機能セットです。
サブジェクト名とサブジェクトの代替名の命名コンポーネントはカスタマイズできます。
重要
サブジェクト名が空の場合は、Subject Alternative Name 拡張が存在し、critical のマークが付けられている必要があります。

3.7.1. サブジェクト名でのリクエスター CN または UID の使用

証明書要求の cn 値または uid 値は、発行した証明書のサブジェクト名をビルドするために使用できます。このセクションでは、サブジェクト名制約に naming 属性 (CN または UID) が証明書要求に存在する必要があるプロファイルを示しています。naming 属性がないと、リクエストは拒否されます。
この設定には、以下の 2 つの部分があります。
  • CN または UID 形式は、Subject Name Constraint の pattern 設定に設定されます。
  • CN または UID トークン、および証明書の特定の接尾辞を含むサブジェクト DN の形式は、Subject Name Default に設定されます。
たとえば、サブジェクト DN で CN を使用するには、次のコマンドを実行します。 
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,DC=example, DC=com
この例では、リクエストに cn=John Smith の CN が含まれる場合、証明書は、cn=John Smith,DC=example, DC=com のサブジェクト DN で発行されます。要求が完了しても、uid=jsmith の UID があり CN がない場合、要求は拒否されます。
同じ設定を使用して、要求側の UID をサブジェクト DN にプルします。 
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=UID=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=UID=$request.req_subject_name.uid$,DC=example, DC=com
pattern パラメーターの形式は、「Subject Name 制約」 および 「サブジェクト名のデフォルト」 で説明されています。

3.7.2. サブジェクト代替名への LDAP ディレクトリー属性値およびその他の情報の挿入

LDAP ディレクトリーからの情報、または要求元によって送信された情報は、Subject Alt Name Extension Default 設定で一致する変数を使用して、証明書のサブジェクト代替名に挿入できます。デフォルトでは、情報のタイプ (形式) と、情報の取得に使用する一致するパターン (変数) を設定します。以下に例を示します。 
policyset.userCertSet.8.default.class_id=subjectAltNameExtDefaultImpl
policyset.userCertSet.8.default.name=Subject Alt Name Constraint
policyset.userCertSet.8.default.params.subjAltNameExtCritical=false
policyset.userCertSet.8.default.params.subjAltExtType_0=RFC822Name
policyset.userCertSet.8.default.params.subjAltExtPattern_0=$request.requestor_email$
policyset.userCertSet.8.default.params.subjAltExtGNEnable_0=true
これにより、要求側の電子メールがサブジェクト名の最初の CN コンポーネントとして挿入されます。追加のコンポーネントを使用するには、Type_、Pattern_、および Enable_ 値を、Type_1 などの数値にインクリメントします。
サブジェクトの alt 名の設定については、「サブジェクト代替名の拡張機能のデフォルト」 を参照してください。
LDAP コンポーネントを証明書のサブジェクト代替名に挿入するには、以下を実行します。
  1. LDAP 属性値を挿入するには、ユーザーディレクトリーの認証プラグイン SharedSecret を有効にする必要があります。
    1. CA コンソールを開きます。 
      pkiconsole https://server.example.com:8443/ca
    2. 左側のナビゲーションツリーで 認証 を選択します。
    3. Authentication Instance タブで、Add をクリックし、SharedSecret 認証プラグインのインスタンスを追加します。
    4. 以下の情報を入力します。 
      Authentication InstanceID=SharedToken
shrTokAttr=shrTok
ldap.ldapconn.host=server.example.com
ldap.ldapconn.port=636
ldap.ldapconn.secureConn=true
ldap.ldapauth.bindDN=cn=Directory Manager
password=password
ldap.ldapauth.authtype=BasicAuth
ldap.basedn=ou=People,dc=example,dc=org
    5. 新規プラグインインスタンスを保存します。
    JOIN 共有トークンの設定に関する詳細は、「CMC 共有シークレットの設定」 を参照してください。
  2. ldapStringAttributes パラメーターは、ユーザーの LDAP エントリーから mail 属性の値を読み込み、その値を証明書要求に追加するよう、認証プラグインに指示します。値が要求に設定されている場合、証明書プロファイルポリシーは、拡張値のその値を挿入するように設定できます。
    dnpattern パラメーターの形式は、「Subject Name 制約」 および 「サブジェクト名のデフォルト」 で説明されています。
  3. CA が証明書拡張機能に LDAP 属性の値を挿入できるようにするには、プロファイルの設定ファイルを編集し、拡張機能のポリシーセットパラメーターを挿入します。たとえば、caFullCMCSharedTokenCert プロファイルの Subject Alternative Name 拡張に mail 属性値を挿入するには、以下のコードを変更します。 
    policyset.setID.8.default.params.subjAltExtPattern_0=$request.auth_token.mail[0]$
    プロファイルの編集に関する詳細は、「RAW 形式での証明書プロファイルの編集」 を参照してください。
  4. CA を再起動します。 
    systemctl restart pki-tomcatd-nuxwdog@instance_name.service
この例では、caFullCMCSharedTokenCert プロファイル登録フォームを介して送信される証明書では、要求側の mail LDAP 属性の値で Subject Alternative Name 拡張機能が追加されます。以下に例を示します。 
Identifier: Subject Alternative Name - 2.5.29.17
    Critical: no
    Value:
    RFC822Name: jsmith@example.com
このポリシーセットのいずれかの Pattern_ パラメーターにトークン ($X$) として設定することにより、証明書に自動的に挿入できる属性が多数あります。一般的なトークンは 表3.1「証明書の設定に使用する変数」 に一覧表示され、デフォルトのプロファイルにはこれらのトークンの使用方法の例が含まれています。

表3.1 証明書の設定に使用する変数

ポリシーセットトークン 説明
$request.auth_token.cn[0]$ 証明書を要求したユーザーの LDAP 共通名 (cn) 属性。
$request.auth_token.mail[0]$ 証明書を更新したユーザーの LDAP メール (mail) 属性の値。
$request.auth_token.tokencertsubject$ 証明書サブジェクト名。
$request.auth_token.uid$ 証明書を要求したユーザーの LDAP ユーザー ID (uid) 属性。
$request.auth_token.userdn$ 証明書を要求したユーザーのユーザー DN。
$request.auth_token.userid$ 証明書を要求したユーザーのユーザー ID 属性の値。
$request.uid$ 証明書を要求したユーザーのユーザー ID 属性の値。
$request.requestor_email$ 要求を送信したユーザーのメールアドレス。
$request.request_name$ 要求を送信した人。
$request.upn$ Microsoft UPN。これには (UTF8String)1.3.6.1.4.1.311.20.2.3,$request.upn$ の形式があります。
$server.source$ サーバーに対し、サブジェクト名のバージョン 4 の UUID (乱数) コンポーネントを生成するように指示します。この値は常に (IA5String)1.2.3.4,$server.source$ 形式になります。
$request.auth_token.user$ 要求が TPS によって送信された場合に使用します。証明書をリクエストした TPS サブシステム信頼マネージャー。
$request.subject$ 要求が TPS によって送信された場合に使用します。TP S が解決して要求したエンティティーのサブジェクト名 DN。例: cn=John.Smith.123456789,o=TMS Org

3.7.3. SAN 拡張での CN 属性の使用

RFC 2818 で非推奨となったドメイン名の検証に、サブジェクト DN の Common Name (CN) 属性の使用に対応しなくなりました。代わりに、これらのアプリケーションやライブラリーは、証明書要求で dNSName の Subject Alternative Name (SAN) の値を使用します。
Certificate System は、RFC 1034 セクション 3.5 に従って優先名前構文と一致し、複数のコンポーネントを持つ場合にのみ CN をコピーします。また、既存の SAN 値が保持されます。たとえば、CN をベースとする dNSName 値は、既存の SAN に追加されます。
SAN 拡張の CN 属性を使用するように Certificate System を設定するには、証明書を発行するために使用する証明書プロファイルを編集します。以下に例を示します。
  1. プロファイルを無効にします。 
    # pki -c password -p 8080 \
     -n "PKI Administrator for example.com" ca-profile-disable profile_name
  2. プロファイルを編集します。 
    # pki -c password -p 8080 \
     -n "PKI Administrator for example.com" ca-profile-edit profile_name
    1. プロファイルに固有のセット番号を使用して、以下の設定を追加します。以下に例を示します。 
      policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl
policyset.serverCertSet.12.default.name=Copy Common Name to Subject
      前述の例では、12 をセット番号として使用しています。
    2. policyset.userCertSet.list パラメーターに新しいポリシーセット番号を追加します。以下に例を示します。 
      policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9,12
    3. プロファイルを保存します。
  3. プロファイルを有効にします。 
    # pki -c password -p 8080 \
     -n "PKI Administrator for example.com" ca-profile-enable profile_name
注記
すべてのデフォルトサーバーグループに、commonNameToSANDefaultImpl のデフォルトが含まれます。

3.7.4. CSR からの SAN 拡張の許可

特定の環境では、管理者は Certificate Signing Request (CSR) で Subject Alternative Name (SAN) 拡張機能を指定できるようにします。

3.7.4.1. CSR から SAN を取得するプロファイルの設定

CSR からの SAN の取得を許可するには、ユーザー拡張機能のデフォルトを使用します。詳細は、「User Supplied Extension Default」を参照してください。
注記
SAN 拡張には、1 つ以上の SAN を含めることができます。
CSR から SAN を受け入れるには、caCMCECserverCert のように、以下のデフォルトおよび制約をプロファイルに追加します。 
prefix.constraint.class_id=noConstraintImpl
prefix.constraint.name=No Constraint

prefix.default.class_id=userExtensionDefaultImpl
prefix.default.name=User supplied extension in CSR
prefix.default.params.userExtOID=2.5.29.17

3.7.4.2. SAN を使用した CSR の生成

たとえば、certutil ユーティリティーを使用して、2 つの SAN を持つ CSR を生成するには、以下を実行します。 
# certutil -R -k ec -q nistp256 -d . -s "cn=Example Multiple SANs" --extSAN dns:www.example.com,dns:www.example.org -a -o /root/request.csr.p10
CSR の生成後に、「CMC 登録プロセス」 で説明されている手順に従って、CMC の登録を完了します。

第4章 キーアーカイブおよびリカバリーの設定

キーアーキタイプおよびリカバリーの詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『キーのアーカイブ、リカバリー、およびローテーション』セクションを参照してください。
この章では、以前は Data Recovery Manager (DRM) と呼ばれていた Key Recovery Authority (KRA) を設定して、秘密鍵をアーカイブし、暗号化されたデータを復元するためにアーカイブされた鍵を回復する方法を説明します。
注記
本章では、クライアント側の鍵生成を使用した鍵のアーカイブのみを説明します。サーバー側のキーの生成とアーカイブは、TPS を介して開始されたか、CA のエンドエンティティーポータルを介して開始されたかにかかわらず、ここでは説明しません。
スマートカード鍵のリカバリーの詳細は、「サーバー側の鍵生成の設定」 を参照してください。
CA の EE ポータルで提供されるサーバー側の鍵生成に関する詳細は、「サーバー側の鍵生成を使用した CSR の生成」 を参照してください。
注記
Gemalto SafeNet LunaSA は、CKE - Key Export モデルでの PKI 秘密鍵抽出のみおよび 非 FIPS モードでのみサポートされます。FIPS モードの LunaSA Cloning モデルおよび CKE モデルは、PKI 秘密鍵の抽出をサポートしません。
KRA がインストールされると、セキュリティードメインに参加し、CA とペアになります。このような場合、秘密暗号化キーをアーカイブおよび復元するように設定されています。ただし、KRA 証明書がセキュリティードメイン内の CA のいずれかではなく外部 CA によって発行される場合は、キーのアーカイブとリカバリープロセスを手動で設定する必要があります。
詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『キーアーカイブの手動設定』セクションを参照してください。
注記
クローン環境では、キーのアーカイブとリカバリーを手動で設定する必要があります。詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『クローン後の CA-KRA コネクター情報の更新』セクションを参照してください。

4.1. コンソールでのエージェント承認キーリカバリーの設定

注記
コンソールでキーリカバリーエージェントの 数 を設定できますが、使用する グループ は CS.cfg ファイルで直接設定できます。コンソールはデフォルトで Key Recovery Authority Agents グループ を使用します。
  1. KRA のコンソールを開きます。以下に例を示します。 
    pkiconsole https://server.example.com:8443/kra
  2. 左側のナビゲーションツリーの Key Recovery Authority のリンクをクリックします。
  3. Required Number of Agents フィールドに、キー復元を承認するのに使用するエージェントの数を入力します。
注記
エージェントが承認したキー復元を CS.cfg ファイルで設定する詳細な方法は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『コマンドラインでのエージェント承認キーリカバリーの設定』を参照してください。

4.2. キーアーカイブおよびリカバリー設定のテスト

注記
新しいブラウザーは、ブラウザーからのキーのアーカイブをサポートしていません。ステップ 1 では、これらのブラウザーの代わりに、『CRMF 生成クライアント』を使用する必要があります。
鍵を正常にアーカイブできるかどうかをテストするには、次を実行します。
  1. CA の Manual User Signing & Encryption Certificates Enrollment フォームを使用して、二重証明書に登録します。
  2. 要求を送信します。エージェントサービスページにログインし、要求を承認します。
  3. エンドエンティティーのページにログインし、証明書が発行されたかどうかを確認します。証明書のリストでは、連続するシリアル番号を持つ新しい証明書が 2 つあります。
  4. Web ブラウザーに証明書をインポートします。
  5. 鍵がアーカイブされたことを確認します。KRA のエージェントサービスページで、Show completed requests を選択します。キーが正常にアーカイブされた場合は、そのキーに関する情報が生成されます。キーが表示されない場合は、ログを確認して、問題を修正します。キーが正常にアーカイブされたら、ブラウザーウィンドウを閉じます。
  6. 鍵を確認します。署名付きで暗号化された電子メールを送信します。メールを受信したら、メッセージを確認して開き、メッセージが署名されて暗号化されているかどうかを確認します。メッセージウィンドウの右上隅に、メッセージが署名されて暗号化されていることを示すセキュリティーアイコンがあるはずです。
  7. 証明書を削除します。暗号化された電子メールを再度確認します。メールクライアントはメッセージを復号できないはずです。
  8. アーカイブされた鍵を正常に復元できるかどうかをテストします。
    1. KRA のエージェントサービスページを開き、Recover Keys リンクをクリックします。キーの所有者、シリアル番号、または公開鍵で鍵を検索します。キーが正常にアーカイブされた場合は、キー情報が表示されます。
    2. Recover をクリックします。
    3. 表示される形式で、復元する秘密鍵に対応する base-64 でエンコードされた証明書を入力します。この情報を取得するには CA を使用します。base-64 でエンコードされた証明書を指定してアーカイブされた鍵を検索する場合は、ここで証明書を指定する必要はありません。
    4. リカバリーの実行中にブラウザーセッションが閉じられるように Async Recovery チェックボックスが選択されていることを確認してください。
      ヒント
      非同期リカバリーはデフォルトであり、キーのリカバリーを実行するのに推奨される方法です。同期キーリカバリーを実行する場合、ブラウザーウィンドウはシャットダウンできず、リカバリープロセス中に KRA を停止できません。
    5. エージェントスキームに応じて、指定された数のエージェントがこの鍵のリカバリーを承認する必要があります。エージェントに、リカバリーキーを検索してもらい、開始された回復を承認してもらいます。
    6. すべてのエージェントがリカバリーを承認すると、次の画面は、証明書で PKCS #12 ファイルを暗号化するようにパスワードを要求します。
    7. 次の画面は、復元されたキーペアを含む PKCS #12 ブロブをダウンロードするリンクを返します。リンクに従い、blob をファイルに保存します。
      重要
      gcr-viewer ユーティリティーでブラウザーから直接 PKCS #12 ファイルを開くと、特定の状況で失敗する可能性があります。この問題を回避するには、gcr-viewer ファイルをダウンロードし、手動で開きます。
  9. ブラウザーのデータベースに鍵を復元します。ブラウザーおよびメールクライアントに .p12 ファイルをインポートします。
  10. テストメールを開きます。メッセージは再度表示されます。

第5章 証明書の要求、登録、および管理

証明書は要求され、エンドユーザーに使用されます。証明書登録および更新は管理者に限定されていませんが、登録プロセスおよび更新プロセスを理解すると、「証明書プロファイルの設定」 で説明されているように、管理者が適切な証明書プロファイルを管理および作成でき、各証明書タイプに対して適切な認証方法 (9章証明書を登録するための認証 を参照) しやすくなります。
この章では、CertificateCertificate Systemnbsp;System の外部で使用するための証明書の要求、受信、および更新について説明します。CertificateCertificate Systemnbsp;System サブシステム証明書の要求と更新については、16章サブシステム証明書の管理 を参照してください。

5.1. 証明書の登録および更新について

登録 とは、証明書の要求および受信のプロセスです。登録プロセスの仕組みは、証明書の種類、キーペアの生成方法、および証明書自体の生成と承認の方法によってわずかに異なります。特定の方法が何であれ、高レベルでの証明書の登録には、同じ基本的な手順があります。
  1. 証明書要求 (CSR) が生成されます。
  2. 証明書要求が CA に送信されます。
  3. 要求は、要求したエンティティーを認証し、それを提出するために使用された証明書プロファイルのルールを満たしていることを要求が確認することで検証されます。
  4. リクエストが承認されている。
  5. 要求側は新しい証明書を取得します。
証明書の有効期間が終了すると、証明書を更新できます。

5.2. 証明書署名リクエストの作成

従来は、証明書要求 (CSR) の生成には以下の方法が使用されます。
  • コマンドラインユーティリティーを使用した CSR の生成
  • 補助ブラウザー内での CSR の生成
  • サーバーのインストーラーなど、アプリケーション内での CSR の生成
これらの方法の一部は CSR の直接送信をサポートしますが、含まれない場合があります。
RHCS 9.7 以降、サーバー側のキー生成がサポートされ、Firefox v69 以降や Chrome などの新しいバージョンのブラウザー内でのキー生成サポートの削除によってもたらされる不便を克服します。このため、本セクションでは、キー生成のブラウザーサポートについて説明しません。これらのブラウザーの古いバージョンが古い RHCS ドキュメントで指定されているように機能し続けるべきではないと信じる理由はありませんが。
通常、アプリケーションから生成された CSR は PKCS#10 の形式を取ります。それらが正しく生成されると、RHCS によりサポートされるはずです。
次のサブセクションでは、RHCS でサポートされている次の方法を説明します。
  • コマンドラインユーティリティー
  • サーバー側の鍵生成

5.2.1. コマンドラインユーティリティーを使用した CSR の生成

Red Hat Certificate System は、以下のユーティリティーを使用した CSR の作成をサポートします。
  • certutil: PKCS #10 リクエストの作成に対応します。
  • PKCS10Client: PKCS #10 リクエストの作成に対応します。
  • CRMFPopClient: CRMF 要求の作成をサポートします。
  • pki client-cert-request: PKCS#10 および CRMF リクエストの両方をサポートします。
次のセクションでは、これらのユーティリティーを機能豊富な登録プロファイルフレームワークで使用する方法の例をいくつか示します。

5.2.1.1. certutil を使用した CSR の作成

本セクションでは、certutil ユーティリティーを使用して CSR を作成する方法を説明します。
certutil の使用の詳細は、以下を参照してください。
  • certutil(1) の man ページを参照してください。
  • certutil --help コマンドの出力
5.2.1.1.1. certutil を使用した EC キーで CSR の作成
以下の手順は、certutil ユーティリティーを使用して Elliptic Curve(EC) キーペアと CSR を作成する方法を示しています。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. バイナリー CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ certutil -d . -R -k ec -q nistp256 -s "CN=subject_name" -o /user_or_entity_database_directory/request-bin.csr
    プロンプトが表示されたら、必要な NSS データベースのパスワードを入力します。
    パラメーターの詳細は、certutil(1) の man ページを参照してください。
  3. 作成したバイナリー形式の CSR を PEM 形式に変換します。 
    $ BtoA /user_or_entity_database_directory/request-bin.csr /user_or_entity_database_directory/request.csr
  4. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/request.csr

		MIICbTCCAVUCAQAwKDEQMA4GA1UEChMHRXhhbXBsZTEUMBIGA1UEAxMLZXhhbXBs
		...
    これは、PKCS#10 PEM 証明書要求です。
5.2.1.1.2. certutil を使用したユーザー定義拡張による CSR の作成
以下の手順は、certutil ユーティリティーを使用してユーザー定義の拡張で CSR を作成する方法を示しています。
登録要求は、CA で定義された登録プロファイルにより制限されることに注意してください。例B.3「CSR の Multiple User Supplied Extension」を参照してください。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. ユーザー定義の Extended Key Usage 拡張とユーザー定義の Key Usage 拡張で CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ certutil -d . -R -k rsa -g 1024 -s "CN=subject_name" --keyUsage keyEncipherment,dataEncipherment,critical --extKeyUsage timeStamp,msTrustListSign,critical -a -o /user_or_entity_database_directory/request.csr
    プロンプトが表示されたら、必要な NSS データベースのパスワードを入力します。
    パラメーターの詳細は、certutil(1) の man ページを参照してください。
  3. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/request.csr
		Certificate request generated by NSS certutil
		Phone: (not specified)

		Common Name: user 4-2-1-2
		Email: (not specified)
		Organization: (not specified)
		State: (not specified)
		Country: (not specified)
    これは、PKCS#10 PEM 証明書要求です。

5.2.1.2. PKCS10Client を使用した CSR の作成

本セクションでは、PKCS10Client ユーティリティーを使用して CSR を作成する方法を説明します。
PKCS10Client の使用に関する詳細は、以下を参照してください。
  • PKCS10Client(1) の man ページを参照してください。
  • PKCS10Client --help コマンドの出力
5.2.1.2.1. PKCS10Client を使用した CSR の作成
以下の手順では、PKCS10Client ユーティリティーを使用して Elliptic Curve (EC) キーペアと CSR を作成する方法を説明します。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ PKCS10Client -d . -p NSS_password -a ec -c nistp256 -o /user_or_entity_database_directory/example.csr -n "CN=subject_name"
    パラメーターの詳細は、PKCS10Client(1) の man ページを参照してください。
  3. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----
5.2.1.2.2. PKCS10Client を使用した SharedSecret ベースの CMC の CSR の作成
以下の手順では、PKCS10Client ユーティリティーを使用して、SharedSecret ベースの CMC 用の RSA 鍵ペアと CSR を作成する方法を説明します。これは、デフォルトでは caFullCMCSharedTokenCert プロファイルおよび caECFullCMCSharedTokenCert プロファイルによって処理される CMC 共有 Secret 認証方法にのみ使用します。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ PKCS10Client -d . -p NSS_password -o /user_or_entity_database_directory/example.csr -y true -n "CN=subject_name"
    パラメーターの詳細は、PKCS10Client(1) の man ページを参照してください。
  3. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----

5.2.1.3. CRMFPopClient を使用した CSR の作成

Certificate Request Message Format (CRMF) は、CMC で受け入れられている CSR 形式であり、主要なアーカイブ情報を要求に安全に埋め込むことができます。
本セクションでは、CRMFPopClient ユーティリティーを使用して CSR を作成する方法を説明します。
CRMFPopClient の詳細な使用方法は、CRMFPopClient(1) の man ページを参照してください。
5.2.1.3.1. CRMFPopClient を使用したキー Archival を持つ CSR の作成
以下の手順では、CRMFPopClient ユーティリティーを使用して RSA キーペアと、鍵アーカイブオプションで CSR を作成する方法を説明します。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. KRA トランスポート証明書を取得します。 
    $ pki ca-cert-find --name "DRM Transport Certificate"
		---------------
		1 entries found
		---------------
			Serial Number: 0x7
			Subject DN: CN=DRM Transport Certificate,O=EXAMPLE
			Status: VALID
			Type: X.509 version 3
			Key A    lgorithm: PKCS #1 RSA with 2048-bit key
			Not Valid Before: Thu Oct 22 18:26:11 CEST 2015
			Not Valid After: Wed Oct 11 18:26:11 CEST 2017
			Issued On: Thu Oct 22 18:26:11 CEST 2015
			Issued By: caadmin
		----------------------------
		Number of entries returned 1
  3. KRA トランスポート証明書をエクスポートします。 
    $ pki ca-cert-show 0x7 --output kra.transport
  4. CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -v -o /user_or_entity_database_directory/example.csr
    Elliptic Curve (EC) キーペアと CSR を作成するには、-a ec -t false オプションをコマンドに渡します。
    パラメーターの詳細は、CRMFPopClient(1) の man ページを参照してください。
  5. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----
5.2.1.3.2. CRMFPopClient を使用した SharedSecret ベースの CMC の CSR の作成
以下の手順では、CRMFPopClient ユーティリティーを使用して、SharedSecret ベースの CMC 用の RSA 鍵ペアと CSR を作成する方法を説明します。これは、デフォルトでは caFullCMCSharedTokenCert プロファイルおよび caECFullCMCSharedTokenCert プロファイルによって処理される CMC 共有 Secret 認証方法にのみ使用します。
  1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
    $ cd /user_or_entity_database_directory/
  2. KRA トランスポート証明書を取得します。 
    $ pki ca-cert-find --name "DRM Transport Certificate"
		---------------
		1 entries found
		---------------
			Serial Number: 0x7
			Subject DN: CN=DRM Transport Certificate,O=EXAMPLE
			Status: VALID
			Type: X.509 version 3
			Key A    lgorithm: PKCS #1 RSA with 2048-bit key
			Not Valid Before: Thu Oct 22 18:26:11 CEST 2015
			Not Valid After: Wed Oct 11 18:26:11 CEST 2017
			Issued On: Thu Oct 22 18:26:11 CEST 2015
			Issued By: caadmin
		----------------------------
		Number of entries returned 1
  3. KRA トランスポート証明書をエクスポートします。 
    $ pki ca-cert-show 0x7 --output kra.transport
  4. CSR を作成し、これを /user_or_entity_database_directory/request.csr ファイルに保存します。 
    $ CRMFPopClient -d . -p password -n "cn=subject_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" -y -v -o /user_or_entity_database_directory/example.csr
    EC キーペアと CSR を作成するには、コマンドに -a ec -t false オプションを渡します。
    パラメーターの詳細は、CRMFPopClient --help コマンドの出力を参照してください。
  5. 必要に応じて、CSR ファイルが正しいことを確認します。 
    $ cat /user_or_entity_database_directory/example.csr
		-----BEGIN CERTIFICATE REQUEST-----
		MIICzzCCAbcCAQAwgYkx
		...
		-----END CERTIFICATE REQUEST-----

5.2.1.4. PKI CLI での client-cert-request を使用した CSR の作成

pkiコマンドラインツールは、client-cert-request コマンドで使用して CSR を生成することもできます。ただし、前述のツールとは異なり、pki で 生成された CSR は CA に直接送信されます。PKCS#10 または CRMF 要求の両方を生成できます。
PKCS#10 要求の生成例: 
pki -d user token db directory -P https -p 8443 -h host.test.com -c user token db passwd client-cert-request "uid=test2" --length 4096 --type pkcs10
CRMF リクエストの生成例: 
pki -d user token db directory -P https -p 8443 -h host.test.com -c user token db passwd client-cert-request "uid=test2" --length 4096 --type crmf
成功するとリクエスト ID が返されます。
要求が送信されると、エージェントは pki ca-cert-request-approve コマンドを使用して認証できます。
以下に例を示します。 
pki -d agent token db directory -P https -p 8443 -h host.test.com -c agent token db passwd -n <CA agent cert nickname> ca-cert-request-approve request id
詳細は、pki client-cert-request --help コマンドを実行して man ページを参照してください。

5.2.2. サーバー側の鍵生成を使用した CSR の生成

Firefox v69 以降や Chrome など、多くの新しいバージョンのブラウザーでは、PKI キーを生成する機能と、キーアーカイブ用の CRMF のサポートが削除されています。RHEL では、CRMFPopClient (CR MFPopClient--help を参照) または pki (pki client-cert-request --help を参照) などの CLI を回避策として使用することができます。
サーバー側の Keygen の登録は、トークンキー管理システム (TMS) の導入以来、長い間行われてきました。このシステムでは、キーをスマートカードでローカルに生成するのではなく、KRA で生成できます。Red Hat Certificate System 9 では、ブラウザーのキー生成の問題を解決するための同様のメカニズムが導入されました。鍵はサーバーで生成され (特に KRA で)、PKCS#12 のクライアントに安全に転送されます。
注記
暗号化証明書にのみサーバー側 Keygen メカニズムを使用することが強く推奨されます。

5.2.2.1. 主な機能

  • 証明書要求キーは KRA で生成されます (注: CA と連携するには、KRA をインストールする必要があります)。
  • プロファイルのデフォルトプラグイン serverKeygenUserKeyDefaultImpl は、キーアーカイブ (つまり enableArchival パラメーター) を有効または無効にするための選択を提供します。
  • RSA 鍵と EC 鍵の両方のサポート
  • 手動 (エージェント) 承認と自動承認 (ディレクトリーパスワードベースなど) の両方のサポート

5.2.2.2. Server-Side Keygen を使用した証明書の登録

デフォルトの Sever-Side Keygen 登録プロファイルは、EE ページの List Certificate Profiles タブにあります。

サーバー側の鍵の生成を使用した手動ユーザーのデュアル使用証明書登録

図5.1 エージェントの手動による承認を必要とするサーバー側のキータイプの登録

エージェントの手動による承認を必要とするサーバー側のキータイプの登録

サーバー側の鍵生成を使用したディレクトリー認証ユーザーのデュアル使用証明書の登録

図5.2 LDAP の uid/pwd 認証が正常に実行されると自動的に承認される サーバー側のキータイプの登録

LDAP の uid/pwd 認証が正常に実行されると自動的に承認される サーバー側のキータイプの登録
リクエストの承認方法に関係なく、Server-Side Keygen Enrollment メカニズムでは、エンドエンティティーユーザーが PKCS#12 パッケージのパスワードを入力する必要があります。このパスワードには、発行された証明書と、発行後にサーバーによって生成された暗号化された秘密鍵が含まれます。
重要
パスワードは共有しないでください。CA や KRA のエージェントでさえありません。
登録要求が承認されると、PKCS#12 パッケージが生成され、以下が行われます。
  • 手動承認の場合、PKCS#12 ファイルは要求を承認する CA エージェントに返されます。その後、エージェントは PKCS#12 ファイルをユーザーに転送することが期待されます。
  • 自動承認の場合、PKCS#12 ファイルはリクエストを送信したユーザーに返されます。

図5.3 エージェントによる手動による登録

エージェントによる手動による登録
PKCS#12 ファイルを受け取ったら、アプリケーションごとにこのファイルをユーザーの内部証明書/キーデータベースに pkcs12util インポートするなどの CLI を使用できます。たとえば、ユーザーの Firefox nss データベースです。

5.2.2.3. キーリカバリー

証明書登録プロファイルで enableArchival パラメーターが true に設定されている場合、Server-Side Keygen 登録時に秘密鍵がアーカイブされます。その後、アーカイブされた秘密鍵は、認定 KRA エージェントにより復元できます。

5.2.2.4. 追加情報

5.2.2.4.1. KRA 要求レコード
注記
このメカニズムの性質上、プロファイルで enableArchival パラメーターが true に設定されている場合、Server-Side keygen 要求ごとに 2 つの KRA 要求レコードがあります。
  • 要求タイプ asymkeyGenRequest の 1 つ
    この要求タイプは、KRA エージェントページの List Requests を使用してフィルターすることはできません。Show All Requests を選択して、一覧を表示できます。
  • 要求タイプの リカバリー の場合
5.2.2.4.2. 監査レコード
有効にした場合には、以下の監査レコードを確認することができます。
CA
  • SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST
  • SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST
KRA
  • SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST_PROCESSED
  • SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST_PROCESSED (まだ実装されていません)

5.3. 証明書を登録する Internet Explorer の設定

警告
以下の手順はサポートされなくなり、参照用にのみ維持されます。この機能は Internet Explorer 11 で非推奨となり、Microsoft は IE 10 のサポートを終了しました。
Microsoft Windows のセキュリティー設定により、Internet Explorer を使用してエンドエンティティーページ経由で証明書を要求および登録するには、追加のブラウザー設定が必要になります。ブラウザーは、CA のエンドエンティティーページにアクセスする前に CA を信頼するように設定されている必要があります。

5.3.1. キー制限および Internet Explorer について

Microsoft は、RSA キーおよび ECC 鍵の潜在的な鍵サイズのサブセットのみに対応する特定の暗号プロバイダーを使用します。これらについては、表5.1「プロバイダーおよびキーサイズ」 に一覧表示されます。
キーサイズのサポートは、Internet Explorer で使用されるプロファイルの設定に影響を及ぼす可能性があります。プロファイルの設定は、3章証明書を発行するルール (証明書プロファイル) の作成 で説明されています。

表5.1 プロバイダーおよびキーサイズ

アルゴリズム プロバイダー サポート対象のキーサイズ
ECC Microsoft Software Key Storage Provider
  • nistp256
  • nistp384
  • nistp521
ECC Microsoft Smart Card Key Storage Provider
  • nistp256
  • nistp384
  • nistp521
RSA Microsoft Base Cryptographic Provider
  • 1024
RSA Microsoft Strong Cryptographic Provider
  • 1024
  • 2048
  • 3072
  • 4096
  • 8192
RSA Enhanced Cryptographic Provider
  • 1024
  • 2048
  • 3072
  • 4096
  • 8192
RSA Microsoft Software Key Storage Provider
  • 1024
  • 2048
  • 3072
  • 4096
  • 8192

5.3.2. Internet Explorer の設定

  1. Internet Explorer を開きます。
  2. Tools → Internet Options → Advanced → Security を開き、TLS 1.2 の選択を解除します。
  3. CA 証明書チェーンをインポートします。
    1. CA のセキュアでない終了サービスページを開きます。以下に例を示します。 
      http://server.example.com:8080/ca/ee/ca
    2. Retrieval タブをクリックします。
    3. 左側のメニューで Import CA Certificate Chain をクリックし、Download the CA certificate chain in binary form を選択します。
    4. プロンプトが表示されたら、CA 証明書チェーンファイルを保存します。
    5. Internet Explorer メニューで Tools をクリックし、Internet Options を選択します。
    6. Content タブを開き、Certificates ボタンをクリックします。
    7. インポートボタン をクリックします。インポートウィンドウで、インポートした証明書チェーンを参照し、選択します。
      インポートプロセスは、CA 証明書チェーンに使用する証明書ストアを要求します。Automatically select the certificate store based on the type of certificate を選択します。
    8. 証明書チェーンをインポートしたら、Trusted Root Certificate Authorities タブを開いて、証明書チェーンが正常にインポートされたことを確認します。
  4. Internet Explorer を設定して、スクリプトに安全でない DOM 制御を使用できるように要求します。これが許可されておらず、エンドエンティティーが証明書を標準 (非 SSL) エンドエンティティーページに登録しようとすると、Internet Explorer はこれらのページをブロックします。
    1. Internet Explorer メニューで Tools をクリックし、Internet Options を選択します。
    2. セキュリティー タブを開き、カスタムレベル をクリックします。
    3. ActiveX Controls and Plugins 領域で、Initialize and script ActiveX controls not marked as safe 設定の値を、Prompt に変更します。
  5. 証明書チェーンをインポートした後、Internet Explorer はセキュアなサービスページにアクセスできます。セキュアなサイトを開きます。以下に例を示します。 
    https://server.example.com:8443/ca/ee/ca
  6. エンドサービスページを開く際に、セキュリティー例外が発生する可能性があります。CA サービスサイトを Internet Explorer の Trusted Sites 一覧に追加します。
    1. Internet Explorer メニューで Tools をクリックし、Internet Options を選択します。
    2. Security タブを開き、Sites をクリックして CA サイトを信頼できる一覧に追加します。
    3. CA サービスページに対する Security level for this zone スライダーを、Medium-High に設定します。このセキュリティー設定が今後制限すぎる場合は、それを Medium にリセットしてください。
  7. Tools → Compatibility View and Compatibility View Settings を開いて、特定のサイトをリストに追加して Compatibility View 設定を有効にします。
  8. ブラウザーを閉じます。
Internet Explorer が登録に使用できることを確認するには、「End-Entities ページでの証明書の要求および受信」 の説明に従ってユーザー証明書を登録してみてください。

5.4. 証明書の要求および受信

「証明書の登録および更新について」 で説明されているように、CSR が生成されたら、発行用に CA に送信する必要があります。「証明書署名リクエストの作成」 で説明されている方法のいくつかが、CSR を CA に直接送信しますが、CSR を別のステップで送信する必要がある場合もあります。これは、ユーザーが実行するか、エージェントが事前に署名することができます。
本セクションでは、RHCS CA でサポートされる別の送信手順を説明します。

5.4.1. End-Entities ページでの証明書の要求および受信

CA エンドエンティティーポータル (つまり、https://host.domain:port#/ca/ee/ca)) で、エンドエンティティーは、Enrollment/Renewal タブの該当する各登録プロファイルに表示される HTML 登録フォームを使用して、証明書要求を送信できます (CSR。CSR の生成方法は 「証明書署名リクエストの作成」 を参照)。
このセクションでは、マーカー行 -----BEGIN NEW CERTIFICATE REQUEST----- および -----END NEW CERTIFICATE REQUEST----- を含む Base64 エンコード形式の CSR があることを前提としています。
デフォルトの登録プロファイルの多くは、Base64 でエンコードされた CSR に貼り付けることができる 証明書要求 テキストボックスと、証明書要求タイプ の選択ドロップダウンリストを提供します。
証明書の登録フォームで、必要な情報を入力します。
標準の要件は以下のとおりです。
  • 証明書要求のタイプ。これは PKCS#10 または CRMF です。サブシステム管理コンソールを介して作成された証明書要求は PKCS#10 です。certutil ツールを通じて作成されたものやその他のユーティリティーは通常 PKCS #10 です。
  • 証明書要求。-----BEGIN NEW CERTIFICATE REQUEST----- および -----END NEW CERTIFICATE REQUEST----- 行を含む、ベース 64 でエンコードされた Blob を貼り付けます。
  • Requester Name。これは、証明書を要求するユーザーの共通名です。
  • Requester Email。これは、要求側のメールアドレスです。エージェントまたは CA システムは、このアドレスを使用して、証明書を発行する際に要求側に接続します。例: jdoe@someCompany.com
  • Requester Phone。これは、要求側の連絡先番号です。
送信されたリクエストは、エージェントの承認のためにキューに置かれます。エージェントは、証明書要求を処理し、承認する必要があります。
注記
登録プロファイルによっては、Red Hat Certificate System が提供する LDAP uid/pwd 認証メソッドを使用することで、自動承認を行うことがあります。これらのプロファイルによる登録では、次のセクションに手動でエージェントの承認は必要ありません。サポートされる承認方法は、9章証明書を登録するための認証 を参照してください。
手動承認の場合は、証明書が承認および生成されると、証明書を取得できます。
  1. Certificate Manager の end-entities ページを開きます。以下に例を示します。 
    https://server.example.com:8443/ca/ee/ca
  2. Retrieval タブをクリックします。
  3. 証明書要求の送信時に作成された要求 ID 番号を入力し、Submit をクリックします。
  4. 次のページには、証明書要求のステータスが表示されます。ステータスが complete すると、証明書へのリンクがあります。Issued certificate のリンクをクリックします。
  5. 新しい証明書情報は、pretty-print 形式、base-64 エンコード形式、および PKCS #7 形式で表示されます。
    このページでは、以下のアクションを実行できます。
    • この証明書をサーバーまたは他のアプリケーションにインストールするには、base-64 でエンコードされた証明書が含まれている Installing This Certificate in a Server セクションまで下にスクロールします。
  6. base-64 でエンコードされた証明書 (マーカー行 -----BEGIN CERTIFICATE----- および -----END CERTIFICATE----- を含む) をテキストファイルにコピーします。テキストファイルを保存し、これを使用して秘密鍵があるエンティティーのセキュリティーモジュールに証明書のコピーを保存します。「ユーザーの作成」を参照してください。

5.5. 証明書の更新

本セクションでは、証明書の更新方法を説明します。証明書の更新の設定方法は 「更新を有効にするためのプロファイルの設定」 を参照してください。
証明書の更新は、元の証明書と同じ目的で使用されるプロパティーを使用して、証明書を再生成します。一般的には、更新には 2 つのタイプがあります。
  • 同じキーの更新 は、証明書の元のキー、プロファイル、および要求を受け取り、同じキーを使用して、新しい有効期間と有効期限で新しい証明書を再作成します。これは、以下のいずれかの方法で実行できます。
    • 元のプロファイルから元の証明書要求 (CSR) の再送信、または
    • certutil などのサポートツールを使用した元のキーで CSR の再生成
  • 証明書の キーを再生成 するには、同じ情報を使用して証明書要求を再生成する必要があるため、新しいキーペアが生成されます。その後、CSR は元のプロファイルを介して送信されます。

5.5.1. 同じキーの更新

5.5.1.1. CSR の再利用

エンドエンティティーポータルには、同じキー更新に対する承認メソッドが 3 つあります。
  • エージェントが承認した方法では、更新する証明書のシリアル番号を送信する必要があります。この方法では、CA エージェントの承認が必要になります。
  • ディレクトリーベースの更新では、更新する証明書のシリアル番号を送信する必要があり、CA は現在の証明書ディレクトリーエントリーから情報を取得します。ldap uid/pwd が正常に認証されると、証明書は自動的に承認されます。
  • 証明書ベースの更新は、ブラウザーデータベースの証明書を使用して認証し、同じ証明書を再発行します。
5.5.1.1.1. エージェントによる承認またはディレクトリーベースの更新
場合によっては、CA エージェントによって、またはユーザーディレクトリーのログイン情報を提供することによって、証明書の更新要求を手動で承認する必要があります。
  1. 証明書 (またはそのクローン) の CA のエンドエンティティーサービスページを開きます。 
    https://server.example.com:8443/ca/ee/ca
  2. 使用する更新フォームの名前をクリックします。
  3. 更新する証明書のシリアル番号を入力します。これは、10 進数または 16 進数の形式にすることができます。
  4. 更新ボタンをクリックします。
  5. リクエストが送信されます。ディレクトリーベースの更新では、更新された証明書が自動的に返されます。それ以外の場合、更新リクエストはエージェントにより承認されます。
5.5.1.1.2. 証明書ベースの更新
ユーザー証明書によってはブラウザーに直接保存されるため、更新フォームによっては、更新する証明書について、ブラウザーの証明書データベースを確認するだけです。証明書を更新できる場合は、CA が自動的に承認され、再発行されます。
重要
更新中の証明書の有効期限が すでに 切れている場合は、証明書ベースの更新には使用できない可能性があります。ブラウザークライアントは、期限切れの証明書での SSL クライアント認証を許可しない可能性があります。
この場合には、他の更新方法のいずれかを使用して証明書を更新する必要があります。
  1. 証明書 (またはそのクローン) の CA のエンドエンティティーサービスページを開きます。 
    https://server.example.com:8443/ca/ee/ca
  2. 使用する更新フォームの名前をクリックします。
  3. 入力フィールドがないため、Renew ボタンをクリックします。
  4. プロンプトが表示されたら、更新する証明書を選択します。
  5. 要求が送信され、更新された証明書が自動的に返されます。

5.5.1.2. 同じキーを持つ CSR を生成して更新

元の CSR が利用できない場合があります。この certutil ツールを使用して、キーペアが NSS データベースにある場合に、同じキーで CSR を再生成できます。これは、次の手順で実行できます。
  1. NSS データベースで、対応するキー ID を検索します。 
    Certutil -d <nssdb dir> -K
  2. 特定のキーを使用して CSR を生成します。 
    Certutil -d <nssdb dir> -R -k <key id> -s <subject DN> -o <CSR output file>
または、keyid の代わりに、キーが NSS データベースの証明書に関連付けられている場合は、ニックネーム を使用できます。
  • 既存のニックネームを使用して CSR を生成します。 
    Certutil -d <nssdb dir> -R -k <nickname> -s <subject DN> -o <CSR output file>

5.5.2. 証明書のキー変更による更新

キーの再生成 による更新は、基本的に古い証明書と同じ情報で新しい CSR を生成するため、「証明書署名リクエストの作成」 で説明されている方法のいずれかに従ってください。古い証明書と同じ情報を入力します。

5.6. CMC を使用した証明書要求の送信

このセクションでは、CMS (Certificate Management over CMS) を使用して証明書を登録する手順を説明します。
CMC を使用して証明書を登録する設定とワークフローの一般的な情報は、以下を参照してください。
  • 『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『CMC の設定』 セクションを参照してください。
  • 『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『CMC を使用した登録』 セクション
  • CMCRequest(1) の man ページを参照してください。
  • CMCResponse(1) の man ページを参照してください。
CMC の登録は、さまざまなシナリオの要件を満たすためにさまざまな方法で可能です。「CMC 登録プロセス」 は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『CMC を使用した登録』 セクションを補足します。さらに、「実用的な CMC 登録シナリオ」 セクションを使用すると、管理者はどのメカニズムをどのシナリオで使用するかを決定できます。

5.6.1. CMC 登録の使用

CMC 登録により、登録クライアントは認証に CMCAuth プラグインを使用できます。これにより、証明書要求はエージェント証明書で事前署名されます。Certificate Manager は、エージェント証明書で署名した有効な要求を受け取れると、証明書を自動的に発行します。
注記
CMC 登録はデフォルトで有効になっています。設定が変更されていない限り、CMC 登録認証プラグインまたはプロファイルを有効にする必要はありません。
CMCAuth 認証プラグインは、クライアントに CMC 失効も提供します。CMC の失効により、クライアントはエージェント証明書によって署名された証明書要求を取得し、そのような要求を Certificate Manager に送信できます。Certificate Manager は、エージェント証明書で署名した有効な要求を受け取ると、証明書を自動的に取り消します。CMCRevoke コマンドラインツールを使用して、CMC 失効を作成できます。CMCRevoke の詳細は、「CMC 失効の実行」 を参照してください。
CMC リクエストは、ブラウザーのエンドエンティティーフォームから、または HttpClient などのツールを使用して送信して、適切なプロファイルにリクエストを投稿できます。この CMCRequest ツールは、署名済み証明書要求を生成し、HttpClient ツールまたはブラウザーのエンドエンティティーフォームを使用して、証明書を自動的かつ即座に登録および受信します。
CMCRequest ツールには簡単なコマンド構文があり、.cfg 入力ファイルに指定されるすべての設定が設定されます。 
CMCRequest /path/to/file.cfg
以下の構文で、CMCEnroll ツールを使用して 1 回の登録を作成することもできます。 
CMCEnroll -d /agent's/certificate/directory -h password -n cert_nickname -r certrequest.file -p certDB_passwd [-c "comment"]
これらのツールの詳細は、CMCEnroll(1) の man ページで説明されています。
注記
引用符で囲まれたスペースを含む値を囲みます。

5.6.1.1. CMCEnroll のテスト

  1. certutil ツールを使用して証明書要求を作成します。
  2. PKCS #10 ASCII 出力をテキストファイルにコピーします。
  3. CMCEnroll ユーティリティーを実行します。
    たとえば、入力ファイルが request34.txt を呼び出すと、エージェント証明書はブラウザーデータベースに保存され、エージェント証明書の証明書の一般名は CertificateManagerAgentsCert で、および証明書データベースのパスワードは secret で、コマンドは次のとおりです。 
    CMCEnroll -d ~jsmith/.mozilla/firefox/1234.jsmith -n "CertificateManagerAgentsCert" -r /export/requests/request34.txt -p secret
    このコマンドの出力は、ファイル名に加えられた .out で同じファイル名のファイルに保存されます。
  4. エンドエンティティーを通じて署名済み証明書を提出します。
    1. エンドエンティティーを開きます。 
      https://server.example.com:8443/ca/ee/ca
    2. 証明書プロファイルのリストから CMC 登録フォームを選択します。
    3. 出力ファイルの内容をこの形式の Certificate Request テキスト領域に貼り付けます。
    4. 貼り付けられたコンテンツから -----BEGIN NEW CERTIFICATE REQUEST----- および ----END NEW CERTIFICATE REQUEST----- を削除します。
    5. 連絡先情報を入力して、フォームに入力します。
  5. 証明書は即座に処理され、返されます。
  6. エージェントページを使用して、新しい証明書を検索します。

5.6.2. CMC 登録プロセス

CMC を使用して証明書を要求および発行するには、次の一般的な手順を使用します。
  1. Certificate Signing Request (CSR) を、以下のいずれかの形式で作成します。
    • PKCS #10 形式
    • Certificate Request Message Format (CRMF) 形式
    これらの形式で CSR を作成する方法は、「証明書署名リクエストの作成」 を参照してください。
  2. 管理証明書をクライアントの NSS データベースにインポートします。以下に例を示します。
    • 以下のコマンドを実行して、.p12 ファイルから管理クライアント証明書を抽出します。 
      $ openssl pkcs12 -in /root/.dogtag/instance/ca_admin_cert.p12 -clcerts -nodes -nokeys -out /root/.dogtag/instance/ca_admin_cert.crt
    • 『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『証明書/キー暗号化トークンの管理』セクションに従って、管理クライアント証明書の検証およびインポートを行います。 
      $ PKICertImport -d . -n "CA Admin - Client Certificate" -t ",," -a -i /root/.dogtag/instance/ca_admin_cert.crt -u C
      重要
      CA 管理クライアント証明書をインポートする前に、中間証明書とルート CA 証明書がインポートされていることを確認します。
    • 証明書に関連付けられた秘密鍵をインポートします。 
      $ pki -c password pkcs12-import --pkcs12-file /root/.dogtag/instance/ca_admin_cert.p12 --pkcs12-password-file /root/.dogtag/instance/ca/pkcs12_password.conf
  3. 以下の内容で、/home/user_name/cmc-request.cfg などの CMC 要求用の設定ファイルを作成します。 
    # NSS database directory where CA agent certificate is stored
dbdir=/home/user_name/.dogtag/nssdb/

# NSS database password
password=password

# Token name (default is internal)
tokenname=internal

# Nickname for signing certificate
nickname=subsystem_admin

# Request format: pkcs10 or crmf
format=pkcs10

# Total number of PKCS10/CRMF requests
numRequests=1

# Path to the PKCS10/CRMF request
# The content must be in Base-64 encoded format.
# Multiple files are supported. They must be separated by space.
input=/home/user_name/file.csr

# Path for the CMC request
output=/home/user_name/cmc-request.bin
    詳細は、CMCRequest(1) の man ページを参照してください。
  4. CMC 要求を作成します。 
    $ CMCRequest /home/user_name/cmc-request.cfg
    コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルの output パラメーターで指定されたファイルに CMC 要求を保存します。
  5. /home/user_name/cmc-submit.cfg などの HttpClient の設定ファイルを作成します。このファイルは、後で CMC 要求を CA に送信します。作成されたファイルに以下の内容を追加します。 
    # PKI server host name
host=server.example.com

# PKI server port number
port=8443

# Use secure connection
secure=true

# Use client authentication
clientmode=true

# NSS database directory where the CA agent certificate is stored.
dbdir=/home/user_name/.dogtag/nssdb/

# NSS database password
password=password

# Token name (default: internal)
tokenname=internal

# Nickname of signing certificate
nickname=subsystem_admin

# Path for the CMC request
input=/home/user_name/cmc-request.bin

# Path for the CMC response
output=/home/user_name/cmc-response.bin
    重要
    nickname パラメーターで指定された証明書のニックネームは、CMC 要求で以前使用された内容と一致させる必要があります。
  6. 要求する証明書のタイプに応じて、前の手順で作成した設定ファイルに次のパラメーターを追加します。 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=profile_name
    CA 署名証明書の場合の例を以下に示します。 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
    重要
    エージェントが次のステップで CMC 要求を送信する場合は、このパラメーターで指定したプロファイルは CMCAuth 認証プラグインを使用する必要があります。ユーザーが作成した登録では、プロファイルは CMCUserSignedAuth プラグインを使用する必要があります。詳細は、「CMC 認証プラグイン」 を参照してください。
  7. CMC 要求を CA に送信します。 
    $ HttpClient /home/user_name/cmc-submit.cfg
  8. CMC の応答を PKCS #7 証明書チェーンに変換するには、CMCResponse ユーティリティーの -i パラメーターに CMC レスポンスファイルを渡します。以下に例を示します。 
    $ CMCResponse -i /home/user_name/cmc-response.bin -o /home/user_name/cert_chain.crt

5.6.3. 実用的な CMC 登録シナリオ

本セクションでは、CA 管理者がどの状況でどの CMC メソッドを使用するかを決定できるようにするための、頻繁な実際の使用シナリオとそのワークフローを説明します。
CMC を使用して証明書を登録する一般的なプロセスは、「CMC 登録プロセス」 を参照してください。

5.6.3.1. システム証明書およびサーバー証明書の取得

LDAP や Web サーバーなどのサービスで TLS サーバー証明書が必要な場合、このサーバーの管理者はサービスのドキュメントに基づいて CSR を作成し、承認のために CA のエージェントに送信します。このプロセスには、「CMC 登録プロセス」 で説明されている手順を使用します。また、以下の要件を考慮してください。
登録プロファイル
エージェントは、「CMC 認証プラグイン」 にリストされている既存の CMC プロファイルのいずれかを使用する必要があります。または、CMCAuth 認証メカニズムを使用するカスタムプロファイルを作成します。
CMC 署名証明書
システム証明書の場合、CA エージェントは CMC 要求を生成して署名する必要があります。そのためには、CMCRequest 設定ファイルの nickname パラメーターを CA エージェントのニックネームに設定します。
注記
CA エージェントは、独自の秘密鍵にアクセスできるようにする必要があります。
HttpClient TLS Client Nickname
HttpClient の設定ファイル内で TLS クライアント認証に関するユーティリティーの設定ファイルに対して、CMCRequest ユーティリティー設定ファイルへのサインインに同じ証明書を使用します。
httpclient servlet パラメーター
HttpClient ユーティリティーに渡される設定ファイルの servlet では、要求を処理する CMC サーブレットおよび登録プロファイルが参照されます。
要求する証明書のタイプに応じて、直前の手順で作成した設定ファイルに以下のエントリーのいずれかを追加します。
  • CA 署名証明書の場合: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
  • KRA トランスポート証明書の場合: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCkraTransportCert
  • OCSP 署名証明書の場合: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCocspCert
  • 監査署名証明書の場合: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCauditSigningCert
  • サブシステム証明書の場合:
    • RSA 証明書の場合: 
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCsubsystemCert
    • ECC 証明書の場合: 
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCsubsystemCert
  • TLS サーバー証明書の場合:
    • RSA 証明書の場合: 
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert
    • ECC 証明書の場合: 
      servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCECCserverCert
  • 管理証明書の場合: 
    servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caFullCMCUserCert
詳細は以下を参照してください。
  • エージェントが CSR を事前署名する場合、エージェントは識別のために CSR を調べるため、Proof of Identification が確立されたと見なされます。追加の CMC 固有の識別証明は必要ありません。
  • PKCS #10 ファイルはすでに Proof of Possession (POP) 情報を提供し、追加の Proof of Possession (POP) は必要ありません。
  • エージェントの事前承認済みリクエストでは、識別はエージェントによってチェックされるため、PopLinkWittnessV2 機能を無効にする必要があります。

5.6.3.2. ユーザーの初回署名証明書の取得

ユーザーの最初の署名証明書を承認する方法は 2 つあります。
5.6.3.2.1. エージェント証明書を使用した CMC 要求の署名
エージェント証明書を使用して CMC 要求に署名するプロセスは、「システム証明書およびサーバー証明書の取得」 で説明されているシステム証明書およびサーバー証明書の場合と同じです。唯一の違いは、ユーザーが CSR を作成し、承認のために CA エージェントに送信することです。
5.6.3.2.2. 共有シークレットを使用した証明書の登録の認証
ユーザーが最初の署名証明書を取得したいが、エージェントが、「エージェント証明書を使用した CMC 要求の署名」 で説明されているように要求を承認できない場合は、共有トークンを使用できます。このトークンを使用すると、ユーザーは最初の署名証明書を取得できます。次に、この証明書を使用してユーザーの他の証明書に署名できます。
このシナリオでは、Shared Secret のメカニズムを使用して、ユーザーの最初の署名証明書を取得します。「CMC 登録プロセス」 とともに以下の情報を使用します。
  1. ユーザーまたは CA 管理者として共有トークンを作成します。詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『共有シークレットトークンの作成』セクションを参照してください。
    以下の点に留意してください。
    • ユーザーがトークンを作成した場合、ユーザーはトークンを CA 管理者に送信する必要があります。
    • CA 管理者がトークンを作成した場合、管理者はユーザーがトークンを生成するのに使用するパスワードを共有する必要があります。セキュアな方法でパスワードを送信します。
  2. CA 管理者として、LDAP のユーザーエントリーに Shared Token を追加します。詳細は、「証明書の登録用ユーザーエントリーへの CMC 共有シークレットの追加」 と、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『CMC 共有シークレット機能の有効化』セクションを参照してください。
  3. CMCRequest ユーティリティーに渡される設定ファイルで以下のパラメーターを使用します。
    • identification.enable
    • witness.sharedSecret
    • identityProofV2.enable
    • identityProofV2.hashAlg
    • identityProofV2.macAlg
    • request.useSharedSecret
    • request.privKeyId
  4. CA で必要な場合は、CMCRequest ユーティリティーに渡される設定ファイルで以下のパラメーターも使用します。
    • popLinkWitnessV2.enable
    • popLinkWitnessV2.keyGenAlg
    • popLinkWitnessV2.macAlg

5.6.3.3. ユーザーの暗号化のみの証明書の取得

本セクションでは、既存のユーザー署名証明書で署名された暗号化のみの証明書を取得するワークフローを説明します。
注記
ユーザーがさまざまな用途で複数の証明書を所有していて、1 つが署名している場合、ユーザーは最初に署名証明書を取得する必要があります。ユーザーが署名証明書を所有すると、CMC Shared Secret メカニズムを設定して依存することなく、Proof Of Origin に使用できます。
ユーザーの最初の署名証明書を取得する方法は、「ユーザーの初回署名証明書の取得」 を参照してください。
ユーザーとして以下を行います。
  1. Network Security Services (NSS) データベースまたはユーザーの署名証明書および鍵が含まれるスマートカードに保存されている暗号化トークンを使用します。
  2. PKCS #10 形式または CRMF 形式で CSR を生成します。
    注記
    (キーのアーカイブが必要な場合は) CRMF 形式を使用してください。
  3. CMC 要求を生成します。
    これは暗号のみの証明書であるため、秘密鍵は署名できません。そのため、Proof Of Possession (POP) は含まれていません。このため、登録には、2 つの手順が必要です。最初のリクエストが成功すると、EncryptedPOP 制御のある CMC 状態が生じます。次に、ユーザーは応答を使用して、DecryptedPOP 制御を含む CMC 要求を生成し、2 番目のステップで送信します。
    1. 最初のステップでは、デフォルトのパラメーターに加えて、ユーザーは、CMCRequest ユーティリティーに渡される設定ファイルに次のパラメーターを設定する必要があります。
      • identification.enable
      • witness.sharedSecret
      • identityProofV2.enable
      • identityProofV2.hashAlg
      • identityProofV2.macAlg
      • popLinkWitnessV2.enable (CA で必要な場合)
      • popLinkWitnessV2.keyGenAlg (CA で必要な場合)
      • popLinkWitnessV2.macAlg (CA で必要な場合)
      • request.privKeyId
      詳細は、CMCRequest(1) の man ページを参照してください。
      応答には以下が含まれます。
      • CMC で暗号化された POP コントロール
      • POP の required エラーでの CMCStatusInfoV2 コントロール
      • リクエスト ID
    2. 次のステップでは、デフォルトのパラメーターに加えて、ユーザーは、CMCRequest ユーティリティーに渡される設定ファイルに次のパラメーターを設定する必要があります。
      • decryptedPop.enable
      • encryptedPopResponseFile
      • decryptedPopRequestFile
      • request.privKeyId
      詳細は、CMCRequest(1) の man ページを参照してください。
5.6.3.3.1. キーアーカイブを使用した暗号化のみの証明書の取得例
キーアーカイブを使用して登録を実行するには、CRMF 要求にユーザーの暗号化された秘密鍵を含む CMC 要求を生成します。以下の手順は、ユーザーが署名証明書をすでに所有していることを前提としています。この署名証明書のニックネームは、手順の設定ファイルに設定されます。
注記
以下の手順は、署名に使用できない暗号のみの鍵で使用される 2 通の発行を説明します。証明書に署名できるキーを使用する場合は、-q POP_NONE の代わりに -q POP_SUCCESS オプションを、単一トリップ発行のために CRMFPopClient ユーティリティーに渡します。
POP_SUCCESS で CRMFPoPClient を使用する方法は、「CRMFPopClient を使用したキー Archival を持つ CSR の作成」 および 「CRMFPopClient を使用した SharedSecret ベースの CMC の CSR の作成」 を参照してください。
  1. KRA トランスポート証明書を検索します。以下に例を示します。 
    $ pki cert-find --name KRA_transport_certificate_subject_CN
  2. 前の手順で取得した KRA トランスポート証明書のシリアル番号を使用して、証明書をファイルに保存します。たとえば、/home/user_name/kra.cert ファイルに 12345 シリアル番号がある証明書を保存するには、次のコマンドを実行します。 
    $ pki cert-show 12345 --output /home/user_name/kra.cert
  3. CRMFPopClient ユーティリティーを使用して以下を行います。
    • キーアーカイブを使用して CSR を作成します。
      1. 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。 
        $ cd /home/user_name/
      2. RSA 秘密鍵が KRA トランスポート証明書によりラップされる CRMF 要求を作成するには、CRMFPopClient ユーティリティーを使用します。たとえば、要求を /home/user_name/crmf.req ファイルに保存するには、以下のコマンドを実行します。 
        $ CRMFPopClient -d . -p token_password -n subject_DN -q POP_NONE \
		 -b /home/user_name/kra.cert -w "AES/CBC/PKCS5Padding" \
		 -v -o /home/user_name/crmf.req
        コマンドで表示される秘密鍵の ID をメモします。ID は、2 番目のトリップの設定ファイルの request.privKeyId パラメーターの値として、後のステップで必要になります。
  4. 以下の内容を含む、/home/user_name/cmc.cfg など、CRMRequest ユーティリティー用の設定ファイルを作成します。 
    #numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

#input: full path for the PKCS10 request or CRMF request,
#the content must be in Base-64 encoded format
input=/home/user_name/crmf.req

#output: full path for the CMC request in binary format
output=/home/user_name/cmc.req

#tokenname: name of token where agent signing cert can be found
#(default is internal)
tokenname=internal

#nickname: nickname for user certificate which will be used
#to sign the CMC full request.
nickname=signing_certificate

#dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/home/user_name/.dogtag/nssdb/

#password: password for cert8.db which stores the agent certificate
password=password

#format: request format, either pkcs10 or crmf
format=crmf
  5. CMC 要求を作成します。 
    $ CMCRequest /home/user_name/cmc.cfg
    コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルの output パラメーターで指定されたファイルに CMC 要求を保存します。
  6. /home/user_name/cmc-submit.cfg などの HttpClient の設定ファイルを作成します。このファイルは、後で CMC 要求を CA に送信します。作成されたファイルに以下の内容を追加します。 
    #host: host name for the http server
host=server.example.com

#port: port number
port=8443

#secure: true for secure connection, false for nonsecure connection
secure=true

#input: full path for the enrollment request, the content must be in
#binary format
input=/home/user_name/cmc.req

#output: full path for the response in binary format
output=/home/user_name/cmc-response_round_1.bin

#tokenname: name of token where TLS client authentication cert can be found
#(default is internal)
#This parameter will be ignored if secure=false
tokenname=internal

#dbdir: directory for cert8.db, key3.db and secmod.db
#This parameter will be ignored if secure=false
dbdir=/home/user_name/.dogtag/nssdb/

#clientmode: true for client authentication, false for no client authentication
#This parameter will be ignored if secure=false
clientmode=true

#password: password for cert8.db
#This parameter will be ignored if secure=false and clientauth=false
password=password

#nickname: nickname for client certificate
#This parameter will be ignored if clientmode=false
nickname=signing_certificate

#servlet: servlet name
servlet=/ca/ee/ca/profileSubmitUserSignedCMCFull?profileId=caFullCMCUserSignedCert
  7. CMC 要求を CA に送信します。 
    $ HttpClient /home/user_name/cmc-submit.cfg
    コマンドが成功すると、HTTPClient ユーティリティーは、CMC 応答を、設定ファイルの output パラメーターで指定されたファイルに保存します。
  8. 応答ファイルを CMCResponse ユーティリティーに渡して応答を確認します。以下に例を示します。 
    $ CMCResponse -d /home/user_name/.dogtag/nssdb/ -i /home/user_name/cmc-response_round_1.bin
    最初のトリップが成功した場合は、CMCResponse は、以下のような出力を表示します。 
    Certificates:
		Certificate:
				Data:
						Version:  v3
						Serial Number: 0x1
						Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
						Issuer: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain
						Validity:
								Not Before: Wednesday, May 17, 2017 6:06:50 PM PDT America/Los_Angeles
								Not  After: Sunday, May 17, 2037 6:06:50 PM PDT America/Los_Angeles
						Subject: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain
...
Number of controls is 3
Control #0: CMC encrypted POP
	 OID: {1 3 6 1 5 5 7 7 9}
		 encryptedPOP decoded
Control #1: CMCStatusInfoV2
	 OID: {1 3 6 1 5 5 7 7 25}
	 BodyList: 1
	 OtherInfo type: FAIL
		 failInfo=POP required
Control #2: CMC ResponseInfo
	 requestID: 15
  9. 2 番目のトリップの場合は、後の手順で使用する /home/user_name/cmc_DecryptedPOP.cfg などの DecryptedPOP の設定ファイルを作成します。作成されたファイルに以下の内容を追加します。 
    #numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

#input: full path for the PKCS10 request or CRMF request,
#the content must be in Base-64 encoded format
#this field is actually unused in 2nd trip
input=/home/user_name/crmf.req

#output: full path for the CMC request in binary format
#this field is actually unused in 2nd trip
output=/home/user_name/cmc2.req

#tokenname: name of token where agent signing cert can be found
#(default is internal)
tokenname=internal

#nickname: nickname for agent certificate which will be used
#to sign the CMC full request.
nickname=signing_certificate

#dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/home/user_name/.dogtag/nssdb/

#password: password for cert8.db which stores the agent
#certificate
password=password

#format: request format, either pkcs10 or crmf
format=crmf

decryptedPop.enable=true
encryptedPopResponseFile=/home/user_name/cmc-response_round_1.bin
request.privKeyId=-25aa0a8aad395ebac7e6a19c364f0dcb5350cfef
decryptedPopRequestFile=/home/user_name/cmc.DecryptedPOP.req
  10. DecryptPOP CMC 要求を作成します。 
    $ CMCRequest /home/user_name/cmc.DecryptedPOP.cfg
    コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルの decryptedPopRequestFile パラメーターで指定されたファイルに CMC 要求を保存します。
  11. /home/user_name/decrypted_POP_cmc-submit.cfg などの HttpClient の設定ファイルを作成します。このファイルは、後で DecryptedPOP CMC 要求を CA に送信します。作成されたファイルに以下の内容を追加します。 
    #host: host name for the http server
host=server.example.com

#port: port number
port=8443

#secure: true for secure connection, false for nonsecure connection
secure=true

#input: full path for the enrollment request, the content must be in binary format
input=/home/user_name/cmc.DecryptedPOP.req

#output: full path for the response in binary format
output=/home/user_name/cmc-response_round_2.bin

#tokenname: name of token where TLS client authentication cert can be found (default is internal)
#This parameter will be ignored if secure=false
tokenname=internal

#dbdir: directory for cert8.db, key3.db and secmod.db
#This parameter will be ignored if secure=false
dbdir=/home/user_name/.dogtag/nssdb/

#clientmode: true for client authentication, false for no client authentication
#This parameter will be ignored if secure=false
clientmode=true

#password: password for cert8.db
#This parameter will be ignored if secure=false and clientauth=false
password=password

#nickname: nickname for client certificate
#This parameter will be ignored if clientmode=false
nickname=singing_certificate

#servlet: servlet name
servlet=/ca/ee/ca/profileSubmitUserSignedCMCFull?profileId=caFullCMCUserCert
  12. Decrypted CMC 要求を CA に送信します。 
    $ HttpClient /home/user_name/decrypted_POP_cmc-submit.cfg
    コマンドが成功すると、HTTPClient ユーティリティーは、CMC 応答を、設定ファイルの output パラメーターで指定されたファイルに保存します。
  13. CMC の応答を PKCS #7 証明書チェーンに変換するには、CMCResponse ユーティリティーの -i パラメーターに CMC レスポンスファイルを渡します。以下に例を示します。 
    $ CMCResponse -i /home/user_name/cmc-response_round_2.bin -o /home/user_name/certs.p7
    または、個々の証明書を PEM 形式で表示するには、-v ユーティリティーに渡します。
    次のトリップが成功した場合は、CMCResponse は、以下のような出力を表示します。 
    Certificates:
		Certificate:
				Data:
						Version:  v3
						Serial Number: 0x2D
						Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
						Issuer: CN=CA Signing Certificate,OU=pki-tomcat,O=unknown00262DFC6A5E Security Domain
						Validity:
								Not Before: Thursday, June 15, 2017 3:43:45 PM PDT America/Los_Angeles
								Not  After: Tuesday, December 12, 2017 3:43:45 PM PST America/Los_Angeles
						Subject: CN=user_name,UID=example,OU=keyArchivalExample
...
Number of controls is 1
Control #0: CMCStatusInfo
	 OID: {1 3 6 1 5 5 7 7 1}
	 BodyList: 1
	 Status: SUCCESS

5.7. 一括発行の実行

管理者が多数の証明書を同時に送信および生成する必要がある場合があります。Certificate System で提供されるツールの組み合わせを使用して、証明書要求を含むファイルを CA に送信できます。この手順例では、リクエストを生成する PKCS10Client コマンドと、CA に要求を送信する sslget コマンドを使用します。
  1. このプロセスはスクリプト化されているため、CA (ホスト、ポート) と、認証に使用されるアイテム (エージェント証明書と証明書データベースおよびパスワード) を識別するために複数の変数を設定する必要があります。たとえば、ターミナルでエクスポートして、セッションに以下の変数を設定します。 
    export d=/var/tmp/testDir
export p=password
export f=/var/tmp/server.csr.txt
export nick="CA agent cert"
export cahost=1.2.3.4
export caport=8443
    注記
    ローカルシステムには、エージェントの証明書を持つ有効なセキュリティーデータベースが必要です。データベースを設定するには、以下を行います。
    1. ブラウザーからエージェントユーザー証明書および鍵をエクスポートまたはダウンロードし、agent.p12 などのファイルに保存します。
    2. 必要に応じて、セキュリティーデータベース用の新しいディレクトリーを作成します。 
      mkdir ${d}
    3. 必要な場合は、新規セキュリティーデータベースを作成します。 
      certutil -N -d ${d}
    4. Certificate System インスタンスを開きます。 
      systemctl stop pki-tomcatd@instance_name.service
    5. pk12util を使用して証明書をインポートします。 
      # pk12util -i /tmp/agent.p12 -d ${d} -W p12filepassword
      手順に成功すると、コマンドは以下の出力を出力します。 
      pk12util: PKCS12 IMPORT SUCCESSFUL
    6. Certificate System インスタンスを開きます。 
      systemctl start pki-tomcatd@instance_name.service
  2. 2 つの追加の変数を設定する必要があります。要求の処理に使用される CA プロファイルを識別する変数、およびプロファイルフォームの情報を提供するための post ステートメントの送信に使用される変数。 
    export post="cert_request_type=pkcs10&xmlOutput=true&profileId=caAgentServerCert&cert_request="
export url="/ca/ee/ca/profileSubmitSSLClient"
    注記
    この例では、証明書要求を caAgentServerCert プロファイルに送信します (ただし、post ステートメントの profileId 要素で識別されます)。カスタムプロファイルを含む任意の証明書プロファイルを使用できます。
  3. 変数設定をテストします。 
    echo ${d} ${p} ${f} ${nick} ${cahost} ${caport} ${post} ${url}
  4. (この例では) PKCS10Client を使用して証明書要求を生成します。 
    time for i in {1..10}; do /usr/bin/PKCS10Client -d ${d} -p ${p} -o ${f}.${i} -s "cn=testms${i}.example.com"; cat ${f}.${i} >> ${f}; done

perl -pi -e 's/\r\n//;s/\+/%2B/g;s/\//%2F/g' ${f}

wc -l ${f}
  5. CA のステータスとトランザクションログを確認します。 
    /etc/init.d/pki-ca status

tail -f /var/log/pki-ca/transactions&
  6. 手順 4 で作成した一括証明書要求ファイルを、sslget を使用する CA プロファイルインターフェイスに送信します。以下に例を示します。 
    cat ${f} | while read thisreq; do /usr/bin/sslget -n "${nick}" -p ${p} -d ${d} -e ${post}${thisreq} -v -r ${url} ${cahost}:${caport}; done

5.8. Cisco ルーターでの証明書の登録

Cisco によって設計された Simple Certificate Enrollment Protocol (SCEP) は、ルーターが CA などの証明書発行機関と通信して、ルーターの証明書を登録するための方法です。
通常、ルーターインストーラーは CA の URL とチャレンジパスワード (ワンタイム PIN とも呼ばれます) をルーターに入力し、コマンドを発行して登録を開始します。次に、ルーターは SCEP を介して CA と通信し、証明書を生成、要求、および取得します。ルーターは、SCEP を使用して保留中の要求のステータスを確認することもできます。

5.8.1. SCEP 登録の有効化

セキュリティー上の理由から、SCEP 登録は CA でデフォルトで無効になっています。ルーターの登録を可能にするには、CA に対して SCEP 登録を手動で有効にする必要があります。
  1. 設定ファイルを編集できるように CA サーバーを停止します。 
    systemctl stop pki-tomcatd@instance_name.service
  2. CA の CS.cfg ファイルを開きます。 
    vim /var/lib/pki/instance_name/ca/conf/CS.cfg
  3. ca.scep.enable を true に設定します。パラメーターが存在しない場合は、パラメーターで行を追加します。 
    ca.scep.enable=true
  4. CA サーバーを起動します。 
    systemctl start pki-tomcatd@instance_name.service

5.8.2. SCEP のセキュリティー設定の設定

管理者は、登録認証と通常の証明書登録に同じ証明書を使用しない、または接続強度の低下を防ぐために許可された暗号化アルゴリズムを設定するなど、いくつかの異なるパラメーターを使用して、SCEP 接続に特定のセキュリティー要件を設定できます。これらのパラメーターは、表5.2「SCEP セキュリティーの設定パラメーター」 に一覧表示されます。

表5.2 SCEP セキュリティーの設定パラメーター

パラメーター 説明
ca.scep.encryptionAlgorithm デフォルトまたは優先暗号化アルゴリズムを設定します。
ca.scep.allowedEncryptionAlgorithms 許可される暗号化アルゴリズムのコンマ区切りリストを設定します。
ca.scep.hashAlgorithm デフォルトまたは優先ハッシュアルゴリズムを設定します。
ca.scep.allowedHashAlgorithms 許可されるハッシュアルゴリズムのコンマ区切りリストを設定します。
ca.scep.nickname SCEP 通信に使用する証明書のニックネームを指定します。このパラメーターが設定されていない限り、デフォルトで CA のキーペアおよび証明書が使用されます。
ca.scep.nonceSizeLimit SCEP リクエストに許可される最大 nonce サイズ (バイト単位) を設定します。デフォルトは 16 バイトです。
SCEP 登録の接続にセキュリティー設定を設定するには、以下を実行します。
  1. 設定ファイルを編集できるように CA サーバーを停止します。 
    systemctl stop pki-tomcatd@instance_name.service
  2. CA の CS.cfg ファイルを開きます。 
    vim /var/lib/pki/instance_name/ca/conf/CS.cfg
  3. 表5.2「SCEP セキュリティーの設定パラメーター」 に記載されているように、必要なセキュリティーパラメーターを設定します。このパラメーターが存在しない場合は、CS.cfg ファイルに追加します。 
    ca.scep.encryptionAlgorithm=DES3
ca.scep.allowedEncryptionAlgorithms=DES3
ca.scep.hashAlgorithm=SHA1
ca.scep.allowedHashAlgorithms=SHA1,SHA256,SHA512
ca.scep.nickname=Server-Cert
ca.scep.nonceSizeLimit=20
  4. CA サーバーを起動します。 
    systemctl start pki-tomcatd@instance_name.service

5.8.3. SCEP 登録のルーターの設定

注記
ルーター IOS の全バージョンには関連する暗号化機能があるわけではありません。ファームウェアイメージに認証局の相互運用性があることを確認します。証明書システム SCEP サポートは、IOS C2600 Software (C2600-JK9S-M), バージョン 12.2(40), RELEASE SOFTWARE (fc1) を実行している Cisco 2611 ルーターでテストされました。
ルーターに SCEP 証明書を登録する前に、ルーターが適切に設定されていることを確認します。
  • ルーターは、IP アドレス、DNS サーバー、およびルーティング情報で設定する必要があります。
  • ルーターの日付/時刻が正しく設定されている必要があります。
  • ルーターのホスト名と dnsname を設定する必要があります。
ルーターのハードウェアの設定方法は、ルーターのドキュメントを参照してください。

5.8.4. ルーターの SCEP 証明書の生成

以下の手順では、ルーターの SCEP 証明書を生成する方法を説明します。
  1. ランダムな PIN を選択します。
  2. ルーターが CA に対して直接認証できるように、PIN とルーターの ID を flatfile.txt ファイルに追加します。以下に例を示します。 
    vim /var/lib/pki/instance_name/ca/conf/flatfile.txt

UID:172.16.24.238
PWD:Uojs93wkfd0IS
    PWD 行の後に空の行を挿入してください。
    ルーターの IP アドレスは、IPv4 アドレスまたは IPv6 アドレスになります。
    フラットファイルの認証の使用は、「フラットファイル認証の設定」 に記載されています。
  3. ルーターのコンソールにログインします。以下の例では、ルーターの名前は scep です。 
    scep>
  4. 特権コマンドを有効にします。 
    scep> enable
  5. 設定モードを入力します。 
    scep# conf t
  6. root で始まり、証明書チェーン内のすべての CA に CA 証明書をインポートします。たとえば、次のコマンドシーケンスは、チェーン内の 2 つの CA 証明書をルーターにインポートします。 
    scep(config)# crypto ca trusted-root1
scep(ca-root)# root CEP http://server.example.com:8080/ca/cgi-bin/pkiclient.exe
scep(ca-root)# crl optional
scep(ca-root)# exit
scep(config)# cry ca authenticate 1
scep(config)# crypto ca trusted-root0
scep(ca-root)# root CEP http://server.example.com:8080/ca/cgi-bin/pkiclient.exe
scep(ca-root)# crl optional
scep(ca-root)# exit
scep(config)# cry ca authenticate 0
  7. CA アイデンティティーを設定し、SCEP 登録プロファイルにアクセスするための URL を入力します。CA の場合の例を以下に示します。 
    scep(config)# crypto ca identity CA
scep(ca-identity)# enrollment url http://server.example.com:8080/ca/cgi-bin
scep(ca-identity)# crl optional
  8. CA の証明書を取得します。 
    scep(config)# crypto ca authenticate CA
Certificate has the following attributes:
Fingerprint: 145E3825 31998BA7 F001EA9A B4001F57
% Do you accept this certificate? [yes/no]: yes
  9. RSA 鍵ペアを生成します。 
    scep(config)# crypto key generate rsa
The name for the keys will be: scep.server.example.com
Choose the size of the key modulus in the range of 360 to 2048 for your
General Purpose Keys. Choosing a key modulus greater than 512 may take
a few minutes.

How many bits in the modulus [512]:
Generating RSA keys ...
[OK]
  10. 最後に、ルーターに証明書を生成します。 
    scep(config)# crypto ca enroll CA
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
password to the CA Administrator in order to revoke your certificate.
For security reasons your password will not be saved in the configuration.
Please make a note of it.

Password: secret
Re-enter password: secret

% The subject name in the certificate will be: scep.server.example.com
% Include the router serial number in the subject name? [yes/no]: yes
% The serial number in the certificate will be: 57DE391C
% Include an IP address in the subject name? [yes/no]: yes
% Interface: Ethernet0/0
% Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the fingerprint.

% Fingerprint:D89DB555 E64CC2F7 123725B4 3DBDF263

Jan 12 13:41:17.348: %CRYPTO-6-CERTRET: Certificate received from Certificate
  11. 設定モードを閉じます。 
     scep(config)# exit
  12. ルーターが適切に登録されたことを確認するには、ルーターに保存されている証明書の一覧を表示します。 
    scep# show crypto ca certificates
Certificate
 Status: Available
 Certificate Serial Number: 0C
 Key Usage: General Purpose
 Issuer:
	CN = Certificate Authority
	 O = Sfbay Red hat Domain 20070111d12
 Subject Name Contains:
	Name: scep.server.example.com
	IP Address: 10.14.1.94
	Serial Number: 57DE391C
 Validity Date:
	start date: 21:42:40 UTC Jan 12 2007
	end date: 21:49:50 UTC Dec 31 2008
 Associated Identity: CA

CA Certificate
 Status: Available
 Certificate Serial Number: 01
 Key Usage: Signature
 Issuer:
	CN = Certificate Authority
	 O = Sfbay Red hat Domain 20070111d12
 Subject:
	CN = Certificate Authority
	 O = Sfbay Red hat Domain 20070111d12
 Validity Date:
	start date: 21:49:50 UTC Jan 11 2007
	end date: 21:49:50 UTC Dec 31 2008
 Associated Identity: CA

5.8.5. Subordinate CA の使用

ルーターが CA に対して認証できるようにするには、ルートから CA 証明書チェーンのすべての CA 証明書をルーターにインポートする必要があります。たとえば、次のコマンドシーケンスは、チェーン内の 2 つの CA 証明書をルーターにインポートします。 
scep(config)# crypto ca trusted-root1
scep(ca-root)# root CEP http://server.example.com:8080/ca/cgi-bin/pkiclient.exe
scep(ca-root)# crl optional
scep(ca-root)# exit
scep(config)# cry ca authenticate 1
scep(config)# crypto ca trusted-root0
scep(ca-root)# root CEP http://server.example.com:8080/ca/cgi-bin/pkiclient.exe
scep(ca-root)# crl optional
scep(ca-root)# exit
scep(config)# cry ca authenticate 0
CA 証明書に CRL ディストリビューションポイントの拡張が設定されていない場合は、次 optional に設定して CRL 要件をオフにします。 
scep(ca-root)# crl optional
その後、「ルーターの SCEP 証明書の生成」 の説明に従って CA アイデンティティーを設定します。

5.8.6. ルーターの再登録

ルーターを新しい証明書で再登録できるようにするには、既存の設定を削除する必要があります。
  1. 既存のキーを削除 (ゼロ化)。 
    scep(config)# crypto key zeroize rsa
% Keys to be removed are named scep.server.example.com.
Do you really want to remove these keys? [yes/no]: yes
  2. CA アイデンティティーを削除します。 
    scep(config)# no crypto ca identity CA
% Removing an identity will destroy all certificates received from
the related Certificate Authority.

Are you sure you want to do this? [yes/no]: yes
% Be sure to ask the CA administrator to revoke your certificates.

No enrollment sessions are currently active.

5.8.7. デバッグの有効化

ルーターは、debug ステートメントを有効にして、SCEP 操作中に追加のデバッグを提供します。 
 scep# debug crypto pki callbacks
 Crypto PKI callbacks debugging is on

 scep# debug crypto pki messages
 Crypto PKI Msg debugging is on

 scep# debug crypto pki transactions
 Crypto PKI Trans debugging is on

 scep#debug crypto verbose
 verbose debug output debugging is on

5.8.8. SCEP で ECC 証明書を発行

デフォルトでは、ECCCA はすぐに使用できる SCEP をサポートしていません。ただし、指定した RSA 証明書を使用して、以下の 2 つの領域を処理することで回避できます。
  • 暗号化/複号証明書 - 暗号化機能/複号機能を持つ RSA 証明書 (以下の例では scepRSAcert) を指定します。
  • 署名証明書 - 自己署名ではなく、クライアント側で使用する RSA 証明書を取得します (以下の例では signingCert 証明書)。
たとえば、scepRSAcert 証明書が暗号化/複号証明書で、署名証明書である SignCert を使用する場合は、次のコマンドを実行します。 
sscep enroll -c ca.crt -e scepRSAcert.crt -k local.key -r local.csr -K sign.key -O sign.crt -E 3des -S sha256 -l cert.crt -u 'http://example.example.com:8080/ca/cgi-bin/pkiclient.exe'

第6章 Token Management System の使用および設定: TPS および TKS

本章では、HSM または トークン と呼ばれるハードウェアセキュリティーモジュールを使用して、Certificate System インスタンスの証明書および鍵を生成および保存する手順を説明します。
本章には管理手順のみが含まれています。Token Management System 9 の概念に関する一般的な情報は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』を参照してください。

6.1. TPS プロファイル

注記
一般情報は、『Red Hat Certificate System 9 計画、インストール、およびデプロイメントのガイド』 の 『TPS Profiles』 セクションを参照してください。
個々のファイルまたは LDAP で定義および保存される CA 登録プロファイルとは異なり、TPS プロファイル (トークンタイプとも呼ばれます) は TPS 設定ファイル CS.cfg で定義されます。
TPS プロファイル (トークンタイプ) の設定パラメーターは、以下の形式で設定されます。 
op.<explicit op>.<profile id>.<implicit op>.<key type>.*
上記の <explicit op> および <implicit op> は、以下の TPS 操作セクションで説明される明示的な操作および暗黙的な操作のいずれかであり、<key type> は各証明書タイプに指定された名前になります。
設定パラメーターの例は、次の例のようになります。 
op.enroll.userKey.keyGen.encryption.*

6.2. TPS 操作

明示的な操作

明示的な操作 はユーザーが呼び出す操作です。明示的な操作には、enroll (op.enroll.*)、format (op.format.*)、および pinReset (op.pinReset.*) が含まれます。

暗黙的な操作

暗黙的な操作 は、明示的な操作が処理されるときにトークンのポリシーまたはステータスが原因で発生する操作です。暗黙的な操作には、keyGen (op.enroll.userKey.keyGen.*)、renewal (op.enroll.userKey.renewal.*)、update.applet (op.enroll.userKey.update.applet.*)、およびキー更新 (op.enroll.userKey.update.symmetricKeys.*) が含まれます。

暗黙的な操作の一部は、キーのタイプごとに制御されます。これには、recovery、serverKeygen、および revocation が含まれます。
次の TPS プロファイルの例では、サーバー側で生成されるユーザーキーを指定しています。 
op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true
op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1
op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true
さらに、次の例は、状態遷移中、キーが侵害されたトークンが失効理由 1 で認証を取り消す必要があることを TPS に通知します。 
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert=true
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert.reason=1
RFC 5280 に基づいて、失効可能な理由とそれらのコードは以下のように定義されます。

表6.1 失効理由およびコード

理由 コード
指定なし 0
keyCompromise 1
CACompromise 2
affiliationChanged 3
superseded 4
cessationOfOperation 5
certificateHold 6
removeFromCRL 8
privilegeWithdrawn 9
AACompromise 10

6.3. トークンポリシー

本セクションでは、TPS UI を使用して、トークンごとに適用可能なトークンポリシーの一覧を提供します。各セクションでは、各ポリシーが設定にどのように反映されるかを示します。
注記
一般情報は、『Red Hat Certificate System 9 計画、インストール、およびデプロイメントガイド』の『トークンポリシー』セクションを参照してください。
ポリシーは、セミコロン (";"") で区切られたポリシーの集合体です。各ポリシーは、キーワード YES または NO を使用してオンまたはオフにできます。以下のリストの各ポリシーは、デフォルト値 (設定がポリシー文字列にまったく存在しなかった場合に TPS によって実行されるアクション) で導入されます。
RE_ENROLL=YES
このポリシーは、トークンが再登録操作を許可するかどうかを制御します。これにより、すでに登録されたトークン (証明書を含む) を再登録し、新しいトークンを登録できるようになります。これを NO に設定すると、再登録を試行するとサーバーはエラーを返します。
このポリシーでは、特別な設定は必要ありません。登録は、標準の登録プロファイルで続行されます。このプロファイルは、最初にトークンを登録する可能性があります。
RENEW=NO;RENEW_KEEP_OLD_ENC_CERTS=YES
更新により、トークンは、プロファイルで生成された証明書をトークンの所定の場所で更新することができます。RENEW を YES に設定すると、Enterprise Security Client (ESC) からの簡単な登録により、上記のように再登録せずに更新が行われます。
RENEW_KEEP_OLD_ENC_CERTS 設定は、更新操作が以前のバージョンの暗号化証明書を保持するかどうかを決定します。以前の証明書を保持すると、ユーザーは古い証明書で暗号化されたデータにアクセスできます。このオプションを NO に設定すると、古い証明書で暗号化したすべてのものを復元できなくなることを意味します。
設定: 
op.enroll.userKey.renewal.encryption.ca.conn=ca1
op.enroll.userKey.renewal.encryption.ca.profileId=caTokenUserEncryptionKeyRenewal
op.enroll.userKey.renewal.encryption.certAttrId=c2
op.enroll.userKey.renewal.encryption.certId=C2
op.enroll.userKey.renewal.encryption.enable=true
op.enroll.userKey.renewal.encryption.gracePeriod.after=30
op.enroll.userKey.renewal.encryption.gracePeriod.before=30
op.enroll.userKey.renewal.encryption.gracePeriod.enable=false
op.enroll.userKey.renewal.keyType.num=2
op.enroll.userKey.renewal.keyType.value.0=signing
op.enroll.userKey.renewal.keyType.value.1=encryption
op.enroll.userKey.renewal.signing.ca.conn=ca1
op.enroll.userKey.renewal.signing.ca.profileId=caTokenUserSigningKeyRenewal
op.enroll.userKey.renewal.signing.certAttrId=c1
op.enroll.userKey.renewal.signing.certId=C1
op.enroll.userKey.renewal.signing.enable=true
op.enroll.userKey.renewal.signing.gracePeriod.after=30
op.enroll.userKey.renewal.signing.gracePeriod.before=30
op.enroll.userKey.renewal.signing.gracePeriod.enable=false
このタイプの更新設定は、更新固有の追加設定をいくつか追加し、基本的な userKey 標準登録プロファイルをミラーリングします。このパリティーが必要なのは、更新が開始される前に、トークンに最初に登録された証明書の数とタイプを正確に更新するためです。
FORCE_FORMAT=NO
このポリシーにより、登録操作ごとにフォーマット操作が要求されます (有効な場合)。これは、ユーザーが管理者に返すことなくトークンをリセットできるようにする最終手順です。これを YES に設定すると、ユーザーが開始された登録操作がすべて形式になり、トークンがフォーマットされた状態に対して強制的にリセットされます。
追加の設定は必要ありません。単純な形式は、標準のフォーマット操作の実行に使用されるものと同じ TPS プロファイルで実行されます。
PIN_RESET=NO
このポリシーは、すでに登録されているトークンが ESC を使用して明示的なピンリセット変更を実行できるかどうかを決定します。この値は、YES に設定しなければならないか、サーバーがエラーにより発生した操作は拒否されます。
設定: 
op.enroll.userKey.pinReset.enable=true
op.enroll.userKey.pinReset.pin.maxLen=10
op.enroll.userKey.pinReset.pin.maxRetries=127
op.enroll.userKey.pinReset.pin.minLen=4
上記の例では、minLen および maxLen の設定が、選択したパスワードの長さに制約を課し、maxRetries 設定は、ロックアップする前に指定された回数の再試行のみを許可するようにトークンを設定します。
TPS ポリシーは、最新の TPS ユーザーインターフェイスを使用して簡単に編集できます。ポリシーの変更を必要とするトークンに移動し、Edit をクリックします。これにより、フィールドを編集できるダイアログが表示されます。これは、セミコロンで区切られたポリシーのコレクションです。TPS が認識するには、サポートされる各ポリシーを <POLICYNAME>=YES または <POLICYNAME>=NO に設定する必要があります。

6.4. トークン操作およびポリシー処理

このセクションでは、トークンに関連する主要な操作 (明示的および暗黙的) について説明します。以下のリストは、各機能とその設定について記載しています。
注記
一般情報は、『Red Hat Certificate System 9 計画、インストール、およびデプロイメントガイド』の『トークンポリシー』セクションを参照してください。
形式
(ユーザーが開始した) Format 操作は、製造元から提供された完全に空白の状態のトークンを受け取り、Coolkey アプレットを読み込みます。
設定例: 
#specify that we want authentication for format. We almost always want this at true:
op.format.userKey.auth.enable=true
#specify the ldap authentication configuration, so TPS knows where to validate credentials:
op.format.userKey.auth.id=ldap1
#specify the connection the the CA
op.format.userKey.ca.conn=ca1
#specify id of the card manager applet on given token
op.format.userKey.cardmgr_instance=A0000000030000

#specify if we need to match the visa cuid to the nist sp800sp derivation algorithm KDD value. Mostly will be false:
op.format.userKey.cuidMustMatchKDD=false

#enable ability to restrict key changoever to a specific range of key set:
op.format.userKey.enableBoundedGPKeyVersion=true
#enable the phone home url to write to the token:
op.format.userKey.issuerinfo.enable=true
#actual home url to write to token:
op.format.userKey.issuerinfo.value=http://server.example.com:8080/tps/phoneHome
#specify whether to request a login from the client. Mostly true, external reg may want this to be false:
op.format.userKey.loginRequest.enable=true
#Actual range of desired keyset numbers:
op.format.userKey.maximumGPKeyVersion=FF
op.format.userKey.minimumGPKeyVersion=01
#Whether or not to revoke certs on the token after a format, and what the reason will be if so:
op.format.userKey.revokeCert=true
op.format.userKey.revokeCert.reason=0
#This will roll back the reflected keyyset version of the token in the tokendb. After a failed key changeover operation. This is to keep the value in sync with reality in the tokendb. Always false, since this version of TPS avoids this situation now:
op.format.userKey.rollbackKeyVersionOnPutKeyFailure=false

#specify connection to the TKS:
op.format.userKey.tks.conn=tks1
#where to get the actual applet file to write to the token:
op.format.userKey.update.applet.directory=/usr/share/pki/tps/applets
#Allows a completely blank token to be recognized by TPS. Mostly should be true:
op.format.userKey.update.applet.emptyToken.enable=true
#Always should be true, not supported:
op.format.userKey.update.applet.encryption=true
#Actual version of the applet file we want to upgrade to. This file will have a name something like: 1.4.54de7a99.ijc:
op.format.userKey.update.applet.requiredVersion=1.4.54de790f
#Symm key changeover:
op.format.userKey.update.symmetricKeys.enable=false
op.format.userKey.update.symmetricKeys.requiredVersion=1
#Make sure the token db is in sync with reality. Should always be true:
op.format.userKey.validateCardKeyInfoAgainstTokenDB=true
登録
基本的な登録操作では、フォーマットされたトークンを取得し、トークンをカスタマイズするために証明書とキーをトークンに配置します。次の設定例では、これを制御する方法を説明します。
この例は、更新および内部リカバリーを処理しない基本的な登録を示しています。ここで説明されていない設定は、Format セクションで説明されています。または必須ではありません。 
op.enroll.userKey.auth.enable=true
op.enroll.userKey.auth.id=ldap1
op.enroll.userKey.cardmgr_instance=A0000000030000
op.enroll.userKey.cuidMustMatchKDD=false

op.enroll.userKey.enableBoundedGPKeyVersion=true
op.enroll.userKey.issuerinfo.enable=true
op.enroll.userKey.issuerinfo.value=http://server.example.com:8080/tps/phoneHome

#configure the encryption cert and keys  we want on the token:

#connection the the CA, which issues the certs:
op.enroll.userKey.keyGen.encryption.ca.conn=ca1
#Profile id we want the CA to use to issue our encrytion cert:
op.enroll.userKey.keyGen.encryption.ca.profileId=caTokenUserEncryptionKeyEnrollment

#These two cover the indexes of the certs written to the token. Each cert needs a unique index or “slot”. In our sample the enc cert will occupy slot 2 and the signing cert, shown later, will occupy slot 1. Avoid overlap with these numbers:
op.enroll.userKey.keyGen.encryption.certAttrId=c2
op.enroll.userKey.keyGen.encryption.certId=C2

op.enroll.userKey.keyGen.encryption.cuid_label=$cuid$
#specify size of generated private key:
op.enroll.userKey.keyGen.encryption.keySize=1024
op.enroll.userKey.keyGen.encryption.keyUsage=0
op.enroll.userKey.keyGen.encryption.keyUser=0
#specify pattern for what the label of the cert will look like when the cert nickname is displayed in browsers and mail clients:
op.enroll.userKey.keyGen.encryption.label=encryption key for $userid$
#specify if we want to overwrite certs on a re-enrollment operation. This is almost always the case:
op.enroll.userKey.keyGen.encryption.overwrite=true

#The next several settings specify the capabilities that the private key on the final token will inherit. For instance this will determine if the cert can be used for encryption or digital signatures. There are settings for both the private and public key.

op.enroll.userKey.keyGen.encryption.private.keyCapabilities.decrypt=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.derive=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.encrypt=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.private=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.sensitive=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.sign=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.signRecover=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.token=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.unwrap=true
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.verify=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.verifyRecover=false
op.enroll.userKey.keyGen.encryption.private.keyCapabilities.wrap=false
op.enroll.userKey.keyGen.encryption.privateKeyAttrId=k4
op.enroll.userKey.keyGen.encryption.privateKeyNumber=4
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.decrypt=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.derive=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.encrypt=true
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.private=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.sensitive=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.sign=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.signRecover=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.token=true
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.unwrap=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.verify=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.verifyRecover=false
op.enroll.userKey.keyGen.encryption.public.keyCapabilities.wrap=true

#The following index numbers correspond to the index or slot that the private and public keys occupy. The common formula we use is that the public key index will be 2 * cert id + 1, and the private key index, shown above will be 2 * cert id. In this example the cert id is 2, so the key ids will be 4 and 5 respectively. When composing these, be careful not to create conflicts. This applies to the signing key section below.

op.enroll.userKey.keyGen.encryption.publicKeyAttrId=k5
op.enroll.userKey.keyGen.encryption.publicKeyNumber=5

#specify if, when a certificate is slated for revocation, based on other rules, we want to check to see if some other token is using this cert in a shared situation. If this is set to true, and this situation is found the cert will not be revoked until the last token wants to revoke this cert:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.holdRevocationUntilLastCredential=false

#specify, if we want server side keygen, if we want to have that generated key archived to the drm. This is almost always the case, since we want the ability to later recover a cert and its encryption private key back to a new token:
op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true
#connection to drm to generate the key for us:
op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1
#specify server side keygen of the encryption private key. This most often will be desired:
op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true

#This setting tells us how many certs we want to enroll for this TPS profile, in the case “userKey”. Here we want 2 total certs. The next values then go on to index into the config what two types of certs we want, signing and encryption:
op.enroll.userKey.keyGen.keyType.num=2
op.enroll.userKey.keyGen.keyType.value.0=signing
op.enroll.userKey.keyGen.keyType.value.1=encryption

#configure the signing cert and keys we want on the token the settings for these are similar to the encryption settings already discussed, except the capability flags presented below, since this is a signing key.

op.enroll.userKey.keyGen.signing.ca.conn=ca1
op.enroll.userKey.keyGen.signing.ca.profileId=caTokenUserSigningKeyEnrollment
op.enroll.userKey.keyGen.signing.certAttrId=c1
op.enroll.userKey.keyGen.signing.certId=C1
op.enroll.userKey.keyGen.signing.cuid_label=$cuid$
op.enroll.userKey.keyGen.signing.keySize=1024
op.enroll.userKey.keyGen.signing.keyUsage=0
op.enroll.userKey.keyGen.signing.keyUser=0
op.enroll.userKey.keyGen.signing.label=signing key for $userid$
op.enroll.userKey.keyGen.signing.overwrite=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.decrypt=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.derive=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.encrypt=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.private=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.sensitive=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.sign=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.signRecover=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.token=true
op.enroll.userKey.keyGen.signing.private.keyCapabilities.unwrap=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.verify=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.verifyRecover=false
op.enroll.userKey.keyGen.signing.private.keyCapabilities.wrap=false
op.enroll.userKey.keyGen.signing.privateKeyAttrId=k2
op.enroll.userKey.keyGen.signing.privateKeyNumber=2
op.enroll.userKey.keyGen.signing.public.keyCapabilities.decrypt=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.derive=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.encrypt=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.private=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.sensitive=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.sign=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.signRecover=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.token=true
op.enroll.userKey.keyGen.signing.public.keyCapabilities.unwrap=false
op.enroll.userKey.keyGen.signing.public.keyCapabilities.verify=true
op.enroll.userKey.keyGen.signing.public.keyCapabilities.verifyRecover=true
op.enroll.userKey.keyGen.signing.public.keyCapabilities.wrap=false
op.enroll.userKey.keyGen.signing.publicKeyAttrId=k3
op.enroll.userKey.keyGen.signing.publicKeyNumber=3
ピンリセット
ピンリセットは、合理的に実行されるべきかどうかを判断するポリシーに依存するため、ピンリセットの設定については 「トークンポリシー」 で説明しています。
更新
更新は、すでに登録されているトークンに対して実行することが合法であるかどうかを判断するためのポリシーに依存しているため、更新の設定については 「トークンポリシー」 で説明しています。
復元
TPS ユーザーインターフェイスのユーザーが以前にアクティブだったトークンを紛失や破棄などの好ましくない状態にマークすると、復元が暗黙的に開始されます。これが発生すると、同じユーザーによる次の新しいトークンの登録は、次の設定に従って、ユーザーの古いトークンからこの新しいトークンに証明書を復元します。
この操作の最終結果は、ユーザーが古いトークンから回復された暗号化証明書を含む可能性のある新しい物理トークンを取得することです。これにより、ユーザーは必要に応じてデータの暗号化と復号を続行できます。以下のサンプル設定例に示すように、通常、新しい署名証明書もこのトークンに配置されます。
以下は、設定に示されているように、TPS ユーザーインターフェイスでトークンを手動で配置できるサポートされている状態のリストです。
  • tokendb._069=# - DAMAGED (1): リカバリー設定の destroyed に相当します。トークンが物理的に破損された場合に使用します。
  • tokendb._070=# - PERM_LOST (2): リカバリー設定の keyCompromise に相当します。トークンが永久に失われた場合に使用されます。
  • tokendb._071=# - SUSPENDED (3): リカバリー設定の onHold に相当します。トークンを一時的に配置した際に使用されますが、ユーザーはトークンを再度検索することが予想されます。
  • tokendb._072=# - TERMINATED (6): リカバリー設定で terminated するもの。トークンをサービス対象外にするために内部の理由から使用します。
リカバリー設定の例: 
#When a token is marked destroyed, don’t revoke the certs on the token unless all other tokens do not have the certs included:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.holdRevocationUntilLastCredential=false
#specify if we even want to revoke certs a token is marked destroyed:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeCert=false
#if we want to revoke any certs here, specify the reason for revocation that will be sent to the CA:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeCert.reason=0
#speficy if we want to revoke expired certs when marking the token destroyed:
op.enroll.userKey.keyGen.encryption.recovery.destroyed.revokeExpiredCerts=false
追加の設定を使用して、新しいトークンに対して回復操作を実行するときに (元のトークンが破棄済みとしてマークされている場合)、サポートされている静的回復の種類を指定します。以下のスキームがサポートされます。
  • Recover Last (RecoverLast): トークンに配置される最新の暗号化証明書を復旧します。
  • Generate New Key and Recover Last (GenerateNewKeyAndRecoverLast): Recover Last と同じですが、新しい暗号化証明書を生成し、トークンにアップロードします。新しいトークンには 2 つの証明書が含まれます。
  • Generate New Key (GenerateNewKey): 新しい暗号化証明書を生成し、トークンに配置します。古い証明書は復元しないでください。
以下に例を示します。 
op.enroll.userKey.keyGen.encryption.recovery.destroyed.scheme=RecoverLast
次の設定例は、永久に失われたとマークされたトークンを回復する方法を決定します。 
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert=true
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeCert.reason=1
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.revokeExpiredCerts=false
op.enroll.userKey.keyGen.encryption.recovery.keyCompromise.scheme=GenerateNewKey

# Section when a token is marked terminated.

op.enroll.userKey.keyGen.encryption.recovery.terminated.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.encryption.recovery.terminated.revokeCert=true
op.enroll.userKey.keyGen.encryption.recovery.terminated.revokeCert.reason=1
op.enroll.userKey.keyGen.encryption.recovery.terminated.revokeExpiredCerts=false
op.enroll.userKey.keyGen.encryption.recovery.terminated.scheme=GenerateNewKey

# This section details the recovery profile with respect to which certs and of what kind get recovered on the token.

op.enroll.userKey.keyGen.recovery.destroyed.keyType.num=2
op.enroll.userKey.keyGen.recovery.destroyed.keyType.value.0=signing
op.enroll.userKey.keyGen.recovery.destroyed.keyType.value.1=encryption
最後に、次の例では、古いトークンにあった署名証明書に対してシステムが何を行うかを決定します。ほとんどの場合、署名秘密鍵の複数のコピーが使用可能になる可能性を回避するために、GenerateNewKey 復元スキームを使用する必要があります (たとえば、新しいトークンで復元されたものと、永久に失われたが他の誰かによって発見された古いトークンで復元されたもの)。 
op.enroll.userKey.keyGen.recovery.keyCompromise.keyType.value.0=signing
op.enroll.userKey.keyGen.recovery.keyCompromise.keyType.value.1=encryption
op.enroll.userKey.keyGen.recovery.onHold.keyType.num=2
op.enroll.userKey.keyGen.recovery.onHold.keyType.value.0=signing
op.enroll.userKey.keyGen.recovery.onHold.keyType.value.1=encryption

op.enroll.userKey.keyGen.signing.recovery.destroyed.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeCert=true
op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeCert.reason=0
op.enroll.userKey.keyGen.signing.recovery.destroyed.revokeExpiredCerts=false
op.enroll.userKey.keyGen.signing.recovery.destroyed.scheme=GenerateNewKey
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeCert=true
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeCert.reason=1
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.revokeExpiredCerts=false
op.enroll.userKey.keyGen.signing.recovery.keyCompromise.scheme=GenerateNewKey
op.enroll.userKey.keyGen.signing.recovery.onHold.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.signing.recovery.onHold.revokeCert=true

op.enroll.userKey.keyGen.signing.recovery.onHold.revokeCert.reason=6
op.enroll.userKey.keyGen.signing.recovery.onHold.revokeExpiredCerts=false
op.enroll.userKey.keyGen.signing.recovery.onHold.scheme=GenerateNewKey
op.enroll.userKey.keyGen.signing.recovery.terminated.holdRevocationUntilLastCredential=false
op.enroll.userKey.keyGen.signing.recovery.terminated.revokeCert=true
op.enroll.userKey.keyGen.signing.recovery.terminated.revokeCert.reason=1
op.enroll.userKey.keyGen.signing.recovery.terminated.revokeExpiredCerts=false
op.enroll.userKey.keyGen.signing.recovery.terminated.scheme=GenerateNewKey

# Configuration for the case when we mark a token “onHold” or temporarily lost

op.enroll.userKeyTemporary.keyGen.encryption.recovery.onHold.revokeCert=true
op.enroll.userKeyTemporary.keyGen.encryption.recovery.onHold.revokeCert.reason=0
op.enroll.userKeyTemporary.keyGen.encryption.recovery.onHold.scheme=RecoverLast
op.enroll.userKeyTemporary.keyGen.recovery.onHold.keyType.num=2
op.enroll.userKeyTemporary.keyGen.recovery.onHold.keyType.value.0=signing
op.enroll.userKeyTemporary.keyGen.recovery.onHold.keyType.value.1=encryption
op.enroll.userKeyTemporary.keyGen.signing.recovery.onHold.revokeCert=true
op.enroll.userKeyTemporary.keyGen.signing.recovery.onHold.revokeCert.reason=0
op.enroll.userKeyTemporary.keyGen.signing.recovery.onHold.scheme=GenerateNewKey
アプレットの更新
以下の例は、Coolkey アプレット更新操作の設定方法を示しています。この操作は、フォーマット、登録、および PIN のリセット操作中に実行できます。 
op.format.userKey.update.applet.directory=/usr/share/pki/tps/applets
op.format.userKey.update.applet.emptyToken.enable=true
op.format.userKey.update.applet.encryption=true
op.format.userKey.update.applet.requiredVersion=1.4.54de790f
これらのオプションの一部は、Format セクションですでに紹介されています。これらは、アプレットのアップグレードを許可する必要があるかどうか、アプレットファイルの場所、およびトークンをアップグレードするアプレットのバージョンを決定するために必要な情報を提供します。requiredVersion のバージョンは、directory 内のファイル名にマッピングされます。
キーの更新
この操作は、フォーマット、登録、および PIN リセット操作中に実行でき、ユーザーは Global Platform キーセットのバージョンを製造元が提供するデフォルトからアップグレードできます。
TPS
次のオプションは、特定のトークンに代わって要求された次のフォーマット操作中に、キーセットを 1 から 2 にアップグレードするように TPS に指示します。これが行われたら、TKS はトークンに書き込まれる 3 つの新しいキーを取得する必要があります。その後、トークンは同じ TPS および TKS インストールで使用する必要があります。そうしないと、ロックされます。 
op.format.userKey.update.symmetricKeys.enable=true
op.format.userKey.update.symmetricKeys.requiredVersion=2
代わりに、現在よりも低いバージョンを指定して、キーセットをダウングレードすることもできます。
TKS
上記のように、TKS は、トークンに書き込む新しい鍵を生成するように設定する必要があります。まず、新しいマスターキー識別子 02 は、次の例に示すように、TKS CS.cfg の PKCS #11 オブジェクトのニックネームにマップする必要があります。 
tks.mk_mappings.#02#01=internal:new_master
tks.defKeySet.mk_mappings.#02#01=internal:new_master
上記の例では、キーセット番号が TKS NSS データベースに存在する実際のマスターキーにマップされます。
マスターキーは、01 などの ID で識別されます。TKS は、この ID を、マッピングの masterKeyId 部分として指定した PKCS #11 オブジェクトのニックネームにマッピングします。したがって、最初の番号はマスターキーのバージョンが更新されると更新され、2 番目の番号は一貫性を保ちます。
バージョン 1 からバージョン 2 にアップグレードしようとすると、マッピングによって、新しいキーセットの 3 つの部分を取得するために使用されるマスターキーのニックネームを見つける方法が決まります。
上記の例 internal の設定は、マスターキーがあるトークンの名前を参照します。また、nethsm など、名前を持つ外部 HSM モジュールも使用できます。強力な new_master は、マスターキーのニックネーム自体の例です。

6.5. 内部登録

注記
一般情報は、『Red Hat Certificate System 9 計画、インストール、およびデプロイメントのガイド』 の 『TPS Profiles』 セクションを参照してください。
内部登録: この場合、TPS プロファイル (トークンタイプ) は、マッピングリゾルバー で決定されます。外部の登録 とは対照的に、認証情報はプロファイル自体で定義されます。以下に例を示します。 
op.enroll.userKey.auth.enable=true
op.enroll.userKey.auth.id=ldap1
外部登録とは、CA および KRA コネクター情報が各プロファイルの各キータイプで定義される点です。以下に例を示します。 
op.enroll.userKey.keyGen.encryption.ca.conn=ca1
op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1
ただし、TKS コネクター情報はプロファイルごとに定義されます。 
op.enroll.userKey.tks.conn=tks1
注記
内部登録および外部登録との間での登録タイプの切り替えにより、引き続き使用するには、以前に登録したトークンをすべてフォーマットする必要があります。

6.6. 外部登録

外部登録は、認証されたユーザーの LDAP レコードからトークンタイプ (TPS プロファイル) を取得します。また、証明書/鍵のリカバリー情報を同じユーザーレコードに指定できます。
External Registration TPS プロファイルは、前述の Internal Registration プロファイルと似ています。これにより、クライアント側の鍵とサーバー側の鍵の両方に新しい証明書登録を指定できます。内部登録とは異なり、トークンに取得および読み込む特定の証明書 (およびその一致する鍵) を選択できます。
注記
内部登録および外部登録との間での登録タイプの切り替えにより、引き続き使用するには、以前に登録したトークンをすべてフォーマットする必要があります。

6.6.1. 外部登録の有効化

外部登録は、TPS インスタンス全体に対してグローバルに有効にできます。以下の例は、外部登録に関連するグローバル設定パラメーターのセットを示しています。 
externalReg.allowRecoverInvalidCert.enable=true
externalReg.authId=ldap1
externalReg.default.tokenType=externalRegAddToToken
externalReg.delegation.enable=true
externalReg.enable=true
externalReg.recover.byKeyID=false
externalReg.format.loginRequest.enable=true
externalReg.mappingResolver=keySetMappingResolver

6.6.2. ユーザー LDAP レコード属性名のカスタマイズ

次の例に、外部登録に関連する認証パラメーターを示します (デフォルト値を使用)。 
auths.instance.ldap1.externalReg.certs.recoverAttributeName=certsToAdd
auths.instance.ldap1.externalReg.cuidAttributeName=tokenCUID
auths.instance.ldap1.externalReg.tokenTypeAttributeName=tokenType
LDAP レコード属性名はここでカスタマイズできます。ユーザーの LDAP レコードの実際の属性がこの設定と一致していることを確認します。

6.6.3. certsToAdd 属性の設定

certsToAdd 属性は、以下の形式で複数の値を取ります。 
<cert serial # in decimal>,<CA connector ID>,<key ID>,<kra connector ID>
以下に例を示します。 
59,ca1,0,kra1
重要
デフォルトでは、キーリカバリーは証明書ごとにキーを検索します。これにより、<key ID> 値が無関係になります。ただし、TPS はオプションでこの属性を使用してキーを検索するように設定できます。そのため、通常は値を 0 に設定するのは簡単です。この値は無効であるため、一致しないキーを取得できなくなります。
鍵 ID による復元は推奨されていません。これは、証明書がこの場合に鍵と一致しているかどうかを検証することができないためです。
証明書および CA 情報のみを持つ certsToAdd 属性を指定する場合、TPS は問題の証明書がトークン上にあり、保存する必要があることを仮定します。この概念は キー保持 と呼ばれます。
以下の例は、ユーザー LDAP レコードに関連する属性を示しています。 
tokenType: externalRegAddToToken
certstoadd: 59,ca1,0,kra1
certstoadd: 134,ca1,0,kra1
Certstoadd: 24,ca1

6.6.4. ユーザーマッチングの実施に対するトークン

必要に応じて、登録に使用されるトークンがユーザーレコードのトークンレコード固有の ID (CUID) 属性と一致するようにシステムを設定できます。この属性 (tokencuid) がレコードにない場合は、CUID 一致は強制されません。 
Tokencuid: a10192030405028001c0
外部登録に関するもう 1 つの属性は、各トークンのトークンポリシーが無視されます。
注記
外部登録で回復される証明書とキーの場合は、CA と KRA のコネクター情報がユーザー LDAP レコードで指定されます。復元される証明書/キーに関連する TPS プロファイルで指定された CA または KRA コネクター情報、もしくはその両方は無視されます。 
certstoadd: 59,ca1,0,kra1

6.6.5. 委譲サポート

委譲サポートは、認証 (ログイン)、データの暗号化と復号、または署名 (制限付き) に関してユーザーが代理で行動できる委任者がいる場合 (たとえば、会社の幹部に 1 人以上の委譲者がいる場合) に役立ちます。
シナリオの例としては、各幹部が、幹部に代わって行動するために使用する独自のトークンを持っている場合があります。このトークンには、(TPS プロファイルにより決定する) 以下の証明書と鍵の組み合わせが含まれます。
  • Authentication certificate/keys: CN には、委譲の名前と一意の ID が含まれます。Subject Alternative Name (SAN) 拡張機能には、幹部の Principal Name (UPN) が含まれます。
  • 暗号化証明書: ワイヤレスの暗号化証明書の正確なコピーです。
  • 証明書の署名: CN には委譲の名前と一意の ID が含まれます。SAN には、エグゼクティブの RFC822Name が含まれています。
委譲サポートを有効にするには、以下のパラメーターを使用します。 
externalReg.delegation.enable=true
重要
バグを回避するには、/var/lib/pki/instance_name/tps/conf/CS.cfg ファイルの op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId パラメーターを caTokenUserDelegateAuthKeyEnrollment に手動で設定します。 
op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId=caTokenUserDelegateAuthKeyEnrollment

6.6.6. SAN および DN のパターン

認証インスタンス設定の auths.instance.<authID>.ldapStringAttributes は、認証中に取得する属性を指定します。以下に例を示します。 
auths.instance.ldap1.ldapStringAttributes=mail,cn,uid,edipi,pcc,firstname,lastname,exec-edipi,exec-pcc,exec-mail,certsToAdd,tokenCUID,tokenType
ユーザーの LDAP レコードの取得後、これらの属性の値を参照して、$auth.<attribute name>$ の形式で証明書の Subject Alternative Name (SAN) or Distinguished Name (DN) を形成することができます。以下に例を示します。 
op.enroll.delegateIEtoken.keyGen.authentication.SANpattern=$auth.exec-edipi$.$auth.exec-pcc$@EXAMPLE.com
op.enroll.delegateIEtoken.keyGen.authentication.dnpattern=cn=$auth.firstname$.$auth.lastname$.$auth.edipi$,e=$auth.mail$,o=TMS Org
パターンが SAN および DN の TPS プロファイルで使用される場合は、TPS プロファイルに指定された CA 登録プロファイルが正しく設定されていることが重要です。以下に例を示します。
TPS、プロファイル delegateIEtoken で
op.enroll.delegateIEtoken.keyGen.authentication.ca.profileId=caTokenUserDelegateAuthKeyEnrollment
CA で、プロファイル caTokenUserDelegateAuthKeyEnrollment に登録します。
上記の TPS プロファイルで DN を指定できるようにするには、subjectDNInputImpl プラグインを入力のいずれかとして指定する必要があります。 
input.i2.class_id=subjectDNInputImpl
input.i2.name=subjectDNInputImpl
同様に、上記の TPS プロファイルで SAN を指定できるようにするには、subjectAltNameExtInputImpl プラグインを指定する必要があります。 
input.i3.class_id=subjectAltNameExtInputImpl
input.i3.name=subjectAltNameExtInputImpl
subjAltExtpattern も指定する必要があります。 
policyset.set1.p6.default.params.subjAltExtPattern_0=(UTF8String)1.3.6.1.4.1.311.20.2.3,$request.req_san_pattern_0$
上記の例では、OID 1.3.6.1.4.1.311.20.2.3 は User Principal Name (UPN) の OID で、request.req_san_pattern_0 は、delegateIEtoken SAN パターンで指定された最初の SAN パターンになります。
複数の SAN を同時に指定できます。TPS 側で、複数の SAN をコンマ (",") で区切った SANpattern で指定します。CA 側では、対応する subjAltExtPattern の数を以下の形式で定義する必要があります。 
policyset.<policy set id>.<policy id>.default.params.subjAltExtPattern_<ordered number>=
上記の例では、<ordered number> は 0 で始まり、TPS 側で指定した各 SAN パターンについて 1 つずつ増えます。 
policyset.set1.p6.default.params.subjAltExtPattern_0=
policyset.set1.p6.default.params.subjAltExtPattern_1=
...
完全な例を以下に示します。

例6.1 SANpattern および DNpattern の設定

LDAP レコードには、以下の情報が含まれます。 
givenName: user1a
mail: user1a@example.org
firstname: user1a
edipi: 123456789
pcc: AA
exec-edipi: 999999999
exec-pcc: BB
exec-mail: user1b@EXAMPLE.com
tokenType: delegateISEtoken
certstoadd: 59,ca1,0,kra1
TPS 外部登録プロファイル delegateIEtoken には、以下が含まれます。
  • SANpattern: 
    op.enroll.delegateISEtoken.keyGen.authentication.SANpattern=$auth.exec-edipi$.$auth.exec-pcc$@EXAMPLE.com
  • DNPattern: 
    op.enroll.delegateISEtoken.keyGen.authentication.dnpattern=cn=$auth.firstname$.$auth.lastname$.$auth.edipi$,e=$auth.mail$,o=TMS Org
CA caTokenUserDelegateAuthKeyEnrollment には以下が含まれます。 
input.i2.class_id=subjectDNInputImpl
input.i2.name=subjectDNInputImpl
input.i3.class_id=subjectAltNameExtInputImpl
input.i3.name=subjectAltNameExtInputImpl

policyset.set1.p6.constraint.class_id=noConstraintImpl
policyset.set1.p6.constraint.name=No Constraint
policyset.set1.p6.default.class_id=subjectAltNameExtDefaultImpl
policyset.set1.p6.default.name=Subject Alternative Name Extension Default
policyset.set1.p6.default.params.subjAltExtGNEnable_0=true
policyset.set1.p6.default.params.subjAltExtPattern_0=(UTF8String)1.3.6.1.4.1.311.20.2.3,$request.req_san_pattern_0$
policyset.set1.p6.default.params.subjAltExtType_0=OtherName
policyset.set1.p6.default.params.subjAltNameExtCritical=false
policyset.set1.p6.default.params.subjAltNameNumGNs=1
結果の証明書には次のものが含まれます。 
Subject: CN=user1a..123456789,E=user1a@example.org,O=TMS Org
Identifier: Subject Alternative Name - 2.5.29.17
Critical: no
Value:
  OtherName: (UTF8String)1.3.6.1.4.1.311.20.2.3,999999999.BB@EXAMPLE.com

6.7. Mapping Resolver の設定

Token Processing System は、デフォルトで単一のマッピングリゾルバーを提供します。リゾルバーは FilterMappingResolver と呼ばれています。本セクションでは、その設定について説明します。
注記
マッピングリゾルバーの一般的な情報は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『マッピングリゾルバー』セクションを参照してください。

6.7.1. Key Set Mapping Resolver

外部の登録時、ユーザーの認証を行う前に、キーセットはリゾルバーを使用して解決する必要があります。
キーセットマッピングリゾルバー名は以下のように定義されます。 
externalReg.mappingResolver=<keySet mapping resolver name>
以下に例を示します。 
externalReg.mappingResolver=keySetMappingResolver
以下の設定例は、完全なインスタンスの設定を示しています。 
mappingResolver.keySetMappingResolver.class_id=filterMappingResolverImpl
mappingResolver.keySetMappingResolver.mapping.0.filter.appletMajorVersion=0
mappingResolver.keySetMappingResolver.mapping.0.filter.appletMinorVersion=0
mappingResolver.keySetMappingResolver.mapping.0.filter.keySet=
mappingResolver.keySetMappingResolver.mapping.0.filter.tokenATR=
mappingResolver.keySetMappingResolver.mapping.0.filter.tokenCUID.end=a1000000000000000000
mappingResolver.keySetMappingResolver.mapping.0.filter.tokenCUID.start=a0000000000000000000
mappingResolver.keySetMappingResolver.mapping.0.target.keySet=defKeySet
mappingResolver.keySetMappingResolver.mapping.1.filter.appletMajorVersion=1
mappingResolver.keySetMappingResolver.mapping.1.filter.appletMinorVersion=1
mappingResolver.keySetMappingResolver.mapping.1.filter.keySet=
mappingResolver.keySetMappingResolver.mapping.1.filter.tokenATR=1234
mappingResolver.keySetMappingResolver.mapping.1.filter.tokenCUID.end=
mappingResolver.keySetMappingResolver.mapping.1.filter.tokenCUID.start=
mappingResolver.keySetMappingResolver.mapping.1.target.keySet=defKeySet
mappingResolver.keySetMappingResolver.mapping.2.filter.appletMajorVersion=
mappingResolver.keySetMappingResolver.mapping.2.filter.appletMinorVersion=
mappingResolver.keySetMappingResolver.mapping.2.filter.keySet=
mappingResolver.keySetMappingResolver.mapping.2.filter.tokenATR=
mappingResolver.keySetMappingResolver.mapping.2.filter.tokenCUID.end=
mappingResolver.keySetMappingResolver.mapping.2.filter.tokenCUID.start=
mappingResolver.keySetMappingResolver.mapping.2.target.keySet=jForte
mappingResolver.keySetMappingResolver.mapping.order=0,1,2
上記の例は、0、1、および 2 という名前の 3 つのマッピングを定義します。これらは、例の mappingResolver.keySetMappingResolver.mapping.order=0,1,2 行を使用して昇順で順序付けされます。この順序は、入力パラメーターが最初にマッピングフィルター 0 に対して実行されることを意味します。入力パラメーターがそのフィルターに一致しない場合にのみ、マッピング順序の次のフィルターが試行されます。たとえば、以下の特性を持つトークンが評価されます。 
CUID=a0000000000000000011
appletMajorVersion=0
appletMinorVersion=0
次に、マッピング 0 を渡し、そのターゲットが割り当てられます。これは、defKeySet に設定されます。これは、アプレットのバージョンが一致し、CUID がそのマッピングの CUID の開始範囲と終了範囲内にあるためです。
一方、トークンに以下のパラメーターがある場合には、以下を行います。 
CUID=b0000000000000000000
ATR=2222
appletMajorVersion=1
appletMinorVersion=1
この場合、このトークンは指定された CUID 範囲外であるため、0 のマッピングに失敗します。また、アプレットバージョンが一致すると ATR がマッピングされないため、1 マッピングも失敗します。上記のトークンはマッピング 2 とそのターゲット jForte に割り当てられます。
マッピング 2 には、そのフィルターへの割り当てがないことに留意してください。これにより、マッピングがすべてのトークンと照合され、実質的にデフォルトの値になります。このようなマッピングは、マッピング順序の最後に指定する必要があります。これ以降、他のマッピングは評価されないためです。

6.7.2. Token Type (TPS) Mapping Resolver

Token Processing System で定義されたデフォルトの tokenType マッピングリゾルバーは、formatProfileMappingResolver、enrollProfileMappingResolver、および pinResetProfileMappingResolver の 3 つです。前のセクションで説明した外部登録の場合と比較すると、内部登録の場合、トークンタイプは実際には定義されたマッピングリゾルバーから計算されます。
トークンタイプマッピングリゾルバー名は以下のように定義されます。 
op.<op>.mappingResolver=<mapping resolver name>
以下に例を示します。 
op.enroll.mappingResolver=enrollProfileMappingResolver
以下の設定例は、enrollProfileMappingResolver を説明します。 
mappingResolver.enrollProfileMappingResolver.class_id=filterMappingResolverImpl
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.appletMajorVersion=1
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.appletMinorVersion=
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.tokenATR=
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.tokenCUID.end=b1000000000000000000
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.tokenCUID.start=b0000000000000000000
mappingResolver.enrollProfileMappingResolver.mapping.0.filter.tokenType=userKey
mappingResolver.enrollProfileMappingResolver.mapping.0.target.tokenType=userKey
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.appletMajorVersion=1
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.appletMinorVersion=
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.tokenATR=
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.tokenCUID.end=a0000000000000001000
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.tokenCUID.start=a0000000000000000000
mappingResolver.enrollProfileMappingResolver.mapping.1.filter.tokenType=soKey
mappingResolver.enrollProfileMappingResolver.mapping.1.target.tokenType=soKey
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.appletMajorVersion=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.appletMinorVersion=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.tokenATR=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.tokenCUID.end=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.tokenCUID.start=
mappingResolver.enrollProfileMappingResolver.mapping.2.filter.tokenType=
mappingResolver.enrollProfileMappingResolver.mapping.2.target.tokenType=userKey
mappingResolver.enrollProfileMappingResolver.mapping.order=1,0,2
上記の例で、3 つのマッピングが enrollProfileMappingResolver で定義されます。マッピングの名前は 0、1、および 2 です。mappingResolver.enrollProfileMappingResolver.mapping.order=1,0,2 行は、マッピングを処理する順番を定義します。トークンがマッピングと一致する場合、その順序でそれ以上のマッピングは評価されません。マッピングと一致しない場合は、順序の次のマッピングが試行されます。
以下のパラメーターが含まれるトークンの場合: 
CUID=a0000000000000000011
appletMajorVersion=1
appletMinorVersion=0
extension: tokenType=soKey
アプレットバージョンが一致すると、CUID は指定された開始範囲および終了範囲内で失敗し、拡張機能 tokenType は一致するため、この設定を持つトークンはマッピング 1 用のフィルターに一致します。そのため、このトークンには、そのマッピングのターゲットが割り当てられます (soKey)。
別の場合では、トークンに以下のパラメーターがある場合: 
CUID=b0000000000000000010
appletMajorVersion=1
appletMinorVersion=1
この場合、CUID は指定された範囲外であるため、1 トークンのマッピングに失敗します。tokenType エクステンションがないため、0 へのマッピングも失敗します。以前のフィルターのいずれにも一致しないすべてのトークンに一致するフィルターが指定されていないため、このトークンはマッピング 2 に一致します。

6.8. 認証設定

Token Processing System は、デフォルトでユーザー ID とパスワード (UidPwdDirAuthentication) を使用したディレクトリーベースの認証をサポートします。認証インスタンスは、以下のパターンを使用して CS.cfg ファイルで定義されます。 
auths.instance.<auths ID>.*
<auths ID> は、認証設定のために TPS プロファイルによって参照されるオーセンティケーターの名前です。以下に例を示します。 
op.enroll.userKey.auth.id=ldap1
以下の設定例は、認証インスタンスの完全な定義を示しています。 
auths.impl.UidPwdDirAuth.class=com.netscape.cms.authentication.UidPwdDirAuthentication
auths.instance.ldap1.pluginName=UidPwdDirAuth
auths.instance.ldap1.authCredName=uid
auths.instance.ldap1.dnpattern=
auths.instance.ldap1.externalReg.certs.recoverAttributeName=certsToAdd
auths.instance.ldap1.externalReg.cuidAttributeName=tokenCUID
auths.instance.ldap1.externalReg.tokenTypeAttributeName=tokenType
auths.instance.ldap1.ldap.basedn=dc=sjc,dc=example,dc=com
auths.instance.ldap1.ldap.ldapauth.authtype=BasicAuth
auths.instance.ldap1.ldap.ldapauth.bindDN=
auths.instance.ldap1.ldap.ldapauth.bindPWPrompt=ldap1
auths.instance.ldap1.ldap.ldapauth.clientCertNickname=subsystemCert cert-pki-tomcat
auths.instance.ldap1.ldap.ldapconn.host=host1.EXAMPLE.com
auths.instance.ldap1.ldap.ldapconn.port=389
auths.instance.ldap1.ldap.ldapconn.secureConn=False
auths.instance.ldap1.ldap.ldapconn.version=3
auths.instance.ldap1.ldap.maxConns=15
auths.instance.ldap1.ldap.minConns=3
auths.instance.ldap1.ldapByteAttributes=
auths.instance.ldap1.ldapStringAttributes=mail,cn,uid,edipi,pcc,firstname,lastname,exec-edipi,exec-pcc,exec-mail,certsToAdd,tokenCUID,tokenType
auths.instance.ldap1.ldapStringAttributes._000=#################################
auths.instance.ldap1.ldapStringAttributes._001=# For isExternalReg
auths.instance.ldap1.ldapStringAttributes._002=#   attributes will be available as
auths.instance.ldap1.ldapStringAttributes._003=#       $<attribute>$
auths.instance.ldap1.ldapStringAttributes._004=#   attributes example:
auths.instance.ldap1.ldapStringAttributes._005=#mail,cn,uid,edipi,pcc,firstname,lastname,exec-edipi,exec-pcc,exec-mail,certsToAdd,tokenCUID,tokenType
auths.instance.ldap1.ldapStringAttributes._006=#################################
auths.instance.ldap1.pluginName=UidPwdDirAuth
auths.instance.ldap1.ui.description.en=This authenticates user against the LDAP directory.
auths.instance.ldap1.ui.id.PASSWORD.credMap.authCred=pwd
auths.instance.ldap1.ui.id.PASSWORD.credMap.msgCred.extlogin=PASSWORD
auths.instance.ldap1.ui.id.PASSWORD.credMap.msgCred.login=password
auths.instance.ldap1.ui.id.PASSWORD.description.en=LDAP Password
auths.instance.ldap1.ui.id.PASSWORD.name.en=LDAP Password
auths.instance.ldap1.ui.id.UID.credMap.authCred=uid
auths.instance.ldap1.ui.id.UID.credMap.msgCred.extlogin=UID
auths.instance.ldap1.ui.id.UID.credMap.msgCred.login=screen_name
auths.instance.ldap1.ui.id.UID.description.en=LDAP User ID
auths.instance.ldap1.ui.id.UID.name.en=LDAP User ID
auths.instance.ldap1.ui.retries=3
auths.instance.ldap1.ui.title.en=LDAP Authentication
TPS 認証インスタンスは、CA の UidPwdDirAuthentication 認証インスタンスと同様に設定されます。これは、いずれも同じプラグインで処理されるためです。ただし、TPS では、CA 設定に加えて追加のパラメーターが必要になります。
(内部登録と外部登録の両方の) 共通操作の場合、この認証方法を呼び出すプロファイルは、クライアント側で UID とパスワードにラベルを付ける方法のプロジェクトを TPS が許可します。これは、上記の例の auths.instance.ldap1.ui.id.UID.name.en=LDAP User ID パラメーターおよび auths.instance.ldap1.ui.id.PASSWORD.name.en=LDAP Password パラメーターによって制御されます。この設定では、クライアントが UID/password ペアを LDAP User ID および LDAP Password として表示するように指示します。どちらのパラメーターもカスタマイズできます。
credMap.authCred エントリーは、内部認証プラグインが提示された情報を受け入れる方法を設定し、credMap.msgCred エントリーは、この情報が TPS に渡される方法を設定します。これらのフィールドでは、カスタマイズされたプラグインの実装を使用でき、カスタム認証プラグインを使用しない限り、デフォルト値のままにする必要があります。
外部登録に関連するパラメーターは、「外部登録」 を参照してください。
CA 認証設定と同様に、同じ認証実装に対して複数の認証インスタンスを定義できます。これは、TPS がユーザーの複数のグループを提供する場合に便利です。各グループに独自の TPS プロファイルを使用するよう指示することができます。各グループが独自のディレクトリーサーバー認証を使用するように設定されます。

6.9. コネクター

コネクターは、TPS が他のサブシステム (主に CA、KRA、および TKS) と通信する方法を定義します。通常、これらのパラメーターは TPS のインストール時に設定されます。以下は、コネクター設定の例になります。 
tps.connector.ca1.enable=true
tps.connector.ca1.host=host1.EXAMPLE.com
tps.connector.ca1.maxHttpConns=15
tps.connector.ca1.minHttpConns=1
tps.connector.ca1.nickName=subsystemCert cert-pki-tomcat
tps.connector.ca1.port=8443
tps.connector.ca1.timeout=30
tps.connector.ca1.uri.enrollment=/ca/ee/ca/profileSubmitSSLClient
tps.connector.ca1.uri.getcert=/ca/ee/ca/displayBySerial
tps.connector.ca1.uri.renewal=/ca/ee/ca/profileSubmitSSLClient
tps.connector.ca1.uri.revoke=/ca/ee/subsystem/ca/doRevoke
tps.connector.ca1.uri.unrevoke=/ca/ee/subsystem/ca/doUnrevoke
tps.connector.kra1.enable=true
tps.connector.kra1.host=host1.EXAMPLE.com
tps.connector.kra1.maxHttpConns=15
tps.connector.kra1.minHttpConns=1
tps.connector.kra1.nickName=subsystemCert cert-pki-tomcat
tps.connector.kra1.port=8443
tps.connector.kra1.timeout=30
tps.connector.kra1.uri.GenerateKeyPair=/kra/agent/kra/GenerateKeyPair
tps.connector.kra1.uri.TokenKeyRecovery=/kra/agent/kra/TokenKeyRecovery
tps.connector.tks1.enable=true
tps.connector.tks1.generateHostChallenge=true
tps.connector.tks1.host=host1.EXAMPLE.com
tps.connector.tks1.keySet=defKeySet
tps.connector.tks1.maxHttpConns=15
tps.connector.tks1.minHttpConns=1
tps.connector.tks1.nickName=subsystemCert cert-pki-tomcat
tps.connector.tks1.port=8443
tps.connector.tks1.serverKeygen=true
tps.connector.tks1.timeout=30
tps.connector.tks1.tksSharedSymKeyName=sharedSecret
tps.connector.tks1.uri.computeRandomData=/tks/agent/tks/computeRandomData
tps.connector.tks1.uri.computeSessionKey=/tks/agent/tks/computeSessionKey
tps.connector.tks1.uri.createKeySetData=/tks/agent/tks/createKeySetData
tps.connector.tks1.uri.encryptData=/tks/agent/tks/encryptData
TPS プロファイルは、これらのコネクターを ID で参照します。たとえば、以下のようになります。 
op.enroll.userKey.keyGen.signing.ca.conn=ca1
同じ種類のコネクター (複数の CA コネクターなど) を複数定義できます。これは、1 つの TPS インスタンスが、異なるトークングループに複数のバックエンド Certificate System サーバーを提供する場合に便利です。
注記
TPS のコネクターの自動フェイルオーバーはサポートされていません。元のシステムのクローンが作成されていれば、TPS を別の CA、KRA、または TKS にポイントするには、手動フェイルオーバーの手順を実行する必要があります。

6.10. 失効ルーティングの設定

失効ルーティングを設定するには、まず関連する CA コネクターのリストを定義し、それらを以下の形式でコネクターリストに追加する必要があります。 
tps.connCAList=ca1,ca2
さらに、CA 署名証明書を TPS nssdb に追加し、信頼を設定する必要があります。 
#cd <TPS instance directory>/alias
#certutil -d . -A -n <CA signing cert nickname> -t “CT,C,C” -i <CA signing cert b64 file name>
最後に、以下のオプションを使用して CA 署名証明書のニックネームをコネクターに追加する必要があります。 
tps.connector.ca1.caNickname=caSigningCert cert-pki-tomcat CA
注記
CA の検出時に、TPS は CA の Authority Key Identifier を自動的に計算し、コネクター設定に追加する場合があります。以下に例を示します。 
tps.connector.ca1.caSKI=i9wOnN0QZLkzkndAB1MKMcjbRP8=
この動作は想定されています。

6.11. サーバー側の鍵生成の設定

サーバー側の鍵の生成は、鍵が任意の Certificate System サブシステムである Key Recovery Authority (KRA) により生成されることを意味します。KRA によるキーの生成は、紛失したトークンまたは破損したトークンのキーの回復、または外部登録の場合のキーの取得を可能にするために必要です。本セクションでは、TMS でサーバー側の鍵の生成を設定する方法を説明します。
TPS のインストール時に、キーのアーカイブを使用するかどうかを尋ねられます。確認すると、セットアップは自動基本設定、特に次のパラメーターを実行します。
KRA の TPS コネクターパラメーター:
tps.connector.kra1.enable=true
tps.connector.kra1.host=host1.EXAMPLE.com
tps.connector.kra1.maxHttpConns=15
tps.connector.kra1.minHttpConns=1
tps.connector.kra1.nickName=subsystemCert cert-pki-tomcat
tps.connector.kra1.port=8443
tps.connector.kra1.timeout=30
tps.connector.kra1.uri.GenerateKeyPair=/kra/agent/kra/GenerateKeyPair
tps.connector.kra1.uri.TokenKeyRecovery=/kra/agent/kra/TokenKeyRecovery
サーバー側の鍵生成用の TPS プロファイル固有のパラメーター:
op.enroll.userKey.keyGen.encryption.serverKeygen.archive=true
op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1
op.enroll.userKey.keyGen.encryption.serverKeygen.enable=true
serverKeygen.archive の serverKeygen.enable=true オプションを有効にします。
重要
LunaSA HSM は、RSA 暗号化用に 2048 ビットより小さい鍵サイズに対応しません。
たとえば、鍵のサイズを 2048 ビットに設定するには、/var/lib/pki/instance_name/tps/conf/CS.cfg ファイルに以下のパラメーターを設定します。 
op.enroll.userKey.keyGen.encryption.keySize=2048
TKS 設定:
以下は、(TPS を介して) TKS と KRA との間の通信に使用されるトランスポート証明書のニックネームを設定します。 
tks.drm_transport_cert_nickname=transportCert cert-pki-tomcat KRA
参照したトランスポート証明書も TKS インスタンスセキュリティーモジュールに存在する必要があります。以下に例を示します。 
transportCert cert-pki-tomcat KRA                            u,u,u
KRA の設定
PKCS#11 トークンに応じて、kra.keygen.temporaryPairs パラメーター、kra.keygen.sensitivePairs パラメーター、および kra.keygen.extractablePairs パラメーターは、鍵生成オプションに合わせてカスタマイズできます。これらのパラメーターはすべて、デフォルトで false に設定されます。
これらのパラメーターの値は、Red Hat Certificate System でサポートされているセキュリティーモジュールでテストされています。
NSS (FIPS モードの場合):
kra.keygen.extractablePairs=true
nCipher neld Connect 6000 (デフォルトでは指定なしの機能)
RSA 鍵を指定する場合: 
kra.keygen.temporaryPairs=true
(他のパラメーターは指定しないでください。)
ECC キーを生成する場合: 
kra.keygen.temporaryPairs=true
kra.keygen.sensitivePairs=false
kra.keygen.extractablePairs=true
LunaSA CKE - Key Export Model (非 FIPS モード):
kra.keygen.temporaryPairs=true
kra.keygen.sensitivePairs=true
kra.keygen.extractablePairs=true
注記
Gemalto SafeNet LunaSA は、CKE - Key Export モデルでの PKI 秘密鍵抽出のみおよび 非 FIPS モードでのみサポートされます。FIPS モードの LunaSA Cloning モデルおよび CKE モデルは、PKI 秘密鍵の抽出をサポートしません。
注記
LunaSA CKE - Key Export Model が FIPS モードにあると、pki 秘密鍵を抽出できません。

6.12. 新しい鍵セットの設定

本セクションでは、Token Processing System (TPS) および Token Key Service (TKS) で設定したデフォルトのキーの代わりに設定する方法を説明します。
TKS 設定
デフォルトのキーセットは、/var/lib/pki/instance_name/tks/conf/CS.cfg ファイルで以下のオプションを使用して TKS に設定されます。 
tks.defKeySet._000=##
tks.defKeySet._001=## Axalto default key set:
tks.defKeySet._002=##
tks.defKeySet._003=## tks.defKeySet.mk_mappings.#02#01=<tokenname>:<nickname>
tks.defKeySet._004=##
tks.defKeySet.auth_key=#40#41#42#43#44#45#46#47#48#49#4a#4b#4c#4d#4e#4f
tks.defKeySet.kek_key=#40#41#42#43#44#45#46#47#48#49#4a#4b#4c#4d#4e#4f
tks.defKeySet.mac_key=#40#41#42#43#44#45#46#47#48#49#4a#4b#4c#4d#4e#4f
tks.defKeySet.nistSP800-108KdfOnKeyVersion=00
tks.defKeySet.nistSP800-108KdfUseCuidAsKdd=false
上記の設定は、TMS で使用できる特定のタイプまたはクラスのトークンに固有の設定を定義します。最も重要な部分は、3 つの開発者キーまたは (すぐに使用できる) セッションキーです。これらは、対称キーのハンドオーバーが行われる前に安全なチャネルを作成するために使用されます。これらのキーのタイプが異なる場合には、これらのキーに異なるデフォルト値が設定される可能性があります。
nistSP800 キー分散方式を記述した設定では、この方式を使用するか、標準的な Visa 方式を使用するかを制御します。具体的には、tks.defKeySet.nistSP800-108KdfOnKeyVersion オプションの値により NIST バージョンが使用されることが判断されます。この nistSP800-108KdfUseCuidAsKdd オプションを使用すると、処理時に CUID のレガシーキー ID 値を使用できます。新しい KDD 値が最も一般的に使用されるため、このオプションはデフォルトで無効 (false) になります。これにより、新しいキーセットを設定して、新しいクラスのキーのサポートを有効にすることができます。

例6.2 jForte クラスのサポートの有効化

jForte クラスのサポートを有効にするには、以下を設定します。 
tks.jForte._000=##
tks.jForte._001=## SAFLink's jForte default key set:
tks.jForte._002=##
tks.jForte._003=## tks.jForte.mk_mappings.#02#01=<tokenname>:<nickname>
tks.jForte._004=##
tks.jForte.auth_key=#30#31#32#33#34#35#36#37#38#39#3a#3b#3c#3d#3e#3f
tks.jForte.kek_key=#50#51#52#53#54#55#56#57#58#59#5a#5b#5c#5d#5e#5f
tks.jForte.mac_key=#40#41#42#43#44#45#46#47#48#49#4a#4b#4c#4d#4e#4f
tks.jForte.nistSP800-108KdfOnKeyVersion=00
tks.jForte.nistSP800-108KdfUseCuidAsKdd=false
以前の例と比較して、3 つの静的セッションキーの違いに注意してください。
Certificate System は、Giesecke & Devrient (G&D) Smart Cafe 6 スマートカードの Secure Channel Protocol 03 (SCP03) をサポートします。TKS でこれらのスマートカードに対する SCP03 サポートを有効にするには、/var/lib/pki/instance_name/tks/conf/CS.cfg ファイルに設定します。 
tks.defKeySet.prot3.divers=emv
tks.defKeySet.prot3.diversVer1Keys=emv
tks.defKeySet.prot3.devKeyType=DES3
tks.defKeySet.prot3.masterKeyType=DES3
TPS 設定
サポートしているクライアントがトークンで操作を実行しようとすると、TPS が新しいキーセットを認識するように設定する必要があります。デフォルトの defKeySet は、ほとんどの場合使用されます。
TPS で keySet を決定する主な方法は、「Mapping Resolver の設定」 を決定します。このリゾルバーメカニズムを確立するために必要な正確な設定については、リンクされたセクションを参照してください。
KeySet Mapping Resolver が存在しない場合は、TPS が適切な keySet を決定するのに複数のフォールバック方法を使用できます。
  • TPS の CS.cfg 設定ファイルに、tps.connector.tks1.keySet=defKeySet を追加できます。
  • 特定のクライアントは、希望する keySet 値を明示的に渡すように設定することもできます。ただし、現時点では、Enterprise Security Client にはこの機能はありません。
  • TPS が希望の方法に基づいて適切な keySet を計算すると、セキュアなチャネルの作成にも keySet 値を渡すことができるように TKS へのすべての要求を計算します。その後、TKS は (上記の説明) 独自の keySet 設定を使用し、続行方法を決定します。

6.13. 新しいマスターキーの設定

本セクションでは、Token Key Service (TKS) で新しいマスターキーを設定するのに必要な手順および設定を説明します。背景情報は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 を参照してください。

手順6.1 新規マスターキーの作成

  1. TKS セキュリティーデータベースへのアクセスに必要な PIN の内部を取得します。 
    # cat /var/lib/pki/pki-tomcat/tks/conf/password.conf
internal=649713464822
internaldb=secret12
replicationdb=-752230707
  2. TKS インスタンスの alias/ ディレクトリーを開きます。 
    # cd /var/lib/pki/pki-tomcat/alias
  3. tkstool ユーティリティーを使用して新規マスターキーを生成します。以下に例を示します。 
    # tkstool -M -n new_master -d /var/lib/pki/pki-tomcat/alias -h <token_name>
Enter Password or Pin for "NSS Certificate DB":

Generating and storing the master key on the specified token . . .

Naming the master key "new_master" . . .

Computing and displaying KCV of the master key on the specified token . . .

new_master key KCV:  CA5E 1764
  4. 鍵がデータベースに正しく追加されていることを確認します。 
    # tkstool -L -d .


 slot:  NSS User Private Key and Certificate Services
token:  NSS Certificate DB

Enter Password or Pin for "NSS Certificate DB":
        <0> new_master

6.13.1. ラップされたマスターキーの生成および転送 (Key Ceremony)

マスターキーを外部トークンまたは複数の場所で使用する場合は、ハードウェアトークンに安全に転送できるように ラップ する必要があります。この tkstool ユーティリティーを使用するとトランスポートキーを生成できます。次に、トークンが生成されるファシリティーにマスターキーを送信します。ラップマスターキーを転送するプロセスは、一般的に キーセレモニー と呼ばれます。
注記
トランスポートキーは、生成されたマスターキーとのみ使用できます。

手順6.2 ラップされたマスターキーの生成および転送

  1. Token Key Service セキュリティーデータベースへのアクセスに必要な内部 PIN を取得します。 
    # cat /var/lib/pki/pki-tomcat/tks/conf/password.conf

internal=649713464822
internaldb=secret12
replicationdb=-752230707
  2. TKS インスタンスの alias/ ディレクトリーを開きます。 
    # cd /var/lib/pki/pki-tomcat/alias
  3. transport という名前のトランスポートキーを作成します。 
    # tkstool -T -d . -n transport
    注記
    tkstool ユーティリティーは、生成された 3 つのセッションキーごとにキー共有と KCV 値を出力します。この手順の後半で新しいデータベースにトランスポートキーを再生成する必要がある場合に、それらをファイルに保存し、失われた場合はキーを再生成します。
  4. プロンプトが表示されたら、データベースのパスワードを入力します。次に、画面の指示に従って、ランダムなシードを生成します。 
    A random seed must be generated that will be used in the
creation of your key.  One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

|************************************************************|

Finished.


Type the word "proceed" and press enter
  5. 次のプロンプトにより、一連のセッションキーが生成されます。最終メッセージになるまで、画面の指示に従ってください。 
    Successfully generated, stored, and named the transport key!
  6. トランスポートキーを使用してマスターキーを生成してラップし、これを file という名前のファイルに保存します。 
    # tkstool -W -d . -n new_master -t transport -o file 
Enter Password or Pin for "NSS Certificate DB":
Retrieving the transport key (for wrapping) from the specified token . . .
Generating and storing the master key on the specified token . . .
Naming the master key "new_master" . . .
Successfully generated, stored, and named the master key!
Using the transport key to wrap and store the master key . . .
Writing the wrapped data (and resident master key KCV) into the
 file called "file" . . .

       wrapped data:   47C0 06DB 7D3F D9ED
                       FE91 7E6F A7E5 91B9
       master key KCV: CED9 4A7B
       (computed KCV of the master key residing inside the wrapped data)
  7. ラップされたマスターキーを適切な場所またはファシリティーにコピーします。
  8. 必要な場合は、HSM またはファシリティーで新しいセキュリティーデータベースを生成します。 
    # tkstool -N -d <directory>
    新たなデータベースで生成した鍵と同じ鍵を生成する -l オプションを追加します。この方法でトランスポートキーを再生成するには、この手順で前のステップで生成した各セッションキーに対してセッションキー共有と KCV を入力する必要があります。 
    # tkstool -I -d <directory> -n verify_transport
  9. トランスポートキーを使用して、ファイルに保存されているマスターキーをアンラップします。要求されたら、セキュリティーデータベースの PIN を入力します。 
    # tkstool -U -d directory -n new_master -t verify_transport -i file
Enter Password or Pin for "NSS Certificate DB":
Retrieving the transport key from the specified token (for
 unwrapping) . . .
Reading in the wrapped data (and resident master key KCV) from
 the file called "file" . . .

     wrapped data:   47C0 06DB 7D3F D9ED
                     FE91 7E6F A7E5 91B9
     master key KCV: CED9 4A7B
     (pre-computed KCV of the master key residing inside the wrapped data)

Using the transport key to temporarily unwrap the master key to
recompute its KCV value to check against its pre-computed KCV value . . .
     master key KCV: CED9 4A7B
     (computed KCV of the master key residing inside the wrapped data)
     master key KCV: CED9 4A7B
     (pre-computed KCV of the master key residing inside the wrapped data)

Using the transport key to unwrap and store the master key on the
 specified token . . .
Naming the master key "new_master" . . .
Successfully unwrapped, stored, and named the master key!
  10. 鍵がデータベースに追加されたことを確認します。 
    # tkstool -L -d
slot:  NSS User Private Key and Certificate Services
token:  NSS Certificate DB

Enter Password or Pin for "NSS Certificate DB":
			 <0> transport
			 <1> new_master

6.14. TKS/TPS 共有対称キーの設定

共有対称キーは、TPS サブシステムと TKS サブシステムの両方の NSS データベースに存在する必要があります。このキーは、TPS サブシステムの作成時に自動的に生成されます。TPS と TKS の両方が同じ Tomcat インスタンスにインストールされている場合は、TKS により自動的に鍵を使用するため、追加の設定は必要ありません。ただし、両方のサブシステムが別のインスタンス上にある場合や、別の物理ホストがある場合は、本セクションで説明されている手順に従って鍵を TKS に安全に転送する必要があります。
TPS と TKS との間で共有キーを安全に転送するには、いくつかの方法を使用できます。
  • authomatic メソッド: このメソッドは、TPS のサブシステム証明書がソフトウェア NSS データベースに保持されている場合に機能します。
  • 上記の方法が失敗した場合は、フォールバック手動の方法を使用できます。この方法では、TPS からキーをラップできる tkstool ユーティリティーを使用して TPS で共有キーを生成できます。これにより、転送中にキーを公開せずに安全な転送を可能にし、TKS NSS データベースにアンラップします。
以下は、鍵のインポートに使用される方法に関係なく、TPS と TKS の両方の一般的な設定を説明します。自動方式により、これらの設定が自動的に生成されることに注意してください。
TKS
tks.useNewSharedSecretNames=true
tps.0.host=dhcp-16-206.sjc.example.com
tps.0.nickname=TPS-<tps host name>-8443 sharedSecret
tps.0.port=8443
tps.0.userid=,TPS-<tps host name>-8443
tps.list=0
注記
上記のリストは、TKS が複数の TPS インスタンスに接続している場合に拡張できます。
TPS
conn.tks1.tksSharedSymKeyName=TPS-<tps host name>-8443 sharedSecret
注記
ホスト名は、TKS 側で設定されるホスト名と同じでなければなりません。

6.14.1. 共有対称キーを手動で生成して転送

本セクションでは、共有対称鍵を手動で生成および転送する方法を説明します。この方法は、自動生成およびトランスポートが失敗した場合に便利ですが、それ以外の場合には回避する必要があります。
手動の方法は、2 つの手順で設定されています。最初のインスタンスは Token Key Service 側で実行され、トークン処理システムの 2 番目のサービスで実行されます。

手順6.3 手動共有シークレットキーメソッド - TKS 側

  1. 最初のシステムにトークンキーサービスをインストールします。インストール手順については、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 を参照してください。
  2. TKS サービスを停止します。 
    #systemctl stop pki-tomcatd@pki-tomcat.service
  3. /var/lib/pki/pki-tomcat/alias ディレクトリーに移動し、tkstool を使用して TKS で共有の秘密鍵を作成します。新しい TKS インスタンスを再起動する前に、共有鍵を生成してください。
    重要
    tkstool スクリプトにより、キーの作成プロセス中に鍵に関する情報が表示されます。後でキーを TPS にインポートするのに必要となるため、この情報を書き留めてください。 
    #cd /var/lib/pki/pki-tomcat/alias
#tkstool -T -d /var/lib/pki/pki-tomcat/tks/alias -n TPS-<tps host name>-8443 sharedSecret
Generating the first session key share . . .
    first session key share:      792F AB89 8989 D902
                                  9429 6137 8632 7CC4
    first session key share KCV:  D1B6 14FD
Generating the second session key share . . .
    second session key share:      4CDF C8E0 B385 68EC
                                   380B 6D5E 1C19 3E5D
    second session key share KCV:  1EC7 8D4B
Generating the third session key share . . .
    third session key share:      CD32 3140 25B3 C789
                                  B54F 2C94 26C4 9752
    third session key share KCV:  73D6 8633
Generating first symmetric key . . .
Generating second symmetric key . . .
Generating third symmetric key . . .
Extracting transport key from operational token . . .
    transport key KCV:  A8D0 97A2
Storing transport key on final specified token . . .
Naming transport key "sharedSecret" . . .
Successfully generated, stored, and named the transport key!
  4. TKS に新しいキーを設定します。 
    tks.useNewSharedSecretNames=true
tps.0.host=dhcp-16-206.sjc.redhat.com
tps.0.nickname=TPS-<tps host name>-8443 sharedSecret
tps.0.port=8443
tps.0.userid=TPS-<tps host name>-8443 sharedSecret
tps.list=0
  5. TKS を起動します。 
    #systemctl start pki-tomcatd@pki-tomcat.service

手順6.4 手動による共有シークレットキーメソッド - TPS 側

  1. 2 番目のシステムに Token Processing System をインストールします。インストール手順については、『Red Hat Certificate System 9 計画、インストール、およびデプロイメントのガイド』 を参照してください。
  2. TPS サービスを停止します。 
    #systemctl stop pki-tomcatd@pki-tomcat.service
  3. /var/lib/pki/pki-tomcat/alias ディレクトリーに移動し、tkstool を使用して NSS ソフトウェアトークンに共有鍵をインポートします。 
    #cd /var/lib/pki/pki-tomcat/alias
#tkstool -I -d . -n TPS-<tps host name>-8443 sharedSecret
    この時点で、スクリプトは上記の手順の TKS 側で共有鍵を生成およびラップする際に表示されるセッションキー共有を求めるプロンプトを表示します。
  4. TPS で共有シークレットを設定します。 
    conn.tks1.tksSharedSymKeyName=TPS-<tps host name>-8443 sharedSecret
  5. TPS サービスを起動します。 
    #systemctl start pki-tomcatd@pki-tomcat.service

6.15. 異なる SCP バージョンでの異なるアプレットの使用

Certificate System では、/var/lib/instance_name/tps/conf/CS.cfg ファイルの以下のパラメーターで、各トークン操作に対してすべての Secure Channel Protocol (SCP) バージョンに読み込むアプレットを指定します。 
op.operation.token_type.update.applet.requiredVersion=version
ただし、以下のパラメーターを追加して、特定の SCP バージョンに個別のアプレットを設定することもできます。 
op.operation.token_type.update.applet.requiredVersion.prot.protocol_version=version
Certificate System は、以下の操作の個別のプロトコルバージョンの設定に対応します。
  • format
  • enroll
  • pinReset

例6.3 登録操作用のプロトコルバージョンの設定

userKey トークンの登録操作を実行するときに、SCP03 に特定のアプレットを設定し、他のすべてのプロトコルに別のアプレットを設定するには、以下を行います。
  1. /var/lib/instance_name/tps/conf/CS.cfg ファイルを編集します。
    1. デフォルトで使用されるアプレットを指定するには、op.enroll.userKey.update.applet.requiredVersion パラメーターを設定します。以下に例を示します。 
      op.enroll.userKey.update.applet.requiredVersion=1.4.58768072
    2. op.enroll.userKey.update.applet.requiredVersion.prot.3 パラメーターを設定して、アプレットの Certificate System が SCP03 プロトコルに使用するように設定します。以下に例を示します。 
      op.enroll.userKey.update.applet.requiredVersion.prot.3=1.5.558cdcff
  2. Certificate System を再起動します。 
    systemctl restart pki-tomcatd@instance_name.service
TKS で SCP03 for Giesecke & Devrient (G&D) Smart Cafe 6 スマートカードを有効にする方法は、「新しい鍵セットの設定」 を参照してください。

第7章 証明書の取り消しおよび CRL 発行

CertificateCertificate Systemnbsp;System は、証明書を取り消す方法と、証明書取り消しリスト (CRL) と呼ばれる取り消された証明書のリストを作成する方法を提供します。この章では、証明書を取り消す方法と、CMC の取り消しについて説明し、CRL と CRL 設定について詳しく説明します。

7.1. 証明書の失効について

証明書は、エンドユーザー (証明書の元の所有者) または Certificate Manager エージェントによって取り消すことができます。エンドユーザーは、エンドエンティティーページにある失効フォームを使用して証明書を取り消すことができます。エージェントは、エージェントサービスインターフェイスで適切な形式を使用して、エンドエンティティー証明書を破棄することができます。いずれの場合も、証明書ベース (SSL/TLS クライアント認証) が必要です。
エンドユーザーは、認証用に提示された証明書と同じサブジェクト名が含まれる証明書のみを取り消します。認証に成功すると、サーバーはエンドユーザーに属する証明書を一覧表示します。次に、エンドユーザーが失効する証明書を選択するか、リスト内のすべての証明書を取り消します。エンドユーザーは、各証明書またはリスト全体の失効日や失効理由などの追加の詳細を指定することもできます。
エージェントは、シリアル番号の範囲や発行先名コンポーネントに基づいて証明書を取り消します。失効要求が送信されると、エージェントは、失効する証明書を選択できる証明書のリストを受け取ります。エージェントがエンドユーザーの証明書を破棄する方法は、『Red Hat Certificate System 9 計画、インストール、およびデプロイメントのガイド』を参照してください。
失効要求が承認されると、Certificate Manager は、その内部データベースで対応する証明書レコードを失効し、これを設定すると、公開ディレクトリーから失効した証明書が削除されます。これらの変更は、CA が発行する次の CRL に反映されます。
ID トークンとして公開鍵証明書を使用するサーバーおよびクライアントアプリケーションには、証明書の有効性に関する情報へのアクセスが必要です。証明書の有効性を決定する要素の 1 つが失効ステータスであるため、これらのアプリケーションは、検証する証明書が取り消されているかどうかを確認する必要があります。CA は以下を行う責任があります。
  • 失効要求が CA によって受け取られ、承認されている場合は、証明書を取り消します。
  • 失効した証明書のステータスを、その有効性ステータスを確認する必要のある関係者またはアプリケーションが利用できるようにします。
証明書が取り消されるたびに、Certificate Manager は内部データベース内の証明書のステータスを自動的に更新し、内部データベース内の証明書のコピーを失効としてマークし、データベースから証明書を削除するように Certificate Manager が設定されている場合は、失効した証明書を公開ディレクトリーから削除します。
証明書の失効ステータスを通信するための標準的な方法の 1 つは、失効した証明書のリスト (証明書失効リスト (CRL)) を公開することです。CRL は、失効した証明書の公開されている証明書の公開されているリストです。
Certificate Manager は CRL を生成するように設定できます。これらの CRL は、CRL 設定で拡張固有のモジュールを有効にすることで、X.509 標準に準拠するように作成できます。サーバーは、CRL 発行ポイントフレームワークを介して標準の CRL 拡張をサポートします。発行ポイントの CRL 拡張設定の詳細は、「CRL 拡張機能の設定」 を参照してください。証明書マネージャーは、証明書が取り消されるたびに、定期的に CRL を生成できます。公開が設定されている場合、CRL はファイル、LDAP ディレクトリー、または OCSP レスポンダーに公開できます。
CRL は、CRL にリストされている証明書を発行した CA によって、またはその CA によって CRL の発行を許可されたエンティティーによって発行され、デジタル署名されます。CA は、単一のキーペアを使用して、発行する証明書と CRL の両方に署名することも、2 つのキーペアを、1 つは発行する証明書、もう 1 つは CRL にそれぞれ使用することもできます。
デフォルトでは、Certificate Manager は 1 つのキーペアを使用して、発行する証明書を署名し、生成する CRL を生成します。Certificate Manager に別のキーペアを作成し、CRL の署名専用に使用する場合は、「異なる証明書を使用するように CA を設定して CRL を署名」 を参照してください。
CRL は、発行ポイントが定義および設定されているとき、および CRL 生成が有効になっているときに生成されます。
CRL が有効になっている場合、サーバーは証明書が取り消されるときに失効情報を収集します。サーバーは、設定されたすべての発行ポイントに対して、取り消された証明書との一致を試みます。特定の証明書は、どの発行ポイントとも一致できないか、1 つの発行ポイント、複数の発行ポイント、またはすべての発行ポイントと一致します。取り消された証明書が発行ポイントと一致すると、サーバーは証明書に関する情報をその発行ポイントのキャッシュに格納します。
キャッシュをコピーする間隔は秒単位で内部ディレクトリーにコピーされます。CRL を作成する間隔に達すると、CRL がキャッシュから作成されます。この発行ポイントにデルタ CRL が設定されている場合は、この時点でデルタ CRL も作成されます。Certificate Manager がこの情報の収集を開始したため、完全な CRL には、失効した証明書情報がすべて含まれます。デルタ CRL には、完全な CRL の最終更新以降、取り消されたすべての証明書情報が含まれます。
完全な CRL は、デルタ CRL のように順番に番号が付けられます。完全な CRL とデルタは同じ番号を持つことができます。この場合、デルタ CRL は 次 の完全な CRL と同じ番号を持ちます。たとえば、完全な CRL が最初の CRL の場合、これは CRL 1 になります。デルタ CRL は Delta CRL 2 です。CRL 1 と Delta CRL 2 で結合されたデータは、次の完全な CRL である CRL 2 と同等です。
注記
発行ポイントの拡張に変更を加えると、その発行ポイントに対して次の完全な CRL でデルタ CRL が作成されません。デルタ CRL は、作成される 2 番目 の完全な CRL で作成され、その後のすべての完全な CRL と共に作成されます。
内部データベースには、最新の CRL および delta CRL のみが保存されます。新しい CRL が作成されると、古い CRL が上書きされます。
CRL が公開されると、CRL およびデルタ CRL の各更新は、公開設定で指定された場所に公開されます。公開する方法は、保存される CRL の数を決定します。ファイル公開では、各 CRL は、CRL の番号を使用してファイルに公開されるため、ファイルは上書きされません。LDAP 公開では、公開される各 CRL はディレクトリーエントリーに CRL を含む属性の古い CRL に置き換えられます。
デフォルトでは、CRL には失効した証明書に関する情報が含まれません。サーバーには、発行ポイントにオプションを有効にして、失効した証明書を含めることができます。期限切れの証明書が含まれている場合、失効した証明書に関する情報は、証明書の有効期限が切れても CRL から削除されません。失効した証明書が含まれていない場合は、証明書の有効期限が切れると、失効した証明書に関する情報が CRL から削除されます。

7.1.1. ユーザーが開始した失効

エンドユーザーが証明書失効要求を送信すると、失効プロセスの最初のステップは、Certificate Manager がエンドユーザーを識別および認証して、ユーザーが他の誰かに属する証明書ではなく、自分の証明書を失効させようとしていることを確認することです。
SSL/TSL クライアント認証では、サーバーは、エンドユーザーが取り消されるものと同じサブジェクト名を持つ証明書を提示することを期待し、それを認証目的で使用します。サーバーは、クライアント認証用に提示された証明書のサブジェクト名を内部データベースの証明書にマッピングすることにより、失効要求の信頼性を検証します。サーバーは、証明書が内部データベース内で 1 つ以上の有効な証明書にマップされている場合に限り証明書を取り消します。
認証に成功すると、サーバーは、クライアント認証に対して提示される証明書の発行先名と一致する、有効または期限切れの証明書の一覧を表示します。次に、ユーザーは、取り消す証明書を選択するか、リスト内のすべての証明書を取り消すことができます。

7.1.2. 証明書の失効理由

Certificate Manager は、発行した証明書をすべて取り消すことができます。次のように、CRL に含まれることが多い証明書を取り消すための一般的に受け入れられている理由コードがあります。
  • 0不特定 (特に理由はありません)。
  • 1証明書に関連する秘密鍵が侵害されました。
  • 2証明書を発行した CA に関連付けられた秘密鍵が危険にさらされました。
  • 3証明書の所有者は、証明書の発行者とは関係がなくなり、その証明書で取得したアクセス権を失ったか、証明書を必要としなくなりました。
  • 4別の証明書がこれに置き換わります。
  • 5証明書を発行した CA は、操作する予定です。
  • 6証明書は、さらなるアクションが行われるまで保留されています。これは取り消されたものとして処理されますが、証明書がアクティブで再度有効になるように、将来保持されないことがあります。
  • 8証明書は保留から削除されたため、CRL から 削除 されます。これはデルタ CRL でのみ有効です。
  • 9証明書の所有者の権限が撤回されているため、証明書は取り消されます。
証明書は、管理者、エージェント、およびエンドエンティティーにより取り消されます。エージェント権限を持つエージェントおよび管理者は、エージェントサービスページでフォームを使用して証明書を取り消すことができます。エンドユーザーは、エンドエンティティーインターフェイスの Revocation タブのフォームを使用して証明書を失効させることができます。エンドユーザーは自分の証明書のみを取り消すことができますが、エージェントと管理者はサーバーによって発行された証明書を取り消すことができます。証明書を取り消すには、エンドユーザーもサーバーに対する認証に必要になります。
証明書が取り消されると、Certificate Manager は内部データベースの証明書のステータスを更新します。サーバーは、内部データベースのエントリーを使用して、取り消されたすべての証明書を追跡します。設定すると、CRL を中央リポジトリーに公開して公開し、リスト内の証明書が無効になったことを他のユーザーに通知します。

7.1.3. CRL 発行ポイント

CRL は非常に大きくなる可能性があるため、大きな CRL の取得と配信のオーバーヘッドを最小限に抑える方法は複数あります。この方法の 1 つは、証明書領域全体を分割し、個別の CRL を各パーティションに関連付けます。このパーティションは CRL 発行ポイント と呼ばれます。これは、失効した全証明書のサブセットが保持される場所です。パーティション設定は、取り消された証明書が CA 証明書であるかどうか、特定の理由で取り消されたかどうか、または特定のプロファイルを使用して発行されたかどうかに基づいて行うことができます。各発行ポイントは名前で識別されます。
デフォルトでは、Certificate Manager は単一の CRL (マスター CRL) を生成し、公開します。発行ポイントは、すべての証明書、CA 署名証明書のみ、または期限切れの証明書を含むすべての証明書の CRL を生成できます。
発行ポイントを定義したら、それらを証明書に含めることができるため、証明書の失効ステータスを確認する必要があるアプリケーションは、マスターまたはメイン CRL の代わりに、証明書で指定された CRL 発行ポイントにアクセスできます。発行ポイントで維持される CRL はマスター CRL よりも小さいため、失効ステータスの確認ははるかに高速です。
CRL ディストリビューションポイントは、GRLDistributionPoint 拡張機能を設定して証明書に関連付けることができます。

7.1.4. Delta CRL

デルタ CRL は、定義された発行ポイントに対して発行できます。デルタ CRL には、完全な CRL への最後の更新以降に取り消された証明書に関する情報が含まれます。発行先の Delta CRL は、DeltaCRLIndicator 拡張を有効にして作成されます。

7.1.5. CRL の公開

Certificate Manager は CRL をファイル、LDAP 準拠のディレクトリー、または OCSP レスポンダーに公開できます。CRL が公開される場所と頻度は、8章証明書および CRL の公開 で説明されているように、証明書マネージャーで設定されます。
CRL は非常に大きくなる可能性があるため、CRL の公開には非常に長い時間がかかる可能性があり、プロセスが中断される可能性があります。特別なパブリッシャーは、HTTP 1.1 を介して CRL をファイルに発行するように設定できます。プロセスが中断された場合、CA サブシステムの Web サーバーは、最初からではなく、中断された時点から発行を再開できます。この操作は、「再開可能な CRL ダウンロードの設定」 に説明があります。

7.1.6. 証明書失効ページ

Certificate Manager のエンドエンティティーページには、SSL/TLS クライアントによって認証されたデフォルトの HTML フォームが含まれます。フォームは Revocation タブからアクセスできます。User Certificate リンクをクリックすると、このような失効のフォームが表示されます。
組織の要件に合わせてフォームの外観を変更するには、UserRevocation.html (SSL/TSL クライアント認証によるクライアントまたは個人証明書の失効を許可するフォーム) を編集します。このファイルは、/var/lib/instance_name/webapps/subsystem_type/ee/subsystem_type ディレクトリーにあります。

7.2. CMC 失効の実行

CMS (CMC) 登録を介した Certificate Management と同様に、CMC 失効により、ユーザーは失効クライアントをセットアップし、一致する subjectDN 属性を使用するエージェント証明書またはユーザー証明書のいずれかを使用して失効要求に署名できます。これにより、ユーザーは署名済み要求を Certificate Manager に送信できます。
または、Shared Secret Token メカニズムを使用して CMC の失効を認証することもできます。詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』を参照してください。
ユーザーまたはエージェントが要求に署名するかどうか、または Shared Secret Token が使用されているかどうかに関係なく、Certificate Manager は、有効な失効要求を受信すると、証明書を自動的に失効させます。
Certificate System は、CMC 失効要求用に以下のユーティリティーを提供します。
重要
Red Hat は、CMCRequest ユーティリティーを使用して、失効要求の生成を推奨します。これは、CMCRevoke よりも多くのオプションを提供するためです。

7.2.1. CMCRequest を使用した証明書の取り消し

CMCRequest を使用して証明書を取り消すには、以下を実行します。
  1. 以下の内容で、/home/user_name/cmc-request.cfg などの CMC 失効要求の設定ファイルを作成します。 
    #numRequests: Total number of PKCS10 requests or CRMF requests.
numRequests=1

#output: full path for the CMC request in binary format
output=/home/user_name/cmc.revoke.userSigned.req

#tokenname: name of token where user signing cert can be found
#(default is internal)
tokenname=internal

#nickname: nickname for user signing certificate which will be used
#to sign the CMC full request.
nickname=signer_user_certificate

#dbdir: directory for cert8.db, key3.db and secmod.db
dbdir=/home/user_name/.dogtag/nssdb/

#password: password for cert8.db which stores the user signing
#certificate and keys
password=myPass

#format: request format, either pkcs10 or crmf.
format=pkcs10

## revocation parameters
revRequest.enable=true
revRequest.serial=45
revRequest.reason=unspecified
revRequest.comment=user test revocation
revRequest.issuer=issuer
revRequest.sharedSecret=shared_secret
  2. CMC 要求を作成します。 
    # CMCRequest /home/user_name/cmc-request.cfg
    コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルの output パラメーターで指定されたファイルに CMC 要求を保存します。
  3. /home/user_name/cmc-submit.cfg などの設定ファイルを作成します。このファイルは、後で CMC 取り消し要求を CA に送信します。作成されたファイルに以下の内容を追加します。 
    #host: host name for the http server
host=>server.example.com

#port: port number
port=8443

#secure: true for secure connection, false for nonsecure connection
secure=true

#input: full path for the enrollment request, the content must be
#in binary format
input=/home/user_name/cmc.revoke.userSigned.req

#output: full path for the response in binary format
output=/home/user_name/cmc.revoke.userSigned.resp

#tokenname: name of token where SSL client authentication certificate
#can be found (default is internal)
#This parameter will be ignored if secure=false
tokenname=internal

#dbdir: directory for cert8.db, key3.db and secmod.db
#This parameter will be ignored if secure=false
dbdir=/home/user_name/.dogtag/nssdb/

#clientmode: true for client authentication, false for no client
#authentication. This parameter will be ignored if secure=false
clientmode=true

#password: password for cert8.db
#This parameter will be ignored if secure=false and clientauth=false
password=password

#nickname: nickname for client certificate
#This parameter will be ignored if clientmode=false
nickname=signer_user_certificate
    重要
    CMC 失効要求に署名されている場合は、secure パラメーターおよび clientmode パラメーターも true に設定します。さらに nickname パラメーターも入力します。
  4. 要求に署名したユーザーに応じて、HttpClient の設定ファイルの servlet パラメーターを適切に設定する必要があります。
    • エージェントが要求に署名した場合は、以下を設定します。 
      servlet=/ca/ee/ca/profileSubmitCMCFull
    • ユーザーが要求に署名した場合は、以下を設定します。 
      servlet=/ca/ee/ca/profileSubmitSelfSignedCMCFull
  5. CMC 要求を送信します。 
    # HttpClient /home/user_name/cmc-submit.cfg
CMCRequest を使用して証明書の取り消しの詳細は、CMCRequest(1) man ページを参照してください。

7.2.2. CMCRevoke を使用した証明書の取り消し

CMC 失効ユーティリティー CMCRevoke は、エージェントの証明書を使用して失効要求に署名するために使用されます。このユーティリティーは、必要な情報 (証明書のシリアル番号、発行者名、失効理由) を渡して取り消す証明書を識別し、次に失効を実行する CA エージェントを識別するための必要な情報 (証明書のニックネームと証明書のあるデータベース) を渡します。
証明書が取り消される理由は、次のいずれかです (数値は、CMCRevoke に渡される値です)。
  • 0: 指定無し
  • 1: キーが侵害されました。
  • 2: CA キーが侵害されました
  • 3: 従業員の所属が変更になりました
  • 4: 証明書が置き換えられました
  • 5: 運用停止
  • 6: 証明書が保留中です
利用可能なツール引数は、『コマンドラインツールツールガイド』 で詳細に説明されています。

7.2.2.1. CMCRevoke のテスト

  1. 既存の証明書の CMC 失効要求を作成します。 
    CMCRevoke -d/path/to/agent-cert-db -nnickname -iissuerName -sserialName -mreason -ccomment
    たとえば、エージェント証明書を含むディレクトリーは ~jsmith/.mozilla/firefox/ で、証明書のニックネームは AgentCert で、証明書のシリアル番号は 22 の場合、コマンドは次のとおりです 
    CMCRevoke -d"~jsmith/.mozilla/firefox/" -n"ManagerAgentCert" -i"cn=agentAuthMgr" -s22 -m0 -c"test comment"
    注記
    引用符で囲まれたスペースを含む値を囲みます。
    重要
    引数とその値の間には空白を入れないでください。たとえば、26 のシリアル番号は -26 ではなく、-s 26 となります。
  2. エンドエンティティーを開きます。 
    https://server.example.com:8443/ca/ee/ca
  3. Revocation タブを選択します。
  4. メニューの CMC Revoke リンクを選択します。
  5. CMCRevoke からテキストエリアに出力を貼り付けます。
  6. 貼り付けられたコンテンツから -----BEGIN NEW CERTIFICATE REQUEST----- および ----END NEW CERTIFICATE REQUEST----- を削除します。
  7. Submit をクリックします。
  8. 返されるページは、正しい証明書が取り消されていることを確認します。

7.3. CRL の実行

  1. Certificate Manager は、その CA 署名証明書キーを使用して CRL に署名します。CRL に個別の署名キーペアを使用するには、CRL 署名キーを設定し、このキーを使用して CRL に署名するように Certificate Manager の設定を変更します。詳細は、「異なる証明書を使用するように CA を設定して CRL を署名」を参照してください。
  2. CRL 発行ポイントの設定発行ポイントは、マスター CRL に対してすでにセットアップされ、有効にされています。

    図7.1 デフォルトの CRL 発行ポイント

    デフォルトの CRL 発行ポイント
    CRL の追加の発行ポイントを作成できます。詳細は、「発行ポイントの設定」を参照してください。
    発行ポイントを設定して CRL のリストを定義するときに設定したオプションに応じて、発行ポイントが作成できる CRL には 5 つのタイプがあります。
    • マスター CRL には、CA 全体から失効した証明書の一覧が含まれます。
    • ARL は、失効した CA 証明書のみが含まれる Authority Revocation List です。
    • 期限切れの証明書を持つ CRL には、CRL で有効期限が切れた証明書が含まれます。
    • 証明書プロファイルの CRL は、最初に証明書を作成するために使用されるプロファイルに基づいて、失効した証明書を判別します。
    • 理由コードによる CRL は、失効した理由コードに基づいて、失効した証明書を判別します。
  3. 各発行ポイントに CRL を設定します。詳細は、「各発行ポイントの CRL の設定」を参照してください。
  4. 発行ポイントに設定された CRL 拡張機能を設定します。詳細は、「CRL 拡張機能の設定」 を参照してください。
  5. 発行ポイントの拡張を有効にすることにより、発行ポイントにデルタ CRL を設定するか、または発行ポイント DeltaCRLIndicator または CRLNumber. の拡張を有効にします。
  6. 発行先に関する情報が含まれるように CRLDistributionPoint 拡張機能を設定します。
  7. ファイル、LDAP ディレクトリー、または OCSP レスポンダーへの公開 CRL を設定します。公開の設定の詳細は、8章証明書および CRL の公開 を参照してください。

7.3.1. 発行ポイントの設定

発行ポイントは、新しい CRL に含まれる証明書を定義します。マスター CRL 発行ポイントは、Certificate Manager の失効した証明書の一覧を含むマスター CRL 用にデフォルトで作成されます。
新規の発行ポイントを作成するには、以下の手順を実施します。
  1. CertificateCertificate Systemnbsp;System コンソールを開きます。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、左側のナビゲーションメニューから Certificate Manager を展開します。次に、CRL Issuing Points を選択します。
  3. 発行ポイントを編集するには、発行ポイントを選択して、Edit をクリックします。編集できるパラメーターは、発行ポイントの名前と、発行ポイントが有効か無効かだけです。
    発行ポイントを追加するには、Add をクリックします。CRL Issuing Point エディターウインドウが開きます。

    図7.2 CRL Issuing Point エディター

    CRL Issuing Point エディター
    注記
    一部のフィールドがコンテンツを読み取るのに十分な大きさで表示されない場合は、コーナーの 1 つをドラッグしてウィンドウを拡大します。
    以下のフィールドに入力します。
    • Enable。選択した場合は発行ポイントを有効にします。無効にする場合は選択を解除します。
    • CRL Issuing Point name。発行ポイントの名前を指定します。スペースは使用できません。
    • Description。発行ポイントを説明します。
  4. OK をクリックします。
新しい発行ポイントを表示して設定するには、CA コンソールを閉じ、その後にコンソールを再度開きます。新しい発行ポイントは、ナビゲーションツリーの CRL Issuing Points エントリーの下に一覧表示されます。
新しい発行ポイントに CRL を設定し、CRL と使用する CRL 拡張機能を設定します。発行ポイントの設定に関する詳細は、「各発行ポイントの CRL の設定」 を参照してください。CRL 拡張機能の設定に関する詳細は、「CRL 拡張機能の設定」 を参照してください。作成された CRL はすべて、エージェントサービスページの Update Revocation List ページに表示されます。

7.3.2. 各発行ポイントの CRL の設定

生成間隔、CRL バージョン、CRL 拡張、署名アルゴリズムなどの情報はすべて、発行ポイントの CRL 用に設定できます。CRL は発行ポイントごとに設定する必要があります。
  1. CA コンソールを開きます。 
    pkiconsole https://server.example.com:8443/ca
  2. ナビゲーションツリーで、Certificate Manager を選択し、CRL Issuing Points を選択します。
  3. Issuing Points エントリーの下に、発行ポイント名を選択します。
  4. 発行ポイントの Update タブに情報を指定して、CRL の更新方法および頻度を設定します。このタブには、Update Schema および Update Frequency の 2 つのセクションがあります。
    • Update Schema セクションには以下のオプションが含まれます。
      • Enable CRL generation。このチェックボックスは、発行ポイントに CRL が生成されるかどうかを設定します。
      • Generate full CRL every # delta(s)。このフィールドは、変更の数に関連して CRL が作成された頻度を設定します。
      • Extend next update time in full CRLs。これにより、生成された CRL に nextUpdate フィールドを設定するオプションが提供されます。nextUpdate パラメーターは、フル CRL かデルタ CRL かに関係なく、次の CRL が発行される日付を示します。フル CRL とデルタ CRL の組み合わせを使用している場合は、Extend next update time in full CRLs を有効にすると、フル CRL の nextUpdate パラメーターに次の フル CRL が発行されるタイミングを表示させることができます。それ以外の場合は、フル CRL の nextUpdate パラメーターは、そのデルタが次に発行される CR L になるため、次の デルタ CRL がいつ発行されるかを示します。
    • Update Frequency セクションは、CRL が生成され、ディレクトリーに発行されたときに異なる間隔を設定します。
      • Every time a certificate is revoked or released from hold。これにより、証明書を取り消すたびに Certificate Manager が CRL を生成するよう設定されます。Certificate Manager は、CRL が生成されるたびに、設定されたディレクトリーに CRL を発行しようとします。CRL の生成は、CRL のサイズが大きい場合に消費できます。証明書が取り消されるたびに CRL を生成するように Certificate Manager を設定すると、サーバーがかなりの時間使用される可能性があります。この間、サーバーは受け取った変更でディレクトリーを更新できなくなります。
        この設定は、標準的なインストールには推奨されません。このオプションは、サーバーが CRL をフラットファイルに発行したかどうかのテストなど、すぐに失効をテストするために選択する必要があります。
      • Update the CRL at。このフィールドは、CRL を更新する必要がある毎日の時間を設定します。複数回指定するには、01:50,04:55,06:55 などのコンマ区切りリストを入力します。複数日のスケジュールを入力するには、コンマ区切りのリストを入力して同じ日の時間を設定し、セミコロンで区切ったリストを入力して異なる日の時間を識別します。たとえば、これは、サイクルの 1 日目の 午前 1:50、4:55、および 6:55、そして 2 日目の午前 2:00、5:00、および午後 5:00 に失効を設定します。 
        01:50,04:55,06:55;02:00,05:00,17:00
      • CRL をすべて更新 します。このチェックボックスでは、フィールドに設定された間隔で CRL を生成できます。たとえば、毎日 CRL を発行するには、チェックボックスを選択して、このフィールドに 1440 を入力します。
      • Next update grace period。Certificate Manager が特定の頻度で CRL を更新する場合、サーバーは、CRL を作成して発行する時間を確保するために、次の更新時間までの猶予期間を持つように設定できます。たとえば、サーバーが 2 分の猶予期間で 20 分ごとに CRL を更新するように設定されていて、CRL が 16:00 に更新された場合、CRL は 16:18 に再更新されます。
    重要
    既知の問題により、現在フルおよびデルタの証明書失効リストのスケジュールを設定している場合、Update CRL every time a certificate is revoked or released from hold オプションでは、2 つの grace period 設定を記入する必要もあります。したがって、このオプションを選択するには、最初に Update CRL every オプションを選択して、する必要がありますし、Next update grace period # minutes ボックスに番号を入力する必要があります。
  5. Cache タブは、キャッシュが有効であるかどうかとキャッシュ頻度を設定します。

    図7.3 CRL キャッシュタブ

    CRL キャッシュタブ
    • Enable CRL cache。このチェックボックスは、デルタ CRL の作成に使用されるキャッシュを有効にします。キャッシュが無効になっている場合は、デルタ CRL は作成されません。キャッシュの詳細は、「証明書の失効について」 を参照してください。
    • キャッシュを毎回更新 します。このフィールドは、キャッシュが内部データベースに書き込む頻度を設定します。証明書が取り消されるたびに、キャッシュをデータベースに書き出すには、0 に設定します。
    • キャッシュリカバリーを有効 にします。このチェックボックスを選択すると、キャッシュを復元できます。
    • Enable CRL cache testing。このチェックボックスは、特定の CRL 発行ポイントの CRL パフォーマンステストを有効にします。このオプションで生成された CRL は、デプロイした CA では使用しないでください。テスト目的で発行された CRL には、パフォーマンステストのみを目的として生成されたデータが含まれているためです。
  6. フォーマット タブでは、作成される CRL のフォーマットおよびコンテンツを設定します。CRL Format および CRL Contents の 2 つのセクションがあります。

    図7.4 CRL 形式タブ

    CRL 形式タブ
    • CRL Format セクションには、以下の 2 つのオプションがあります。
      • Revocation list signing algorithm は、CRL 暗号化を行うために許可された暗号のドロップダウンの一覧です。
      • Allow extensions for CRL v2 するには、発行ポイントに CRL v2 拡張を有効にするチェックボックスがあります。これが有効な場合は、「CRL 拡張機能の設定」 で説明されている必要な CRL 拡張機能を設定します。
      注記
      CRL を作成するには、拡張機能を有効にする必要があります。
    • CRL Contents セクションには、CRL に追加する証明書のタイプを設定する 3 つのチェックボックスがあります。
      • Include expired certificates。これには、期限切れになった証明書が含まれます。これを有効にすると、失効した証明書に関する情報は、証明書の期限が切れた後も CRL に残ります。これが有効になっていないと、証明書の有効期限が切れると、失効した証明書に関する情報が削除されます。
      • CA certificates only。これには、CRL の CA 証明書のみが含まれます。このオプションを選択すると、失効した CA 証明書のみを一覧表示する Authority Revocation List (ARL) が作成されます。
      • Certificates issued according to profiles。これには、リストされたプロファイルに従って発行された証明書のみが含まれます。複数のプロファイルを指定するには、コンマ区切りのリストを入力します。
  7. Save をクリックします。
  8. この発行ポイントでは、拡張機能は可能で、設定できます。詳細は「CRL 拡張機能の設定」を参照してください。

7.3.3. CRL 拡張機能の設定

注記
拡張機能には、発行ポイントに CRLs v2 の Allow extensions for CRLs v2 チェックボックスが選択されている場合にのみ、発行ポイントに必要です。
発行ポイントが作成されると、3 つの拡張機能 (CRLReason、InvalidityDate、および CRLNumber) が自動的に有効になります。その他の拡張は利用できますが、デフォルトで無効になっています。これは、有効化および変更できます。利用可能な CRL 拡張の詳細は、「標準 X.509 v3 CRL 拡張機能リファレンス」 を参照してください。
CRL 拡張機能を設定するには、以下を行います。
  1. CA コンソールを開きます。 
    pkiconsole https://server.example.com:8443/ca
  2. ナビゲーションツリーで、Certificate Manager を選択し、CRL Issuing Points を選択します。
  3. Issuing Points エントリーの下にある発行ポイント名を選択し、発行ポイントの下にある CRL 拡張 エントリーを選択します。
    右側のペインには、設定された拡張機能を一覧表示する CRL Extensions Management タブが表示されます。

    図7.5 CRL 拡張機能

    CRL 拡張機能
  4. ルールを変更するには、ルールを選択し、Edit/View をクリックします。
  5. ほとんどの拡張には 2 つのオプションがあり、有効にして、重要なかどうかを設定します。詳細情報が必要なものもあります。必要な値をすべて指定します。各拡張機能およびそれらの拡張機能のパラメーターに関する詳細は、「標準 X.509 v3 CRL 拡張機能リファレンス」 を参照してください。
  6. OK をクリックします。
  7. Refresh をクリックし、すべてのルールの更新されたステータスを表示します。

7.3.4. 異なる証明書を使用するように CA を設定して CRL を署名

CS.cfg ファイルを編集してこの機能を設定する方法は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『異なる証明書を使用するように CA を設定して CRL を署名』セクションを参照してください。

7.3.5. キャッシュからの CRL の生成

デフォルトでは、CRL は CA の内部データベースから生成されます。ただし、証明書が取り消されてメモリーに保持されるため、失効情報を収集できます。その後、この失効情報を使用して、メモリーから CRL を更新できます。内部データベースから CRL を生成するために必要なデータベース検索を省略すると、パフォーマンスが大幅に改善されます。
注記
キャッシュから CRL を生成する際のパフォーマンスの向上により、ほとんどの環境で enableCRLCache パラメーターが有効になります。ただし、実稼働環境ではこの Enable CRL cache testing パラメーターを有効に しないでください。

7.3.5.1. コンソールでのキャッシュからの CRL 生成の設定

  1. コンソールを開きます。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、Certificate Manager フォルダーと CRL Issuing Points サブディレクトリーを展開します。
  3. MasterCRL ノードを選択します。
  4. Enable CRL cache を選択します。
  5. 変更を保存します。

7.3.5.2. CS.cfg のキャッシュからの CRL 生成の設定

CS.cfg ファイルを編集してこの機能を設定する方法は、『Red Hat Certificate System の計画、インストール、およびデプロイメントのガイド』の『CS.cfg のキャッシュからの CRL 生成の設定』セクションを参照してください。

7.4. Full および Delta CRL スケジュールの設定

CRL は定期的に生成されます。「各発行ポイントの CRL の設定」 の設定でその期間は切り替わるものです。
CRL は、時間ベースのスケジュールに従って発行されます。CRL は、証明書が失効するたびに、1 日の特定の時間帯に、または数十分に 1 回発行することができます。
時間ベースの CRL 生成スケジュールは、生成されるすべての CRL に適用されます。CRL には完全な CRL とデルタ CRL の 2 つの種類があります。完全な CRL には、取り消されたすべての証明書のレコードがありますが、デルタ CRL には、最後の CRL (デルタまたは完全) が生成されてから取り消された証明書のみが含まれます。
デフォルトでは、完全な CRL はスケジュールで指定した間隔で生成されます。正確な delta CRL を生成することで、完全な CRL を生成するまでに時間がかかる場合があります。生成間隔は CRL スキーマ で設定され、デルタと完全な CRL を生成するスキームを設定します。
たとえば、間隔が 3 に設定されている場合、生成される最初の CRL はフル CRL とデルタ CRL の両方になり、次の 2 つの世代の更新はデルタ CRL のみになり、4 番目の間隔は再びフル CRL とデルタ CRL の両方になります。つまり、3 番目の生成間隔はすべて完全な CRL とデルタ CRL の両方があります。 
Interval   1, 2, 3, 4, 5, 6, 7 ...
Full CRL   1        4        7 ...
Delta CRL  1, 2, 3, 4, 5, 6, 7 ...
注記
完全な CRL に加えてデルタ CRL を生成するには、CRL キャッシュを有効にする必要があります。

7.4.1. コンソールでの CRL 更新間隔の設定

  1. コンソールを開きます。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、Certificate Manager フォルダーと CRL Issuing Points サブディレクトリーを展開します。
  3. MasterCRL ノードを選択します。
  4. Generate full CRL every # delta(s) フィールドに、必要な間隔を入力します。
  5. 証明書失効の機会、周期的な間隔、または更新が発生する時間を設定することにより、更新頻度を設定します。
    • Update CRL every time a certificate is revoked or released from hold チェックボックスを選択します。Update CRL every time a certificate is revoked or released from hold オプションでも、2 つの Grace period 設定を入力する必要があります。これは既知の問題で、バグは Red Hat Bugzilla で追跡されています。
    • Update CRL every time a certificate is revoked or released from hold チェックボックスを選択します。
    • Update CRL at チェックボックスを選択し、01:50,04:55,06:55 などの特定の時刻をコンマで区切って入力します。
    • Update CRL every チェックボックスを選択し、240 などの必要な間隔を入力します。
  6. 変更を保存します。
重要
Update CRL every time a certificate is revoked or released from hold オプションでも、2 つの grace period 設定を入力する必要があります。これは既知の問題で、バグは Red Hat Bugzilla で追跡されています。
注記
間隔ごとに CRL を更新するとドリフトが発生する場合があります。通常、ドリフトは手動更新と CA の再起動時に実行されます。
スケジュールのずれを防ぐには、Update CRL at チェックボックスを選択して値を入力します。間隔の更新は、24 時間ごとに Update CRL at 値と再同期します。
間隔で CRL を更新する場合は、Update CRL at 値は 1 つだけ受け入れられます。

7.4.2. CS.cfg での CRL の更新間隔の設定

CS.cfg ファイルを編集してこの機能を設定する方法は、『Red Hat Certificate System の計画、インストール、およびデプロイメントのガイド』の『CS.cfg での CRL の更新間隔の設定』セクションを参照してください。

7.4.3. 複数の日における CRL 生成スケジュールの設定

デフォルトで、CRL 生成のスケジュールは 24 時間に対応しています。また、デフォルトでは、フル CRL とデルタ CRL が有効になっている場合、1 つまたはすべてのデルタ CRL の代わりに、特定の間隔、つまり 3 回の更新ごとにフル CRL が発生します。
複数日にわたる CRL 生成スケジュールを設定するには、時間のリストでコンマを使用して同じ日の時間を区切り、セミコロンを使用して日を区切ります。 
ca.crl.MasterCRL.dailyUpdates=01:00,03:00,18:00;02:00,05:00,17:00
この例では、スケジュールの 1 日目の 01:00、03:00、および 18:00 と、スケジュールの 2 日目の 02:00、05:00、および 17:00 に CRL を更新します。3 日目にサイクルが再開します。
注記
セミコロンは新規日を示します。セミコロンで一覧を開始すると、CRL が生成されない最初の日になります。同様に、リストをセミコロンで終了すると、CRL が生成されないスケジュールに最終日が追加されます。2 つのセミコロンを合わせると、CRL が生成されない日になります。
デルタ更新とは独立してフル CRL 更新を設定するために、時間のリストは、完全な CRL 更新がいつ発生するかを示すアスタリスクが前に付いた時間値を受け入れます。 
ca.crl.MasterCRL.dailyUpdates=01:00,03:00,18:00,*23:00;02:00,05:00,21:00,*23:30
この例では、1 日目の 01:00、03:00、および 18:00 にデルタ CRL 更新を生成し、23:00 にフル CRL およびデルタ CRL の更新を生成します。2 日目では、デルタ CRL は 02:00、05:00、および 21:00 で更新されます。これは、フル CRL およびデルタ CRL の更新が 23:30 で行われます。3 日目にサイクルが再開します。
注記
セミコロンとアスタリスク構文は、コンソールと CS.cfg ファイルを手動で編集する時に機能します。

7.5. 失効チェックの有効化

失効チェック とは、Certificate System サブシステムが、エージェントまたは管理者がインスタンスの安全なインターフェイスにアクセスしようとしたときに、証明書が有効であり、失効していないことを確認することを意味します。これは、ローカルの OCSP サービス (CA の内部 OCSP サービスまたは個別の OCSP レスポンダー) を使用して証明書の失効ステータスを確認します。
OCSP 設定は、「OCSP (Online Certificate Status Protocol) レスポンダーの使用」 で説明されています。
『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『CA での自動失効チェックの有効化』を参照してください。
『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『サブシステムの証明書失効チェックの有効化』を参照してください。

7.6. OCSP (Online Certificate Status Protocol) レスポンダーの使用

7.6.1. OCSP レスポンダーの設定

Online Certificate Status Manager の設定時にセキュリティードメイン内の CA が選択される場合は、OCSP サービスを設定する追加の手順は必要ありません。CA の CRL 公開は自動的に設定され、その署名証明書は Online Certificate Status Manager の証明書データベースで自動的に追加および信頼されます。ただし、セキュリティーのないドメイン CA を選択した場合は、Online Certificate Status Manager の設定後に OCSP サービスを手動で設定する必要があります。
注記
OCSP Manager が属するセキュリティードメイン内のすべての CA は、設定時に OCSP Manager によって自動的に信頼されるわけではありません。CA パネルで設定された CA の証明書チェーン内のすべての CA は、OCSP マネージャーによって自動的に信頼されます。セキュリティードメイン内にあるが証明書チェーンにはない他の CA は、手動で信頼させる必要があります。
セキュリティードメイン外の Certificate Manager に Online Certificate Status Manager を設定するには、次を行います。
  1. OCSP レスポンダーに公開されるすべての CA に CRL を設定します。
  2. OCSP サービスが処理するすべての CA で、公開を有効にし、パブリッシャーを設定し、公開ルールを設定します (8章証明書および CRL の公開)。Certificate Manager が LDAP ディレクトリーに公開され、Online Certificated Status Manager がそのディレクトリーから読み込むように設定している場合は、これは必要ありません。
  3. 証明書プロファイルは、Certificate Manager が OCSP サービス要求をリッスンする場所を指す Authority Information Access 拡張機能を含むように設定する必要があります (「証明書マネージャーの内部 OCSP サービスの有効化」)。
  4. OCSP Responder を設定します。
  5. 設定後に両方のサブシステムを再起動します。
  6. CA が OCSP レスポンダーに適切に接続されていることを確認します (「証明書マネージャーおよびオンライン証明書ステータスマネージャーの接続の確認」)。

7.6.2. OCSP レスポンダーへの CA の特定

CRL を Online Certificate Status Manager に公開するように CA を設定する前に、Online Certificate Status Manager の内部データベースに CA 署名証明書を保存することにより、CA を Online Certificate Status Manager に識別する必要があります。Certificate Manager は、この証明書に関連するキーペアの CRL を署名します。Online Certificate Status Manager は、保存した証明書に対して署名を検証します。
注記
Online Certificate Status Manager の設定時にセキュリティードメイン内の CA が選択されている場合は、CA を認識するように Online Certificate Status Manager を設定する手順が追加する必要はありません。CA 署名の証明書は自動的に追加され、Online Certificate Status Manager の証明書データベースで信頼されます。ただし、非セキュリティードメイン CA が選択されている場合は、Online Certificate Status Manager を設定した後、CA 署名証明書を証明書データベースに手動で追加する必要があります。
CRL を Online Certificate Status Manager に公開する CA の証明書チェーンをインポートする必要はありません。OCSP サービスに証明書チェーンが必要なのは、CA が CRL を公開するときに SSL/TLS 認証を介して Online Certificate Status Manager に接続する場合のみです。それ以外の場合は、Online Certificate Status Manager に完全な証明書チェーンは必要ありません。
ただし、Online Certificate Status Manager の証明書データベースには、CRL に署名した証明書 (CA 署名証明書または個別の CRL 署名証明書) が必要です。OCSP サービスは、CRL に署名した証明書を、証明書チェーンではなく、データベース内の証明書と比較することにより、CRL を検証します。ルート CA とその下位 CA の 1 つが CRL を Online Certificate Status Manager に公開する場合、Online Certificate Status Manager には両方の CA の CA 署名証明書が必要です。
CA が Online Certificate Status Manager に公開している証明書の署名に使用される CA または CRL 署名証明書をインポートするには、次の手順を実行します。
  1. Certificate Manager の base-64 CA 署名証明書は、CA のエンドエンティティーページから取得します。
  2. オンライン証明書ステータスマネージャーエージェントページを開きます。URL の形式は https://hostname:SSLport/ocsp/agent/ocsp です。
  3. 左側のフレームで、Add Certificate Authority をクリックします。
  4. フォームで、エンコードされた CA 署名証明書を Base 64 encoded certificate (including the header and footer) というラベルの付いたテキスト領域内に貼り付けます。
  5. 証明書が正常に追加されたことを確認するには、左側のフレームで List Certificate Authorities をクリックします。
その結果、新しい CA に関する情報が表示されます。This Update フィールド、Next Update、および Requests Served Since Startup フィールドには、ゼロ (0) の値が表示されます。

7.6.2.1. 証明書マネージャーおよびオンライン証明書ステータスマネージャーの接続の確認

Certificate Manager を再起動すると、Online Certificate Status Manager の SSL/TLS ポートに接続しようとします。Certificate Manager が実際に Online Certificate Status Manager と通信したことを確認するには、This Update フィールドおよび Next Update フィールドを確認します。これらのフィールドは、CA が Online Certificate Status Manager と最後に通信したときの適切なタイムスタンプで更新する必要があります。クライアントが証明書失効リストのステータスに対して OCSP サービスにクエリーを試行していないため、Requests Served Since Startup フィールドにはゼロ (0) の値が表示されるはずです。

7.6.2.2. 失効情報ストアの設定: 内部データベース

Online Certificate Status Manager は各 Certificate Manager の CRL を内部データベースに保存し、これを CRL ストアとして使用し、証明書の失効ステータスを確認します。Online Certificate Status Manager が CRL を内部データベースに格納するために使用する設定を変更するには、以下を実行します。
  1. オンライン証明書ステータスマネージャーコンソールを開きます。 
    pkiconsole https://server.example.com:8443/ocsp
  2. Configuration タブで Online Certificate Status Manager を選択し、Revocation Info Stores を選択します。
    右側のペインには、Online Certificate Status Manager が使用できる 2 つのリポジトリーが表示されます。デフォルトでは、内部データベースで CRL を使用します。
  3. defStore を選択し、Edit/View をクリックします。
  4. defStore 値を編集します。
    • notFoundAsGood.問題の証明書が CRL のいずれかに見つからない場合は、GOOD の OCSP 応答を返すように OCSP サービスを設定します。これを選択しないと、応答は UNKNOWN になり、クライアントが発生した場合にはエラーメッセージが表示されます。
    • byName.OCSP レスポンダーは、応答を行う OCSP レスポンダーの ID を含む基本的な応答タイプのみをサポートします。基本応答タイプの ResponderID フィールドは、ocsp.store.defStore.byName パラメーターの値により決定されます。byName パラメーターが true である、または存在しない場合、OCSP 認証局署名証明書サブジェクト名は OCSP 応答の ResponderID フィールドとして使用されます。byName パラメーターが false の場合、OCSP 認証局署名証明書キーハッシュは OCSP 応答の ResponderID フィールドになります。
    • includeNextUpdate.次の CRL 更新時間のタイムスタンプが含まれます。

7.6.2.3. 失効情報ストアの設定: LDAP ディレクトリー

OCSP Manager はデフォルトでは CA CRL を内部データベースに保存しますが、代わりに LDAP ディレクトリーに公開された CRL を使用するよう設定することができます。
重要
ldapStore メソッドが有効になっていると、OCSP ユーザーインターフェイスは証明書のステータスを確認しません。
LDAP ディレクトリーを使用するように Online Certificate Status Manager を設定するには、以下を実行します。
  1. オンライン証明書ステータスマネージャーコンソールを開きます。 
    pkiconsole https://server.example.com:8443/ocsp
  2. Configuration タブで Online Certificate Status Manager を選択し、Revocation Info Stores を選択します。
    右側のペインには、Online Certificate Status Manager が使用できる 2 つのリポジトリーが表示されます。デフォルトでは、内部データベースで CRL を使用します。
  3. LDAP ディレクトリーで CRL を使用するには、Set Default をクリックして ldapStore オプションを有効にします。
  4. ldapStore を選択し、Edit/View をクリックします。
  5. ldapStore パラメーターを設定します。
    • numConns.OCSP サービスがチェックする必要のある LDAP ディレクトリーの合計数。デフォルトでは、これは 0 に設定されます。この値を設定すると、対応する host フィールド、port フィールド、baseDN フィールド、および refreshInSec フィールドの数が表示されます。
    • host.LDAP ディレクトリーの完全修飾 DNS ホスト名。
    • port。LDAP ディレクトリーの SSL/TLS ポート以外のポート。
    • baseDN.CRL の検索を開始する DN。たとえば、O=example.com です。
    • refreshInSec.接続が更新される頻度。デフォルトは 86400 秒 (毎日) です。
    • caCertAttr.デフォルト値である cACertificate;binary はそのままにしておきます。これは、Certificate Manager がその CA 署名証明書を公開する属性です。
    • crlAttr.デフォルト値である certificateRevocationList;binary はそのままにしておきます。これは、Certificate Manager が CRL を公開する属性です。
    • notFoundAsGood.問題の証明書が CRL のいずれかに見つからない場合は、GOOD の OCSP 応答を返すように OCSP サービスを設定します。これを選択しないと、応答は UNKNOWN になり、クライアントが発生した場合にはエラーメッセージが表示されます。
    • byName.OCSP レスポンダーは、応答を行う OCSP レスポンダーの ID を含む基本的な応答タイプのみをサポートします。基本応答タイプの ResponderID フィールドは、ocsp.store.defStore.byName パラメーターの値により決定されます。byName パラメーターが true である、または存在しない場合、OCSP 認証局署名証明書サブジェクト名は OCSP 応答の ResponderID フィールドとして使用されます。byName パラメーターが false の場合、OCSP 認証局署名証明書キーハッシュは OCSP 応答の ResponderID フィールドになります。
    • includeNextUpdate.Online Certificate Status Manager には、次の CRL 更新時間のタイムスタンプを含めることができます。

7.6.2.4. OCSP サービス設定のテスト

以下を実行して、Certificate Manager が OCSP 要求を適切に処理できるかどうかをテストします。
  1. ブラウザーまたはクライアントで失効チェックをオンにします。
  2. OCSP サービス用に有効になっている CA から証明書を要求します。
  3. 要求を承認します。
  4. ブラウザーまたはクライアントに証明書をダウンロードします。
  5. CA がブラウザーまたはクライアントで信頼されていることを確認します。
  6. Certificate Manager の内部 OCSP サービスのステータスを確認します。
    CA エージェントサービスページを開き、OCSP サービス のリンクを選択します。
  7. 独立した Online Certificate Status Manager サブシステムをテストします。
    Online Certificate Status Manager エージェントサービスページを開き、List Certificate Authorities リンクをクリックします。
    このページには、CRL を Online Certificate Status Manager に公開するための設定された Certificate Manager に関する情報が表示されます。このページには、最後に起動した時点の Online Certificate Status Manager のアクティビティーも要約されています。
  8. 証明書を取り消します。
  9. ブラウザーまたはクライアントで証明書を確認します。サーバーは、証明書が取り消されたことを返す必要があります。
  10. Certificate Manager の OCSP サービスステータスを再度チェックして、次のことが発生したことを確認します。
    • ブラウザーは OCSP クエリーを Certificate Manager に送信します。
    • Certificate Manager は OCSP の応答をブラウザーに送信します。
    • ブラウザーはその応答を使用して証明書を検証し、証明書を検証できなかったというステータスを返しました。
  11. 独立した OCSP サービスサブシステムを再度チェックし、これらの問題が発生することを確認します。
    • 証明書マネージャーは、CRL を Online Certificate Status Manager に公開します。
    • ブラウザーは OCSP 応答を Online Certificate Status Manager に送信します。
    • Online Certificate Status Manager は OCSP の応答をブラウザーに送ります。
    • ブラウザーはその応答を使用して証明書を検証し、証明書を検証できなかったというステータスを返しました。

7.6.3. 問題のあるシリアル番号のレスポンスの設定

OCSP レスポンダーは、証明書が有効かどうかを判断する前に、証明書の失効ステータスと有効期限を確認します。デフォルトでは、OCSP は証明書の他の情報を検証しません。
notFoundAsGood パラメーターは、OCSP が無効なシリアル番号で証明書を処理する方法を設定します。このパラメーターはデフォルトで有効になっています。つまり、証明書が不正なシリアル番号で存在する場合は、証明書が有効であれば、OCSP が証明書の GOOD のステータスを返します。
OCSP に、不正なシリアル番号と失効ステータスに基づいて証明書をチェックおよび拒否させるには、notFoundAsGood 設定を変更します。この場合、OCSP は、間違ったシリアル番号を持つ証明書とともに UNKNOWN ステータスを返します。クライアントはエラーとして解釈し、それに応じて応答できます。
  1. オンライン証明書ステータスマネージャーコンソールを開きます。 
    pkiconsole https://server.example.com:8443/ocsp
  2. Configuration タブで Online Certificate Status Manager を選択し、Revocation Info Stores を選択します。
  3. defStore を選択し、Edit/View をクリックします。
  4. notFoundAsGood 値を編集します。このチェックボックスを選択すると、証明書のシリアル番号が不正な場合でも OCSP が GOOD の値を返します。チェックボックスの選択を解除すると、OCSP は、UNKNOWN の値を送信します。クライアントはこれをエラーとして解釈できます。
  5. OCSP Manager を再起動します。 
    ]# systemctl restart pki-tomcatd@instance-name.service

7.6.4. 証明書マネージャーの内部 OCSP サービスの有効化

Certificate Manager には、OCSP 準拠のクライアントでビルトインの OCSP サービスがあり、Certificate Manager に、証明書の失効ステータスを直接問い合わせることができます。Certificate Manager がインストールされると、OCSP 署名証明書が発行され、OCSP サービスがデフォルトで有効になります。この OCSP 署名証明書は、OCSP サービスリクエストへのすべての応答に署名するために使用されます。内部 OCSP サービスは、Certificate Manager の内部データベースに格納されている証明書のステータスをチェックするため、このサービスを使用するように公開を設定する必要はありません。
クライアントは、Certificate Manager の SSL/TLS エンドエンティティーポートを介して OCSP サービスをクエリーできます。証明書失効ステータスをクエリーすると、Certificate Manager は証明書の内部データベースを検索し、そのステータスを確認してクライアントに応答します。Certificate Manager は発行されたすべての証明書のリアルタイムステータスであるため、失効確認の方法は最も正確です。
インストール時に、すべての CA ビルトイン OCSP サービスが有効になっている。ただし、このサービスを使用するには、CA が Authority Information Access 拡張で証明書を発行する必要があります。
  1. CA のエンドエンティティーに移動します。以下に例を示します。 
    https://server.example.com:8443/ca/ee/ca
  2. CA 署名証明書を探します。
  3. 証明書で Authority Info Access 拡張を探し、https://server.example.com:8443/ca/ocsp などの Location URIName 値をメモします。
  4. 登録プロファイルを更新して、Authority Information Access 拡張を有効にし、Location パラメーターを Certificate Manager の URI に設定します。証明書プロファイルの編集に関する詳細は、「証明書プロファイルの設定」 を参照してください。
  5. CA インスタンスを再起動します。 
    ]# systemctl restart pki-tomcatd@instance-name.service
注記
Certificate Manager の内部 OCSP サービスを無効にするには、CA の CS.cfg ファイルを編集し、ca.ocsp パラメーターの値を false に変更します。 
ca.ocsp=false

7.6.5. OCSPClient プログラムを使用した OCSP リクエストの送信

OCSPClient プログラムは、OCSP リクエストの実行に使用できます。以下に例を示します。 
]# OCSPClient -h server.example.com -p 8080 -d /etc/pki/pki-tomcat/alias -c "caSigningCert cert-pki-ca" --serial 2
CertID.serialNumber=2
CertStatus=Good
OCSPClient コマンドは、以下のコマンドラインオプションと共に使用できます。

表7.1 利用可能な OCSPClient オプション

オプション 説明
-d database セキュリティーデータベースの場所 (デフォルト: 現行ディレクトリー)
-h hostname OCSP サーバーのホスト名 (デフォルト: example.com)
-p port OCSP サーバーのポート番号 (デフォルト: 8080)
-t path OCSP サービスパス (デフォルト: /ocsp/ee/ocsp)
-c nickname CA 証明書のニックネーム (デフォルト: CA 署名証明書)
-n times 送信番号 (デフォルトは 1)
--serial serial_number チェックする証明書のシリアル番号
--input input_file DER でエンコードされた OCSP 要求が含まれる入力ファイル
--output output_file DER でエンコードされた OCSP 応答を保存する出力ファイル
-v, --verbose 詳細モードで実行
--help ヘルプメッセージを表示

7.6.6. GET メソッドを使用した OCSP リクエストの送信

RFC 6960 で説明されているように、255 バイト未満の OCSP 要求は、GET メソッドを使用して Online Certificate Status Manager に送信できます。GET 経由で OCSP 要求を送信するには、以下のコマンドを実行します。
  1. クエリーされるステータスで、証明書の OCSP 要求を生成します。以下に例を示します。 
    ]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64

MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
  2. Web ブラウザーのアドレスバーに URL を貼り付けて、ステータス情報を返します。ブラウザーが OCSP 要求を処理できるようにする必要があります。 
    https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
  3. OCSP Manager は、ブラウザーが解釈できる証明書のステータスを返します。設定可能なステータスは GOOD、REVOKED、および UNKNOWN です。
あるいは、curl などのツールを使用して、要求と openssl を使用して応答を解析して、コマンドラインから OCSP を実行します。以下に例を示します。
  1. クエリーされるステータスで、証明書の OCSP 要求を生成します。以下に例を示します。 
    ]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64

MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
  2. curl を使用して、OCSP 要求を送信するために OCSP Manager に接続します。 
    curl https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE= > ocspresp.der
  3. openssl を使用して応答を解析します。 
    openssl ocsp -respin ocspresp.der -resp_text
Authority Information Access 拡張機能を備えた 7.1 CA によって発行された証明書を GET メソッドを使用して OCSP に送信するには、「Certificate System 7.1 以前で発行された証明書のリダイレクトの設定」 で説明するように、要求を適切な URL に転送するためのリダイレクトを作成する必要があります。

7.6.7. Certificate System 7.1 以前で発行された証明書のリダイレクトの設定

ファイルルート /ocsp/ee/ocsp/ を含む URL で指定された OCSP ユーザーページの場所は、Certificate System 9 または Certificate System 8.1 と、Certificate System 7.1 とで異なります (Certificate System 7.1 では /ocsp/)。Authority Information Access 拡張機能を備えた 7.1 以前の CA によって発行された証明書を OCSP に送信するには、リダイレクトを作成して、要求を適切な URL に転送します。
注記
リダイレクトの設定は、Authority Information Access 拡張機能を備えた 7.1 以前の CA によって発行された証明書を管理するためにのみ必要です。証明書が新しいバージョンの Certificate Manager によって発行されている場合、または Authority Information Access 拡張機能が含まれていない場合、この設定は必要ありません。
  1. OCSP レスポンダーを停止します。 
    ]# systemctl stop pki-tomcatd@instance-name.service
  2. OCSP のエンドユーザー Web アプリケーションディレクトリーに移動します。以下に例を示します。 
    ]# cd /var/lib/pki-ocsp/webapps/ocsp
  3. OCSP の Web アプリケーションディレクトリーの ROOT/WEB-INF/ ディレクトリーにある ROOT ディレクトリーに移動します。以下に例を示します。 
    ]# cd /var/lib/pki-ocsp/webapps/ocsp/ROOT/WEB-INF/
  4. OCSP の Web アプリケーションディレクトリーの ROOT ディレクトリーに lib/ ディレクトリーを作成して開きます。 
    ]# mkdir lib
]# cd lib/
  5. /usr/share/java/pki/cms.jar JAR ファイルへリンクするシンボリックリンクを作成します。以下に例を示します。 
    ]# ln -s /usr/share/java/pki/cms.jar cms.jar
  6. メインの Web アプリケーションディレクトリーに移動します。以下に例を示します。 
    ]# cd /var/lib/pki-ocsp/webapps/ocsp/
  7. 現行インスタンス (ocsp) ディレクトリーの名前を変更します。以下に例を示します。 
    ]# mv /var/lib/pki-ocsp/webapps/ocsp/ocsp /var/lib/pki-ocsp/webapps/ocsp/ocsp2
  8. 元の ocsp/ ディレクトリーの WEB-INF/ ディレクトリーに移動します。以下に例を示します。 
    ]# cd  /var/lib/pki-ocsp/webapps/ocsp/ocsp/WEB-INF
  9. 元の ocsp/WEB-INF/ ディレクトリーで、web.xml ファイルを編集し、eeocspAddCRL と csadmin-wizard サーブレットの間に行マッピングを追加します。 
       <servlet-mapping>
      <servlet-name>  ocspOCSP  </servlet-name>
      <url-pattern>   /ee/ocsp/*  </url-pattern>
   </servlet-mapping>
  10. ROOT ディレクトリーに web.xml ファイルを作成し、インストールします。以下に例を示します。 
    <?xml version="1.0" encoding="ISO-8859-1"?>
<web-app>

  <display-name>Welcome to Tomcat</display-name>
  <description>
     Welcome to Tomcat
  </description>

  <servlet>
    <servlet-name>ocspProxy</servlet-name>
    <servlet-class>com.netscape.cms.servlet.base.ProxyServlet</servlet-class>
    <init-param>
      <param-name>destContext</param-name>
      <param-value>/ocsp2</param-value>
    </init-param>
    <init-param>
      <param-name>destServlet</param-name>
      <param-value>/ee/ocsp</param-value>
    </init-param>
  </servlet>

  <servlet>
    <servlet-name>ocspOther</servlet-name>
    <servlet-class>com.netscape.cms.servlet.base.ProxyServlet</servlet-class>
    <init-param>
      <param-name>destContext</param-name>
      <param-value>/ocsp2</param-value>
    </init-param>
    <init-param>
      <param-name>srcContext</param-name>
      <param-value>/ocsp</param-value>
    </init-param>
    <init-param>
      <param-name>destServlet</param-name>
      <param-value></param-value>
    </init-param>
    <init-param>
      <param-name>matchURIStrings</param-name>

<param-value>/ocsp/registry,/ocsp/acl,/ocsp/jobsScheduler,/ocsp/ug,/ocsp/server,/ocsp/log,
            /ocsp/auths,/ocsp/start,/ocsp/ocsp,/ocsp/services,/ocsp/agent,/ocsp/ee,
            /ocsp/admin</param-value>
    </init-param>
    <init-param>
      <param-name>destServletOnNoMatch</param-name>
      <param-value>/ee/ocsp</param-value>
    </init-param>
    <init-param>
      <param-name>appendPathInfoOnNoMatch</param-name>
      <param-value>/ocsp</param-value>
    </init-param>
  </servlet>

  <servlet-mapping>
    <servlet-name>ocspProxy</servlet-name>
    <url-pattern>/ocsp</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>ocspOther</servlet-name>
    <url-pattern>/ocsp/*</url-pattern>
  </servlet-mapping>

</web-app>
  11. /var/lib/pki-ocsp/conf/context.xml ファイルを編集して、以下の行を追加します。 
    <Context>
 to 
<Context crossContext="true" >
  12. /var/lib/pki-ocsp/webapps/ocsp/ocsp2/services.template ファイルを編集し、以下の行を変更します。 
    result.recordSet[i].uri);
 to 
result.recordSet[i].uri + "/");
  13. OCSP インスタンスを起動します。 
    ]# systemctl restart pki-tomcatd@instance-name.service

パート III. CA サービスを管理するための追加設定

第8章 証明書および CRL の公開

RedRed Hat Certificate Systemnbsp;Hat CertificateRed Hat Certificate Systemnbsp;System には、Certificate Manager 用のカスタマイズ可能な公開フレームワークが含まれており、証明書機関は、証明書、証明書失効リスト (CRL)、およびその他の証明書関連オブジェクトを、サポートされているリポジトリー (LDAP 準拠のディレクトリー、フラットファイル、およびオンライン検証機関) に有効にします。本章では、証明書および CRL をファイル、ディレクトリー、および Online Certificate Status Manager に公開するように Certificate Manager を設定する方法を説明します。
パブリッシュを設定する一般的なプロセスは次のとおりです。
  1. ファイル、LDAP ディレクトリー、または OCSP レスポンダーへの公開を設定します。
    使用する場所の数に応じて、単一のパブリッシャーまたは複数のパブリッシャーが存在する可能性があります。場所は、証明書と CRL、または証明書の種類などのより細かい定義によって分割できます。ルールは、発行者に関連付けられることにより、発行するタイプと場所を決定します。
  2. ルールを設定して、どの証明書がその場所に公開されるかを決定します。証明書または CRL が一致するすべてのルールがアクティブ化されるため、ファイルベースのルールとディレクトリーベースのルールを一致させることにより、同じ証明書をファイルと LDAP ディレクトリーに公開できます。
    ルールは、各オブジェクトタイプ (CA 証明書、CRL、ユーザー証明書、およびクロスペアの証明書) に設定できます。使用されていないルールをすべて無効にします。
  3. CRL を設定します。CRL は公開前に設定する必要があります。7章証明書の取り消しおよび CRL 発行 を参照してください。
  4. パブリッシャー、マッパー、およびルールの設定後に公開を有効にします。公開が有効になると、サーバーはすぐに公開を開始します。パブリッシャー、マッパー、およびルールが完全に設定されていない場合は、パブリッシュが正しく機能しない可能性があります。

8.1. 公開の概要

CertificateCertificate Systemnbsp;System は、証明書をファイルまたは LDAP ディレクトリーに公開し、CRL をファイル、LDAP ディレクトリー、または OCSP レスポンダに公開することができます。
柔軟性を高めるために、特定のタイプの証明書または CRL を単一の形式または 3 つすべての形式で公開できます。たとえば、CA 証明書はディレクトリーにのみ公開され、ファイルには公開されず、ユーザー証明書はファイルとディレクトリーの両方に公開できます。
注記
OCSP レスポンダーは CRL に関する情報のみを提供します。証明書は OCSP レスポンダーに公開されません。
証明書ファイルと CRL ファイルに異なる公開場所を設定でき、さまざまな種類の証明書ファイルや異なるタイプの CRL ファイルとの間で異なる公開場所を設定することができます。
同様に、異なるタイプの証明書や異なるタイプの CRL をディレクトリー内の異なる場所に公開できます。たとえば、所属企業の West Coast 部門からの証明書は、ディレクトリーの 1 つのブランチで公開することができますが、East Coast 部門のユーザーの証明書をディレクトリー内の他のブランチに公開することができます。
公開が有効になっている場合、証明書または CRL が発行、更新、または取り消されるたびに、公開システムが呼び出されます。証明書または CRL はルールによって評価され、ルールのタイプおよび述語と一致するかどうかを確認します。タイプは、オブジェクトが CRL、CA 証明書、またはその他の証明書であるかどうかを指定します。述語は、評価されるオブジェクトのタイプに対してさらに基準を設定します。たとえば、ユーザー証明書を指定するか、West Coast ユーザー証明書を指定できます。述語を使用するには、公開ルールの述語フィールドに値を入力する必要があります。また、対応する値 (形式は多少異なります) を証明書または証明書要求に含める必要があります。証明書または証明書要求の値は、証明書のタイプなどの証明書の情報から取得することも、要求フォームに配置された非表示の値から取得することもできます。述語が設定されていない場合は、そのタイプのすべての証明書が一致することが考慮されます。たとえば、CRL がタイプとして設定されている場合、すべての CRL がルールに一致します。
マッチするすべてのルールは、そのルールで指定された方法および場所に従って証明書または CRL を公開します。指定された証明書または CRL は、ルール、複数のルール、またはすべてのルールに一致しません。公開システムは、発行されたすべての証明書と CRL をすべてのルールと照合しようとします。
ルールがマッチすると、そのルールに関連するパブリッシャーに指定されたメソッドおよび場所に従って、証明書または CRL が公開されます。たとえば、ルールがユーザーに発行されたすべての証明書と一致し、ルールにその場所 /etc/CS/certificates のファイルに公開する発行者がある場合、証明書はファイルとしてその場所に公開されます。別のルールが、ユーザーに発行されたすべての証明書に一致し、そのルールに LDAP 属性 userCertificate;binary 属性に公開するパブリッシャーがある場合、証明書は、ユーザーのエントリーのこの属性で LDAP 公開が有効になったときに指定されたディレクトリーに発行されます。
ファイルに公開するように指定するルールの場合、証明書または CRL が古くなったディレクトリーに新しいファイルが作成されます。
LDAP ディレクトリーに公開するように指定するルールの場合、指定された属性に、証明書または CRL がディレクトリーに指定されたエントリーに公開されます。CA は、公開された証明書または CRL 属性の値を後続の証明書または CRL で上書きします。簡単に言うと、すでに公開されている既存の証明書または CRL は、次の証明書または CRL に置き換えられます。
Online Certificate Status Manager への公開を指定するルールの場合、CRL はこのマネージャーに公開されます。証明書は Online Certificate Status Manager に公開されません。
LDAP 公開の場合は、ユーザーのエントリーの場所を決定する必要があります。マッパーは、公開するエントリーを決定するために使用されます。マッパーには、エントリーの正確な DN、証明書から取得した DN を作成するための情報を関連付けた変数、あるいはディレクトリーを検索してエントリー内の一意の属性や属性のセットを検索し、エントリーの正しい DN を確認するための十分な情報を含めることができます。
証明書が取り消されると、サーバーは公開ルールを使用して、LDAP ディレクトリーまたはファイルシステムから対応する証明書を見つけて削除します。
証明書の有効期限が切れると、サーバーは設定されたディレクトリーからその証明書を削除できます。サーバーはこれを自動的に実行しません。適切なジョブを実行するようにサーバーを設定する必要があります。詳細は、12章自動ジョブの設定 を参照してください。
公開の設定には、パブリッシャー、マッパー、およびルールを設定する必要があります。

8.1.1. パブリッシャー

パブリッシャー は、証明書と CRL が公開される場所を指定します。ファイルに公開する場合、パブリッシャーはファイルシステムの公開ディレクトリーを指定します。LDAP ディレクトリーに公開する場合、発行者は証明書または CRL を格納するディレクトリーの属性を指定します。マッパーは、エントリーの DN を決定するために使用されます。DN ごとに、その DN を導出するための異なる式が設定されます。LDAP 公開が有効であるときに LDAP ディレクトリーの場所が指定されます。OCSP レスポンダーに CRL を公開する場合、パブリッシャーは Online Certificate Status Manager のホスト名と URI を指定します。

8.1.2. マッパー

マッパー は LDAP 公開でのみ使用されます。マッパーは、証明書または証明書要求からの情報に基づいて、エントリーの DN を構築します。サーバーには、証明書のサブジェクト名および証明書要求の情報があり、この情報を使用してそのエントリーの DN を作成する方法を把握する必要があります。マッパーは、利用可能な情報を DN、またはディレクトリー内で検索してエントリーの DN を取得できる一意の情報に変換するための式を提供します。

8.1.3. ルール

ファイル、LDAP、および OCSP 公開の ルール は、証明書または CRL を公開するかどうかとその方法をサーバーに指示します。ルールは、最初に、ルールのタイプと述語を設定することにより、公開されるもの、特定の特性に一致する証明書または CRL を定義します。次に、ルールは、パブリッシャーに関連付けられ、LDAP 公開の場合はマッパーに関連付けられることにより、公開方法と場所を指定します。
ルールは、PKI デプロイメントに必要なだけ単純または複雑にすることができ、さまざまなシナリオに対応するのに十分な柔軟性があります。

8.1.4. ファイルへの公開

サーバーは、証明書と CRL をフラットファイルに公開できます。フラットファイルは、リレーショナルデータベースなどの任意のリポジトリーにインポートできます。サーバーが証明書および CRL をファイルに公開するように設定されている場合、公開ファイルは DER でエンコードされたバイナリーブロブ、base-64 でエンコードされたテキストブロブ、またはその両方になります。
  • サーバーの問題の各証明書について、DER でエンコードされた形式または base-64 でエンコードされた形式で、証明書が含まれるファイルを作成します。各ファイルには cert-serial_number.der または cert-serial_number.b64 という名前が付けられます。serial_number は、ファイルに含まれる証明書のシリアル番号です。たとえば、シリアル番号が 1234 の DER でエンコードされた証明書のファイル名は、cert-1234.der です。
  • サーバーが CRL を生成するたびに、DER でエンコードされた形式または base-64 でエンコードされた形式で新しい CRL を含むファイルが作成されます。各ファイルの名前は、形式に応じて、issuing_point_name-this_update.der または issuing_point_name-this_update.b64 のいずれかになります。issuing_point_name は CRL を公開する CRL 発行ポイントを識別します。this_update は、ファイルに含まれる CRL のタイム依存更新値から取得する値を指定します。たとえば、値 This Update: Friday January 28 15:36:00 PST 2020 の DER でエンコードされた CRL のファイル名は、MasterCRL-20200128-153600.der です。

8.1.5. OCSP 公開

CertificateCertificate Systemnbsp;System OCSP サービスには、Certificate Manager の内部サービスと Online Certificate Status Manager の 2 つの形式があります。内部サービスは、Certificate Manager の内部データベースを確認して、証明書のステータスを報告します。内部サービスは公開用に設定されていません。内部データベースに格納されている証明書を使用して、証明書のステータスを判別します。Online Certificate Status Manager は、Certificate Manager によって送信される CRL を確認します。パブリッシャーは、CRL が送信される場所ごとに設定され、送信される各タイプの CRL に対して 1 つのルールが設定されます。
両方の OCSP サービスの詳細は、「OCSP (Online Certificate Status Protocol) レスポンダーの使用」 を参照してください。

8.1.6. LDAP 公開

LDAP の公開 では、サーバーは LDAP または LDAPS を使用して証明書、CRL、およびその他の証明書関連のオブジェクトをディレクトリーに公開します。公開するディレクトリーのブランチは、公開ディレクトリー と呼ばれます。
  • サーバーが発行する証明書ごとに、ユーザーのエントリーの指定された属性に DER エンコード形式の証明書を含むブロブが作成されます。証明書は DER でエンコードされたバイナリーブロブとして公開されます。
  • サーバーが CRL を生成するたびに、CA のエントリーの指定された属性で、DER でエンコードされた形式で新しい CRL を含むブロブを作成します。
LDAP プロトコルまたは SSL (LDAPS) プロトコルを使用して、証明書および CRL を LDAP 準拠のディレクトリーに公開し、アプリケーションは HTTP 経由で証明書および CRL を取得できます。HTTP で証明書および CRL の取得をサポートすると、一部のブラウザーはサーバーから通常の更新を受け取るディレクトリーから最新の CRL を自動的にインポートできます。ブラウザーは CRL を使用してすべての証明書を自動的にチェックし、証明書が取り消されていないことを確認できます。
LDAP 公開が機能するには、ユーザーエントリーが LDAP ディレクトリーに存在する必要があります。
サーバーと公開ディレクトリーが何らかの理由で同期しなくなった場合は、特権ユーザー (管理者とエージェント) も手動で公開プロセスを開始できます。手順は、「ディレクトリーでの CRL の手動による更新」を参照してください。

8.2. ファイルへの公開設定

公開を設定する一般的なプロセスには、証明書または CRL を特定の場所に公開するように発行者を設定することが含まれます。使用する場所の数に応じて、単一のパブリッシャーまたは複数のパブリッシャーが存在する可能性があります。場所は、証明書と CRL、または証明書の種類などのより細かい定義によって分割できます。ルールは、発行者に関連付けられることにより、発行するタイプと場所を決定します。
ファイルへの公開は、CRL または証明書を特定のホスト上のテキストファイルに公開するだけです。
パブリッシャーは、発行場所ごとに作成および設定する必要があります。パブリッシャーは、ファイルに公開するために自動的に作成されません。すべてのファイルを単一の場所に公開するには、パブリッシャーを 1 つ作成します。異なる場所に公開するには、各場所にパブリッシャーを作成します。場所には、ユーザー証明書などのオブジェクトタイプ、または West Coast ユーザー証明書などのオブジェクトタイプのサブセットを含めることができます。
ファイルに公開するためのパブリッシャーを作成するには、以下の手順を実施します。
  1. Certificate Manager コンソールにログインします。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択し、Publishers を選択します。
    設定されたパブリッシャーインスタンスを一覧表示する Publishers Management タブが右側で開きます。
  3. Add をクリックして、Select Publisher Plug-in Implementation ウィンドウを開きます。これには、登録済みのパブリッシャーモジュールを一覧表します。
  4. FileBasedPublisher モジュールを選択し、エディターウィンドウを開きます。
    これは、Certificate Manager が証明書をファイルに公開し、CRL をファイルに公開できるようにするモジュールです。
  5. 証明書を公開するための情報を設定します。
    • PublishCertsToFile などの空白のない英数字の発行側の ID
    • Certificate Manager がファイルを公開する必要のあるディレクトリーへのパス。パスは絶対パスにすることも、CertificateCertificate Systemnbsp;System インスタンスディレクトリーからの相対パスにすることもできます。たとえば、/export/CS/certificates です。
    • DER でエンコードされたファイル、base-64 でエンコードされたファイル、またはその両方のチェックボックスを選択して公開するファイルタイプ。
    • CRL の場合は、タイムスタンプの形式です。公開される証明書にはファイル名にシリアル番号が含まれ、CRL はタイムスタンプを使用します。
    • CRL の場合、最新の CRL に移動するためにファイルにリンクを生成するかどうか。有効にすると、リンクは、拡張機能で使用する CRL 発行ポイントの名前が crlLinkExt フィールドに指定されると想定します。
    • CRL の場合、CRL を圧縮 (zip) するかどうか、および使用する圧縮レベル。
パブリッシャーを設定した後、「ルールの作成」 の説明に従って、発行された証明書と CR L のルールを設定します。

8.3. OCSP への公開設定

公開を設定する一般的なプロセスには、証明書または CRL を特定の場所に公開するように発行者を設定することが含まれます。使用する場所の数に応じて、単一のパブリッシャーまたは複数のパブリッシャーが存在する可能性があります。場所は、証明書と CRL、または証明書の種類などのより細かい定義によって分割できます。ルールは、発行者に関連付けられることにより、発行するタイプと場所を決定します。
OCSP Manager への公開は、クライアント検証のために CRL を特定の場所に公開することです。
パブリッシャーは、公開場所ごとに作成および設定する必要があります。パブリッシャーは、OCSP レスポンダーに公開するために自動的に作成されません。単一のパブリッシャーを作成して、すべての場所を 1 つの場所に公開するか、CRL を公開するすべての場所のパブリッシャーを作成します。各場所には、さまざまな種類の CRL を含めることができます。

8.3.1. クライアント認証を使用した OCSP への公開の有効化

  1. Certificate Manager コンソールにログインします。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択し、Publishers を選択します。
  3. Add をクリックして、Select Publisher Plug-in Implementation ウィンドウを開きます。これには、登録済みのパブリッシャーモジュールを一覧表します。
  4. OCSPPublisher モジュールを選択し、エディターウィンドウを開きます。これは、Certificate Manager が CRL を Online Certificate Status Manager に公開できるようにするパブリッシャーモジュールです。
    • パブリッシャー ID は、PublishCertsToOCSP のように、スペースのない英数字の文字列である必要があります。
    • host は、ocspResponder.example.com または IPv4 または IPv6 アドレスなどの完全修飾ドメイン名を使用できます。
    • デフォルトのパスは、/ocsp/agent/ocsp/addCRL のように CRL を送信するディレクトリーです。
    • クライアント認証が使用されている (enableClientAuth が選択されている) 場合は、nickname フィールドに認証に使用する証明書のニックネームを指定します。この証明書は OCSP セキュリティーデータベースに存在している必要があります。これは通常 CA サブシステム証明書です。
  5. OCSP Manager で CA のユーザーエントリーを作成します。ユーザーは、新しい CRL を送信するときに OCSP への認証に使用されます。必要なものは 2 つあります。
    • CA-hostname-EEport などの CA サーバーの後に OCSP ユーザーエントリーに名前を付けます。
    • パブリッシャー設定で指定された証明書を、OCSP ユーザーアカウントのユーザー証明書として使用します。通常、これは CA のサブシステム証明書です。
    サブシステムユーザーの設定については、「ユーザーの作成」 で説明されています。
パブリッシャーを設定した後、「ルールの作成」 の説明に従って、発行された証明書と CR L のルールを設定します。

8.4. LDAP ディレクトリーへの公開設定

公開を設定する一般的なプロセスには、証明書または CRL を特定の場所に公開するように発行者を設定することが含まれます。使用する場所の数に応じて、単一のパブリッシャーまたは複数のパブリッシャーが存在する可能性があります。場所は、証明書と CRL、または証明書の種類などのより細かい定義によって分割できます。ルールは、発行者に関連付けられることにより、発行するタイプと場所を決定します。
LDAP 公開の設定は、ディレクトリーを設定するための追加のステップを除き、他の公開手順と似ています。
  1. 公開される証明書の Directory Server を設定します。特定の属性をエントリーに追加し、ID をバインドし、認証方法を設定する必要があります。
  2. 公開された各オブジェクトのパブリッシャーを設定します (CA 証明書、クロスペア証明書、CRL、およびユーザー証明書)。パブリッシャーは、オブジェクトを格納する属性を宣言します。デフォルトで設定される属性は、各オブジェクトタイプを保存する X.500 標準属性です。この属性はパブリッシャーで変更できますが、通常は LDAP パブリッシャーを変更する必要はありません。
  3. エントリーの DN が証明書のサブジェクト名から派生できるようにマッパーを設定します。通常、CA 証明書、CRL、およびユーザー証明書にを設定する必要はありません。証明書タイプに複数のマッパーを設定できます。これは、たとえば、ディレクトリーツリーの異なる部分にある会社の異なる部門の 2 組のユーザーの証明書を公開する場合に役立ちます。グループごとにマッパーが作成され、ツリーの異なるブランチを指定します。
    マッパーの設定に関する詳細は、「マッパーの作成」 を参照してください。
  4. 「ルールの作成」 で説明されているように、パブリッシャーをマッパーに接続するルールを作成します。
  5. 「公開の有効化」 の説明に従って、パブリッシュを有効にします。

8.4.1. LDAP ディレクトリーの設定

証明書および CRL を公開する前に、Directory Server がパブリッシュシステムと連携するように設定する必要があります。つまり、ユーザーエントリーには証明書情報を受信できる属性が必要で、CRL を表すためにエントリーを作成する必要があります。
  1. CA のエントリーを設定します。Certificate Manager が CA 証明書および CRL を公開するには、ディレクトリーには CA のエントリーが含まれている必要があります。
    ヒント
    LDAP 公開が設定されている場合、Certificate Manager はディレクトリー内の CA のエントリーを自動的に作成または変換します。このオプションは CA マッパーインスタンスおよび CRL マッパーインスタンスの両方で設定され、デフォルトで有効になっています。ディレクトリーが Certificate Manager がディレクトリーでエントリーを作成しないようにする場合は、これらのマッパーインスタンスでこのオプションを無効にし、CA を手動でディレクトリーに追加します。
    CA のエントリーをディレクトリーに追加する場合は、CA の DN に基づいてエントリータイプを選択します。
    • CA の DN が cn コンポーネントで開始する場合は、CA の新規 person エントリーを作成します。別のタイプのエントリーを選択すると、cn コンポーネントが指定されない場合があります。
    • CA の DN が ou コンポーネントで開始する場合は、CA の新規 organizationalunit エントリーを作成します。
    このエントリーは、pkiCA または certificationAuthority オブジェクトクラスにはありません。証明書マネージャーは、このエントリーを CA の署名証明書を公開して、pkiCA または certificationAuthority オブジェクトクラスに自動的に変換します。
    注記
    pkiCA オブジェクトクラスは RFC 4523 に定義されていますが、certificationAuthority オブジェクトクラスは (obsolete) RFC 2256 に定義されています。Directory Server が使用するスキーマ定義に応じて、いずれかのオブジェクトクラスは受け入れ可能です。場合によっては、両方のオブジェクトクラスを同じ CA エントリーに使用できます。
    ディレクトリーエントリーの作成に関する詳細は、Red Hat Directory Server のドキュメントを参照してください。
  2. CA およびユーザーディレクトリーエントリーに正しいスキーマ要素を追加します。
    Certificate Manager が証明書と CRL をディレクトリーに公開できるようにするには、特定の属性およびオブジェクトクラスで設定する必要があります。
    オブジェクトタイプ スキーマ 理由
    エンドエンティティー証明書 userCertificate;binary (属性)
    これは、証明書マネージャーが証明書をパブリッシュする属性です。
    これは多値の属性で、各値は DER でエンコードされたバイナリー X.509 証明書です。inetOrgPerson という名前の LDAP オブジェクトクラスによりこの属性が許可されます。strongAuthenticationUser オブジェクトクラスはこの属性を許可し、他のオブジェクトクラスと組み合わせて、証明書を他のオブジェクトクラスのディレクトリーエントリーに公開できるようにすることができます。Certificate Manager は、このオブジェクトクラスを対応する Directory Server のスキーマテーブルに自動的に追加しません。
    見つかったディレクトリーオブジェクトが userCertificate;binary 属性を許可しないと、証明書の追加または削除に失敗します。
    CA 証明書 caCertificate;binary (属性)
    これは、証明書マネージャーが証明書をパブリッシュする属性です。
    Certificate Manager は、サーバーの起動時に独自の CA ディレクトリーエントリーに独自の CA 証明書を公開します。エントリーは、Certificate Manager の発行者名に対応します。
    これは、pkiCA または certificationAuthority オブジェクトクラスの必須の属性です。Certificate Manager は、CA のディレクトリーエントリーを見つけると、このオブジェクトクラスを CA のディレクトリーエントリーに追加します。
    CRL certificateRevocationList;binary (属性)
    これは、Certificate Manager が CRL を公開する属性です。
    Certificate Manager は、CRL を独自の LDAP ディレクトリーエントリーに公開します。エントリーは、Certificate Manager の発行者名に対応します。
    これは、pkiCA または certificationAuthority オブジェクトクラスの属性です。属性の値は DER でエンコードされたバイナリー X.509 CRL です。CA のエントリーには、エントリーに CRL を公開するために、pkiCAまたはcertificationAuthority オブジェクトクラスがすでに含まれている必要があります。
    デルタ CRL deltaRevocationList;binary (属性)
    これは、Certificate Manager が証明書を公開する属性です。Certificate Manager は、フル CRL とは別に、デルタ CRL を独自の LDAP ディレクトリーエントリーに公開します。デルタ CRL エントリーは、Certificate Manager の発行者名に対応します。
    この属性は、deltaCRL または certificationAuthority-V2 オブジェクトクラスに属します。属性の値は DER でエンコードされたバイナリー X.509 delta CRL です。
  3. Directory Server にアクセスするために使用する Certificate Manager のバインド DN を設定します。
    Certificate Manager は、証明書と CRL をディレクトリーに公開するために、ディレクトリーへの読み取り/書き込み権限を持っている必要があります。これにより、Certificate Manager は、証明書関連情報を含むユーザーエントリーと、CA の証明書および CRL 関連情報を含む CA エントリーを変更できます。
    バインド DN エントリーは、以下のいずれかになります。
    • Directory Manager などの書き込みアクセスを持つ既存の DN。
    • 書き込みアクセスが付与された新規ユーザー。エントリーは、Certificate Manager の DN で識別することができます (例: cn=testCA, ou=Research Dept, o=Example Corporation, st=California, c=US)。
      注記
      このユーザーに付与される特権を慎重に検討してください。このユーザーは、アカウントの ACL を作成して、そのディレクトリーに書き込みできます。Certificate Manager のエントリーへの書き込みアクセス権限を付与する方法については、Directory Server のドキュメントを参照してください。
  4. Certificate Manager が Directory Server に対して認証する方法のディレクトリー認証方法を設定します。Basic 認証 (簡易ユーザー名およびパスワード)、クライアント認証なしの SSL、およびクライアント認証を使用する SSL (証明書ベース) の 3 つのオプションがあります。
    サーバーとの通信方法の設定は、Red Hat Directory Server のドキュメントを参照してください。

8.4.2. LDAP パブリッシャーの設定

Certificate Manager は、LDAP 公開に関連するパブリッシャーのセットを作成、設定、および有効にします。デフォルトのパブリッシャー (CA 証明書、ユーザー証明書、CRL、およびクロスのペア証明書用) は、証明書および CRL を保存するための X.500 標準属性に準拠しており、変更する必要はありません。

表8.1 LDAP パブリッシャー

パブリッシャー 説明
LdapCaCertPublisher CA 証明書を LDAP ディレクトリーに公開します。
LdapCrlPublisher CRL を LDAP ディレクトリーに公開します。
LdapDeltaCrlPublisher デルタ CRL を LDAP ディレクトリーに公開します。
LdapUserCertPublisher すべての種類のエンドエンティティー証明書を LDAP ディレクトリーに公開します。
LdapCrossCertPairPublisher 相互署名付き証明書を LDAP ディレクトリーに公開します。

8.4.3. マッパーの作成

マッパーは LDAP 公開のみで使用されます。マッパーは、証明書のサブジェクト名と、証明書が公開されるディレクトリーエントリーの DN 間の関係を定義します。Certificate Manager は、使用するエントリーを判断できるように、証明書または証明書要求からエントリーの DN を取得する必要があります。マッパーは、ユーザーエントリーの DN と証明書のサブジェクト名またはその他の入力情報との関係を定義して、エントリーの正確な DN を特定し、ディレクトリーで見つけることができるようにします。
設定すると、Certificate Manager は、最も一般的な関係を定義するマッパーのセットを自動的に作成します。デフォルトのマッパーは、表8.2「デフォルトのマッパー」 に一覧表示されます。

表8.2 デフォルトのマッパー

マッパー 説明
LdapUserCertMap ユーザー証明書を公開するために、ディレクトリーでユーザーエントリーの正しい属性を見つけます。
LdapCrlMap CRL を公開するために、ディレクトリーで CA のエントリーの正しい属性を見つけます。
LdapCaCertMap CA 証明書を公開するために、ディレクトリーで CA のエントリーの正しい属性を見つけます。
デフォルトのマッパーを使用するには、DN パターンを指定し、ディレクトリーに CA エントリーを作成するかどうかを指定して、各マクロを設定します。他のマッパーを使用するには、マッパーのインスタンスを作成および設定します。詳細は、「マッパープラグインモジュール 」を参照してください。
  1. Certificate Manager コンソールにログインします。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択し、Mappers を選択します。
    設定されたマッパーを一覧表示する Mappers Management タブが右側で開きます。
  3. 新しいマッパーインスタンスを作成するには、Add をクリックします。Select Mapper Plugin Implementation ウィンドウが開き、登録されたマッパーモジュールが一覧表示されます。モジュールを選択し、そのモジュールを編集します。これらのモジュールに関する詳細は、「マッパープラグインモジュール 」 を参照してください。
  4. マッパーインスタンスを編集し、OK をクリックします。
    各マッパーに関する詳細は、「マッパープラグインモジュール 」 を参照してください。

8.4.4. 設定の完了: ルールおよび有効化

LDAP 公開のマッパーを設定したら、「ルールの作成」 の説明に従って、公開証明書および CRL のルールを設定します。
設定が完了したら、「公開の有効化」 の説明に従って公開を有効にします。

8.5. ルールの作成

ルールは、どの場所にどの証明書オブジェクトを公開するかを決定します。ルールは、連携してではなく、独立して機能します。公開される証明書または CRL は、すべてのルールに対して照合されます。一致するルールはすべてアクティブになります。このようにして、ファイルベースのルール、OCSP ルール、およびディレクトリーベースのルールを照合することにより、同じ証明書または CRL をファイル、Online Certificate Status Manager、および LDAP ディレクトリーに公開できます。
ルールは、各オブジェクトタイプ (CA 証明書、CRL、ユーザー証明書、およびクロスペアの証明書) に設定できます。ルールは、さまざまな種類の証明書またはさまざまな種類の CRL についてより詳細にすることができます。
ルールは最初に、ルールに設定されたタイプと述語をオブジェクトと照合することにより、オブジェクトが一致するかどうかを判断します。一致するオブジェクトは、ルールに関連付けられたパブリッシャーとマッパーにより公開されます。
Certificate Manager が発行する証明書のタイプごとにルールが作成されます。
次の手順を実行して、公開ルールを変更します。
  1. Certificate Manager コンソールにログインします。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択し、Rules を選択します。
    設定したルールを一覧表示する Rules Management タブが右側で開きます。
  3. 既存のルールを編集するには、一覧からそのルールを選択し、Edit をクリックします。これにより、Rule Editor ウィンドウが開きます。
  4. ルールを作成するには、Add をクリックします。これにより、Select Rule Plug-in Implementation ウィンドウが開きます。
    Rule モジュールを選択します。これは唯一のデフォルトモジュールです。カスタムモジュールが登録されている場合は、それらも利用できます。
  5. ルールを編集します。
    • type。これは、ルールが適用される証明書のタイプです。CA 署名証明書の場合、値は cacert です。自己署名証明書の場合、値は xcert です。その他すべてのタイプの証明書の場合、値は certs です。CRL には crl を指定します。
    • predicate。これにより、このルールが適用される証明書または CRL 発行ポイントのタイプに述語の値を設定します。CRL 発行ポイント、デルタ CRL、および証明書の述語値の一覧は 表8.3「述語式」 に表示されます。
    • enable。
    • mapper。ファイルに公開する場合、マッパーは必要ありません。LDAP 公開にのみ必要です。このルールが LDAP ディレクトリーに公開されるパブリッシャーに関連付けられている場合は、ここに適切なマッパーを選択します。他のすべての形式の発行では空白のままにします。
    • publisher。ルールに関連付けるパブリッシャーを設定します。
表8.3「述語式」 は、CRL 発行ポイントおよびデルタ CRL および証明書プロファイルを識別するために使用できる述語を一覧表示します。

表8.3 述語式

述語タイプ 述語
CRL 発行ポイント
issuingPointId==Issuing_Point_Instance_ID && isDeltaCRL==[true|false]
マスター CRL だけを公開するには、isDeltaCRL==false を設定します。delta CRL だけを公開するには、isDeltaCRL==true を設定します。両方を公開するには、マスター CRL のルールとデルタ CRL の別のルールを設定します。
証明書プロファイル
profileId==profile_name
使用するプロファイルに基づいて証明書を公開するには、profileId== を caServerCert などのプロファイル名に設定します。

8.6. 公開の有効化

公開は、ファイル、LDAP、またはその両方に対して有効にできます。パブリッシャー、ルール、およびマッパーの設定後に公開を有効にする必要があります。有効にすると、サーバーは公開を開始しようとします。公開が有効になる前に正しく設定されていなかった場合、公開は望ましくない動作を示したり、失敗したりする可能性があります。
注記
CRL を設定します。CRL は公開前に設定する必要があります。7章証明書の取り消しおよび CRL 発行 を参照してください。
  1. Certificate Manager コンソールにログインします。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択します。
    右側のペインには、LDAP 準拠のディレクトリーに公開するための詳細情報が表示されます。
  3. ファイルの公開のみを有効にするには、Enable Publishing を選択します。
  4. LDAP 公開を有効にするには、Enable Publishing および Enable Default LDAP Connection の両方を選択します。
    Destination セクションで、Directory Server インスタンスの情報を設定します。
    • Host name。Directory Server が SSL クライアント認証通信用に設定されている場合、名前は Directory Server の SSL サーバー証明書のサブジェクト DN 内の cn コンポーネントに一致する必要があります。
      ホスト名は完全修飾ドメイン名または IPv4 アドレスまたは IPv6 アドレスになります。
    • Port number。
    • Directory Manager DN。これは、Directory Manager 権限を持つディレクトリーエントリーの識別名 (DN) です。Certificate Manager はこの DN を使用してディレクトリーツリーにアクセスし、そのディレクトリーに公開します。この DN に設定されたアクセス制御は、Certificate Manager が公開できるかどうかを判断します。公開システムが実際に書き込む必要のある属性に対してのみ読み取り/書き込み権限が制限されている別の DN を作成することができます。
    • Password。これは、CA が証明書または CRL の公開先の LDAP ディレクトリーにバインドするために使用するパスワードです。Certificate Manager は、このパスワードを password.conf ファイルに保存します。以下に例を示します。 
      CA LDAP Publishing:password
      注記
      パブリッシュパスワード (CA LDAP Publishing) を識別するパラメーター名は、ca.publish.ldappublish.ldap.ldapauth.bindPWPrompt パラメーターの Certificate Manager の CS.cfg ファイルで設定されます。
    • Client certificate。これにより、SSL クライアント認証に Certificate Manager が使用する証明書がパブリッシュディレクトリーに設定されます。デフォルトでは、証明書マネージャーは SSL サーバー証明書を使用します。
    • LDAP version。LDAP バージョン 3 を選択します。
    • Authentication。Certificate Manager が Directory Server に対して認証する方法。Basic authentication と SSL client authentication を選択できます。
      Directory Server が基本認証またはクライアント認証なしの SSL 通信用に設定されている場合は、Basic authentication を選択して、Directory マネージャーの DN とパスワードの値を指定します。
      Directory Server がクライアント認証を使用した SSL 通信用に設定されている場合は、SSL client authentication と Use SSL communication オプションを選択し、Certificate Manager がディレクトリーへの SSL クライアント認証に使用する必要のある証明書を識別します。
サーバーは、Directory Server への接続を試みます。情報が正しくない場合、サーバーにはエラーメッセージが表示されます。

8.7. 公開キューの有効化

登録プロセスには、発行した証明書をディレクトリーまたはファイルに公開します。したがって、基本的には、最初の証明書要求を閉じます。ただし、外部ネットワークに証明書を公開すると、発行プロセスが大幅に遅くなり、リクエストが開いたままになります。
この状況を回避するために、管理者は 公開キュー を有効にできます。パブリッシュキューは、別のリクエストキューを使用するリクエスト操作および登録操作 (外部の LDAP ディレクトリーを伴う可能性がある) を分離します。要求キューはすぐに更新され、登録プロセスが完了したことを示します。一方、公開キューがネットワークトラフィックの一時停止時に情報を送信します。
公開キューは、承認された証明書ごとに新しいスレッドを開くのではなく、生成された証明書を公開する定義済みの制限された数のスレッドを設定します。
パブリッシュキューはデフォルトで無効になっています。公開を有効にするとともに、CA コンソールで有効にすることができます。
注記
パブリッシュキューはデフォルトで無効になっていますが、コンソールで LDAP 公開が有効な場合にはキューが自動的に有効になります。それ以外の場合は、キューを手動で有効にできます。

図8.1 公開キューの有効化

公開キューの有効化
ヒント
CS.cfg ファイルを編集してパブリッシュキューを有効にすると、管理者はパブリッシュ操作に使用するスレッドの数やキューページサイズなど、パブリッシュする他のオプションを設定できます。
CS.cfg ファイルを編集してこの機能を設定する方法は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『公開キューの有効化』セクションを参照してください。

8.8. 再開可能な CRL ダウンロードの設定

CertificateCertificate Systemnbsp;System は、中断された CRL ダウンロードをスムーズに再開するためのオプションを提供します。これは、HTTP 経由でプレーンファイルとして CRL を公開することで行われます。CRL のダウンロード方法により、CRL の取得やネットワーク全体の輻輳を軽減することができます。

8.8.1. wget を使用した CRL の取得

CRL は HTTP 経由でテキストファイルとして公開されるため、wget などのツールを使用して CA から手動で取得できます。wget コマンドを使用すると、公開されている CRL を検索できます。たとえば、以前のフル CRL よりも新しいフル CRL を取得するには、次のようにします。 
[root@server ~]# wget --no-check-certificate -d https://server.example.com:8443/ca/ee/ca/crl/MasterCRL.bin
wget の関連パラメーターの概要は、表8.4「CRL の取得に使用する wget オプション」 にまとめています。

表8.4 CRL の取得に使用する wget オプション

引数 説明
引数なし 完全な CRL を取得します。
-N ローカルコピー (delta CRL) よりも新しい CRL を取得します。
-c 部分的にダウンロードしたファイルを取得します。
--no-check-certificate 接続の SSL を省略するため、ホストとクライアント間で SSL を設定する必要はありません。
-d デバッグ情報を出力します。

8.9. ペア間の証明書の公開

クロスペアの証明書は LDAP ディレクトリーまたはファイルに crossCertificatePair エントリーとして公開できます。これはデフォルトで有効になっています。これが無効な場合は、Certificate Manager Console で以下のコマンドを実行して再度有効にできます。
  1. CA コンソールを開きます。 
    pkiconsole https://server.example.com:8443/ca
  2. Configuration タブで、左側のペインの Certificate Manager リンクを選択してから、Publishing リンクを選択します。
  3. Publishing の Rules リンクをクリックし ます。これにより、右側に Rules Management ペインが開きます。
  4. ルールが存在し、無効になっている場合は、enable チェックボックスを選択します。ルールが削除された場合は、Add クリックして新しいルールを作成します。
    1. type ドロップダウンメニューから xcerts を選択します。
    2. 有効 のチェックボックスが選択されていることを確認してください。
    3. mapper ドロップダウンメニューから、LdapCaCertMap を選択します。
    4. publisher ドロップダウンメニューから LdapCrossCertPairPublisher を選択します。
公開ルールで指定されたマッパーとパブリッシャーは両方とも、CA コンソールの左側のナビゲーションウィンドウの Publishing リンクの下の Mapper と Publisher 下に一覧表示されます。デフォルトでは、マッパーの LdapCaCertMap は、LdapCaSimpleMap LDAP エントリーに crossCertificatePair を保存するように指定します。パブリッシャー LDAPCrossPairPublisher は、デフォルトでは CA