管理ガイド
Red Hat Certificate System 9.7 向けに更新
概要
第1章 Red Hat Certificate System サブシステムの概要
1.1. 証明書に使用
1.2. Certificate System サブシステムのレビュー
Enterprise Security Client
1.3. 証明書管理の概観 (非 TMS)
1.4. Token Management System (TMS) の概観
1.5. Red Hat Certificate System サービス
パート I. Red Hat Certificate System ユーザーインターフェイス
第2章 ユーザーインターフェイス
2.1. ユーザーインターフェイスの概要
- PKI コマンドラインインターフェイスおよびその他のコマンドラインユーティリティー
- PKI コンソールのグラフィカルインターフェイス
- Certificate System Web インターフェイス
~/.dogtag/nssdb/
ディレクトリーにある NSS データベースを使用します。「pki CLI の初期化」では、NSS データベースを管理者の証明書およびキーで初期化する詳細な手順を説明します。PKI コマンドラインユーティリティーの使用例は、「pki CLI の使用」に記載されています。その他の例を以下に示します。
PKCS10Client
を使用した CSR の作成」 などの後のセクションで使用されています。
pkiconsole
の初期化」 は、初期化方法を説明します。「CA、OCSP、KRA、および TKS サブシステムに対する pkiconsole
の使用」 では、コンソールインターフェイスの使用の概要を説明します。「Java ベースの管理コンソールを使用した証明書の登録プロファイルの管理」 などの後のセクションでは、特定の操作について詳しく説明します。
2.2. クライアント NSS データベースの初期化
- クライアント用の NSS データベースを準備します。これは、新規データベースか、または既存のデータベースにすることができます。
- CA 証明書チェーンをインポートして信頼します。
- 証明書と対応するキーがあります。NSS データベースで生成したり、PKCS #12 ファイルから他の場所からインポートしたりできます。
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 データベースを作成します。
.p12
ファイルから管理クライアント証明書を抽出します。
$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt
$ PKICertImport -d ~/.redhat-idm-console -n "nickname" -t ",," -a -i file.crt -u C
$ 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
の使用
pkiconsole https://server.example.com:admin_port/subsystem_type
https://192.0.2.1:8443/ca https://[2001:DB8::1111]:8443/ca
図2.1 Certificate System コンソール
- ユーザーおよびグループ
- アクセス制御リスト
- ログ設定
- サブシステム証明書 (セキュリティードメインや監査署名など、サブシステムに発行した証明書)
2.4. Web インターフェイス
2.4.1. ブラウザーの初期化
CA 証明書のインポート
- Authorities タブを選択し、 ボタンをクリックします。
ca.crt
ファイルを選択して、 をクリックします。
クライアント証明書のインポート
- Your Certificates タブを選択します。
ca_admin_cert.p12
などのクライアント p12 ファイルを選択します。- プロンプトにクライアント証明書のパスワードを入力します。
- Your Certificates の下にエントリーが追加されていることを確認します。
Web コンソールへのアクセス
2.4.2. 管理インターフェイス
図2.2 TPS 管理ページ
2.4.3. エージェントインターフェイス
図2.3 Certificate Manager のエージェントサービスページ
- Certificate Manager エージェントサービスには、(証明書を発行する) 証明書要求の承認、証明書の失効、ならびに証明書および CRL の公開が含まれます。CA が発行するすべての証明書は、そのエージェントサービスページで管理できます。
- TPS エージェントサービスは、CA エージェントサービスと同様、フォーマットされ、TPS を介して証明書が発行されたすべてのトークンを管理します。トークンはエージェントで登録、一時停止、および削除できます。他の 2 つのロール (operator および admin) は Web サービスページでトークンを表示できますが、トークンに対するアクションを実行できません。
- KRA エージェントサービスページは、キーリカバリー要求を処理します。キーリカバリー要求は、証明書が失われた場合に既存のキーペアを再利用して証明書を発行できるようにするかどうかを設定します。
- OCSP エージェントサービスページを使用すると、エージェントは CRL を OCSP に公開し、CRL を手動で OCSP に読み込み、クライアント OCSP 要求の状態を表示するように CA を設定します。
2.4.4. エンドユーザーページ
図2.4 Certificate Manager のエンドエンティティーページ
2.5. コマンドラインインターフェイス
2.5.1. pkiCLI
$
pki [CLI options] <command> [command parameters]
2.5.1.1. pki CLI の初期化
$
pki -c <password> client-init
~/.dogtag/nssdb
ディレクトリーに新しいクライアント NSS データベースが作成されます。パスワードは、クライアントの NSS データベースを使用するすべての CLI 操作に指定する必要があります。または、パスワードがファイルに保存されている場合は、-C
オプションを使用してファイルを指定できます。以下に例を示します。
$
pki -C password_file client-init
.p12
ファイルから管理クライアント証明書を抽出します。
$ openssl pkcs12 -in file -clcerts -nodes -nokeys -out file.crt
$ PKICertImport -d ~/.dogtag/nssdb -n "nickname" -t ",," -a -i file.crt -u C
$
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 ca
$
pki ca-cert
--help
オプションを使用します。
$
pki --help
$
pki ca-cert-find --help
$
pki help
$
pki help ca-cert-find
$
pki ca-cert-find
$
pki -U <server URL> -n <nickname> -c <password> <command> [command parameters]
$
pki -n jsmith -c password ca-user-find ...
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 input.ascii output.bin
2.5.3. AuditVerify
$ AuditVerify -d ~jsmith/auditVerifyDir -n Log Signing Certificate -a ~jsmith/auditVerifyDir/logListFile -P "" -v
~jsmith/auditVerifyDir
NSS データベー (-d
) の Log Signing Certificate
(-n
) を使用して監査ログを検証します。検証するログのリスト (-a
) は ~jsmith/auditVerifyDir/logListFile
ファイルにあります。こちらは、コンマ区切りで時系列順に並べられています。証明書の先頭に接頭辞 (-P
) を追加し、キーデータベースのファイル名を空にします。出力は詳細です (-v
)。
2.5.4. BtoA
$
BtoA input.bin output.ascii
2.5.5. CMCRequest
$
CMCRequest example.cfg
CMCRequest
を使用した証明書の取り消し」 を使用した証明書の要求と受け取り
2.5.6. CMCRevoke
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
-n
)、現在のディレクトリー (-d
) の NSS データベース (-b)、トランスポート (kra.transport
) (-b
) に使用する証明書、AES/CBC/PKCS5Padding キーをラップする証明書で新しい CSR を作成します (-v
)。また、生成される CSR が /user_or_entity_database_directory/example.csr
ファイル (-o
) に書き込まれます。
CMCRequest
を使用した証明書の取り消し」 も参照してください。
2.5.9. HttpClient
HttpClient
ユーティリティーは、CMC 要求を送信するための NSS 対応の HTTP クライアントです。
$ HttpClient request.cfg
request.cfg
ファイルに保存されます。詳細は、HttpClient --help コマンドの出力を参照してください。
2.5.10. OCSPClient
$ OCSPClient -h server.example.com -p 8080 -d /etc/pki/pki-tomcat/alias -c "caSigningCert cert-pki-ca" --serial 2
-p
) の server.example.com
OCSP サーバー (-h
) に対してクエリーを実行し、シリアル番号 2 (--serial
) を持つ caSigningcet cert-pki-ca (-c
) が署名した証明書を確認します。/etc/pki/pki-tomcat/alias
ディレクトリーの NSS データベースが使用されます。
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
) です。
2.5.12. PrettyPrintCert
$ PrettyPrintCert ascii_data.cert
ascii_data.cert
ファイルの出力を解析し、その内容を人間が読める形式で表示します。出力には、署名アルゴリズム、指数、モジュール、証明書拡張などの情報が含まれます。
2.5.13. PrettyPrintCrl
$ PrettyPrintCrl ascii_data.crl
ascii_data.crt
ファイルの出力を解析して、その内容を人間が読める形式で表示します。出力には、失効署名アルゴリズム、失効の発行者、取り消された証明書とその理由が一覧になったものなどが含まれます。
2.5.14. TokenInfo
$ TokenInfo ./nssdb/
2.5.15. tkstool
tkstool
ユーティリティーは、トークンキーサービス (TKS) サブシステムと対話します。
$ tkstool -M -n new_master -d /var/lib/pki/pki-tomcat/alias -h token_name
token_name
の /var/lib/pki/pki-tomcat/alias
NSS データベースに new_master (-n
) という名前の新しいマスターキー (-M
) を作成します。
2.6. 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 でトークンを再登録するなど、セキュリティートークンを維持します。
- 管理対象トークンの現在のステータスに関する情報を提供します。
- トークンが失われた場合に別のトークンで鍵をアーカイブおよび復元できるように、サーバー側の鍵生成をサポートします。
- ユーザーがセキュリティートークンを登録して、TPS によって認識されるようにします。
- ユーザーがセキュリティートークンを管理できるようにします。たとえば、Enterprise Security Client を使用すると、TPS でトークンを再登録できます。
- デフォルトおよびカスタムトークンプロファイルを使用したさまざまなトークンのサポートを提供します。デフォルトでは、TPS はユーザーキー、デバイスキー、およびセキュリティー担当者キーを自動的に登録できます。これにより、適切なプロファイルに従って (トークン CUID などの属性によって認識される) さまざまな使用に大してトークンが自動的に自動的に登録されるように、追加のプロファイルを追加できます。
- 管理対象トークンの現在のステータスに関する情報を提供します。
パート II. 証明書サービスの設定
第3章 証明書を発行するルール (証明書プロファイル) の作成
3.1. 証明書プロファイルの概要
- 認証。すべての認証プロファイルで認証方法を指定できます。
- 認可。すべての認定プロファイルで承認方法を指定できます。
- プロファイル入力。プロファイルの入力は、証明書が要求されたときに CA に送信されるパラメーターおよび値です。プロファイル入力には、証明書要求の公開鍵と、証明書の終了エンティティーによって要求される証明書のサブジェクト名が含まれます。
- プロファイルの出力。プロファイルの出力は、エンドエンティティーに証明書を提供する形式を指定するパラメーターおよび値です。プロファイルの出力は、要求が成功したときに PKCS#7 証明書チェーンが含まれる CMC の応答です。
- 証明書の内容。各証明書は、割り当てられたエンティティーの名前 (サブジェクト名)、署名アルゴリズム、有効期間などのコンテンツ情報を定義します。証明書に含まれるものは、X.509 標準で定義されます。X509 標準のバージョン 3 では、証明書に拡張機能を含めることもできます。証明書エクステンションの詳細は、??? を参照してください。証明書プロファイルに関する情報はすべて、プロファイルの設定ファイルのプロファイルポリシーの
set
エントリーで定義されます。複数の証明書が同時に要求される可能性がある場合は、各証明書のニーズを満たすためにプロファイルポリシーに複数のセットエントリーを定義できます。各ポリシーセットは多数のポリシールールで設定され、各ポリシールールは証明書コンテンツのフィールドを記述します。ポリシールールには、以下の内容を含めることができます。- プロファイルのデフォルトです。これらは、証明書内に含まれる情報に対する事前定義済みのパラメーターおよび許可される値です。プロファイルのデフォルトには、証明書の有効期間と、発行する証明書のタイプにどの証明書拡張機能が表示されるかが含まれます。
- プロファイルの制約。制約は、証明書を発行するルールまたはポリシーを設定します。また、プロファイル制約には、証明書のサブジェクト名に少なくとも 1 つの CN コンポーネントを含める必要があるルールが含まれます。また、証明書の有効性を最大 360 日に設定して、更新を許可する猶予期間を定義するルール、または subjectaltname 拡張が常に true に設定される必要があるというルールが含まれます。
3.1.1. 登録プロファイル
例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
output.list=o1 output.o1.class_id=certOutputImpl
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. 証明書拡張: デフォルトおよび制約
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
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
3.1.3. 入力および出力
3.2. 証明書プロファイルの設定
- PKI コマンドラインインターフェイスの使用
- Java ベースの管理コンソールの使用
3.2.1. PKI コマンドラインインターフェイスを使用した証明書の登録プロファイルの管理
pki
ユーティリティーを使用して証明書プロファイルを管理する方法を説明します。詳細は、pki-ca-profile(1) の man ページを参照してください。
3.2.1.1. 証明書プロファイルの有効化および無効化
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 形式の証明書プロファイルの作成
# pki -c password -n caadmin ca-profile-add profile_name.cfg --raw
profileId=profile_name
3.2.1.3. RAW 形式での証明書プロファイルの編集
caCMCECserverCert
プロファイルを編集するには、次のコマンドを実行します。
# pki -c password -n caadmin ca-profile-edit caCMCECserverCert
VI
エディターで開きます。エディターを閉じると、サーバーでプロファイル設定が更新されます。
例3.2 RAW 形式での証明書プロファイルの編集
caCMCserverCert
プロファイルを編集して、ユーザーが提供する複数の拡張機能を許可するには、次を行います。
- CA エージェントであるプロファイルを無効にします。
# pki -c password -n caagemt ca-profile-disable caCMCserverCert
- プロファイルを CA 管理者として編集します。
VI
エディターでプロファイルをダウンロードして開きます。# pki -c password -n caadmin ca-profile-edit caCMCserverCert
- 設定を更新して、拡張機能を受け入れます。詳細は、??? を参照してください。
- プロファイルを 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 CA サブシステムコンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで Certificate Manager を選択し、Certificate Profiles を選択します。設定した証明書プロファイルを一覧表示する Certificate Profile Instances Management タブが開きます。
- 新しい証明書プロファイルを作成するには、をクリックします。Select Certificate Profile Plugin Implementation ウィンドウで、プロファイルが作成される証明書のタイプを選択します。
- Certificate Profile Instance Editor にプロファイル情報を入力します。
- Certificate Profile Instance ID。この ID は、システムがプロファイルの特定に使用する ID です。
- 証明書プロファイル名これは、ユーザーが分かりやすいプロファイルの名前です。
- Certificate Profile Description。
- End User Certificate Profile。これにより、リクエストがプロファイルの入力フォームを介して行われる必要があるかどうかが設定されます。これは通常 true に設定されます。これを false に設定すると、証明書プロファイルの入力ページではなく、Certificate Manager の証明書プロファイルフレームワークを介して署名済みリクエストが処理できるようになります。
- 証明書プロファイル認証これにより、認証方法が設定されます。認証インスタンスのインスタンス ID を指定して、自動認証が設定されます。このフィールドが空の場合、認証方法はエージェントで承認される登録になります。要求はエージェントサービスインターフェイスの要求キューに送信されます。TMS サブシステム用でない限り、管理者は次の認証プラグインのいずれかを選択する必要があります。
- CMCAuth: CA エージェントが登録要求を承認し、送信する必要がある場合に、このプラグインを使用します。
- CMCUserSignedAuth: このプラグインを使用して、エージェント以外のユーザーが独自の証明書を登録できるようにします。
- 新規プロファイルのポリシー、入力、および出力を設定します。一覧から新しいプロファイルを選択し、をクリックします。
- Certificate Profile Rule Editor ウィンドウの Policies タブでポリシーを設定します。ポリシー タブには、プロファイルタイプに対してデフォルトで設定されているポリシーが一覧表示されます。
- ポリシーを追加するには、をクリックします。
- Default フィールドからデフォルトを選択して、Constraints フィールドでそのポリシーに関連付けられた制約を選択し、 をクリックします。
- ポリシー設定 ID を入力します。デュアルキーペアを発行する場合には、個別のポリシーセットで、各証明書に関連付けられたポリシーを定義します。次に、証明書プロファイルポリシー ID と、証明書プロファイルポリシーの名前または識別子を入力します。
- Defaults タブおよび Constraints タブでパラメーターを設定します。Defaults は、証明書要求に設定する属性を定義します。これにより、証明書の内容が決定されます。これらは、拡張、有効期間、または証明書に含まれるその他のフィールドのいずれかになります。制約 は、デフォルト値の有効な値を定義します。各デフォルトまたは制約の詳細は、「デフォルトの参照」 および 「制約の参照」 を参照してください。
既存のポリシーを変更するには、ポリシーを選択し、をクリックします。次に、そのポリシーのデフォルトおよび制約を編集します。ポリシーを削除するには、ポリシーを選択し、をクリックします。 - Certificate Profile Rule Editor ウィンドウの Inputs タブに入力を設定します。プロファイルには複数の入力タイプが存在します。注記TMS サブシステムにプロファイルを設定しない場合は、cmcCertReqInput のみを選択して ボタンをクリックし、他のプロファイルを削除します。
- 入力を追加するには、をクリックします。
- 一覧から入力を選択し、「入力の参照」 を参照してください。をクリックします。デフォルト入力の完全な詳細については、
- New Certificate Profile Editor ウィンドウが開きます。入力 ID を設定して、 をクリックします。
入力は追加および削除が可能です。入力の編集を選択することは可能ですが、入力にはパラメーターやその他の設定がないため、設定するものはありません。入力を削除するには、入力を選択してをクリックします。 - Certificate Profile Rule Editor ウィンドウの Outputs タブで、出力を設定します。自動認証方式を使用する証明書プロファイルには、出力を設定する必要があります。エージェントが承認した認証を使用する証明書プロファイルには、出力を設定する必要はありません。Certificate Output タイプはすべてのプロファイルでデフォルトで設定され、カスタムプロファイルに自動的に追加されます。TMS サブシステムにプロファイルを設定しない限り、certOutput のみを選択します。出力を追加または削除できます。出力の編集を選択することは可能ですが、出力にはパラメーターやその他の設定がないため、設定するものはありません。
- 出力を追加するには、をクリックします。
- 一覧から出力を選択してをクリックします。
- 出力の名前または識別子を指定して、をクリックします。この出力は出力タブに一覧表示されます。これを編集して、この出力のパラメーターに値を指定できます。
出力を削除するには、一覧から出力を選択してをクリックします。 - CA を再起動して、新規プロファイルを適用します。
systemctl restart pki-tomcatd-nuxwdog@instance_name.service
- プロファイルを管理者として作成したら、CA エージェントはエージェントサービスページでプロファイルを承認してプロファイルを有効にする必要があります。
- CA のサービスページを開きます。
https://server.example.com:8443/ca/services
- 証明書プロファイルの管理 リンクをクリックします。このページには、アクティブと非アクティブの両方で、管理者によって設定されたすべての証明書プロファイルが一覧表示されます。
- 承認する証明書プロファイルの名前をクリックします。
- ページの下部で、ボタンをクリックします。
3.2.2.2. コンソールでの証明書プロファイルの編集
- エージェントサービスページにログインし、プロファイルを無効にします。エージェントで証明書プロファイルを有効にすると、その証明書プロファイルは Certificate Profile Instance Management タブで有効とマークされ、コンソールを介して証明書プロファイルはいつでも編集できません。
- Certificate System CA サブシステムコンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで Certificate Manager を選択し、Certificate Profiles を選択します。
- 証明書のプロファイルを選択して、をクリックします。
- Certificate Profile Rule Editor ウィンドウが表示されます。多くのデフォルト、制約、入力、または出力が変更されています。注記プロファイルインスタンス ID は変更しないでください。必要に応じて、ウィンドウの隅の 1 つを引っ張って、ウィンドウを拡大します。
- CA を再起動して変更を適用します。
- エージェントサービスページで、プロファイルを再度有効にします。
3.2.3. 証明書の登録プロファイルの一覧表示
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
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 ...
3.3. プロファイルでの鍵のデフォルトの定義
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.set1.list=p1,p2,p11,p3
,p4,p5,p6,p7,p8,p9,p10
3.4. 更新を有効にするためのプロファイルの設定
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. 同じ鍵を使用した更新
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. 新しい鍵を使用した更新
subjectDN
を使用します。
3.5. 証明書の署名アルゴリズムの設定
3.5.1. CA のデフォルト署名アルゴリズムの設定
- CA コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、Certificate Manager ツリーを展開します。
- General Settings タブで、Algorithm ドロップダウンメニューで使用するアルゴリズムを設定します。
3.5.2. プロファイルでの署名アルゴリズムのデフォルトの設定
.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=-
- CA コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、Certificate Manager ツリーを展開します。
- Certificate Profiles 項目をクリックします。
- Policies タブをクリックします。
- Signing Alg ポリシー を選択して ボタンをクリックします。
- デフォルトの署名アルゴリズムを設定するには、Defaults タブで値を設定します。これが - に設定されている場合、プロファイルは CA のデフォルトを使用します。
- 証明書要求で許可される署名アルゴリズムの一覧を設定するには、Constraints タブを開き、singiningAlgsAllowed の Value フィールドでアルゴリズムの一覧を設定します。制約に使用できる値は、「アルゴリズム制約の署名」 に記載されています。
3.7. サブジェクト名およびサブジェクト代替名の管理
3.7.1. サブジェクト名でのリクエスター CN または UID の使用
cn
値または uid
値は、発行した証明書のサブジェクト名をビルドするために使用できます。このセクションでは、サブジェクト名制約に naming 属性 (CN または UID) が証明書要求に存在する必要があるプロファイルを示しています。naming 属性がないと、リクエストは拒否されます。
- CN または UID 形式は、Subject Name Constraint の pattern 設定に設定されます。
- CN または UID トークン、および証明書の特定の接尾辞を含むサブジェクト DN の形式は、Subject Name Default に設定されます。
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
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
3.7.2. サブジェクト代替名への LDAP ディレクトリー属性値およびその他の情報の挿入
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
- LDAP 属性値を挿入するには、ユーザーディレクトリーの認証プラグイン SharedSecret を有効にする必要があります。
- CA コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- 左側のナビゲーションツリーで 認証 を選択します。
- Authentication Instance タブで、 をクリックして、SharedSecret 認証プラグインのインスタンスを追加します。
- 以下の情報を入力します。
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
- 新規プラグインインスタンスを保存します。
JOIN 共有トークンの設定に関する詳細は、「CMC 共有シークレットの設定」 を参照してください。 - ldapStringAttributes パラメーターは、ユーザーの LDAP エントリーから
mail
属性の値を読み込み、その値を証明書要求に追加するように、認証プラグインに指示します。値が要求に設定されている場合、証明書プロファイルポリシーは、拡張値のその値を挿入するように設定できます。 - CA が証明書拡張機能に LDAP 属性の値を挿入できるようにするには、プロファイルの設定ファイルを編集し、拡張機能のポリシーセットパラメーターを挿入します。たとえば、
caFullCMCSharedTokenCert
プロファイルの Subject Alternative Name 拡張にmail
属性値を挿入するには、以下のコードを変更します。policyset.setID.8.default.params.
subjAltExtPattern_0=$request.auth_token.mail[0]$
プロファイルの編集に関する詳細は、「RAW 形式での証明書プロファイルの編集」 を参照してください。 - 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
ポリシーセットトークン | 説明 |
---|---|
$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.requestor_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 属性の使用
dNSName
Subject Alternative Name (SAN) の値を使用します。
dNSName
値は、既存の SAN に追加されます。
- プロファイルを無効にします。
# pki -c password -p 8080 \ -n "PKI Administrator for example.com" ca-profile-disable profile_name
- プロファイルを編集します。
# pki -c password -p 8080 \ -n "PKI Administrator for example.com" ca-profile-edit profile_name
- プロファイルに固有のセット番号を使用して、以下の設定を追加します。以下に例を示します。
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 をセット番号として使用しています。 policyset.userCertSet.list
パラメーターに新しいポリシーセット番号を追加します。以下に例を示します。policyset.userCertSet.list=1,10,2,3,4,5,6,7,8,9,12
- プロファイルを保存します。
- プロファイルを有効にします。
# pki -c password -p 8080 \ -n "PKI Administrator for example.com" ca-profile-enable profile_name
commonNameToSANDefaultImpl
のデフォルトが含まれます。
3.7.4. CSR からの SAN 拡張の許可
3.7.4.1. 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
第4章 キーアーカイブおよびリカバリーの設定
4.1. コンソールでのエージェント承認キーリカバリーの設定
CS.cfg
ファイルで直接設定できます。コンソールはデフォルトで Key Recovery Authority Agents Group
を使用します。
- KRA のコンソールを開きます。以下に例を示します。
pkiconsole https://server.example.com:8443/kra
- 左側のナビゲーションツリーの Key Recovery Authority のリンクをクリックします。
- Required Number of Agents フィールドに、キー復元を承認するのに使用するエージェントの数を入力します。
CS.cfg
ファイルで設定する詳細な方法は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『コマンドラインでのエージェント承認キーリカバリーの設定』 を参照してください。
4.2. キーアーカイブおよびリカバリー設定のテスト
- CA の Manual User Signing & Encryption Certificates Enrollment フォームを使用して、二重証明書に登録します。
- 要求を送信します。エージェントサービスページにログインし、要求を承認します。
- エンドエンティティーのページにログインし、証明書が発行されたかどうかを確認します。証明書のリストでは、連続するシリアル番号を持つ新しい証明書が 2 つあります。
- Web ブラウザーに証明書をインポートします。
- 鍵がアーカイブされたことを確認します。KRA のエージェントサービスページで、Show completed requests を選択します。キーが正常にアーカイブされた場合は、そのキーに関する情報が生成されます。キーが表示されない場合は、ログを確認して、問題を修正します。キーが正常にアーカイブされたら、ブラウザーウィンドウを閉じます。
- 鍵を確認します。署名付きで暗号化された電子メールを送信します。メールを受信したら、メッセージを確認して開き、メッセージが署名されて暗号化されているかどうかを確認します。メッセージウィンドウの右上隅に、メッセージが署名されて暗号化されていることを示すセキュリティーアイコンがあるはずです。
- 証明書を削除します。暗号化された電子メールを再度確認します。メールクライアントはメッセージを復号できないはずです。
- アーカイブされた鍵を正常に復元できるかどうかをテストします。
- KRA のエージェントサービスページを開き、Recover Keys リンクをクリックします。キーの所有者、シリアル番号、または公開鍵で鍵を検索します。キーが正常にアーカイブされた場合は、キー情報が表示されます。
- 表示される形式で、復元する秘密鍵に対応する base-64 でエンコードされた証明書を入力します。この情報を取得するには CA を使用します。base-64 でエンコードされた証明書を指定してアーカイブされた鍵を検索する場合は、ここで証明書を指定する必要はありません。
- リカバリーの実行中にブラウザーセッションが閉じられるように Async Recovery チェックボックスが選択されていることを確認してください。ヒント非同期リカバリーはデフォルトであり、キーのリカバリーを実行するのに推奨される方法です。同期キーリカバリーを実行する場合、ブラウザーウィンドウはシャットダウンできず、リカバリープロセス中に KRA を停止できません。
- エージェントスキームに応じて、指定された数のエージェントがこの鍵のリカバリーを承認する必要があります。エージェントに、リカバリーキーを検索してもらい、開始された回復を承認してもらいます。
- すべてのエージェントがリカバリーを承認すると、次の画面は、証明書で PKCS #12 ファイルを暗号化するようにパスワードを要求します。
- 次の画面は、復元されたキーペアを含む PKCS #12 ブロブをダウンロードするリンクを返します。リンクに従い、blob をファイルに保存します。重要
gcr-viewer
ユーティリティーでブラウザーから直接 PKCS #12 ファイルを開くと、特定の状況で失敗する可能性があります。この問題を回避するには、gcr-viewer
ファイルをダウンロードし、手動で開きます。
- ブラウザーのデータベースに鍵を復元します。ブラウザーおよびメールクライアントに .p12 ファイルをインポートします。
- テストメールを開きます。メッセージは再度表示されます。
第5章 証明書の要求、登録、および管理
5.1. 証明書の登録および更新について
- 証明書要求 (CSR) が生成されます。
- 証明書要求が CA に送信されます。
- 要求は、要求したエンティティーを認証し、それを提出するために使用された証明書プロファイルのルールを満たしていることを要求が確認することで検証されます。
- リクエストが承認されている。
- 要求側は新しい証明書を取得します。
5.2. 証明書署名リクエストの作成
- コマンドラインユーティリティーを使用した CSR の生成
- 補助ブラウザー内での CSR の生成
- サーバーのインストーラーなど、アプリケーション内での CSR の生成
- コマンドラインユーティリティー
- サーバー側の鍵生成
5.2.1. コマンドラインユーティリティーを使用した 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 を作成する方法を示しています。
- 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。
$ cd /user_or_entity_database_directory/
- バイナリー 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 ページを参照してください。 - 作成したバイナリー形式の CSR を PEM 形式に変換します。
$ BtoA /user_or_entity_database_directory/request-bin.csr /user_or_entity_database_directory/request.csr
- 必要に応じて、CSR ファイルが正しいことを確認します。
$ cat /user_or_entity_database_directory/request.csr MIICbTCCAVUCAQAwKDEQMA4GA1UEChMHRXhhbXBsZTEUMBIGA1UEAxMLZXhhbXBs ...
これは、PKCS#10 PEM 証明書要求です。
5.2.1.1.2. certutil
を使用したユーザー定義拡張による CSR の作成
certutil
ユーティリティーを使用してユーザー定義の拡張で CSR を作成する方法を示しています。
- 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。
$ cd /user_or_entity_database_directory/
- ユーザー定義の 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 ページを参照してください。 - 必要に応じて、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 を作成する方法を説明します。
- 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。
$ cd /user_or_entity_database_directory/
- 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 ページを参照してください。 - 必要に応じて、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 認証方法にのみ使用します。
- 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。
$ cd /user_or_entity_database_directory/
- 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 ページを参照してください。 - 必要に応じて、CSR ファイルが正しいことを確認します。
$ cat /user_or_entity_database_directory/example.csr -----BEGIN CERTIFICATE REQUEST----- MIICzzCCAbcCAQAwgYkx ... -----END CERTIFICATE REQUEST-----
5.2.1.3. CRMFPopClient
を使用した CSR の作成
CRMFPopClient
ユーティリティーを使用して CSR を作成する方法を説明します。
CRMFPopClient
の詳細な使用方法は、CRMFPopClient(1) の man ページを参照してください。
5.2.1.3.1. CRMFPopClient
を使用したキー Archival を持つ CSR の作成
CRMFPopClient
ユーティリティーを使用して RSA キーペアと、鍵アーカイブオプションで CSR を作成する方法を説明します。
- 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。
$ cd /user_or_entity_database_directory/
- 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
- KRA トランスポート証明書をエクスポートします。
$ pki ca-cert-show 0x7 --output kra.transport
- 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 ページを参照してください。 - 必要に応じて、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 認証方法にのみ使用します。
- 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。
$ cd /user_or_entity_database_directory/
- 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
- KRA トランスポート証明書をエクスポートします。
$ pki ca-cert-show 0x7 --output kra.transport
- 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 コマンドの出力を参照してください。 - 必要に応じて、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 要求の両方を生成できます。
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
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
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
5.2.2. サーバー側の鍵生成を使用した CSR の生成
CRMFPopClient
(CR MFPopClient--help を参照) または pki
(pki client-cert-request --help を参照) などの CLI を回避策として使用することができます。
5.2.2.1. 主な機能
- 証明書要求キーは KRA で生成されます (注: CA と連携するには、KRA をインストールする必要があります)。
- プロファイルのデフォルトプラグイン
serverKeygenUserKeyDefaultImpl
は、キーアーカイブ (つまり enableArchival パラメーター) を有効または無効にするための選択を提供します。 - RSA 鍵と EC 鍵の両方のサポート
- 手動 (エージェント) 承認と自動承認 (ディレクトリーパスワードベースなど) の両方のサポート
5.2.2.2. Server-Side Keygen を使用した証明書の登録
サーバー側の鍵の生成を使用した手動ユーザーのデュアル使用証明書登録
図5.1 エージェントの手動による承認を必要とするサーバー側のキータイプの登録
サーバー側の鍵生成を使用したディレクトリー認証ユーザーのデュアル使用証明書の登録
図5.2 LDAP の uid/pwd 認証が正常に実行されると自動的に承認される サーバー側のキータイプの登録
- 手動承認の場合、PKCS#12 ファイルは要求を承認する CA エージェントに返されます。その後、エージェントは PKCS#12 ファイルをユーザーに転送することが期待されます。
- 自動承認の場合、PKCS#12 ファイルはリクエストを送信したユーザーに返されます。
図5.3 エージェントによる手動による登録
pkcs12util
インポートするなどの CLI を使用できます。たとえば、ユーザーの Firefox nss データベースです。
5.2.2.3. キーリカバリー
5.2.2.4. 追加情報
5.2.2.4.1. KRA 要求レコード
- 要求タイプ asymkeyGenRequest の 1 つこの要求タイプは、KRA エージェントページの List Requests を使用してフィルターすることはできません。Show All Requests を選択して、一覧を表示できます。
- 要求タイプの リカバリー の場合
5.2.2.4.2. 監査レコード
- SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST
- SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST
- SERVER_SIDE_KEYGEN_ENROLL_KEYGEN_REQUEST_PROCESSED
- SERVER_SIDE_KEYGEN_ENROLL_KEY_RETRIEVAL_REQUEST_PROCESSED (まだ実装されていません)
5.3. 証明書を登録する Internet Explorer の設定
5.3.1. キー制限および Internet Explorer について
アルゴリズム | プロバイダー | サポート対象のキーサイズ |
---|---|---|
ECC | Microsoft Software Key Storage Provider |
|
ECC | Microsoft Smart Card Key Storage Provider |
|
RSA | Microsoft Base Cryptographic Provider |
|
RSA | Microsoft Strong Cryptographic Provider |
|
RSA | Enhanced Cryptographic Provider |
|
RSA | Microsoft Software Key Storage Provider |
|
5.3.2. Internet Explorer の設定
- Internet Explorer を開きます。
- TLS 1.2 の選択を解除します。→ → → を開き、
- CA 証明書チェーンをインポートします。
- CA のセキュアでない終了サービスページを開きます。以下に例を示します。
http://server.example.com:8080/ca/ee/ca
- Retrieval タブをクリックします。
- 左側のメニューで Import CA Certificate Chain をクリックし、Download the CA certificate chain in binary form を選択します。
- プロンプトが表示されたら、CA 証明書チェーンファイルを保存します。
- Internet Explorer メニューでをクリックし、 を選択します。
- Content タブを開き、Certificates ボタンをクリックします。
- インポートボタン をクリックします。インポートウィンドウで、インポートした証明書チェーンを参照し、選択します。インポートプロセスは、CA 証明書チェーンに使用する証明書ストアを要求します。Automatically select the certificate store based on the type of certificate を選択します。
- 証明書チェーンをインポートしたら、Trusted Root Certificate Authorities タブを開いて、証明書チェーンが正常にインポートされたことを確認します。
- Internet Explorer を設定して、スクリプトに安全でない DOM 制御を使用できるように要求します。これが許可されておらず、エンドエンティティーが証明書を標準 (非 SSL) エンドエンティティーページに登録しようとすると、Internet Explorer はこれらのページをブロックします。
- Internet Explorer メニューでをクリックし、 を選択します。
- セキュリティー タブを開き、カスタムレベル をクリックします。
- ActiveX Controls and Plugins 領域で、Initialize and script ActiveX controls not marked as safe 設定の値を、Prompt に変更します。
- 証明書チェーンをインポートした後、Internet Explorer はセキュアなサービスページにアクセスできます。セキュアなサイトを開きます。以下に例を示します。
https://server.example.com:8443/ca/ee/ca
- エンドサービスページを開く際に、セキュリティー例外が発生する可能性があります。CA サービスサイトを Internet Explorer の Trusted Sites 一覧に追加します。
- Internet Explorer メニューでをクリックし、 を選択します。
- Security タブを開き、Sites をクリックして CA サイトを信頼できる一覧に追加します。
- CA サービスページに対する Security level for this zone スライダーを、Medium-High に設定します。このセキュリティー設定が今後制限すぎる場合は、それを Medium にリセットしてください。
- Compatibility View 設定を有効にします。→ を開いて、特定のサイトをリストに追加して
- ブラウザーを閉じます。
5.4. 証明書の要求および受信
5.4.1. End-Entities ページでの証明書の要求および受信
- 証明書要求のタイプ。これは PKCS#10 または CRMF です。サブシステム管理コンソールを介して作成された証明書要求は PKCS#10 です。certutil ツールを通じて作成されたものやその他のユーティリティーは通常 PKCS #10 です。
- 証明書要求。-----BEGIN NEW CERTIFICATE REQUEST----- および -----END NEW CERTIFICATE REQUEST----- マーカー行を含む base-64 でエンコードされた BLOB を貼り付けます。
- Requester Name。これは、証明書を要求するユーザーの共通名です。
- Requester Email。これは、要求側のメールアドレスです。エージェントまたは CA システムは、このアドレスを使用して、証明書を発行する際に要求側に接続します。たとえば、jdoe@someCompany.com です。
- Requester Phone。これは、要求側の連絡先番号です。
- Certificate Manager の end-entities ページを開きます。以下に例を示します。
http
s
://server.example.com:8443/ca/ee/ca
- Retrieval タブをクリックします。
- 証明書要求の送信時に作成された要求 ID 番号を入力し、をクリックします。
- 次のページには、証明書要求のステータスが表示されます。ステータスが complete すると、証明書へのリンクがあります。Issued certificate のリンクをクリックします。
- 新しい証明書情報は、pretty-print 形式、base-64 エンコード形式、および PKCS #7 形式で表示されます。このページでは、以下のアクションを実行できます。
- この証明書をサーバーまたは他のアプリケーションにインストールするには、base-64 でエンコードされた証明書が含まれている Installing This Certificate in a Server セクションまで下にスクロールします。
- base-64 でエンコードされた証明書 (マーカー行 -----BEGIN CERTIFICATE----- および -----END CERTIFICATE----- を含む) をテキストファイルにコピーします。テキストファイルを保存し、これを使用して秘密鍵があるエンティティーのセキュリティーモジュールに証明書のコピーを保存します。「ユーザーの作成」を参照してください。
5.5. 証明書の更新
- 同じキーの更新 は、証明書の元のキー、プロファイル、および要求を受け取り、同じキーを使用して、新しい有効期間と有効期限で新しい証明書を再作成します。これは、以下のいずれかの方法で実行できます。
- 元のプロファイルから元の証明書要求 (CSR) の再送信、または
- certutil などのサポートツールを使用した元のキーで CSR の再生成
- 証明書の キーを再生成 するには、同じ情報を使用して証明書要求を再生成する必要があるため、新しいキーペアが生成されます。その後、CSR は元のプロファイルを介して送信されます。
5.5.1. 同じキーの更新
5.5.1.1. CSR の再利用
- エージェントが承認した方法では、更新する証明書のシリアル番号を送信する必要があります。この方法では、CA エージェントの承認が必要になります。
- ディレクトリーベースの更新では、更新する証明書のシリアル番号を送信する必要があり、CA は現在の証明書ディレクトリーエントリーから情報を取得します。ldap uid/pwd が正常に認証されると、証明書は自動的に承認されます。
- 証明書ベースの更新は、ブラウザーデータベースの証明書を使用して認証し、同じ証明書を再発行します。
5.5.1.1.1. エージェントによる承認またはディレクトリーベースの更新
- 証明書 (またはそのクローン) の CA のエンドエンティティーサービスページを開きます。
http
s
://server.example.com:8443/ca/ee/ca
- 使用する更新フォームの名前をクリックします。
- 更新する証明書のシリアル番号を入力します。これは、10 進数または 16 進数の形式にすることができます。
- 更新ボタンをクリックします。
- リクエストが送信されます。ディレクトリーベースの更新では、更新された証明書が自動的に返されます。それ以外の場合、更新リクエストはエージェントにより承認されます。
5.5.1.1.2. 証明書ベースの更新
- 証明書 (またはそのクローン) の CA のエンドエンティティーサービスページを開きます。
http
s
://server.example.com:8443/ca/ee/ca
- 使用する更新フォームの名前をクリックします。
- 入力フィールドがないため、ボタンをクリックします。
- プロンプトが表示されたら、更新する証明書を選択します。
- 要求が送信され、更新された証明書が自動的に返されます。
5.5.1.2. 同じキーを持つ CSR を生成して更新
certutil
ツールを使用して、キーペアが NSS データベースにある場合に、同じキーで CSR を再生成できます。これは、次の手順で実行できます。
- NSS データベースで、対応するキー ID を検索します。
Certutil -d <nssdb dir> -K
- 特定のキーを使用して CSR を生成します。
Certutil -d <nssdb dir> -R -k <key id> -s <subject DN> -o <CSR output file>
- 既存のニックネームを使用して CSR を生成します。
Certutil -d <nssdb dir> -R -k <nickname> -s <subject DN> -o <CSR output file>
5.5.2. 証明書のキー変更による更新
5.6. CMC を使用した証明書要求の送信
- 『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『CMC の設定』 セクションを参照してください。
- 『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『CMC を使用した登録』 セクション
- CMCRequest(1) の man ページを参照してください。
- CMCResponse(1) の man ページを参照してください。
5.6.1. CMC 登録の使用
.cfg
入力ファイルに指定されるすべての設定が設定されます。
CMCRequest /path/to/file.cfg
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 のテスト
- certutil ツールを使用して証明書要求を作成します。
- PKCS #10 ASCII 出力をテキストファイルにコピーします。
- CMCEnroll ユーティリティーを実行します。たとえば、入力ファイルが
request34.txt
を呼び出すと、エージェント証明書はブラウザーデータベースに保存され、エージェント証明書の証明書の一般名は CertificateManagerAgentsCert で、および証明書データベースのパスワードは secret で、コマンドは次のとおりです。CMCEnroll -d ~jsmith/.mozilla/firefox/1234.jsmith -n "CertificateManagerAgentsCert" -r /export/requests/request34.txt -p secret
このコマンドの出力は、ファイル名に加えられた .out で同じファイル名のファイルに保存されます。 - エンドエンティティーを通じて署名済み証明書を提出します。
- エンドエンティティーを開きます。
http
s
://server.example.com:8443/ca/ee/ca
- 証明書プロファイルのリストから CMC 登録フォームを選択します。
- 出力ファイルの内容をこの形式の Certificate Request テキスト領域に貼り付けます。
- 貼り付けられたコンテンツから -----BEGIN NEW CERTIFICATE REQUEST----- および ----END NEW CERTIFICATE REQUEST----- を削除します。
- 連絡先情報を入力して、フォームに入力します。
- 証明書は即座に処理され、返されます。
- エージェントページを使用して、新しい証明書を検索します。
5.6.2. CMC 登録プロセス
- Certificate Signing Request (CSR) を、以下のいずれかの形式で作成します。
- PKCS #10 形式
- Certificate Request Message Format (CRMF) 形式
これらの形式で CSR を作成する方法は、「証明書署名リクエストの作成」 を参照してください。 - 管理証明書をクライアントの 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
- 以下の内容で、
/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 ページを参照してください。 - CMC 要求を作成します。
$ CMCRequest /home/user_name/cmc-request.cfg
コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルのoutput
パラメーターで指定されたファイルに CMC 要求を保存します。 /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 要求で以前使用された内容と一致させる必要があります。- 要求する証明書のタイプに応じて、前の手順で作成した設定ファイルに次のパラメーターを追加します。
servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=profile_name
CA 署名証明書の場合の例を以下に示します。servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCcaCert
重要エージェントが次のステップで CMC 要求を送信する場合は、このパラメーターで指定したプロファイルはCMCAuth
認証プラグインを使用する必要があります。ユーザーが作成した登録では、プロファイルはCMCUserSignedAuth
プラグインを使用する必要があります。詳細は、「CMC 認証プラグイン」 を参照してください。 - CMC 要求を CA に送信します。
$ HttpClient /home/user_name/cmc-submit.cfg
- 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 登録シナリオ
5.6.3.1. システム証明書およびサーバー証明書の取得
- 登録プロファイル
- エージェントは、「CMC 認証プラグイン」 にリストされている既存の CMC プロファイルのいずれかを使用する必要があります。または、
CMCAuth
認証メカニズムを使用するカスタムプロファイルを作成します。 - CMC 署名証明書
- システム証明書の場合、CA エージェントは CMC 要求を生成して署名する必要があります。そのためには、
CMCRequest
設定ファイルのnickname
パラメーターを CA エージェントのニックネームに設定します。注記CA エージェントは、独自の秘密鍵にアクセスできるようにする必要があります。 HttpClient
TLS Client NicknameHttpClient
の設定ファイル内で 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. ユーザーの初回署名証明書の取得
- エージェントは CMC 要求を署名します。「エージェント証明書を使用した CMC 要求の署名」 を参照してください。
- 証明書の登録は、共有シークレットを使用して認証されます。「共有シークレットを使用した証明書の登録の認証」 を参照してください。
5.6.3.2.1. エージェント証明書を使用した CMC 要求の署名
5.6.3.3. ユーザーの暗号化のみの証明書の取得
- Network Security Services (NSS) データベースまたはユーザーの署名証明書および鍵が含まれるスマートカードに保存されている暗号化トークンを使用します。
- PKCS #10 形式または CRMF 形式で CSR を生成します。注記(キーのアーカイブが必要な場合は) CRMF 形式を使用してください。
- CMC 要求を生成します。これは暗号のみの証明書であるため、秘密鍵は署名できません。そのため、Proof Of Possession (POP) は含まれていません。このため、登録には、2 つの手順が必要です。最初のリクエストが成功すると、
EncryptedPOP
制御のある CMC 状態が生じます。次に、ユーザーは応答を使用して、DecryptedPOP
制御を含む CMC 要求を生成し、2 番目のステップで送信します。- 最初のステップでは、デフォルトのパラメーターに加えて、ユーザーは、
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
- 次のステップでは、デフォルトのパラメーターに加えて、ユーザーは、
CMCRequest
ユーティリティーに渡される設定ファイルに次のパラメーターを設定する必要があります。decryptedPop.enable
encryptedPopResponseFile
decryptedPopRequestFile
request.privKeyId
詳細は、CMCRequest(1) の man ページを参照してください。
5.6.3.3.1. キーアーカイブを使用した暗号化のみの証明書の取得例
-q POP_NONE
の代わりに -q POP_SUCCESS
オプションを、単一トリップ発行のために CRMFPopClient
ユーティリティーに渡します。
CRMFPoPClient
を使用する方法は、「CRMFPopClient
を使用したキー Archival を持つ CSR の作成」 および 「CRMFPopClient
を使用した SharedSecret ベースの CMC の CSR の作成」 を参照してください。
- KRA トランスポート証明書を検索します。以下に例を示します。
$ pki cert-find --name KRA_transport_certificate_subject_CN
- 前の手順で取得した KRA トランスポート証明書のシリアル番号を使用して、証明書をファイルに保存します。たとえば、
/home/user_name/kra.cert
ファイルに 12345 シリアル番号がある証明書を保存するには、次のコマンドを実行します。$ pki cert-show 12345 --output /home/user_name/kra.cert
CRMFPopClient
ユーティリティーを使用して以下を行います。- キーアーカイブを使用して CSR を作成します。
- 証明書が要求されるユーザーまたはエンティティーの証明書データベースディレクトリーに移動します。以下に例を示します。
$ cd /home/user_name/
- 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
パラメーターの値として、後のステップで必要になります。
- 以下の内容を含む、
/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
- CMC 要求を作成します。
$ CMCRequest /home/user_name/cmc.cfg
コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルのoutput
パラメーターで指定されたファイルに CMC 要求を保存します。 /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
- CMC 要求を CA に送信します。
$ HttpClient /home/user_name/cmc-submit.cfg
コマンドが成功すると、HTTPClient ユーティリティーは、CMC 応答を、設定ファイルのoutput
パラメーターで指定されたファイルに保存します。 - 応答ファイルを
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
- 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
DecryptPOP
CMC 要求を作成します。$ CMCRequest /home/user_name/cmc.DecryptedPOP.cfg
コマンドが成功すると、CMCRequest ユーティリティーは、要求設定ファイルのdecryptedPopRequestFile
パラメーターで指定されたファイルに CMC 要求を保存します。/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
DecryptedPOP
CMC 要求を CA に送信します。$ HttpClient /home/user_name/decrypted_POP_cmc-submit.cfg
コマンドが成功すると、HTTPClient ユーティリティーは、CMC 応答を、設定ファイルのoutput
パラメーターで指定されたファイルに保存します。- 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. 一括発行の実行
- このプロセスはスクリプト化されているため、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
注記ローカルシステムには、エージェントの証明書を持つ有効なセキュリティーデータベースが必要です。データベースを設定するには、以下を行います。- ブラウザーからエージェントユーザー証明書および鍵をエクスポートまたはダウンロードし、
agent.p12
などのファイルに保存します。 - 必要に応じて、セキュリティーデータベース用の新しいディレクトリーを作成します。
mkdir ${d}
- 必要な場合は、新規セキュリティーデータベースを作成します。
certutil -N -d ${d}
- Certificate System インスタンスを停止します。
systemctl stop pki-tomcatd@instance_name.service
- pk12util を使用して証明書をインポートします。
# pk12util -i /tmp/agent.p12 -d ${d} -W p12filepassword
手順に成功すると、コマンドは以下の出力を出力します。pk12util: PKCS12 IMPORT SUCCESSFUL
- Certificate System インスタンスを起動します。
systemctl start pki-tomcatd@instance_name.service
- 2 つの追加の変数を設定する必要があります。要求の処理に使用される CA プロファイルを識別する変数、およびプロファイルフォームの情報を提供するための post ステートメントの送信に使用される変数。
export post="cert_request_type=pkcs10&xmlOutput=true&profileId=caAgentServerCert&cert_request=" export url="/ca/ee/ca/profileSubmitSSLClient"
注記この例では、証明書要求を caAgentServerCert プロファイルに送信します (ただし、post ステートメントの profileId 要素で識別されます)。カスタムプロファイルを含む任意の証明書プロファイルを使用できます。 - 変数設定をテストします。
echo ${d} ${p} ${f} ${nick} ${cahost} ${caport} ${post} ${url}
- (この例では) 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}
- CA のステータスとトランザクションログを確認します。
/etc/init.d/pki-ca status tail -f /var/log/pki-ca/transactions&
- 手順 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 ルーターでの証明書の登録
5.8.1. SCEP 登録の有効化
- 設定ファイルを編集できるように CA サーバーを停止します。
systemctl stop pki-tomcatd@instance_name.service
- CA の
CS.cfg
ファイルを開きます。vim
/var/lib/pki/instance_name/ca/conf/CS.cfg
ca.scep.enable
を true に設定します。パラメーターが存在しない場合は、パラメーターで行を追加します。ca.scep.enable=true
- CA サーバーを起動します。
systemctl start pki-tomcatd@instance_name.service
5.8.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 バイトです。 |
- 設定ファイルを編集できるように CA サーバーを停止します。
systemctl stop pki-tomcatd@instance_name.service
- CA の
CS.cfg
ファイルを開きます。vim
/var/lib/pki/instance_name/ca/conf/CS.cfg
- 表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
- CA サーバーを起動します。
systemctl start pki-tomcatd@instance_name.service
5.8.3. SCEP 登録のルーターの設定
- ルーターは、IP アドレス、DNS サーバー、およびルーティング情報で設定する必要があります。
- ルーターの日付/時刻が正しく設定されている必要があります。
- ルーターのホスト名と dnsname を設定する必要があります。
5.8.4. ルーターの SCEP 証明書の生成
- ランダムな PIN を選択します。
- ルーターが 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 アドレスになります。フラットファイルの認証の使用は、「フラットファイル認証の設定」 に記載されています。 - ルーターのコンソールにログインします。以下の例では、ルーターの名前は scep です。
scep>
- 特権コマンドを有効にします。
scep> enable
- 設定モードを入力します。
scep# conf t
- 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
- 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
- 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
- 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]
- 最後に、ルーターに証明書を生成します。
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
- 設定モードを閉じます。
scep(config)# exit
- ルーターが適切に登録されたことを確認するには、ルーターに保存されている証明書の一覧を表示します。
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 の使用
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
scep(ca-root)# crl optional
5.8.6. ルーターの再登録
- 既存のキーを削除 (ゼロ化)。
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
- 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. デバッグの有効化
scep# debug crypto pki callbacks
Crypto PKI callbacks debugging is onscep# debug crypto pki messages
Crypto PKI Msg debugging is onscep# debug crypto pki transactions
Crypto PKI Trans debugging is onscep#debug crypto verbose
verbose debug output debugging is on
5.8.8. SCEP で ECC 証明書を発行
- 暗号化/複号証明書 - 暗号化機能/複号機能を持つ RSA 証明書 (以下の例では scepRSAcert) を指定します。
- 署名証明書 - 自己署名ではなく、クライアント側で使用する RSA 証明書を取得します (以下の例では signingCert 証明書)。
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
6.1. TPS プロファイル
CS.cfg
で定義されます。
op.<explicit op>.<profile id>.<implicit op>.<key type>.*
op.enroll.userKey.keyGen.encryption.*
6.2. TPS 操作
明示的な操作
明示的な操作 はユーザーが呼び出す操作です。明示的な操作には、entroll
(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
が含まれます。
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
理由 | コード |
---|---|
指定なし | 0 |
keyCompromise | 1 |
CACompromise | 2 |
affiliationChanged | 3 |
superseded | 4 |
cessationOfOperation | 5 |
certificateHold | 6 |
removeFromCRL | 8 |
privilegeWithdrawn | 9 |
AACompromise | 10 |
6.3. トークンポリシー
;
"") で区切られたポリシーの集合体です。各ポリシーは、キーワード 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
設定は、ロックアップする前に指定された回数の再試行のみを許可するようにトークンを設定します。
<POLICYNAME>=YES
または <POLICYNAME>=NO
に設定する必要があります。
6.4. トークン操作およびポリシー処理
- 形式
- (ユーザーが開始した) 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
は、次の例に示すように、TKSCS.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. 内部登録
op.enroll.userKey.auth.enable=true op.enroll.userKey.auth.id=ldap1
op.enroll.userKey.keyGen.encryption.ca.conn=ca1 op.enroll.userKey.keyGen.encryption.serverKeygen.drm.conn=kra1
op.enroll.userKey.tks.conn=tks1
6.6. 外部登録
6.6.1. 外部登録の有効化
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
6.6.3. certsToAdd 属性の設定
certsToAdd
属性は、以下の形式で複数の値を取ります。
<cert serial # in decimal>,<CA connector ID>,<key ID>,<kra connector ID>
59,ca1,0,kra1
certsToAdd
属性を指定する場合、TPS は問題の証明書がトークン上にあり、保存する必要があることを仮定します。この概念は キー保持 と呼ばれます。
tokenType: externalRegAddToToken certstoadd: 59,ca1,0,kra1 certstoadd: 134,ca1,0,kra1 Certstoadd: 24,ca1
6.6.4. ユーザーマッチングの実施に対するトークン
tokencuid
) がレコードにない場合は、CUID 一致は強制されません。
Tokencuid: a10192030405028001c0
certstoadd: 59,ca1
,0,kra1
6.6.5. 委譲サポート
- 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
$auth.<attribute name>$
の形式で証明書の Subject Alternative Name (SAN) または 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
- 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$
上記の例では、OID1.3.6.1.4.1.311.20.2.3
は User Principal Name (UPN) の OID で、request.req_san_pattern_0
は、delegateIEtoken
SAN パターンで指定された最初の SAN パターンになります。
,
") で区切った SANpattern
で指定します。CA 側では、対応する subjAltExtPattern
の数を以下の形式で定義する必要があります。
policyset.<policy set id>.<policy id>.default.params.subjAltExtPattern_<ordered number>=
policyset.set1.p6.default.params.subjAltExtPattern_0= policyset.set1.p6.default.params.subjAltExtPattern_1= ...
例6.1 SANpattern および DNpattern の設定
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
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
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 の設定
FilterMappingResolver
と呼ばれます。本セクションでは、その設定について説明します。
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
0
のマッピングに失敗します。また、アプレットバージョンが一致すると ATR がマッピングされないため、1
マッピングも失敗します。上記のトークンはマッピング 2
とそのターゲット jForte
に割り当てられます。
2
には、そのフィルターへの割り当てがないことに留意してください。これにより、マッピングがすべてのトークンと照合され、実質的にデフォルトの値になります。このようなマッピングは、マッピング順序の最後に指定する必要があります。これ以降、他のマッピングは評価されないためです。
6.7.2. Token Type (TPS) Mapping Resolver
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
enrollProfileMappingResolver
で定義されます。マッピングの名前は 0
、1
、および 2
です。mappingResolver.enrollProfileMappingResolver.mapping.order=1,0,2
行は、マッピングを処理する順序を定義します。トークンがマッピングと一致する場合、その順序でそれ以上のマッピングは評価されません。マッピングと一致しない場合は、順序の次のマッピングが試行されます。
CUID=a0000000000000000011 appletMajorVersion=1 appletMinorVersion=0 extension: tokenType=soKey
tokenType
は一致するため、この設定を持つトークンはマッピング 1
用のフィルターに一致します。そのため、このトークンには、そのマッピングのターゲットが割り当てられます (soKey
)。
CUID=b0000000000000000010 appletMajorVersion=1 appletMinorVersion=1
1
トークンのマッピングに失敗します。0
エクステンションがないため、tokenType
へのマッピングも失敗します。以前のフィルターのいずれにも一致しないすべてのトークンに一致するフィルターが指定されていないため、このトークンはマッピング 2
に一致します。
6.8. 認証設定
UidPwdDirAuthentication
) を使用したディレクトリーベースの認証をサポートします。認証インスタンスは、以下のパターンを使用して CS.cfg
ファイルで定義されます。
auths.instance.<auths ID>.*
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
UidPwdDirAuthentication
認証インスタンスと同様に設定されます。これは、いずれも同じプラグインで処理されるためです。ただし、TPS では、CA 設定に加えて追加のパラメーターが必要になります。
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 に渡される方法を設定します。これらのフィールドでは、カスタマイズされたプラグインの実装を使用でき、カスタム認証プラグインを使用しない限り、デフォルト値のままにする必要があります。
6.9. コネクター
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
op.enroll.userKey.keyGen.signing.ca.conn=ca1
6.10. 失効ルーティングの設定
tps.connCAList=ca1,ca2
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>
tps.connector.ca1.caNickname=caSigningCert cert-pki-tomcat CA
tps.connector.ca1.caSKI=i9wOnN0QZLkzkndAB1MKMcjbRP8=
6.11. サーバー側の鍵生成の設定
- 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
6.12. 新しい鍵セットの設定
- 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. 新しいマスターキーの設定
手順6.1 新規マスターキーの作成
- TKS セキュリティーデータベースへのアクセスに必要な PIN の内部を取得します。
#
cat /var/lib/pki/pki-tomcat/tks/conf/password.conf internal=649713464822 internaldb=secret12 replicationdb=-752230707 - TKS インスタンスの
alias/
ディレクトリーを開きます。#
cd /var/lib/pki/pki-tomcat/alias - 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 - 鍵がデータベースに正しく追加されていることを確認します。
#
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)
手順6.2 ラップされたマスターキーの生成および転送
- Token Key Service セキュリティーデータベースへのアクセスに必要な内部 PIN を取得します。
#
cat /var/lib/pki/pki-tomcat/tks/conf/password.conf internal=649713464822 internaldb=secret12 replicationdb=-752230707 - TKS インスタンスの
alias/
ディレクトリーを開きます。#
cd /var/lib/pki/pki-tomcat/alias transport
という名前のトランスポートキーを作成します。#
tkstool -T -d . -n transport注記tkstool ユーティリティーは、生成された 3 つのセッションキーごとにキー共有と KCV 値を出力します。この手順の後半で新しいデータベースにトランスポートキーを再生成する必要がある場合に、それらをファイルに保存し、失われた場合はキーを再生成します。- プロンプトが表示されたら、データベースのパスワードを入力します。次に、画面の指示に従って、ランダムなシードを生成します。
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
- 次のプロンプトにより、一連のセッションキーが生成されます。最終メッセージになるまで、画面の指示に従ってください。
Successfully generated, stored, and named the transport key!
- トランスポートキーを使用してマスターキーを生成してラップし、これを
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) - ラップされたマスターキーを適切な場所またはファシリティーにコピーします。
- 必要な場合は、HSM またはファシリティーで新しいセキュリティーデータベースを生成します。
#
tkstool -N -d <directory>新たなデータベースで生成した鍵と同じ鍵を生成する-l
オプションを追加します。この方法でトランスポートキーを再生成するには、この手順で前のステップで生成した各セッションキーに対してセッションキー共有と KCV を入力する必要があります。#
tkstool -I -d <directory> -n verify_transport - トランスポートキーを使用して、ファイルに保存されているマスターキーをアンラップします。要求されたら、セキュリティーデータベースの 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! - 鍵がデータベースに追加されたことを確認します。
#
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.15. 異なる SCP バージョンでの異なるアプレットの使用
/var/lib/instance_name/tps/conf/CS.cfg
ファイルの以下のパラメーターで、各トークン操作に対してすべての Secure Channel Protocol (SCP) バージョンに読み込むアプレットを指定します。
op.operation.token_type.update.applet.requiredVersion=version
op.operation.token_type.update.applet.requiredVersion.prot.protocol_version=version
- format
- enroll
- pinReset
例6.3 登録操作用のプロトコルバージョンの設定
userKey
トークンの登録操作を実行するときに、SCP03 に特定のアプレットを設定し、他のすべてのプロトコルに別のアプレットを設定するには、以下を行います。
/var/lib/instance_name/tps/conf/CS.cfg
ファイルを編集します。- デフォルトで使用されるアプレットを指定するには、
op.enroll.userKey.update.applet.requiredVersion
パラメーターを設定します。以下に例を示します。op.enroll.userKey.update.applet.requiredVersion=1.4.58768072
op.enroll.userKey.update.applet.requiredVersion.prot.3
パラメーターを設定して、アプレットの Certificate System が SCP03 プロトコルに使用するように設定します。以下に例を示します。op.enroll.userKey.update.applet.requiredVersion.prot.3=1.5.558cdcff
- Certificate System を再起動します。
systemctl restart pki-tomcatd@instance_name.service
第7章 証明書の取り消しおよび CRL 発行
7.1. 証明書の失効について
- 失効要求が CA によって受け取られ、承認されている場合は、証明書を取り消します。
- 失効した証明書のステータスを、その有効性ステータスを確認する必要のある関係者またはアプリケーションが利用できるようにします。
7.1.1. ユーザーが開始した失効
7.1.2. 証明書の失効理由
- 0.不特定 (特に理由はありません)。
- 1.証明書に関連する秘密鍵が侵害されました。
- 2.証明書を発行した CA に関連付けられた秘密鍵が危険にさらされました。
- 3.証明書の所有者は、証明書の発行者とは関係がなくなり、その証明書で取得したアクセス権を失ったか、証明書を必要としなくなりました。
- 4.別の証明書がこれに置き換わります。
- 5.証明書を発行した CA は、操作する予定です。
- 6.証明書は、さらなるアクションが行われるまで保留されています。これは取り消されたものとして処理されますが、証明書がアクティブで再度有効になるように、将来保持されないことがあります。
- 8.証明書は保留から削除されたため、CRL から 削除 されます。これはデルタ CRL でのみ有効です。
- 9.証明書の所有者の権限が撤回されているため、証明書は取り消されます。
7.1.3. CRL 発行ポイント
7.1.4. Delta CRL
7.1.5. CRL の公開
7.1.6. 証明書失効ページ
UserRevocation.html
(SSL/TSL クライアント認証によるクライアントまたは個人証明書の失効を許可するフォーム) を編集します。ファイルは /var/lib/instance_name/webapps/subsystem_type/ee/subsystem_type
ディレクトリーにあります。
7.2. CMC 失効の実行
subjectDN
属性を使用するエージェント証明書またはユーザー証明書のいずれかを使用して失効要求に署名できます。これにより、ユーザーは署名済み要求を Certificate Manager に送信できます。
CMCRequest
詳細は、「CMCRequest
を使用した証明書の取り消し」 を参照してください。CMCRevoke
詳細は、「CMCRevoke
を使用した証明書の取り消し」 を参照してください。
CMCRequest
ユーティリティーを使用して、失効要求の生成を推奨します。これは、CMCRevoke
よりも多くのオプションを提供するためです。
7.2.1. CMCRequest
を使用した証明書の取り消し
CMCRequest
を使用して証明書を取り消すには、以下を実行します。
- 以下の内容で、
/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
- CMC 要求を作成します。
# CMCRequest /home/user_name/cmc-request.cfg
コマンドが成功すると、CMCRequest
ユーティリティーは、要求設定ファイルのoutput
パラメーターで指定されたファイルに CMC 要求を保存します。 /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
パラメーターも入力します。- 要求に署名したユーザーに応じて、
HttpClient
の設定ファイルのservlet
パラメーターを適切に設定する必要があります。- エージェントが要求に署名した場合は、以下を設定します。
servlet=/ca/ee/ca/profileSubmitCMCFull
- ユーザーが要求に署名した場合は、以下を設定します。
servlet=/ca/ee/ca/profileSubmitSelfSignedCMCFull
- CMC 要求を送信します。
# HttpClient /home/user_name/cmc-submit.cfg
CMCRequest
を使用して証明書の取り消しの詳細は、CMCRequest(1) man ページを参照してください。
7.2.2. CMCRevoke
を使用した証明書の取り消し
- 0: 指定無し
- 1: キーが侵害されました。
- 2: CA キーが侵害されました。
- 3: 従業員の所属が変更になりました
- 4: 証明書が置き換えられました
- 5: 運用停止
- 6: 証明書が保留中です
7.2.2.1. CMCRevoke のテスト
- 既存の証明書の 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
となります。 - エンドエンティティーを開きます。
http
s
://server.example.com:8443/ca/ee/ca
- Revocation タブを選択します。
- メニューの CMC Revoke リンクを選択します。
- CMCRevoke からテキストエリアに出力を貼り付けます。
- 貼り付けられたコンテンツから -----BEGIN NEW CERTIFICATE REQUEST----- および ----END NEW CERTIFICATE REQUEST----- を削除します。
- 返されるページは、正しい証明書が取り消されていることを確認します。
7.3. CRL の実行
- Certificate Manager は、その CA 署名証明書キーを使用して CRL に署名します。CRL に個別の署名キーペアを使用するには、CRL 署名キーを設定し、このキーを使用して CRL に署名するように Certificate Manager の設定を変更します。詳細は、「異なる証明書を使用するように CA を設定して CRL を署名」を参照してください。
- CRL 発行ポイントの設定発行ポイントは、マスター CRL に対してすでにセットアップされ、有効にされています。
図7.1 デフォルトの CRL 発行ポイント
CRL の追加の発行ポイントを作成できます。詳細は、「発行ポイントの設定」を参照してください。発行ポイントを設定して CRL のリストを定義するときに設定したオプションに応じて、発行ポイントが作成できる CRL には 5 つのタイプがあります。- マスター CRL には、CA 全体から失効した証明書の一覧が含まれます。
- ARL は、失効した CA 証明書のみが含まれる Authority Revocation List です。
- 期限切れの証明書を持つ CRL には、CRL で有効期限が切れた証明書が含まれます。
- 証明書プロファイルの CRL は、最初に証明書を作成するために使用されるプロファイルに基づいて、失効した証明書を判別します。
- 理由コードによる CRL は、失効した理由コードに基づいて、失効した証明書を判別します。
- 各発行ポイントに CRL を設定します。詳細は、「各発行ポイントの CRL の設定」を参照してください。
- 発行ポイントに設定された CRL 拡張機能を設定します。詳細は、「CRL 拡張機能の設定」 を参照してください。
- 発行ポイントの拡張を有効にすることにより、発行ポイントにデルタ CRL を設定するか、または発行ポイント DeltaCRLIndicator または CRLNumber の拡張を有効にします。
- 発行先に関する情報が含まれるように CRLDistributionPoint 拡張機能を設定します。
- ファイル、LDAP ディレクトリー、または OCSP レスポンダーへの公開 CRL を設定します。公開の設定の詳細は、8章証明書および CRL の公開 を参照してください。
7.3.1. 発行ポイントの設定
- 証明書システムコンソールの起動
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、左側のナビゲーションメニューから Certificate Manager を展開します。次に、CRL Issuing Points を選択します。
- 発行ポイントを編集するには、発行ポイントを選択して、をクリックします。編集できるパラメーターは、発行ポイントの名前と、発行ポイントが有効か無効かだけです。発行ポイントを追加するには、をクリックします。CRL Issuing Point エディターウインドウが開きます。
図7.2 CRL Issuing Point エディター
注記一部のフィールドがコンテンツを読み取るのに十分な大きさで表示されない場合は、コーナーの 1 つをドラッグしてウィンドウを拡大します。以下のフィールドに入力します。- Enable。選択した場合は発行ポイントを有効にします。無効にする場合は選択を解除します。
- CRL Issuing Point name。発行ポイントの名前を指定します。スペースは使用できません。
- Description。発行ポイントを説明します。
7.3.2. 各発行ポイントの CRL の設定
- CA コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- ナビゲーションツリーで、Certificate Manager を選択し、CRL Issuing Points を選択します。
- Issuing Points エントリーの下に、発行ポイント名を選択します。
- 発行ポイントの Update タブに情報を指定して、CRL の更新方法および頻度を設定します。このタブには、Update Schema および Update Frequency の 2 つのセクションがあります。
- Update Schema セクションには以下のオプションが含まれます。
- CRL 生成を有効にします。このチェックボックスは、発行ポイントに 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 をフラットファイルに発行したかどうかのテストなど、すぐに失効をテストするために選択する必要があります。
- 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
ボックスに番号を入力する必要があります。 - Cache タブは、キャッシュが有効であるかどうかとキャッシュ頻度を設定します。
図7.3 CRL キャッシュタブ
- Enable CRL cache。このチェックボックスは、デルタ CRL の作成に使用されるキャッシュを有効にします。キャッシュが無効になっている場合は、デルタ CRL は作成されません。キャッシュの詳細は、「証明書の失効について」 を参照してください。
- キャッシュを毎回更新 します。このフィールドは、キャッシュが内部データベースに書き込む頻度を設定します。証明書が取り消されるたびに、キャッシュをデータベースに書き出すには、0 に設定します。
- キャッシュリカバリーを有効 にします。このチェックボックスを選択すると、キャッシュを復元できます。
- Enable CRL cache testing。このチェックボックスは、特定の CRL 発行ポイントの CRL パフォーマンステストを有効にします。このオプションで生成された CRL は、デプロイした CA では使用しないでください。テスト目的で発行された CRL には、パフォーマンステストのみを目的として生成されたデータが含まれているためです。
- フォーマット タブでは、作成される CRL のフォーマットおよびコンテンツを設定します。CRL Format および CRL Contents の 2 つのセクションがあります。
図7.4 CRL 形式タブ
- CRL Format セクションには、以下の 2 つのオプションがあります。
- Revocation list signing algorithm は、CRL 暗号化を行うために許可された暗号のドロップダウンの一覧です。
- Allow extensions for CRL v2 するには、発行ポイントに CRL v2 拡張を有効にするチェックボックスがあります。これが有効な場合は、「CRL 拡張機能の設定」 で説明されている必要な CRL 拡張機能を設定します。
注記CRL を作成するには、拡張機能を有効にする必要があります。 - CRL Contents セクションには、CRL に追加する証明書のタイプを設定する 3 つのチェックボックスがあります。
- 期限切れの証明書 を含めます。これには、期限切れになった証明書が含まれます。これを有効にすると、失効した証明書に関する情報は、証明書の期限が切れた後も CRL に残ります。これが有効になっていないと、証明書の有効期限が切れると、失効した証明書に関する情報が削除されます。
- CA 証明書のみこれには、CRL の CA 証明書のみが含まれます。このオプションを選択すると、失効した CA 証明書のみを一覧表示する Authority Revocation List (ARL) が作成されます。
- プロファイルに従って発行された証明書。これには、リストされたプロファイルに従って発行された証明書のみが含まれます。複数のプロファイルを指定するには、コンマ区切りのリストを入力します。
- この発行ポイントでは、拡張機能は可能で、設定できます。詳細は、「CRL 拡張機能の設定」 を参照してください。
7.3.3. CRL 拡張機能の設定
- CA コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- ナビゲーションツリーで、Certificate Manager を選択し、CRL Issuing Points を選択します。
- Issuing Points エントリーの下にある発行ポイント名を選択し、発行ポイントの下にある CRL 拡張 エントリーを選択します。右側のペインには、設定された拡張機能を一覧表示する CRL Extensions Management タブが表示されます。
図7.5 CRL 拡張機能
- ルールを変更するには、ルールを選択し、をクリックします。
- ほとんどの拡張には 2 つのオプションがあり、有効にして、重要なかどうかを設定します。詳細情報が必要なものもあります。必要な値をすべて指定します。各拡張機能およびそれらの拡張機能のパラメーターに関する詳細は、??? を参照してください。
7.3.4. 異なる証明書を使用するように CA を設定して CRL を署名
CS.cfg
ファイルを編集してこの機能を設定する方法は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『異なる証明書を使用するように CA を設定して CRL を署名』 セクションを参照してください。
7.3.5. キャッシュからの CRL の生成
enableCRLCache
パラメーターが有効になります。ただし、実稼働環境ではこの Enable CRL cache testing
パラメーターを有効に しないでください。
7.3.5.1. コンソールでのキャッシュからの CRL 生成の設定
- コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、Certificate Manager フォルダーと CRL Issuing Points サブディレクトリーを展開します。
- MasterCRL ノードを選択します。
- Enable CRL cache を選択します。
- 変更を保存します。
7.3.5.2. CS.cfg のキャッシュからの CRL 生成の設定
CS.cfg
ファイルを編集してこの機能を設定する方法は、『Red Hat Certificate System の計画、インストール、およびデプロイメントのガイド』 の 『CS.cfg のキャッシュからの CRL 生成の設定』 セクションを参照してください。
7.4. Full および Delta CRL スケジュールの設定
Interval 1, 2, 3, 4, 5, 6, 7 ... Full CRL 1 4 7 ... Delta CRL 1, 2, 3, 4, 5, 6, 7 ...
7.4.1. コンソールでの CRL 更新間隔の設定
- コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、Certificate Manager フォルダーと CRL Issuing Points サブディレクトリーを展開します。
- MasterCRL ノードを選択します。
- Generate full CRL every # delta(s) フィールドに、必要な間隔を入力します。
- 証明書失効の機会、周期的な間隔、または更新が発生する時間を設定することにより、更新頻度を設定します。
- 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 などの必要な間隔を入力します。
- 変更を保存します。
7.4.2. CS.cfg での CRL の更新間隔の設定
CS.cfg
ファイルを編集してこの機能を設定する方法は、『Red Hat Certificate System の計画、インストール、およびデプロイメントのガイド』 の 『CS.cfg での CRL の更新間隔の設定』 セクションを参照してください。
7.4.3. 複数の日における CRL 生成スケジュールの設定
ca.crl.MasterCRL.dailyUpdates=01:00,03:00,18:00;02:00,05:00,17:00
ca.crl.MasterCRL.dailyUpdates=01:00,03:00,18:00,*23:00;02:00,05:00,21:00,*23:30
CS.cfg
ファイルを手動で編集する時に機能します。
7.5. 失効チェックの有効化
7.6. OCSP (Online Certificate Status Protocol) レスポンダーの使用
7.6.1. OCSP レスポンダーの設定
- OCSP レスポンダーに公開されるすべての CA に CRL を設定します。
- OCSP サービスが処理するすべての CA で、公開を有効にし、パブリッシャーを設定し、公開ルールを設定します (8章証明書および CRL の公開)。Certificate Manager が LDAP ディレクトリーに公開され、Online Certificated Status Manager がそのディレクトリーから読み込むように設定している場合は、これは必要ありません。
- 証明書プロファイルは、Certificate Manager が OCSP サービス要求をリッスンする場所を指す Authority Information Access 拡張機能を含むように設定する必要があります (「証明書マネージャーの内部 OCSP サービスの有効化」)。
- OCSP Responder を設定します。
- 失効情報ストア (「失効情報ストアの設定: 内部データベース」 および 「失効情報ストアの設定: LDAP ディレクトリー」) を設定します。
- OCSP レスポンダー (「OCSP レスポンダーへの CA の特定」) へのすべての公開証明書マネージャーを特定します。
- 必要に応じて、OCSP 署名証明書 (「CA 証明書の信頼設定の変更」) に署名した CA に信頼を設定します。
- 設定後に両方のサブシステムを再起動します。
- CA が OCSP レスポンダーに適切に接続されていることを確認します (「証明書マネージャーおよびオンライン証明書ステータスマネージャーの接続の確認」)。
7.6.2. OCSP レスポンダーへの CA の特定
- Certificate Manager の base-64 CA 署名証明書は、CA のエンドエンティティーページから取得します。
- オンライン証明書ステータスマネージャーエージェントページを開きます。URL の形式は https://hostname:SSLport/ocsp/agent/ocsp です。
- 左側のフレームで、をクリックします。
- フォームで、エンコードされた CA 署名証明書を Base 64 encoded certificate (including the header and footer) というラベルの付いたテキスト領域内に貼り付けます。
- 証明書が正常に追加されたことを確認するには、左側のフレームで List Certificate Authorities をクリックします。
7.6.2.1. 証明書マネージャーおよびオンライン証明書ステータスマネージャーの接続の確認
7.6.2.2. 失効情報ストアの設定: 内部データベース
- オンライン証明書ステータスマネージャーコンソールを開きます。
pkiconsole https://server.example.com:8443/ocsp
- Configuration タブで Online Certificate Status Manager を選択し、Revocation Info Stores を選択します。右側のペインには、Online Certificate Status Manager が使用できる 2 つのリポジトリーが表示されます。デフォルトでは、内部データベースで CRL を使用します。
- defStore を選択して をクリックします。
- 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 ディレクトリー
ldapStore
メソッドが有効になっていると、OCSP ユーザーインターフェイスは証明書のステータスを確認しません。
- オンライン証明書ステータスマネージャーコンソールを開きます。
pkiconsole https://server.example.com:8443/ocsp
- Configuration タブで Online Certificate Status Manager を選択し、Revocation Info Stores を選択します。右側のペインには、Online Certificate Status Manager が使用できる 2 つのリポジトリーが表示されます。デフォルトでは、内部データベースで CRL を使用します。
- LDAP ディレクトリーで CRL を使用するには、ldapStore オプションを有効にします。をクリックして
- ldapStore を選択して をクリックします。
- 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 サービス設定のテスト
- ブラウザーまたはクライアントで失効チェックをオンにします。
- OCSP サービス用に有効になっている CA から証明書を要求します。
- 要求を承認します。
- ブラウザーまたはクライアントに証明書をダウンロードします。
- CA がブラウザーまたはクライアントで信頼されていることを確認します。
- Certificate Manager の内部 OCSP サービスのステータスを確認します。CA エージェントサービスページを開き、OCSP サービス のリンクを選択します。
- 独立した Online Certificate Status Manager サブシステムをテストします。Online Certificate Status Manager エージェントサービスページを開き、List Certificate Authorities リンクをクリックします。このページには、CRL を Online Certificate Status Manager に公開するための設定された Certificate Manager に関する情報が表示されます。このページには、最後に起動した時点の Online Certificate Status Manager のアクティビティーも要約されています。
- 証明書を取り消します。
- ブラウザーまたはクライアントで証明書を確認します。サーバーは、証明書が取り消されたことを返す必要があります。
- Certificate Manager の OCSP サービスステータスを再度チェックして、次のことが発生したことを確認します。
- ブラウザーは OCSP クエリーを Certificate Manager に送信します。
- Certificate Manager は OCSP の応答をブラウザーに送信します。
- ブラウザーはその応答を使用して証明書を検証し、証明書を検証できなかったというステータスを返しました。
- 独立した OCSP サービスサブシステムを再度チェックし、これらの問題が発生することを確認します。
- 証明書マネージャーは、CRL を Online Certificate Status Manager に公開します。
- ブラウザーは OCSP 応答を Online Certificate Status Manager に送信します。
- Online Certificate Status Manager は OCSP の応答をブラウザーに送ります。
- ブラウザーはその応答を使用して証明書を検証し、証明書を検証できなかったというステータスを返しました。
7.6.3. 問題のあるシリアル番号のレスポンスの設定
notFoundAsGood
パラメーターは、OCSP が無効なシリアル番号で証明書を処理する方法を設定します。このパラメーターはデフォルトで有効になっています。つまり、証明書が不正なシリアル番号で存在する場合は、証明書が有効であれば、OCSP が証明書の GOOD のステータスを返します。
notFoundAsGood
設定を変更します。この場合、OCSP は、間違ったシリアル番号を持つ証明書とともに UNKNOWN ステータスを返します。クライアントはエラーとして解釈し、それに応じて応答できます。
- オンライン証明書ステータスマネージャーコンソールを開きます。
pkiconsole https://server.example.com:8443/ocsp
- Configuration タブで Online Certificate Status Manager を選択し、Revocation Info Stores を選択します。
- defStore を選択して をクリックします。
notFoundAsGood
値を編集します。このチェックボックスを選択すると、証明書のシリアル番号が不正な場合でも OCSP が GOOD の値を返します。チェックボックスの選択を解除すると、OCSP は、UNKNOWN の値を送信します。クライアントはこれをエラーとして解釈できます。- OCSP Manager を再起動します。
]# systemctl restart pki-tomcatd@instance-name.service
7.6.4. 証明書マネージャーの内部 OCSP サービスの有効化
- CA のエンドエンティティーに移動します。以下に例を示します。
http
s
://server.example.com:8443/ca/ee/ca
- CA 署名証明書を探します。
- 証明書で Authority Info Access 拡張を探し、http
s
://server.example.com:8443
/ca/ocsp などの Location URIName 値をメモします。 - 登録プロファイルを更新して、Authority Information Access 拡張を有効にし、Location パラメーターを Certificate Manager の URI に設定します。証明書プロファイルの編集に関する詳細は、「証明書プロファイルの設定」 を参照してください。
- CA インスタンスを再起動します。
]# systemctl restart pki-tomcatd@instance-name.service
CS.cfg
ファイルを編集し、ca.ocsp パラメーターの値を false に変更します。
ca.ocsp=false
7.6.5. 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
オプション | 説明 |
---|---|
-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 リクエストの送信
- クエリーされるステータスで、証明書の OCSP 要求を生成します。以下に例を示します。
]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64 MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
- Web ブラウザーのアドレスバーに URL を貼り付けて、ステータス情報を返します。ブラウザーが OCSP 要求を処理できるようにする必要があります。
https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
- OCSP Manager は、ブラウザーが解釈できる証明書のステータスを返します。設定可能なステータスは GOOD、REVOKED、および UNKNOWN です。
- クエリーされるステータスで、証明書の OCSP 要求を生成します。以下に例を示します。
]# openssl ocsp -CAfile ca.pem -issuer issuer.pem -serial serial_number -reqout - | base64 MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE=
- curl を使用して、OCSP 要求を送信するために OCSP Manager に接続します。
curl https://server.example.com:8443/ocsp/ee/ocsp/MEIwQDA+MDwwOjAJBgUrDgMCGgUABBT4cyABkyiCIhU4JpmIBewdDnn8ZgQUbyBZ44kgy35o7xW5BMzM8FTvyTwCAQE= > ocspresp.der
- openssl を使用して応答を解析します。
openssl ocsp -respin ocspresp.der -resp_text
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 に転送します。
- OCSP レスポンダーを停止します。
]# systemctl stop pki-tomcatd@instance-name.service
- OCSP のエンドユーザー Web アプリケーションディレクトリーに移動します。以下に例を示します。
]# cd /var/lib/pki-ocsp/webapps/ocsp
- OCSP の Web アプリケーションディレクトリーの
ROOT/WEB-INF/
ディレクトリーにあるROOT
ディレクトリーに移動します。以下に例を示します。]# cd /var/lib/pki-ocsp/webapps/ocsp/ROOT/WEB-INF/
- OCSP の Web アプリケーションディレクトリーの
ROOT
ディレクトリーにlib/
ディレクトリーを作成して開きます。]# mkdir lib ]# cd lib/
/usr/share/java/pki/cms.jar
JAR ファイルへリンクするシンボリックリンクを作成します。以下に例を示します。]# ln -s /usr/share/java/pki/cms.jar cms.jar
- メインの Web アプリケーションディレクトリーに移動します。以下に例を示します。
]# cd /var/lib/pki-ocsp/webapps/ocsp/
- 現行インスタンス (
ocsp
) ディレクトリーの名前を変更します。以下に例を示します。]# mv /var/lib/pki-ocsp/webapps/ocsp/ocsp /var/lib/pki-ocsp/webapps/ocsp/ocsp2
- 元の
ocsp/
ディレクトリーのWEB-INF/
ディレクトリーに移動します。以下に例を示します。]# cd /var/lib/pki-ocsp/webapps/ocsp/ocsp/WEB-INF
- 元の
ocsp/WEB-INF/
ディレクトリーで、web.xml
ファイルを編集し、eeocspAddCRL
とcsadmin-wizard
サーブレットの間に行マッピングを追加します。<servlet-mapping> <servlet-name> ocspOCSP </servlet-name> <url-pattern> /ee/ocsp/* </url-pattern> </servlet-mapping>
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>
/var/lib/pki-ocsp/conf/context.xml
ファイルを編集して、以下の行を追加します。<Context> to <Context crossContext="true" >
/var/lib/pki-ocsp/webapps/ocsp/ocsp2/services.template
ファイルを編集し、以下の行を変更します。result.recordSet[i].uri); to result.recordSet[i].uri + "/");
- OCSP インスタンスを起動します。
]# systemctl restart pki-tomcatd@instance-name.service
パート III. CA サービスを管理するための追加設定
第8章 証明書および CRL の公開
- ファイル、LDAP ディレクトリー、または OCSP レスポンダーへの公開を設定します。使用する場所の数に応じて、単一のパブリッシャーまたは複数のパブリッシャーが存在する可能性があります。場所は、証明書と CRL、または証明書の種類などのより細かい定義によって分割できます。ルールは、発行者に関連付けられることにより、発行するタイプと場所を決定します。
- ルールを設定して、どの証明書がその場所に公開されるかを決定します。証明書または CRL が一致するすべてのルールがアクティブ化されるため、ファイルベースのルールとディレクトリーベースのルールを一致させることにより、同じ証明書をファイルと LDAP ディレクトリーに公開できます。ルールは、各オブジェクトタイプ (CA 証明書、CRL、ユーザー証明書、およびクロスペアの証明書) に設定できます。使用されていないルールをすべて無効にします。
- CRL を設定します。CRL は公開前に設定する必要があります。7章証明書の取り消しおよび CRL 発行 を参照してください。
- パブリッシャー、マッパー、およびルールの設定後に公開を有効にします。公開が有効になると、サーバーはすぐに公開を開始します。パブリッシャー、マッパー、およびルールが完全に設定されていない場合は、パブリッシュが正しく機能しない可能性があります。
8.1. 公開の概要
/etc/CS/certificates
のファイルに公開する発行者がある場合、証明書はファイルとしてその場所に公開されます。別のルールが、ユーザーに発行されたすべての証明書に一致し、そのルールに LDAP 属性 userCertificate;binary 属性に公開するパブリッシャーがある場合、証明書は、ユーザーのエントリーのこの属性で LDAP 公開が有効になったときに指定されたディレクトリーに発行されます。
8.1.1. パブリッシャー
8.1.2. マッパー
8.1.3. ルール
8.1.4. ファイルへの公開
- サーバーの問題の各証明書について、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 公開
8.1.6. LDAP 公開
- サーバーが発行する証明書ごとに、ユーザーのエントリーの指定された属性に DER エンコード形式の証明書を含むブロブが作成されます。証明書は DER でエンコードされたバイナリーブロブとして公開されます。
- サーバーが CRL を生成するたびに、CA のエントリーの指定された属性で、DER でエンコードされた形式で新しい CRL を含むブロブを作成します。
8.2. ファイルへの公開設定
- Certificate Manager コンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択し、Publishers を選択します。設定されたパブリッシャーインスタンスを一覧表示する Publishers Management タブが右側で開きます。
- Select Publisher Plug-in Implementation ウィンドウを開きます。これには、登録済みのパブリッシャーモジュールを一覧表します。をクリックして、
- FileBasedPublisher モジュールを選択して、エディターウィンドウを開きます。これは、Certificate Manager が証明書をファイルに公開し、CRL をファイルに公開できるようにするモジュールです。
- 証明書を公開するための情報を設定します。
- PublishCertsToFile などの空白のない英数字の発行側の ID
- Certificate Manager がファイルを公開する必要のあるディレクトリーへのパス。パスは絶対パスを指定でき、Certificate System インスタンスのディレクトリーに相対することもできます。たとえば、
/export/CS/certificates
です。 - DER でエンコードされたファイル、base-64 でエンコードされたファイル、またはその両方のチェックボックスを選択して公開するファイルタイプ。
- CRL の場合は、タイムスタンプの形式です。公開される証明書にはファイル名にシリアル番号が含まれ、CRL はタイムスタンプを使用します。
- CRL の場合、最新の CRL に移動するためにファイルにリンクを生成するかどうか。有効にすると、リンクは、拡張機能で使用する CRL 発行ポイントの名前が crlLinkExt フィールドに指定されると想定します。
- CRL の場合、CRL を圧縮 (zip) するかどうか、および使用する圧縮レベル。
8.3. OCSP への公開設定
8.3.1. クライアント認証を使用した OCSP への公開の有効化
- Certificate Manager コンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択し、Publishers を選択します。
- Select Publisher Plug-in Implementation ウィンドウを開きます。これには、登録済みのパブリッシャーモジュールを一覧表します。をクリックして、
- 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 サブシステム証明書です。
- OCSP Manager で CA のユーザーエントリーを作成します。ユーザーは、新しい CRL を送信するときに OCSP への認証に使用されます。必要なものは 2 つあります。
- CA-hostname-EEport などの CA サーバーの後に OCSP ユーザーエントリーに名前を付けます。
- パブリッシャー設定で指定された証明書を、OCSP ユーザーアカウントのユーザー証明書として使用します。通常、これは CA のサブシステム証明書です。
サブシステムユーザーの設定については、「ユーザーの作成」 で説明されています。
8.4. LDAP ディレクトリーへの公開設定
- 公開される証明書の Directory Server を設定します。特定の属性をエントリーに追加し、ID をバインドし、認証方法を設定する必要があります。
- 公開された各オブジェクトのパブリッシャーを設定します (CA 証明書、クロスペア証明書、CRL、およびユーザー証明書)。パブリッシャーは、オブジェクトを格納する属性を宣言します。デフォルトで設定される属性は、各オブジェクトタイプを保存する X.500 標準属性です。この属性はパブリッシャーで変更できますが、通常は LDAP パブリッシャーを変更する必要はありません。
- エントリーの DN が証明書のサブジェクト名から派生できるようにマッパーを設定します。通常、CA 証明書、CRL、およびユーザー証明書にを設定する必要はありません。証明書タイプに複数のマッパーを設定できます。これは、たとえば、ディレクトリーツリーの異なる部分にある会社の異なる部門の 2 組のユーザーの証明書を公開する場合に役立ちます。グループごとにマッパーが作成され、ツリーの異なるブランチを指定します。マッパーの設定に関する詳細は、「マッパーの作成」 を参照してください。
- 「ルールの作成」 で説明されているように、パブリッシャーをマッパーに接続するルールを作成します。
- 「公開の有効化」 の説明に従って、パブリッシュを有効にします。
8.4.1. LDAP ディレクトリーの設定
- 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 のドキュメントを参照してください。 - CA およびユーザーディレクトリーエントリーに正しいスキーマ要素を追加します。
オブジェクトタイプ スキーマ 理由 エンドエンティティー証明書 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 です。 - 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 のドキュメントを参照してください。
- Certificate Manager が Directory Server に対して認証する方法のディレクトリー認証方法を設定します。Basic 認証 (簡易ユーザー名およびパスワード)、クライアント認証なしの SSL、およびクライアント認証を使用する SSL (証明書ベース) の 3 つのオプションがあります。サーバーとの通信方法の設定は、Red Hat Directory Server のドキュメントを参照してください。
8.4.2. LDAP パブリッシャーの設定
パブリッシャー | 説明 |
---|---|
LdapCaCertPublisher | CA 証明書を LDAP ディレクトリーに公開します。 |
LdapCrlPublisher | CRL を LDAP ディレクトリーに公開します。 |
LdapDeltaCrlPublisher | デルタ CRL を LDAP ディレクトリーに公開します。 |
LdapUserCertPublisher | すべての種類のエンドエンティティー証明書を LDAP ディレクトリーに公開します。 |
LdapCrossCertPairPublisher | 相互署名付き証明書を LDAP ディレクトリーに公開します。 |
8.4.3. マッパーの作成
マッパー | 説明 |
---|---|
LdapUserCertMap | ユーザー証明書を公開するために、ディレクトリーでユーザーエントリーの正しい属性を見つけます。 |
LdapCrlMap | CRL を公開するために、ディレクトリーで CA のエントリーの正しい属性を見つけます。 |
LdapCaCertMap | CA 証明書を公開するために、ディレクトリーで CA のエントリーの正しい属性を見つけます。 |
- Certificate Manager コンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択し、Mappers を選択します。設定されたマッパーを一覧表示する Mappers Management タブが右側で開きます。
- 新しいマッパーインスタンスを作成するには、Select Mapper Plugin Implementation ウィンドウが開き、登録されたマッパーモジュールが一覧表示されます。モジュールを選択し、そのモジュールを編集します。これらのモジュールに関する詳細は、「マッパープラグインモジュール 」 を参照してください。をクリックします。
- マッパーインスタンスを編集し、をクリックします。各マッパーに関する詳細は、「マッパープラグインモジュール 」 を参照してください。
8.4.4. 設定の完了: ルールおよび有効化
8.5. ルールの作成
- Certificate Manager コンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択し、Rules を選択します。設定したルールを一覧表示する Rules Management タブが右側で開きます。
- 既存のルールを編集するには、一覧からそのルールを選択して、Rule Editor ウィンドウが開きます。をクリックします。これにより、
- ルールを作成するには、Select Rule Plug-in Implementation ウィンドウが開きます。をクリックします。これにより、Rule モジュールを選択します。これは唯一のデフォルトモジュールです。カスタムモジュールが登録されている場合は、それらも利用できます。
- ルールを編集します。
- type。これは、ルールが適用される証明書のタイプです。CA 署名証明書の場合、値は cacert です。自己署名証明書の場合、値は xcert です。その他すべてのタイプの証明書の場合、値は certs です。CRL には crl を指定します。
- predicate。これにより、このルールが適用される証明書または CRL 発行ポイントのタイプに述語の値を設定します。CRL 発行ポイント、デルタ CRL、および証明書の述語値の一覧は 表8.3「述語式」 に表示されます。
- enable。
- mapper。ファイルに公開する場合、マッパーは必要ありません。LDAP 公開にのみ必要です。このルールが LDAP ディレクトリーに公開されるパブリッシャーに関連付けられている場合は、ここに適切なマッパーを選択します。他のすべての形式の発行では空白のままにします。
- publisher。ルールに関連付けるパブリッシャーを設定します。
述語タイプ | 述語 |
---|---|
CRL 発行ポイント |
issuingPointId==Issuing_Point_Instance_ID && isDeltaCRL==[true|false]
マスター CRL のみを公開するには、isDeltaCRl==false を設定します。デルタ CRL のみを公開するには、isDeltaCRL==true を設定します。両方を公開するには、マスター CRL のルールとデルタ CRL の別のルールを設定します。
|
証明書プロファイル |
profileId==profile_name
使用するプロファイルに基づいて証明書を公開するには、profileId== を caServerCert などのプロファイル名に設定します。
|
8.6. 公開の有効化
- Certificate Manager コンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択します。右側のペインには、LDAP 準拠のディレクトリーに公開するための詳細情報が表示されます。
- ファイルの公開のみを有効にするには、Enable Publishing を選択します。
- 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
ファイルで設定されます。 - クライアント証明書。これにより、SSL クライアント認証に Certificate Manager が使用する証明書がパブリッシュディレクトリーに設定されます。デフォルトでは、証明書マネージャーは SSL サーバー証明書を使用します。
- LDAP バージョン。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 クライアント認証に使用する必要のある証明書を識別します。
8.7. 公開キューの有効化
図8.1 公開キューの有効化
CS.cfg
ファイルを編集してパブリッシュキューを有効にすると、管理者はパブリッシュ操作に使用するスレッドの数やキューページサイズなど、パブリッシュする他のオプションを設定できます。
CS.cfg
ファイルを編集してこの機能を設定する方法は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『公開キューの有効化』 セクションを参照してください。
8.8. 再開可能な CRL ダウンロードの設定
8.8.1. wget を使用した CRL の取得
[root@server ~]# wget --no-check-certificate -d https://server.example.com:8443/ca/ee/ca/crl/MasterCRL.bin
引数 | 説明 |
---|---|
引数なし | 完全な CRL を取得します。 |
-N | ローカルコピー (delta CRL) よりも新しい CRL を取得します。 |
-c | 部分的にダウンロードしたファイルを取得します。 |
--no-check-certificate | 接続の SSL を省略するため、ホストとクライアント間で SSL を設定する必要はありません。 |
-d | デバッグ情報を出力します。 |
8.9. ペア間の証明書の公開
- CA コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、左側のペインの Certificate Manager リンクを選択してから、Publishing リンクを選択します。
- Publishing の Rules リンクをクリックし ます。これにより、右側に Rules Management ペインが開きます。
- ルールが存在し、無効になっている場合は、enable チェックボックスを選択します。ルールが削除された場合は、 クリックして新しいルールを作成します。
- type ドロップダウンメニューから xcerts を選択します。
- 有効 のチェックボックスが選択されていることを確認してください。
- mapper ドロップダウンメニューから、LdapCaCertMap を選択します。
- publisher ドロップダウンメニューから LdapCrossCertPairPublisher を選択します。
8.10. ファイルへの公開テスト
- CA のエンドエンティティーを開き、証明書をリクエストします。
- 必要に応じて、エージェントサービスページを使用してリクエストを承認します。
- エンドエンティティーページから証明書を取得し、証明書をブラウザーにダウンロードします。
- サーバーが、証明書を含む DER でエンコードされたファイルを生成したかどうかを確認します。証明書のバイナリーブロブが公開されることになっているディレクトリーを開きます。証明書ファイルの名前は
cert-
serial_number.der
にする必要があります。 - Binary to ASCII ツールを使用して、DER でエンコードされた証明書をベース 64 でエンコードされた形式に変換します。このツールの詳細は、
BtoA(1)
man ページを参照してください。BtoA input_file output_file
input_file は、DER でエンコードされた証明書が含まれるファイルへのパスを設定し、output_file は、base-64 でエンコードされた証明書を書き込むようにファイルへのパスを設定します。 - ASCII ファイルを開きます。base-64 でエンコードされた証明書は以下のように表示されます。
-----BEGIN CERTIFICATE----- MMIIBtgYJYIZIAYb4QgIFoIIBpzCCAZ8wggGbMIIBRaADAgEAAgEBMA0GCSqGSIb3DQEBBAUAMFcxC AJBgNVBAYTAlVTMSwwKgYDVQQKEyNOZXRzY2FwZSBDb21tdW5pY2F0aWhfyyuougjgjjgmkgjkgmjg fjfgjjjgfyjfyj9ucyBDb3Jwb3JhdGlvbjpMEaMBgGA1UECxMRSXNzdWluZyhgdfhbfdpffjphotoo gdhkBBdXRob3JpdHkwHhcNOTYxMTA4MDkwNzM0WhcNOTgxMTA4MDkwNzMM0WjBXMQswCQYDVQQGEwJ VUzEsMCoGA1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yY2F0aW9ucyBDb3Jwb3Jhd GlvbjpMEaMBgGA1UECxMRSXNzdWluZyBBdXRob3JpdHkwHh -----END CERTIFICATE-----
- Pretty Print Certificate ツールを使用して、ベース 64 でエンコードされた証明書を読み取り可能なフォームに変換します。このツールの詳細は、
PrettyPrintCert(1)
man ページを参照してください。PrettyPrintCert input_file [output_file]
input_file は base-64 でエンコードされた証明書が含まれる ASCII ファイルへのパスを設定し、任意で output_file に証明書を書き込むファイルにパスを設定できます。出力ファイルが設定されていない場合、証明書情報は標準出力に書き込まれます。 - 出力と、発行された証明書を比較します。証明書のシリアル番号と、ファイル名で使用されている証明書と比較します。すべてが一致する場合、Certificate Manager は証明書をファイルに公開するように正しく設定されています。
- 証明書を取り消します。
- サーバーが、CRL を含む DER でエンコードされたファイルを生成したかどうかを確認します。サーバーが CRL をバイナリーブロブとして公開するディレクトリーを開きます。CRL ファイルの名前は crl-this_update.der であるはずです。this_update は、CRL の時間依存の This Update 変数から派生した値を指定します。
- Binary to ASCII ツールを使用して、DER でエンコードされた CRL をベース 64 でエンコードされた形式に変換します。
BtoA input_file output_file
- Pretty Print CRL ツールを使用して、base 64 でエンコードされた CRL を読み取り可能なフォームに変換します。
PrettyPrintCrl input_file [output_file]
- 出力を比較します。
8.11. ファイルに公開される証明書および CRL の表示
- base-64 ファイルをバイナリーに変換します。以下に例を示します。
AtoB /tmp/example.b64 /tmp/example.bin
- PrettyPrintCert または PrettyPrintCrl ツールを使用して、バイナリーファイルを pretty-print 形式に変換します。以下に例を示します。
PrettyPrintCert example.bin example.cert
PrettyPrintCrl example.der example.crl
8.12. ディレクトリーの証明書および CRL の更新
- 内部データベースで同期していない証明書を検索し、公開または非公開にします。
- Directory Server のダウン中に発行された証明書を公開します。同様に、Directory Server の停止時に取り消された、または有効期限が切れた証明書も使用できます。
- シリアル番号 xx からシリアル番号 yy までのシリアル番号に基づいて、一連の証明書を公開または非公開にします。
8.12.1. ディレクトリーでの証明書の手動による更新
- 証明書でディレクトリーを更新します。
- 期限切れの証明書をディレクトリーから削除します。自動化されたジョブをスケジュールすることにより、公開ディレクトリーからの期限切れの証明書の削除を自動化できます。詳細は、12章自動ジョブの設定 を参照してください。
- ディレクトリーから失効した証明書を削除します。
- Certificate Manager エージェントサービスページを開きます。
- Update Directory Server のリンクを選択します。
- 適切なオプションを選択し、をクリックします。Certificate Manager は、内部データベースの証明書情報でディレクトリーの更新を開始します。大幅に変更した場合は、ディレクトリーの更新にかなりの時間がかかる可能性があります。この期間中、発行された証明書や取り消された証明書など、Certificate Manager を介して行われた変更は、更新に含まれない場合があります。ディレクトリーの更新中に証明書が発行または取り消された場合は、それらの変更を反映するようにディレクトリーを再度更新してください。
- predicate パラメーターの値を profileId!=caCACert に変更して、ユーザー証明書のデフォルト公開ルールを変更します。
- LdapCaCertPublisher プラグインモジュールを使用して別のルールを追加し、predicate パラメーターを profileId=caCACert に設定して CA 証明書を公開します。
8.12.2. ディレクトリーでの CRL の手動による更新
- Certificate Manager エージェントサービスページを開きます。
- Update Revocation List を選択します。
8.13. カスタムマッパーの登録およびプラグインモジュールの公開
- カスタムジョブクラスを作成します。この例では、カスタムパブリッシャープラグインは
MyPublisher.java
になります。 - 新しいクラスをコンパイルします。
javac -d . -classpath $CLASSPATH MyPublisher.java
- CA がカスタムクラスにアクセスできるように、CA の
WEB-INF
Web ディレクトリーにディレクトリーを作成します。mkdir /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes
- 新しいプラグインファイルを新しい
class
ディレクトリーにコピーし、所有者を Certificate System system user (pkiuser
) に設定します。cp -pr com /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes chown -R pkiuser:pkiuser /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes
- プラグインを登録します。
- Certificate Manager コンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、左側のナビゲーションツリーから Certificate Manager を選択します。Publishing を選択します。
- マッパーモジュールを登録するには、Mappers を選択し、Mapper Plugin Registration タブを選択します。パブリッシャーモジュールを登録するには、Publishers を選択し、Publisher Plug-in Registration タブを選択します。
- プラグインを登録するには、をクリックします。
- プラグイン名とプラグインクラス名を設定します。クラス名 (実装された Java クラスへのパス)このクラスがパッケージに含まれる場合は、パッケージ名を含めます。たとえば、com.customplugins という名前のパッケージに customMapper という名前のクラスを登録するには、名前は com.customplugins.customMapper になります。
第9章 証明書を登録するための認証
- エージェントの承認 登録では、承認のためにエンドエンティティーがエージェントに送信されます。エージェントは証明書要求を承認します。
- 自動 登録では、エンドエンティティー要求はプラグインを使用して認証され、証明書要求が処理されます。エージェントは登録プロセスに関与していません。
- CMC 登録 では、サードパーティーのアプリケーションが、エージェントによって署名されてから自動的に処理される要求を作成できます。
9.1. エージェント承認登録の設定
.cfg
ファイルに認証方法を空白のままにしておきます。以下に例を示します。
auth.instance_id=
9.2. 自動登録
- ディレクトリーベースの登録エンドエンティティーは、ユーザー ID とパスワード、またはその DN とパスワードを使用して LDAP ディレクトリーに対して認証されます。「ディレクトリーベースの認証の設定」を参照してください。
- PIN ベースの登録。エンドエンティティーは、ディレクトリーエントリーのユーザー ID、パスワード、および PIN セットを使用して LDAP ディレクトリーに対して認証されます。「PIN ベースの登録の設定」を参照してください。
- 証明書ベースの認証の使用。ある種のエンティティー (エンドユーザーとサーバーやトークンなどの他のエンティティーの両方) は、CA によって発行された ID を証明する証明書を使用して CA に対して認証されます。これは、更新プロセスの認証に元の証明書が提示される、更新に最も一般的に使用されます。「証明書ベースの認証の使用」を参照してください。
- AgentCertAuth.このメソッドは、リクエストを送信したエンティティーがサブシステムエージェントとして認証される場合に証明書要求を自動的に承認します。ユーザーは、エージェント証明書を提示してエージェントとして認証します。提示された証明書がサブシステムでエージェント証明書として認識される場合、CA は証明書要求を自動的に処理します。この形式の自動認証は、サーバー証明書を登録する証明書プロファイルに関連付けることができます。このプラグインはデフォルトで有効になっており、パラメーターはありません。
- フラットファイルベースの登録。ルーター (SCEP) の登録専用に使用されるテキストファイルには、IP アドレス、ホスト名、またはその他の識別子のリストと、通常はランダムな PIN であるパスワードが含まれています。ルーターはその ID と PIN を使用して CA に対して認証し、CA は提示する認証情報をテキストファイルの ID の一覧と比較します。「フラットファイル認証の設定」を参照してください。
9.2.1. ディレクトリーベースの認証の設定
- UidPwdDirAuth または UdnPwdDirAuth 認証モジュールのいずれかのインスタンスを作成して、インスタンスを設定します。
- CA コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、ナビゲーションツリーの Authentication を選択します。注記UidPwdDirAuth プラグインはデフォルトで有効です。
- Select Authentication plug-in Implementation ウインドウが表示されます。
- ユーザー ID およびパスワード認証に UidPwdDirAuth を選択するか、DN およびパスワード認証には UdnPwdDirAuth を選択します。
- Authentication Instance Editor ウィンドウで、以下のフィールドに入力します。
- Authentication Instance ID。デフォルトのインスタンス名を許可するか、新しい名前を入力します。
- dnpattern。ディレクトリー属性およびエントリー DN から形成するサブジェクト名パターンを表す文字列を指定します。
- ldapStringAttributes.エンドエンティティーの 認証 として考慮されるべき LDAP 文字列属性の一覧を指定します。これらの属性に対応する値は、認証ディレクトリーから認証トークンにコピーし、証明書プロファイルによりサブジェクト名を生成するために使用されます。このパラメーターの値の入力は任意です。
- ldapByteAttributes.エンドエンティティーの 認証 として考慮されるべき LDAP バイト (バイナリー) 属性の一覧を指定します。指定した場合、これらの属性に対応する値は、ユーザーの証明書への追加情報の追加など、他のモジュールで使用するために認証ディレクトリーから認証トークンにコピーされます。このパラメーターの値の入力は任意です。
- ldap.ldapconn.host.認証ディレクトリーの完全修飾 DNS ホスト名を指定します。
- ldap.ldapconn.port.認証ディレクトリーが要求をリッスンする TCP/IP ポートを指定します。ldap.ldapconn.secureConn. チェックボックスを選択した場合、これは SSL ポート番号になります。
- ldap.ldapconn.secureConn.認証ディレクトリーが Certificate System からの要求をリッスンするポートのタイプ (SSL または非 SSL) を指定します。これが SSL ポートである場合に選択します。
- ldap.ldapconn.version.LDAP プロトコルのバージョンの 2 または 3 を指定します。バージョン 3.x 以降のすべての Directory Server は LDAPv3 であるため、デフォルトは 3 です。
- ldap.basedn.認証ディレクトリーを検索するためにベース DN を指定します。サーバーは、HTTP 入力 (ユーザーが登録フォームに入るもの) とベース DN の uid フィールド値を使用して LDAP 検索フィルターを構築します。
- ldap.minConns.認証ディレクトリーで許可される最小接続数を指定します。許容値は、1 から 3 です。
- ldap.maxConns.認証ディレクトリーで許可される接続の最大数を指定します。許容値は、3 から 10 です。
- 特定の証明書のポリシーを設定して、ユーザーの登録に使用する証明書プロファイルを設定します。証明書プロファイルの入力を設定して登録フォームをカスタマイズします。また、ユーザーを認証するためにプラグインが必要とする情報の入力を含めます。デフォルトの入力に、収集する必要のあるすべての情報が含まれていない場合には、サードパーティーツールで作成した要求を送信します。プロファイルの設定に関する詳細は、「サブジェクト代替名への LDAP ディレクトリー属性値およびその他の情報の挿入」 を参照してください。
バインドされた LDAP 接続の設定
CS.cfg
の以下の例に従って、ディレクトリーベースの認証を設定します。auths.instance.UserDirEnrollment.ldap.ldapBoundConn=true auths.instance.UserDirEnrollment.ldap.ldapauth.authtype=BasicAuth auths.instance.UserDirEnrollment.ldap.ldapauth.bindDN=cn=Directory Manager auths.instance.UserDirEnrollment.ldap.ldapauth.bindPWPrompt=externalLDAP externalLDAP.authPrefix=auths.instance.UserDirEnrollment cms.passwordlist=internaldb,replicationdb,externalLDAP
bindPWPrompt
は、password.conf
ファイルで使用されるタグまたはプロンプトです。また、options passwordlist
オプションおよびauthPrefix
オプション で使用される名前でもあります。CS.cfg
からタグまたはプロンプトをpassword.conf
でパスワードとともに追加します。externalLDAP=your_password
外部承認の設定
CS.cfg
に以下のオプションを設定する必要があります。
groupsEnable
は、グループの取得を可能にするブール値オプションです。デフォルト値はfalse
です。groupsBasedn
はグループのベース DN です。これは、デフォルトbasedn
と異なる場合に指定する必要があります。group
は、グループの DN コンポーネントです。デフォルト値はou=groups
です。groupObjectClass
は、グループオブジェクトクラスgroupofuniquenames
、groupofnames
のいずれかです。デフォルト値はgroupofuniquenames
です。groupUseridName
は、グループオブジェクトメンバー属性のユーザー ID 属性の名前です。デフォルト値は(cn=*)
です。useridName
は、ユーザー ID DN コンポーネントの名前です。デフォルト値はuid
です。searchGroupUserByUserdn
は、userdn
または${groupUserIdName}=${uid}
属性のグループオブジェクトメンバー属性を検索するかどうかを決定するブール値オプションです。デフォルト値はtrue
です。
auths.instance.UserDirEnrollment.pluginName=UidPwdDirAuth auths.instance.UserDirEnrollment.ldap.basedn=cn=users,cn=accounts,dc=local auths.instance.UserDirEnrollment.ldap.groupObjectClass=groupofnames auths.instance.UserDirEnrollment.ldap.groups=cn=groups auths.instance.UserDirEnrollment.ldap.groupsBasedn=cn=accounts,dc=local auths.instance.UserDirEnrollment.ldap.groupsEnable=true auths.instance.UserDirEnrollment.ldap.ldapconn.host=local auths.instance.UserDirEnrollment.ldap.ldapconn.port=636 auths.instance.UserDirEnrollment.ldap.ldapconn.secureConn=true
/instance_path/ca/profiles/ca/profile_id.cfg
ファイルを変更して、CS.cfg
に定義された UserDirEnrollment
認証インスタンスを使用するようにプロファイルを設定し、および必要に応じて、グループに基づく許可用の ACL を提供します。以下に例を示します。
auth.instance_id=UserDirEnrollment auths.acl=group="cn=devlab-access,ou=engineering,dc=example,dc=com"
9.2.2. PIN ベースの登録の設定
- PIN に必要なスキーマを LDAP ディレクトリーに追加します。
- 設定した PIN に読み取り/書き込みパーミッションを持つ PIN マネージャーユーザーを追加します。
- PIN の使用後に PIN の削除を許可するように ACI を設定し、PIN マネージャーに PIN の読み取り/書き込み権限を付与し、PIN を作成または変更できないようにします。
- 各ユーザーエントリーに PIN を作成します。
- PIN ツールを使用して PIN に必要なスキーマを追加し、ユーザーエントリーに PIN を追加してから PIN をユーザーに配布します。
/usr/share/pki/native-tools/
ディレクトリーを開きます。- テキストエディターで
setpin.conf
ファイルを開きます。 - ファイルに概説されている手順に従って、適切な変更を加えます。通常、更新が必要なパラメーターは、Directory Server のホスト名、Directory Manager のバインドパスワード、および PIN マネージャーのパスワードです。
setpin.conf
ファイルをポイントする optfile オプションを指定して、setpin コマンドを実行します。setpin optfile=/usr/share/pki/native-tools/setpin.conf
このツールは、新しい属性 (デフォルトでは pin) および新しいオブジェクトクラス (デフォルトは pinPerson) でスキーマを変更し、pinmanager ユーザーを作成し、ACI を設定して、pinmanager ユーザーのみが pin 属性を編集できるようにします。- 特定のユーザーエントリーの PIN を生成するか、ユーザー定義の PIN を指定する場合は、これらのエントリーの DN を指定して入力ファイルを作成します。たとえば、以下のようになります。
dn:uid=bjensen,ou=people,dc=example,dc=com dn:uid=jsmith,ou=people,dc=example,dc=com dn:jtyler,ou=people,dc=example,dc=com ...
入力ファイルを構築する方法は、『Certificate System コマンドラインツールガイド』の PIN ジェネレーターの章を参照してください。 - setpin コマンドのセットアップモードを無効にします。setup 行をコメントアウトするか、値を no に変更します。
vim /usr/share/pki/native-tools/setpin.conf setup=no
セットアップモードでは、必要なユーザーとオブジェクトクラスが作成されますが、セットアップモードでは、ツールは PIN を生成しません。 - setpin コマンドを実行して、ディレクトリーに PIN を作成します。ヒント実際にディレクトリーを実際には変更せずに PIN のリストを生成する
write
オプションを使用せずに、最初にツールをテスト実行します。以下に例を示します。setpin host=yourhost port=9446 length=11 input=infile output=outfile write "binddn=cn=pinmanager,o=example.com" bindpw="password" basedn=o=example.com "filter=(uid=u*)" hash=sha256
警告hash
引数をnone
に設定しないでください。hash=none
を付けて setpin コマンドを実行すると、ピンはプレーンテキストとしてユーザー LDAP エントリーに保存されます。 - 必要な認証方法の設定が完了したら、出力ファイルを使用して PIN をユーザーに配信します。
- 証明書プロファイルにポリシーを設定して、ユーザーを登録します。証明書プロファイルポリシーの詳細は、3章証明書を発行するルール (証明書プロファイル) の作成 を参照してください。
- UidPwdPinDirAuth 認証プラグインのインスタンスを作成して設定します。
- CA コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、ナビゲーションツリーの Authentication を選択します。
- Select Authentication plug-in Implementation ウインドウが表示されます。
- UidPwdPinDirAuth プラグインモジュールを選択します。
- Authentication Instance Editor ウィンドウで、以下のフィールドに入力します。
- Authentication Instance ID。デフォルトのインスタンス名を使用するか、新しい名前を入力します。
- removePin.エンドユーザーの認証に成功した後に、認証ディレクトリーから PIN を削除するかどうかを設定します。ディレクトリーから PIN を削除すると、ユーザーが複数回登録できなくなるため、複数の証明書を取得できなくなります。
- pinAttr.PIN の認証ディレクトリー属性を指定します。PIN Generator ユーティリティーは、
setpin.conf
ファイルの objectclass パラメーターの値に属性を設定します。このパラメーターのデフォルト値は pin です。 - dnpattern。ディレクトリー属性およびエントリー DN から形成するサブジェクト名パターンを表す文字列を指定します。
- ldapStringAttributes.エンドエンティティーの 認証 として考慮されるべき LDAP 文字列属性の一覧を指定します。このパラメーターの値の入力は任意です。
- ldapByteAttributes.エンドエンティティーの 認証 として考慮されるべき LDAP バイト (バイナリー) 属性の一覧を指定します。指定した場合、これらの属性に対応する値は、ユーザーの証明書への追加情報の追加など、他のモジュールで使用するために認証ディレクトリーから認証トークンにコピーされます。このパラメーターの値の入力は任意です。
- ldap.ldapconn.host.認証ディレクトリーの完全修飾 DNS ホスト名を指定します。
- ldap.ldapconn.port.認証ディレクトリーが Certificate System からのリクエストをリッスンする TCP/IP ポートを指定します。
- ldap.ldapconn.secureConn.認証ディレクトリーが要求をリッスンするポートの、SSL タイプ、SSL、または非 SSL を指定します。これが SSL ポートである場合に選択します。
- ldap.ldapconn.version.LDAP プロトコルのバージョンの 2 または 3 を指定します。デフォルトでは、3.x 以降のすべての Directory Server バージョンが LDAPv3 であるため、これは 3 になります。
- ldap.ldapAuthentication.bindDN.認証ディレクトリーから PIN を削除する際にバインドするユーザーエントリーを指定します。removePin チェックボックスが選択されている場合に限り、このパラメーターを指定します。ディレクトリー内の PIN 属性のみを変更するパーミッションを持つ別のユーザーエントリーを作成して使用することが推奨されます。たとえば、ディレクトリーのコンテンツ全体を変更する権限があるため、Directory Manager のエントリーを使用しないでください。
- password.ldap.ldapauthbindDN パラメーターで指定された DN に関連付けられたパスワードを指定します。変更を保存したら、サーバーはパスワードをシングルサインオンパスワードキャッシュに保存して、後続の起動時に使用します。このパラメーターは、removePin チェックボックスが選択されている場合にのみ設定する必要があります。
- ldap.ldapAuthentication.clientCertNickname.PIN を削除する認証ディレクトリーへの SSL クライアント認証に使用する証明書のニックネームを指定します。証明書が有効で、認証ディレクトリーの証明書データベースで信頼できる CA によって署名されていることを確認し、認証ディレクトリーの
certmap.conf
ファイルがディレクトリーの DN に正しくマッピングするように設定されていることを確認してください。これは PIN の削除のみに必要です。 - ldap.ldapAuthentication.authtype.認証ディレクトリーから PIN を削除するのに必要な認証タイプ、Basic 認証、または SSL クライアント認証を指定します。
- BasicAuth は Basic 認証を指定します。このオプションを使用すると、ldap.ldapAuthentication.bindDN および password パラメーターの正しい値を入力します。サーバーは ldap.ldapAuthentication.bindDN 属性の DN を使用してディレクトリーにバインドします。
- SslClientAuth は、SSL クライアント認証を指定します。このオプションを使用すると、ldap.ldapconn.secureConn パラメーター の値を true に設定し、証明書のニックネームの ldap.ldapAuthentication.clientCertNickname パラメーターの値を、SSL クライアント認証に使用する証明書のニックネームに設定します。
- ldap.basedn.認証ディレクトリーを検索するためのベース DN を指定します。サーバーは、HTTP インプット (ユーザーが登録フォームに入力するもの) および LDAP 検索フィルターを構築するためのベース DN から uid フィールドの値を使用します。
- ldap.minConns.認証ディレクトリーで許可される最小接続数を指定します。許容値は、1 から 3 です。
- ldap.maxConns.認証ディレクトリーで許可される接続の最大数を指定します。許容値は、3 から 10 です。
- 証明書プロファイルで入力を設定して、登録フォームをカスタマイズします。ユーザーの認証にプラグインが必要とする情報を含めます。デフォルトの入力に、収集する必要のあるすべての情報が含まれていない場合には、サードパーティーツールで作成した要求を送信します。
9.2.3. 証明書ベースの認証の使用
9.2.4. フラットファイル認証の設定
9.2.4.1. flatFileAuth モジュールの設定
- CA コンソールを開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、ナビゲーションツリーの Authentication を選択します。
- flatFileAuth 認証モジュールを選択します。
- ファイルの場所と名前を変更するには、fileName フィールドをリセットします。authentication name パラメーターを変更するには、keyAttributes の値を、CN などの SCEP 登録フォームで送信された別の値にリセットします。また、UID,CN のようにコンマで区切って複数の name パラメーターを使用することもできます。パスワードパラメーター名を変更するには、authAttributes フィールドをリセットします。
- 編集を保存します。
9.2.4.2. flatfile.txt の編集
flatfile.txt
ファイルを使用して、SCEP 登録をすべて認証します。このファイルは、新規 PIN がルーターに発行されるたびに手動で更新する必要があります。
/var/lib/pki/pki-ca/ca/conf/
にあり、認証エントリーごとに 2 つのパラメーター、サイトの UID (通常は IPv4 または IPv6)、およびルーターが発行する PIN の 2 つのパラメーターを指定します。
UID:192.168.123.123 PIN:HU89dj
UID:192.168.123.123 PIN:HU89dj UID:12.255.80.13 PIN:fiowIO89 UID:0.100.0.100 PIN:GRIOjisf
... flatfile.txt entry ... UID:192.168.123.123 PIN:HU89dj UID:12.255.80.13 PIN:fiowIO89 ... error log entry ... [13/Jun/2020:13:03:09][http-9180-Processor24]: FlatFileAuth: authenticating user: finding user from key: 192.168.123.123 [13/Jun/2020:13:03:09][http-9180-Processor24]: FlatFileAuth: User not found in password file.
9.3. CMC 認証プラグイン
CMCAuth
- CA エージェントが CMC 要求に署名する場合は、このプラグインを使用します。
CMCAuth
プラグインを使用するには、登録プロファイルで以下を設定します。auth.instance_id=CMCAuth
デフォルトでは、以下の登録プロファイルはCMCAuth
プラグインを使用します。- システム証明書の場合:
caCMCauditSigningCert
caCMCcaCert
caCMCECserverCert
caCMCECsubsystemCert
caCMCECUserCert
caCMCkraStorageCert
caCMCkraTransportCert
caCMCocspCert
caCMCserverCert
caCMCsubsystemCert
- ユーザー証明書の場合:
caCMCUserCert
caECFullCMCUserCert
caFullCMCUserCert
CMCUserSignedAuth
- 署名付きまたは SharedSecret ベースの CMC 要求を送信する場合は、このプラグインを使用します。
CMCUserSignedAuth
プラグインを使用するには、登録プロファイルに以下を設定します。auth.instance_id=CMCUserSignedAuth
ユーザー署名の CMC 要求は、要求された証明書と同じsubjectDN
属性が含まれるユーザーの証明書で署名する必要があります。ユーザーが署名した CMC 要求を使用できるのは、ユーザーが他の証明書のユーザー ID を証明するために使用できる署名証明書を既に取得している場合のみです。SharedSecret ベースの CMC 要求は、要求が要求自体の秘密鍵によって署名されたことを意味します。この場合、CMC 要求は認証に共有秘密メカニズムを使用する必要があります。SharedSecret ベースの CMC 要求は通常、ユーザーの最初の署名証明書を取得するために使用され、後で他の証明書を取得するために使用されます。詳細は、「CMC SharedSecret 認証」を参照してください。デフォルトでは、以下の登録プロファイルは、CMCUserSignedAuth
プラグインを使用します。caFullCMCUserSignedCert
caECFullCMCUserSignedCert
caFullCMCSharedTokenCert
caECFullCMCSharedTokenCert
9.5. 登録のテスト
- エンドエンティティーを開きます。
http
s
://server.example.com:8443/ca/ee/ca
- 登録 タブで、カスタマイズされた登録フォームを開きます。
- 値を入力してリクエストを送信します。
- プロンプトが表示されたら、キーデータベースにパスワードを入力します。
- 正しいパスワードを入力すると、クライアントはキーペアを生成します。キー生成のプロセスを中断しないでください。キーの生成が完了すると、リクエストはサーバーに送信され、証明書を発行します。サーバーは、証明書プロファイルへの要求を許可し、要求がすべての要件を満たす場合にのみ証明書を発行します。証明書を発行したら、ブラウザーに証明書をインストールします。
- 証明書がブラウザーの証明書データベースにインストールされていることを確認します。
- PIN ベースのディレクトリー認証が PIN の削除で設定されている場合は、同じ PIN を使用して別の証明書を再登録します。リクエストを拒否する必要があります。
9.6. カスタム認証プラグインの登録
- カスタム認証クラスを作成します。この例では、カスタム認証プラグインは、
UidPwdDirAuthenticationTestms.java
となります。 - 新しいクラスをコンパイルします。
javac -d . -classpath $CLASSPATH UidPwdDirAuthenticationTestms.java
- CA が登録フォームからカスタムクラスにアクセスできるように、CA の
WEB-INF
Web ディレクトリーにディレクトリーを作成します。mkdir /usr/share/pki/ca/webapps/ca/WEB-INF/classes
- 新しいプラグインファイルを新しい
class
ディレクトリーにコピーし、所有者を Certificate System system user (pkiuser
) に設定します。cp -pr com /usr/share/pki/ca/webapps/ca/WEB-INF/classes chown -R pkiuser:pkiuser /usr/share/pki/ca/webapps/ca/WEB-INF/classes
- コンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- プラグインを登録します。
- Configuration タブで、ナビゲーションツリーの Authentication をクリックします。
- 右側のペインで、Authentication Plug-in Registration をクリックします。タブは、登録済みのモジュールの一覧を表示します。
- プラグインを登録するには、をクリックします。Register Authentication Plug-in Implementation 画面が表示されます。
- 2 つのフィールドを入力して登録するモジュールを指定します。
- プラグイン名。モジュールの名前。
- クラス名。このモジュールのクラスのフルネーム。これは、実装 Java™ クラスへのパスです。このクラスがパッケージに含まれる場合は、パッケージ名を含めます。たとえば、com.customplugins という名前のパッケージに customAuth という名前のクラスを登録するには、クラス名は com.customplugins.customAuth になります。
- モジュールを登録したら、モジュールをアクティブな認証インスタンスとして追加します。
- Configuration タブで、ナビゲーションツリーの Authentication をクリックします。
- 右側のペインで、Authentication Instance タブをクリックします。
- 一覧からカスタムモジュール
UidPwdDirAuthenticationTestms.java
を選択し、リストからモジュールを追加します。モジュールに適した設定を入力します。
- 新しい認証モジュールを使用するために、新しいエンドエンティティーの登録フォームを作成します。
cd /var/lib/pki/pki-tomcat/ca/profiles/ca cp -p caDirUserCert.cfg caDirUserCertTestms.cfg vi caDirUserCertTestms.cfg desc=Test ms - This certificate profile is for enrolling user certificates with directory-based authentication. visible=true enable=true enableBy=admin name=Test ms - Directory-Authenticated User Dual-Use Certificate Enrollment
auth.instance_id=testms
... - 新規プロファイルを CA の
CS.cfg
ファイルに追加します。ヒントCS.cfg
ファイルを編集する前にバックアップします。vim /var/lib/pki/instance-name/ca/conf/CS.cfg profile.list=caUserCert,caDualCert,caSignedLogCert,caTPSCert,caRARouterCert,caRouterCert,caServerCert,caOtherCert,caCACert,caInstallCACert,caRACert,caOCSPCert,caTransportCert,caDirUserCert,caAgentServerCert,caAgentFileSigning,caCMCUserCert,caFullCMCUserCert,caSimpleCMCUserCert,caTokenDeviceKeyEnrollment,caTokenUserEncryptionKeyEnrollment,caTokenUserSigningKeyEnrollment,caTempTokenDeviceKeyEnrollment,caTempTokenUserEncryptionKeyEnrollment,caTempTokenUserSigningKeyEnrollment,caAdminCert,caInternalAuthServerCert,caInternalAuthTransportCert,caInternalAuthKRAstorageCert,caInternalAuthSubsystemCert,caInternalAuthOCSPCert,DomainController,
caDirUserCertTestms
... profile.caDirUserCertTestms.class_id=caEnrollImpl profile.caDirUserCertTestms.config=/var/lib/pki/pki-tomcat/ca/profiles/ca/caDirUserCertTestms.cfg - CA を再起動します。
systemctl restart pki-tomcatd@instance_name.service
9.7. コマンドラインを使用した証明書ステータスの手動確認
pki
コマンドラインインターフェイスの設定に関する詳細は、「pki CLI の初期化」 を参照してください。
- 保留中の証明書要求の一覧を表示します。
$ pki agent_authentication_parameters ca-cert-request-find --status pending
このコマンドは、保留中の証明書要求をすべて表示します。 - 特定の証明書要求をダウンロードします。
$ pki agent_authentication_parameters ca-cert-request-review id --file request.xml
- エディターまたは別のターミナルでエディターまたは別のターミナルで
request.xml
ファイルを開いて要求の内容を確認して、それが正当であることを確認します。その後、プロンプトに回答します。リクエストが有効な場合は、approve と回答して、Enter を押します。リクエストが無効の場合は reject と回答し、Enter を押します。組織は、セマンティックの相違点をサブスクライブして reject および cancel にすることができます。どちらも証明書は発行されません。
9.8. Web インターフェイスを使用した証明書ステータスの手動による確認
- Web ブラウザーで、以下の URL を開きます。
https://server_host_name:8443/ca/agent/ca
- エージェントとして認証します。ユーザーとして認証し、ブラウザーの設定に関する詳細は、「ブラウザーの初期化」 を参照してください。
- 左側のサイドバーの List requests リンクをクリックします。
- Request type の Show all requests を選択して、Request status の Pending requests を選択して要求をフィルタリングします。
- 右下隅にあるをクリックします。
- 結果ページでは、確認を待機中の保留中のリクエストをすべて表示します。要求番号をクリックして、リクエストを確認します。
- 要求情報を確認し、それが正当な要求であることを確認します。必要に応じて、ポリシー情報を変更して間違いを修正したり、証明書に必要な変更 (not valid after フィールドなど) を行ったりします。必要に応じて、追加の注記を残しておきます。ドロップダウンメニューには、複数のレビューステータスの更新が含まれます。Approve request を選択してリクエストを承認するか、または Reject request を選択して否定してから、 をクリックします。組織は Reject request と Cancel Request とのセマンティックの相違点をサブスクライブできます。いずれの場合でも、証明書は発行されません。
第10章 証明書の登録の認可 (アクセス評価者)
10.1. 承認メカニズム
type
、op
、value
) などを取り、group='Certificate Manager Agents'
などの評価を評価し、評価の結果に応じてブール値を返す 評価 方法を提供します。
10.2. デフォルトの評価者
CS.cfg
ファイルに、以下のエントリーがデフォルトで一覧表示されます。
accessEvaluator.impl.group.class=com.netscape.cms.evaluators.GroupAccessEvaluator accessEvaluator.impl.ipaddress.class=com.netscape.cms.evaluators.IPAddressAccessEvaluator accessEvaluator.impl.user.class=com.netscape.cms.evaluators.UserAccessEvaluator accessEvaluator.impl.user_origreq.class=com.netscape.cms.evaluators.UserOrigReqAccessEvaluator
group
アクセスエバリュエーターは、ユーザーのグループメンバーシッププロパティーを評価します。たとえば、以下の登録プロファイルエントリーでは、CA エージェントのみがそのプロファイルで登録できます。
authz.acl=group="Certificate Manager Agents"
ipaddress
アクセスエバリュエーターは、要求側の IP アドレスを評価します。たとえば、以下の登録プロファイルエントリーでは、指定した IP アドレスを持つホストのみがそのプロファイルで登録を行えます。
authz.acl=ipaddress="a.b.c.d.e.f"
user
アクセスエバリュエーターは、完全一致についてユーザー ID を評価します。たとえば、以下の登録プロファイルエントリーでは、リストされたユーザーと一致するユーザーのみが、そのプロファイルを使用した登録を行うことができます。
authz.acl=user="bob"
user_origreq
アクセスエバリュエーターは、認証されたユーザーを、以前に一致した同等の要求に対して評価します。この特別なエバリュエーターは、更新を要求するユーザーが元の要求を所有するユーザーと同じであることを確認するために、更新を目的として特別に設計されています。たとえば、次の更新登録プロファイルエントリーでは、認証されたユーザーの UID は、更新を要求しているユーザーの UID と一致する必要があります。
authz.acl=user_origreq="auth_token.uid"
第11章 自動通知の使用
11.1. CA の自動通知について
11.1.1. 自動通知の種類
- 発行された証明書。通知メッセージは、証明書を発行したユーザーに自動的に送信されます。ユーザーの証明書要求が拒否されると、拒否メッセージはユーザーに送信されます。
- 証明書失効。ユーザー証明書が取り消されると、通知メッセージはユーザーに自動的に送信されます。
- キューの要求。エージェントに設定されたメールアドレスを使用して、要求がエージェント要求キューに入ると、通知メッセージが 1 つ以上のエージェントに自動的に送信されます。この通知タイプは、メッセージがキューに入るたびにメールを送信します。キュー内のジョブ要求の詳細は、「requestInQueueNotifier (RequestInQueueJob)」 を参照してください。キューのステータスに関する通知をエージェントに送信するジョブもあります。これには、特定の間隔でのキューステータスの概要が含まれます。
11.1.2. エンドエンティティーのメールアドレスの判断
11.2. CA の自動通知の設定
11.2.1. コンソールで自動通知の設定
- Certificate Manager Console を開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブを開きます。
- 左側のナビゲーションツリーで Certificate Manager の見出しを開きます。次に Notification を選択します。Notification タブがウィンドウの右側に表示されます。
- 通知は、新しく発行された証明書、取り消された証明書、および新しい証明書要求の 3 種類のイベントに対して送信できます。イベントの通知を送信するには、タブを選択し、Enable チェックボックスをオンにして、次のフィールドに情報を指定します。
- 送信者のメールアドレス。配信の問題が通知されるユーザーの完全なメールアドレスを入力します。
- Recipient's E-mail Address。これは、キューを確認するエージェントのメールアドレスです。複数の受信側を一覧表示するには、メールアドレスをコンマで区切ります。キューの新しいリクエストのみ。
- Subject。通知の件名のタイトルを入力します。
- コンテンツテンプレートパス。メッセージコンテンツの作成に使用するテンプレートを含むディレクトリーへのパス (ファイル名を含む) を入力します。
- 注記メールサーバーが正しく設定されていることを確認してください。「証明書システム通知用のメールサーバーの設定」 を参照してください。
- 通知メッセージのテンプレートをカスタマイズします。詳細は、「通知メッセージのカスタマイズ」 を参照してください。
- 設定をテストします。「設定のテスト」 を参照してください。
11.2.2. CS.cfg ファイルを編集して特定の通知を設定
- CA サブシステムを停止します。
systemctl stop pki-tomcatd@instance_name.service
- そのインスタンスの
CS.cfg
ファイルを開きます。このファイルは、インスタンスのconf/
ディレクトリー内にあります。 - 有効にする通知タイプのすべての設定パラメーターを編集します。証明書発行の通知には、4 つのパラメーターがあります。
ca.notification.certIssued.emailSubject ca.notification.certIssued.emailTemplate ca.notification.certIssued.enabled ca.notification.certIssued.senderEmail
証明書失効リストの通知については、4 つのパラメーターがあります。ca.notification.certRevoked.emailSubject ca.notification.certRevoked.emailTemplate ca.notification.certRevoked.enabled ca.notification.certRevoked.senderEmail
証明書要求通知には、5 つのパラメーターがあります。ca.notification.requestInQ.emailSubject ca.notification.requestInQ.emailTemplate ca.notification.requestInQ.enabled ca.notification.requestInQ.recipientEmail ca.notification.requestInQ.senderEmail
通知メッセージのパラメーターは、「CA の自動通知の設定」 で説明されています。 - ファイルを保存します。
- CA インスタンスを再起動します。
systemctl start pki-tomcatd@instance_name.service
- 自動メッセージを送信するジョブが作成されている場合は、メールサーバーが正しく設定されていることを確認してください。「証明書システム通知用のメールサーバーの設定」 を参照してください。
- 自動的に送信されたメッセージはカスタマイズ可能です。詳細は 「通知メッセージのカスタマイズ」 を参照してください。
11.2.3. 設定のテスト
- キュー通知内の要求の通知設定の電子メールアドレスを、アクセス可能なエージェントまたは管理者のメールアドレスに変更します。
- エンドエンティティーページを開き、エージェント承認の登録フォームを使用して証明書をリクエストします。リクエストがエージェントの承認に対してキューに入れられると、リクエストインキューのメール通知が送信されます。メッセージを確認して、設定された情報が含まれているかどうかを確認します。
- エージェントインターフェイスにログインし、要求を承認します。サーバーが証明書を発行すると、ユーザーは要求にリストされているアドレスに証明書が発行したメール通知を受け取ります。メッセージをチェックして、正しい情報があるかどうかを確認します。
- エージェントインターフェイスにログインし、証明書を取り消します。ユーザーのメールアドレスには、証明書が取り消されたことを示すメッセージが含まれている必要があります。メッセージをチェックして、正しい情報があるかどうかを確認します。
11.3. 通知メッセージのカスタマイズ
11.3.1. CA 通知メッセージのカスタマイズ
Your certificate request has been processed successfully. SubjectDN= $SubjectDN IssuerDN= $IssuerDN notAfter= $NotAfter notBefore= $NotBefore Serial Number= 0x$HexSerialNumber To get your certificate, please follow this URL: https://$HttpHost:$HttpPort/displayBySerial?op=displayBySerial& serialNumber=$SerialNumber Please contact your admin if there is any problem. And, of course, this is just a \$SAMPLE\$ email notification form.
THE EXAMPLE COMPANY CERTIFICATE ISSUANCE CENTER Your certificate has been issued! You can pick up your new certificate at the following website: https://$HttpHost:$HttpPort/displayBySerial?op=displayBySerial& serialNumber=$SerialNumber This certificate has been issued with the following information: Serial Number= 0x$HexSerialNumber Name of Certificate Holder = $SubjectDN Name of Issuer = $IssuerDN Certificate Expiration Date = $NotAfter Certificate Validity Date = $NotBefore Contact IT by calling X1234, or going to the IT website http://IT if you have any problems.
/var/lib/pki/instance_name/ca/emails
ディレクトリーにあります。
ファイル名 | 説明 |
---|---|
certIssued_CA | 証明書の発行時のプレーンテキスト通知メールのテンプレート。 |
certIssued_CA.html | 証明書が発行されたときにエンドエンティティーに送信される HTML ベースの通知メールのテンプレート。 |
certRequestRejected.html | 証明書リクエストが拒否される際に、エンドエンティティーに対する HTML ベースの通知メールのテンプレート。 |
certRequestRevoked_CA | 証明書が取り消されたときにエンドエンティティーに送信されるプレーンテキストの通知メールのテンプレート。 |
certRequestRevoked_CA.html | 証明書が取り消されたときにエンドエンティティーに送信される HTML ベースの通知メールのテンプレート。 |
reqInQueue_CA | リクエストがキューに入ったときのエージェントへのプレーンテキスト通知メールのテンプレート。 |
reqInQueue_CA.html | リクエストがキューに入ったときのエージェントへの HTML ベースの通知メールのテンプレート。 |
ファイル名 | 説明 |
---|---|
rnJob1.txt | エンドエンティティーに送信されるメッセージコンテンツを作成して、証明書の有効期限が近づいていること、および証明書の有効期限が切れる前に証明書を更新または置換する必要があることを通知するためのテンプレート。 |
rnJob1Summary.txt |
サマリーレポートをエージェントおよび管理者に送信するためのテンプレート。
rnJob1Item.txt テンプレートを使用してメッセージ内のアイテムをフォーマットします。
|
rnJob1Item.txt | サマリーレポートに含まれるアイテムをフォーマットするためのテンプレート。 |
riq1Item.html | サマリーテーブルに含まれる項目をフォーマットするためのテンプレート。これは、riq1Summary.html テンプレートを使用して構築されます。 |
riq1Summary.html |
Certificate Manager のエージェントキューで保留中の要求数を報告するレポートまたはテーブルを計算するテンプレート。
|
publishCerts |
ディレクトリーに公開される証明書を要約したレポートまたはテーブルのテンプレート。
publishCertsItem.html テンプレートを使用して、テーブルのアイテムをフォーマットします。
|
publishCertsItem.html |
サマリーテーブルに含まれるアイテムをフォーマットするためのテンプレート。
|
ExpiredUnpublishJob |
ディレクトリーに公開される証明書を要約したレポートまたはテーブルのテンプレート。
ExpiredUnpublishJobItem テンプレートを使用して、テーブルのアイテムをフォーマットします。
|
ExpiredUnpublishJobItem |
サマリーテーブルに含まれるアイテムをフォーマットするためのテンプレート。
|
トークン | 説明 |
---|---|
$CertType |
証明書のタイプを指定します。次のいずれかになります。
|
$ExecutionTime | ジョブが実行された時間を指定します。 |
$HexSerialNumber | 16 進形式で発行された証明書のシリアル番号を指定します。 |
$HttpHost | Certificate Manager の完全修飾ホスト名を指定して、証明書を取得するエンドエンティティーが接続します。 |
$HttpPort | Certificate Manager のエンドエンティティー (TLS 以外の) ポート番号を指定します。 |
$InstanceID |
通知を送信するサブシステムの ID を指定します。
|
$IssuerDN | 証明書を発行した CA の DN を指定します。 |
$NotAfter | 有効期間の終了日を指定します。 |
$NotBefore | 有効期間の開始日を指定します。 |
$RecipientEmail | 受信者のアドレスを指定します。 |
$RequestId | 要求 ID を指定します。 |
$RequestorEmail | リクエスターのメールアドレスを指定します。 |
$RequestType | 作成されたリクエストのタイプを指定します。 |
$RevocationDate | 証明書が取り消された日付を指定します。 |
$SenderEmail | 送信者のメールアドレスを指定します。これは、通知設定の Sender の E-mail Address フィールドで指定されるアドレスと同じです。 |
$SerialNumber | 発行した証明書のシリアル番号を指定します。シリアル番号は、メッセージで 16 進数で表示されます。 |
$Status | 要求のステータスを指定します。 |
$SubjectDN | 証明書サブジェクトの DN を指定します。 |
$SummaryItemList | 概要通知のアイテムを表示します。各項目は、ジョブがパブリッシュディレクトリーから更新または削除を検出する証明書に対応します。 |
$SummaryTotalFailure | 失敗したサマリーレポートの合計項目数を指定します。 |
$SummaryTotalNum | キューで保留中の証明書要求の総数、または要約レポートのディレクトリーから更新または削除される証明書の総数を示します。 |
$SummaryTotalSuccess | サマリーレポートのアイテムの合計数を表示します。 |
11.4. 証明書システム通知用のメールサーバーの設定
CS.cfg
設定ファイルで以下のパラメーターが指定されていることを確認してください。
smtp.host=localhost smtp.port=25
- CA サブシステム管理コンソールを開きます。以下に例を示します。
pkiconsole https://server.example.com:8443/ca
- 設定 タブで、上部のインスタンス名を強調表示し、SMTP タブを選択します。
- メールサーバーのサーバー名およびポート番号を指定します。サーバー名は、メールサーバーがインストールされているマシンの完全修飾 DNS ホスト名です (mail.example.com)。デフォルトでは、メールサーバーのホスト名は、実際のホスト名ではなく localhost です。SMTP メールサーバーがリッスンするデフォルトのポート番号は 25 です。
11.5. CA のカスタム通知の作成
第12章 自動ジョブの設定
12.1. 自動ジョブについて
12.1.1. 自動ジョブの設定
- Job Scheduler の有効化および設定。詳細は 「ジョブスケジューラーの設定」 を参照してください。
- ジョブモジュールの有効化および設定と、これらのジョブモジュールの設定を行います。詳細は 「特定のジョブの設定」 を参照してください。
- 通知のタイプに関連付けられたテンプレートを変更して、これらのジョブで送信されるメール通知メッセージをカスタマイズします。メッセージの内容は、プレーンテキストメッセージと HTML メッセージの両方で設定されます。外観は、HTML テンプレートを変更することで変更されます。詳細は、「CA 通知メッセージのカスタマイズ」 を参照してください。
12.1.2. 自動ジョブの種類
12.1.2.1. certRenewalNotifier (RenewalNotificationJob)
12.1.2.2. requestInQueueNotifier (RequestInQueueJob)
12.1.2.3. publishCerts (PublishCertsJob)
12.1.2.4. unpublishExpiredCerts (UnpublishExpiredJob)
12.2. ジョブスケジューラーの設定
CScfg.
ファイルを編集することで実行できます。
- Certificate Manager Console を開きます。
pkiconsole https://server.example.com:8443/ca
- Configuration タブナビゲーションツリーで、Job Scheduler をクリックします。これにより、General Settings タブが開き、Job Scheduler が現在有効になっているかどうかを確認します。
- Enable Jobs Schedule チェックボックスをクリックして、Job Scheduler を有効または無効にします。ジョブスケジューラーを無効にすると、すべてのジョブが無効になります。
- スケジューラーが Check Frequency フィールドでジョブをチェックする頻度を設定します。頻度は、Job Scheduler デーモンスレッドがウェイクアップし、cron 指定に対応する設定済みのジョブを呼び出す頻度です。デフォルトでは、1 分に設定されています。注記この情報を入力するウィンドウは小さすぎて入力内容を確認できない可能性があります。Certificate Manager Console の隅をウィンドウ全体を拡大します。
12.3. 特定のジョブの設定
12.3.1. 証明書マネージャーコンソールを使用した特定のジョブの設定
- Certificate Manager Console を開きます。
pkiconsole https://server.example.com:8443/ca
- ジョブスケジューラーが有効になっていることを確認します。詳細は、「ジョブスケジューラーの設定」 を参照してください。
- Configuration タブで、ナビゲーションツリーから Job Scheduler を選択します。次に Jobs を選択して、Job Instance タブを開きます。一覧からジョブインスタンスを選択し、をクリックします。ジJob Instance Editor が開き、現在のジョブ設定が表示されます。
図12.1 ジョブ設定
- ジョブを有効にするには enabled を選択します。
- このダイアログのフィールドで設定設定を指定して設定します。
- certRenewalNotifier は、「certRenewalNotifier の設定パラメーター」 を参照してください。
- requestInQueueNotifier は、「requestInQueueNotifier の設定パラメーター」 を参照してください。
- publishCerts は、「publishCerts の設定パラメーター」 を参照してください。
- unpublishExpiredCerts は、「unpublishExpiredCerts の設定パラメーター」 を参照してください。
- cron 時間頻度の設定に関する詳細は、「自動ジョブの頻度設定」 を参照してください。
- ジョブが自動メッセージを送信するように設定されている場合は、メールサーバーが正しく設定されていることを確認してください。「証明書システム通知用のメールサーバーの設定」 を参照してください。
- 電子メールメッセージテキストと外観をカスタマイズします。
12.3.2. 設定ファイルを編集してジョブを設定
- ジョブスケジューラーが有効で設定されていることを確認します。「ジョブスケジューラーの設定」 を参照してください。
- CA サブシステムインスタンスを停止します。
systemctl stop pki-tomcatd@instance_name.service
- テキストエディターで、そのサーバーインスタンスの
CS.cfg
ファイルを開きます。 - 設定されているジョブモジュールのすべての設定パラメーターを編集します。
- certRenewalNotifier ジョブを設定するには、jobsScheduler.job.certRenewalNotifier で始まるすべてのパラメーターを編集します。「certRenewalNotifier の設定パラメーター」 を参照してください。
- requestInQueueNotifier ジョブを設定するには、jobsScheduler.job.requestInQueueNotifier で始まるすべてのパラメーターを編集します。「requestInQueueNotifier の設定パラメーター」 を参照してください。
- publishCerts ジョブを設定するには、jobsScheduler.job.publishCerts で始まるすべてのパラメーターを編集します。「publishCerts の設定パラメーター」 を参照してください。
- unpublishExpiredCerts ジョブを設定するには、jobsScheduler.job.unpublishExpiredCerts で始まるすべてのパラメーターを編集します。「unpublishExpiredCerts の設定パラメーター」 を参照してください。
- ファイルを保存します。
- サーバーインスタンスを再起動します。
systemctl start pki-tomcatd@instance_name.service
- ジョブが自動的にメッセージを送信する場合は、メールサーバーが正しく設定されていることを確認してください。「証明書システム通知用のメールサーバーの設定」 を参照してください。
- 自動ジョブメッセージをカスタマイズします。
12.3.3. certRenewalNotifier の設定パラメーター
CS.cfg
ファイルまたは Certificate Manager コンソール のいずれかで、certRenewalNotifier ジョブに設定できるこれらのパラメーターの詳細を提供します。
パラメーター | 説明 |
---|---|
enabled | ジョブを有効または無効にするかどうかを指定します。true の場合はジョブを有効にします。false に設定すると 無効にします。 |
cron |
このジョブの実行スケジュールを設定します。これにより、Job Scheduler デーモンスレッドが、更新通知を送信するために証明書をチェックする時間を設定します。これらの設定は、「自動ジョブの頻度設定」 の規則に従う必要があります。以下に例を示します。
0 3 * * 1-5
この例のジョブは、月曜日から金曜日の午後 3 時まで実行されます。
|
notifyTriggerOffset | 証明書の有効期限の前に最初の通知が送信される期間 (日数) を設定します。 |
notifyEndOffset | 証明書の有効期限が切れてから、証明書が置き換えられない場合に通知が送信され続ける期間 (日数) を設定します。 |
senderEmail | 配信問題について通知する通知メッセージの送信者を設定します。 |
emailSubject | 通知メッセージの Subject 行のテキストを設定します。 |
emailTemplate | メッセージコンテンツの作成に使用するテンプレートが含まれるディレクトリーに、ファイル名を含むパスを設定します。 |
summary.enabled | 更新通知の概要レポートをコンパイルして送信すべきかどうかを設定します。true の値はサマリーを送信できるようにします。false はこれを無効にします。有効にする場合は、残りのサマリーパラメーターを設定します。これは、サーバーでサマリーレポートを送信するために必要です。 |
summary.recipientEmail | サマリーメッセージの受信者を指定します。これらは、ユーザー証明書または他のユーザーのステータスを知る必要があるエージェントである可能性があります。各メールアドレスをコンマで区切ることで、複数の受信者を設定できます。 |
summary.senderEmail | サマリーメッセージの送信者のメールアドレスを指定します。 |
summary.emailSubject | 要約メッセージの件名を指定します。 |
summary.itemTemplate | サマリーレポート用に収集される各アイテムのコンテンツおよび形式を作成するために使用するテンプレートが含まれるディレクトリーに、ファイル名を含むパスを指定します。 |
summary.emailTemplate | サマリーレポートのメール通知を作成するために使用するテンプレートが含まれるディレクトリーに、ファイル名を含むパスを指定します。 |
12.3.4. requestInQueueNotifier の設定パラメーター
CS.cfg
ファイルまたは Certificate Manager コンソール のいずれかで、requestInQueueNotifier ジョブに設定できるこれらのパラメーターの詳細を提供します。
パラメーター | 説明 |
---|---|
enabled | ジョブを有効 (true) または無効 (false) にするかを設定します。 |
cron |
ジョブを実行する時刻を設定します。これは、Job Scheduler デーモンスレッドが保留中のリクエストのキューをチェックする時間です。この設定は、「自動ジョブの頻度設定」 の規則に従う必要があります。以下に例を示します。
0 0 * * 0 |
subsystemid | ジョブを実行しているサブシステムを指定します。Certificate Manager で利用できる値は ca です。 |
summary.enabled | 達成されたジョブの要約をコンパイルして送信するかどうかを指定します。true 値によりサマリーレポートが有効になり、false により無効になります。有効にする場合は、残りのサマリーパラメーターを設定します。これは、サーバーでサマリーレポートを送信するために必要です。 |
summary.emailSubject | 要約メッセージの件名を指定します。 |
summary.emailTemplate | 要約レポートの作成に使用するテンプレートを含むディレクトリーへのパス (ファイル名を含む) を指定します。 |
summary.senderEmail | 配信問題について通知する通知メッセージの送信者を指定します。 |
summary.recipientEmail | サマリーメッセージの受信者を指定します。これらは、保留中の要求または他のユーザーを処理する必要があるエージェントである可能性があります。各メールアドレスをコンマで区切ることで、複数の受信者を一覧に追加することができます。 |
12.3.5. publishCerts の設定パラメーター
CS.cfg
ファイルまたは Certificate Manager コンソール のいずれかで、publishCerts ジョブに設定できるこれらのパラメーターの詳細を提供します。
パラメーター | 説明 |
---|---|
enabled | ジョブが有効かどうかを指定します。true の値は有効で、false 無効になります。 |
cron |
ジョブの実行時には、時間スケジュールを設定します。これは、Job Scheduler デーモンスレッドが証明書をチェックして、公開ディレクトリーから期限切れの証明書を削除する時間です。この設定は、「自動ジョブの頻度設定」 の規則に従う必要があります。以下に例を示します。
0 0 * * 6 |
summary.enabled | ジョブによって公開される証明書の概要をコンパイルおよび送信するかどうかを指定します。true 値によりサマリーレポートが有効になり、false により無効になります。有効にする場合は、残りのサマリーパラメーターを設定します。これは、サーバーでサマリーレポートを送信するために必要です。 |
summary.emailSubject | 要約メッセージの件名を指定します。 |
summary.emailTemplate | 要約レポートの作成に使用するテンプレートを含むディレクトリーへのパス (ファイル名を含む) を指定します。 |
summary.itemTemplate | ファイル名を含むパスを指定し、サマリーレポート用に収集された各アイテムのコンテンツおよび形式を作成するのに使用するテンプレートが含まれるディレクトリーへのパスを指定します。 |
summary.senderEmail | 配信の問題について通知するサマリーメッセージの送信者を指定します。 |
summary.recipientEmail | サマリーメッセージの受信者を指定します。これらは、ユーザー証明書または他のユーザーのステータスを知る必要があるエージェントである可能性があります。各メールアドレスをコンマで区切ることで、複数の受信者を設定できます。 |
12.3.6. unpublishExpiredCerts の設定パラメーター
CS.cfg
ファイルまたは Certificate Manager コンソールのいずれかで、unpublishedExpiresCerts ジョブに設定できるこれらのパラメーターの詳細を提供します。
パラメーター | 説明 |
---|---|
enabled | ジョブが有効かどうかを指定します。true の値は有効で、false 無効になります。 |
cron |
ジョブの実行時には、時間スケジュールを設定します。これは、Job Scheduler デーモンスレッドが証明書をチェックして、公開ディレクトリーから期限切れの証明書を削除する時間です。この設定は、「自動ジョブの頻度設定」 の規則に従う必要があります。以下に例を示します。
0 0 * * 6 |
summary.enabled | ジョブによって公開される証明書の概要をコンパイルおよび送信するかどうかを指定します。true 値によりサマリーレポートが有効になり、false により無効になります。有効にする場合は、残りのサマリーパラメーターを設定します。これは、サーバーでサマリーレポートを送信するために必要です。 |
summary.emailSubject | 要約メッセージの件名を指定します。 |
summary.emailTemplate | 要約レポートの作成に使用するテンプレートを含むディレクトリーへのパス (ファイル名を含む) を指定します。 |
summary.itemTemplate | ファイル名を含むパスを指定し、サマリーレポート用に収集された各アイテムのコンテンツおよび形式を作成するのに使用するテンプレートが含まれるディレクトリーへのパスを指定します。 |
summary.senderEmail | 配信の問題について通知するサマリーメッセージの送信者を指定します。 |
summary.recipientEmail | サマリーメッセージの受信者を指定します。これらは、ユーザー証明書または他のユーザーのステータスを知る必要があるエージェントである可能性があります。各メールアドレスをコンマで区切ることで、複数の受信者を設定できます。 |
12.3.7. 自動ジョブの頻度設定
Minute Hour Day_of_month Month_of_year Day_of_week
フィールド | 値 |
---|---|
Minute | 0-59 |
Hour | 0-23 |
Day of month | 1-31 |
Month of year | 1-12 |
Day of week | 0-6 (0= 日曜日) |
15 * * * *
0 12 12 4 *
0 0 1,15 * 1
15 3 * * 1-5
12.4. ジョブモジュールの登録
- カスタムジョブクラスを作成します。この例では、カスタムジョブプラグインは
MyJob.java
と呼ばれます。 - 新しいクラスをコンパイルします。
javac -d . -classpath $CLASSPATH MyJob.java
- CA がカスタムクラスにアクセスできるように、CA の
WEB-INF
Web ディレクトリーにディレクトリーを作成します。mkdir /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes
- 新しいプラグインファイルを新しい
class
ディレクトリーにコピーし、所有者を Certificate System system user (pkiuser
) に設定します。cp -pr com /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes chown -R pkiuser:pkiuser /var/lib/pki/instance_name/ca/webapps/ca/WEB-INF/classes
- プラグインを登録します。
- Certificate Manager コンソールにログインします。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、左側のナビゲーションツリーで Job Scheduler を選択します。Jobs を選択します。ジョブインスタンスタブが開き、現在設定されているジョブが一覧表示されます。Job Plugin Registration タブを選択します。
- Register Job Scheduler Plugin Implementation ウィンドウで、以下の情報を入力します。
- プラグイン名。プラグインモジュールの名前を入力します。
- クラス名。このモジュールのクラスのフルネームを入力します。これは実装する Java™ クラスへのパスです。このクラスがパッケージに含まれる場合は、パッケージ名を含めます。たとえば、com.customplugins という名前のパッケージに含まれる customJob という名前のクラスを登録するには、com.customplugins.customJob と入力します。
パート IV. サブシステムインスタンスの管理
第13章 基本的なサブシステム管理
13.1. PKI インスタンス
- 個別の PKI インスタンス
- 単一の Java ベースの Apache Tomcat インスタンスとして実行します。
- 単一の PKI サブシステム (CA、KRA、OCSP、TKS、または TPS) が含まれます。
- 同じ物理マシンまたは仮想マシン (VM) に共存する場合は、一意のポートを使用する必要があります。
- 共有 PKI インスタンス
- 単一の Java ベースの Apache Tomcat インスタンスとして実行します。
- 個別の PKI インスタンスと同一の単一の PKI サブシステムを含めることができます。
- PKI サブシステムの各タイプの 1 つまで、任意の組み合わせを含めることができます。
- CA
- TKS
- CA、KRA
- CA、OCSP
- TKS、TPS
- CA、KRA、TKS、TPS
- CA、KRA、OCSP、TKS、TPS
- などになります。
- そのインスタンスに含まれるすべてのサブシステムが同じポートを共有できるようにし、
- 複数の同一物理マシンまたは仮想マシンに共存する場合、一意のポートを使用する必要があります。
13.2. PKI インスタンス実行管理
13.2.1. PKI インスタンスの起動、停止、および再起動
systemd
を使用して、他のシステムプログラムと同様に起動、停止、および再起動します。
- root としてサーバーマシンにログインします。
- アクションとインスタンス名を指定して、systemctl コマンドを実行します。
systemctl start|stop|restart pki-tomcatd@instance_name.service
以下に例を示します。systemctl restart pki-tomcatd@pki-tomcat.service
13.2.2. マシン再起動後の PKI インスタンスの再起動
- サブシステムで使用される Directory Server インスタンスがローカルマシンにインストールされている場合は、管理サーバーと Directory Server プロセスを再起動します。
systemctl start dirsrv-admin.service systemctl start dirsrv@instance_name.service
- Certificate System サブシステムインスタンスを起動します。
systemctl start pki-tomcatd@instance_name.service
13.2.3. PKI インスタンスステータスの確認
systemctl -l status pki-tomcatd@pki-tomcat.service pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled) Active: inactive (dead) since Fri 2015-11-20 19:04:11 MST; 12s ago Process: 8728 ExecStop=/usr/libexec/tomcat/server stop (code=exited, status=0/SUCCESS) Process: 8465 ExecStart=/usr/libexec/tomcat/server start (code=exited, status=143) Process: 8316 ExecStartPre=/usr/bin/pkidaemon start tomcat %i (code=exited, status=0/SUCCESS) Main PID: 8465 (code=exited, status=143) Nov 20 19:04:10 pki.example.com server[8728]: options used: -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager Nov 20 19:04:10 pki.example.com server[8728]: arguments used: stop Nov 20 19:04:11 pki.example.com server[8465]: Nov 20, 2015 7:04:11 PM org.apache.catalina.core.StandardServer await Nov 20 19:04:11 pki.example.com server[8465]: INFO: A valid shutdown command was received via the shutdown port. Stopping the Server instance. Nov 20 19:04:11 pki.example.com server[8465]: PKIListener: org.apache.catalina.core.StandardServer[before_stop] Nov 20 19:04:11 pki.example.com server[8465]: PKIListener: org.apache.catalina.core.StandardServer[stop] Nov 20 19:04:11 pki.example.com server[8465]: PKIListener: org.apache.catalina.core.StandardServer[configure_stop] Nov 20 19:04:11 pki.example.com server[8465]: Nov 20, 2015 7:04:11 PM org.apache.coyote.AbstractProtocol pause Nov 20 19:04:11 pki.example.com server[8465]: INFO: Pausing ProtocolHandler ["http-bio-8080"] Nov 20 19:04:11 pki.example.com systemd[1]: Stopped PKI Tomcat Server pki-tomcat.
systemctl -l status pki-tomcatd@pki-tomcat.service pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled) Active: active (running) since Fri 2015-11-20 19:09:09 MST; 3s ago Process: 8728 ExecStop=/usr/libexec/tomcat/server stop (code=exited, status=0/SUCCESS) Process: 9154 ExecStartPre=/usr/bin/pkidaemon start tomcat %i (code=exited, status=0/SUCCESS) Main PID: 9293 (java) CGroup: /system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd@pki-tomcat.service ������9293 java -DRESTEASY_LIB=/usr/share/java/resteasy-base -Djava.library.path=/usr/lib64/nuxwdog-jni -classpath /usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/var/lib/pki/pki-tomcat -Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/lib/pki/pki-tomcat/temp -Djava.util.logging.config.file=/var/lib/pki/pki-tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.security.manager -Djava.security.policy==/var/lib/pki/pki-tomcat/conf/catalina.policy org.apache.catalina.startup.Bootstrap start Nov 20 19:09:10 pki.example.com server[9293]: Nov 20, 2015 7:09:10 PM org.apache.catalina.core.StandardService startInternal Nov 20 19:09:10 pki.example.com server[9293]: INFO: Starting service Catalina Nov 20 19:09:10 pki.example.com server[9293]: Nov 20, 2015 7:09:10 PM org.apache.catalina.core.StandardEngine startInternal Nov 20 19:09:10 pki.example.com server[9293]: INFO: Starting Servlet Engine: Apache Tomcat/7.0.54 Nov 20 19:09:10 pki.example.com server[9293]: Nov 20, 2015 7:09:10 PM org.apache.catalina.startup.HostConfig deployDescriptor Nov 20 19:09:10 pki.example.com server[9293]: INFO: Deploying configuration descriptor /etc/pki/pki-tomcat/Catalina/localhost/ROOT.xml Nov 20 19:09:12 pki.example.com server[9293]: Nov 20, 2015 7:09:12 PM org.apache.catalina.startup.HostConfig deployDescriptor Nov 20 19:09:12 pki.example.com server[9293]: INFO: Deployment of configuration descriptor /etc/pki/pki-tomcat/Catalina/localhost/ROOT.xml has finished in 2,071 ms Nov 20 19:09:12 pki.example.com server[9293]: Nov 20, 2015 7:09:12 PM org.apache.catalina.startup.HostConfig deployDescriptor Nov 20 19:09:12 pki.example.com server[9293]: INFO: Deploying configuration descriptor /etc/pki/pki-tomcat/Catalina/localhost/pki#admin.xml
13.2.4. 再起動時に自動的に起動するための PKI インスタンスの設定
# systemctl enable dirsrv-admin.service # systemctl enable dirsrv.target # systemctl enable pki-tomcatd@pki-tomcat.service
# systemctl disable pki-tomcatd@pki-tomcat.service # systemctl disable dirsrv.target # systemctl disable dirsrv-admin.service
13.2.5. Certificate System Service の sudo パーミッションの設定
pkiadmin
システムグループの使用が推奨されるオプションです。詳細は、『Red Hat Certificate System 9 計画、インストール、およびデプロイメントのガイド』を参照してください。 Certificate System 管理者であるすべてのオペレーティングシステムユーザーがこのグループに追加されます。pkiadmin
のシステムグループが存在する場合は、特定のタスクを実行するための sudo アクセスを付与することができます。
/etc/sudoers
ファイルを編集します。Red Hat Enterprise Linux 7 では、visudo コマンドを使用して実行できます。# visudo
- マシンにインストールされているものに応じて、Directory Server、Administration Server、PKI 管理ツール、および各 PKI サブシステムインスタンスの行を追加して、pkiadmin グループに sudo 権限を付与します。
# For Directory Server services %pkiadmin ALL = PASSWD: /usr/bin/systemctl * dirsrv.target %pkiadmin ALL = PASSWD: /usr/bin/systemctl * dirsrv-admin.service # For PKI instance management %pkiadmin ALL = PASSWD: /usr/sbin/pkispawn * %pkiadmin ALL = PASSWD: /usr/sbin/pkidestroy * # For PKI instance services %pkiadmin ALL = PASSWD: /usr/bin/systemctl * pki-tomcatd@instance_name.service
13.3. サブシステムのコンソールおよびサービスを開く
13.3.1. サブシステムの Web サービスページの検索
https://server.example.com:8443/ca/services
https
://server.example.com:8443/ca/ee/ca
https://1.2.3.4:8443/ca/services https://[00:00:00:00:123:456:789:00:]:8443/ca/services
SSL に使用 | クライアント認証に使用[a] | Web サービス | Web サービスの場所 |
---|---|---|---|
Certificate Manager | |||
No | エンドエンティティー | ca/ee/ca/ | |
はい | いいえ | エンドエンティティー | ca/ee/ca |
はい | はい | エージェント | ca/agent/ca |
はい | いいえ | サービス | ca/services |
はい | いいえ | コンソール | pkiconsole https://host:port/ca |
キーリカバリー認証局 | |||
はい | はい | エージェント | kra/agent/kra |
はい | いいえ | サービス | kra/services |
はい | いいえ | コンソール | pkiconsole https://host:port/kra |
オンライン証明書ステータスマネージャー | |||
はい | はい | エージェント | ocsp/agent/ocsp |
はい | いいえ | サービス | ocsp/services |
はい | いいえ | コンソール | pkiconsole https://host:port/ocsp |
トークンキーサービス | |||
はい | いいえ | サービス | tks/services |
はい | いいえ | コンソール | pkiconsole https://host:port/tks |
トークン処理システム | |||
はい | サービス | index.cgi | |
[a]
クライアント認証値が No のサービスは、クライアント認証を要求するように再設定できます。Yes または No のいずれかの値を持たないサービスは、クライアント認証を使用するように設定することはできません。
|
13.3.2. 証明書システム管理コンソールの起動
pkiconsole https://server.example.com:admin_port/subsystem_type
pkiconsole https://server.example.com:8443/kra
pkiconsole https://1.2.3.4:8443/ca pkiconsole https://[00:00:00:00:123:456:789:00:]:8443/ca
13.3.3. Java 管理コンソールの SSL の有効化
- このシステムを使用して管理者の証明書を保存します。証明書は、CA 自体からのものか、サブシステムの証明書に署名した CA からのものである必要があります。
- サブシステムコンソールを開きます。
- 左側の ユーザーとグループ オプションを選択します。
- ユーザー タブで管理ユーザーを選択し、 をクリックします。
- Web ブラウザーに保存されている管理者証明書などの base-64 でエンコードされた SSL クライアント証明書を貼り付けます。
クライアント証明書が SSL クライアント認証に適していることを確認してください。それ以外の場合、サーバーはクライアント証明書を受け入れず、/var/log/
instanceID/system
のエラーログにエラーメッセージを投稿します。failure (14290): Error receiving connection SEC_ERROR_INADEQUATE_CERT_TYPE - Certificate type not approved for application.)
- サブシステムを停止します。
systemctl stop pki-tomcatd@instance_name.service
- インスタンス設定ディレクトリー
/var/lib/pki/instance_name/subsystem_type/conf
を開きます。 CS.cfg
ファイルを開きます。- authType パラメーターの値を pwd から sslclientauth に変更します。
authType=sslclientauth
- ファイルを保存します。
server.xml
ファイルを開きます。- admin インターフェイスコネクターセクションで clientAuth="false" 属性を clientAuth="want" に変更します。
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true"
clientAuth="want"
sslProtocol="SSL" ..... serverCertFile="/var/lib/pki/pki-tomcat/conf/serverCertNick.conf" passwordFile="/var/lib/pki/pki-tomcat/conf/password.conf" passwordClass="org.apache.tomcat.util.net.jss.PlainPasswordFile" certdbDir="/var/lib/pki/pki-tomcat/alias"/>この want 値は、クライアント認証が優先されますが、必須ではありません。これにより、(コンソールなど) 簡単に使用できるインターフェイスを介したクライアント認証が可能になりますが、クライアント認証を簡単にサポートしないクライアント (セキュリティードメイン内の他のサブシステム) は通常の接続を使用して接続できます。 - サブシステムを起動します。
systemctl start pki-tomcatd@instance_name.service
.redhat-idm-console
ディレクトリーに保存されます。
.p12
ファイルにエクスポートして pk12util を使用してインポートして、ブラウザーの証明書およびキーデータベースを .redhat-idm-console
ディレクトリーにコピーします。(この手順では、証明書がブラウザーから .p12
ファイルにエクスポートされていることを前提とします)。
- ブラウザーから
admin.p12
などのファイルに管理者ユーザー証明書および鍵をエクスポートします。 - ユーザーのコンソールディレクトリーを開きます。
/user-directory/.redhat-idm-console
- 必要な場合は、新規セキュリティーデータベースを作成します。
certutil -N -d .
- Certificate System インスタンスを停止します。
systemctl stop pki-tomcatd@instance_name.service
- pk12util を使用して証明書をインポートします。
# pk12util -i /tmp/admin.p12 -d /user-directory/.redhat-idm-console -W [p12filepassword]
手順に成功すると、コマンドは以下を出力します。pk12util: PKCS12 IMPORT SUCCESSFUL
- ブラウザーから発行される CA 証明書の 64 ビットブロブをエクスポートし、これを
ca.crt
ファイルなどに保存します。 - 管理者ユーザー証明書に関連するベース 64-blob から CA 証明書をインポートします。
certutil -A -d . -n ca -t CT,C,C -i ./ca.crt
- Certificate System インスタンスを起動します。
systemctl start pki-tomcatd@instance_name.service
- コンソールを起動します。これで、証明書の入力を求められます。
13.4. Java Security Manager でのサブシステムの実行
13.4.1. Security Manager ポリシーファイルについて
/usr/share/tomcat/conf
ディレクトリーにあるデフォルトの Tomcat ポリシーからのcatalina.policy
ファイル。これは、一般的な Tomcat ファイルが更新されるたびに更新されます。- サブシステムインスタンスで提供される
/var/lib/pki/instance_name/subsystem_type/conf
ディレクトリー内のpki.policy
ファイル。 - ユーザー定義のセキュリティーポリシーを含む
/var/lib/pki/instance_name/subsystem_type/conf
ディレクトリーのcustom.policy
ファイル。
catalina.policy
ファイルの作成を開始すると常に連結されます。また、インスタンスに使用される /var/lib/pki/instance_name/subsystem_type/conf
ディレクトリーにもこの 3 つのファイルが連結されます。
pki.policy
ファイルには、PKI サブシステムが使用する Tomcat、LDAP、およびシンボリックリンクサービスへの無制限のアクセスを付与するパーミッションが含まれます。以下に例を示します。
// These permissions apply to Tomcat java as utilized by PKI instances grant codeBase "file:/usr/share/java/tomcat/-" { permission java.security.AllPermission; };
custom.policy
ファイルはデフォルトでは空になっています。管理者は、指定の PKI ポリシーおよび Tomcat ポリシーに加えて、このファイルでポリシーを作成することができます。
13.4.2. Java Security Manager を使用しないサブシステムインスタンスの起動
/etc/pki/default.cfg
ファイルの [Tomcat] セクションの下の pki_security_manager=true
をオーバーライドすることによって作成された場合を除く)。ただし、以下のように、インスタンスを起動または再起動して、Java Security Manager を起動 せず に実行することができます。
手順13.1 Java Security Manager を使用しないインスタンスの起動
- インスタンスを停止します。
# systemctl stop pki-tomcatd@instance_name.service
/etc/sysconfig/instance_name
ファイルを編集し、セキュリティーマネージャーをオフにします。SECURITY_MANAGER="false"
- インスタンスを起動します。
# systemctl start pki-tomcatd@instance_name.service
13.5. LDAP データベースの設定
- 証明書要求の保存および取得
- 証明書レコードの保存および取得
- CRL の保存
- ACL の保存
- 特権ユーザーとロール情報の保存
- エンドユーザーの暗号化秘密鍵レコードの保存および取得
/slapd-
DS_name/db/
内の他のディレクトリーサーバーデータベースと一緒に一覧表示されます。これらのデータベースは、/etc/pki/default.cfg
ファイル内の指定されたサブシステムセクションの下の変数 pki_ds_database
の値によって決定される値によって名前が付けられます (デフォルトでは CS_instance_name-CA、CS_instance_name-KRA、CS_instance_name-OCSP、CS_instance_name-TKS、および CS_instance_name-TPS)。これは、インスタンス設定時に指定されるデフォルトの形式です。たとえば、証明書マネージャーが ca1 の場合、データベース名は ca1-CA になります。同様に、データベース名は、/etc/pki/default.cfg
ファイル内の指定されたサブシステムセクション下の pki_ds_base_dn
の値によって決定されます (デフォルトでは o=CS_instance_name-CA、o=CS_instance_name-KRA、o=CS_instance_name-OCSP、o=CS_instance_name-TKS、または o=CS_instance_name-TPS)。
13.5.1. 内部データベース設定の変更
- サブシステム管理コンソールにログインします。
pkiconsole https://server.example.com:admin_port/subsystem_type
- Configuration タブで Internal Database タブを選択します。
- ホスト名、ポート、およびバインド DN フィールドを変更して、Directory Server インスタンスを変更します。ホスト名は、Directory Server がインストールされているマシンの完全修飾ホスト名です (certificates.example.com など)。Certificate System はこの名前を使用してディレクトリーにアクセスします。デフォルトでは、内部データベースとして使用されている Directory Server インスタンスのホスト名は、実際のホスト名ではなく、localhost と表示されます。これは、localhost のサーバーはローカルマシンからしかアクセスできないため、内部データベースがシステムの外部に表示されないようにするために行われます。したがって、デフォルト設定では、ローカルマシンからこの Directory Server インスタンスに接続する責任が最小限に抑えられます。ホスト名は、内部データベースの可視性がローカルサブネットに制限されている場合は、localhost 以外のものに変更できます。たとえば、Certificate System と Directory Server が負荷分散のために別のマシンにインストールされている場合は、Directory Server がインストールされているマシンのホスト名を指定します。ポート番号は、Directory Server と SSL 以外の通信に使用される TCP/IP ポートです。DN は Directory Manager DN である必要があります。Certificate System サブシステムは、ディレクトリーツリーにアクセスしてディレクトリーと通信する際にこの DN を使用します。
- 設定が変更されます。変更にサーバーの再起動が必要な場合は、プロンプトとそのメッセージが表示されます。その場合には、サーバーを再起動します。
13.5.2. Directory Server で証明書システムが発行する証明書の使用
- Directory Server ホストで以下を行います。
- Directory Server インスタンスを停止します。
# systemctl stop dirsrv@instance_name
- Certificate Signing Request (CSR) を生成します。たとえば、2048 ビット RSA 暗号化を使用し、これを
~/ds.csr
ファイルに保存する CSR を生成するには、以下を実行します。# PKCS10Client -d /etc/dirsrv/slapd-instance_name/ -p password -a rsa -l 2048 -o ~/ds.csr -n "CN=$HOSTNAME" PKCS10Client: Debug: got token. PKCS10Client: Debug: thread token set. PKCS10Client: token Internal Key Storage Token logged in... PKCS10Client: key pair generated. PKCS10Client: CertificationRequest created. PKCS10Client: b64encode completes. Keypair private key id: -3387b397ebe254b91c5d6c06dc36618d2ea8b7e6 -----BEGIN CERTIFICATE REQUEST----- ... -----END CERTIFICATE REQUEST----- PKCS10Client: done. Request written to file: ~/ds.csr
- Directory Server インスタンスを起動し、CA が要求の処理できるようにします。
# systemctl start dirsrv@instance_name
- CSR を Certificate System の CA に送信します。以下に例を示します。
# pki -d /etc/dirsrv/slapd-instance_name/ ca-cert-request-submit --profile caServerCert --csr-file ~/ds.csr ----------------------------- Submitted certificate request ----------------------------- Request ID: 13 Type: enrollment Request Status: pending Operation Result: success
- Certificate System ホストで以下を行います。
- CA エージェント証明書を Network Security Services (NSS) データベースにインポートして、CMC フル要求を署名します。
- 新しいディレクトリーを作成します。以下に例を示します。
# mkdir ~/certs_db/
- 新たに作成したディレクトリーでデータベースを初期化します。
# certutil -N -d ~/certs_db/
- CA 署名証明書のシリアル番号を表示します。
# pki -p 8080 ca-cert-find --name "CA Signing Certificate" --------------- 1 entries found --------------- Serial Number: 0x87bbe2d ...
- 前の手順のシリアル番号を使用して、CA 署名証明書を
~/certs_db/CA.pem
ファイルにダウンロードします。# pki -p 8080 ca-cert-show 0x87bbe2d --output ~/certs_db/CA.pem
- CA 署名証明書を NSS データベースにインポートします。
# pki -d ~/certs_db/ -c password client-cert-import "CA Certificate" --ca-cert ~/certs_db/CA.pem
- エージェントの証明書をインポートします。
# pk12util -d ~/certs_db/ -i ~/.dogtag/instance_name/ca_admin_cert.p12 Enter Password or Pin for "NSS FIPS 140-2 Certificate DB": password Enter password for PKCS12 file: password pk12util: PKCS12 IMPORT SUCCESSFUL
- CMS (CMC) 要求で Certificate Management を作成します。
~/sslserver-cmc-request.cfg
などの設定ファイルを以下の内容で作成します。# NSS database directory where the CA agent certificate is stored. dbdir=~/certs_db/ # NSS database password. password=password # Token name (default is internal). tokenname=internal # Nickname for CA agent certificate. nickname=caadmin # 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=~/ds.csr # Path for the CMC request. output=~/sslserver-cmc-request.bin
- CMC 要求を作成します。
# CMCRequest ~/sslserver-cmc-request.cfg ... The CMC enrollment request in base-64 encoded format: ... The CMC enrollment request in binary format is stored in ~/sslserver-cmc-request.bin
- CMC 要求を送信します。
~/sslserver-cmc-submit.cfg
などの設定ファイルを以下の内容で作成します。# 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=~/certs_db/ # NSS database password. password=password # Token name (default: internal). tokenname=internal # Nickname of CA agent certificate. nickname=caadmin # CMC servlet path servlet=/ca/ee/ca/profileSubmitCMCFull?profileId=caCMCserverCert # Path for the CMC request. input=~/sslserver-cmc-request.bin # Path for the CMC response. output=~/sslserver-cmc-response.bin
- 要求を送信します。
# HttpClient sslserver-cmc-submit.cfg ... The response in binary format is stored in ~/sslserver-cmc-response.bin
- 必要に応じて、結果を確認します。
# CMCResponse -d ~/certs_db/ -i ~/sslserver-cmc-response.bin ... Number of controls is 1 Control #0: CMCStatusInfoV2 OID: {1 3 6 1 5 5 7 7 25} BodyList: 1 Status: SUCCESS
- Directory Server 証明書のシリアル番号を表示します。
# pki -p 8080 ca-cert-find --name "DS Certificate" --------------- 1 entries found --------------- Serial Number: 0xc3eeb0c ...
- 前の手順でシリアル番号を使用して、証明書をダウンロードします。
# pki -p 8080 ca-cert-show 0xc3eeb0c --output ~/ds.crt
- Directory Server および CA 証明書の証明書を Directory Server ホストにコピーします。以下に例を示します。
# scp ~/ds.crt ~/certs_db/CA.pem ds.example.com:~/
- Certificate System を停止します。
# systemctl stop pki-tomcatd@instance_name.service
- Directory Server ホストで以下を行います。
- Directory Server インスタンスを停止します。
# systemctl stop dirsrv@instance_name
- 証明書を置き換えます。詳細は、『Red Hat Directory Server 管理ガイド』 の該当するセクションを参照してください。
- 古い証明書および CA 証明書を削除します。『証明書の削除』を参照してください。
- Certificate System が発行する CA 証明書をインストールします。『認証局証明書のインストール』を参照してください。
- Certificate System が発行する Directory Server の証明書をインストールします。『証明書のインストール』を参照してください。
- Directory Server インスタンスを停止します。
# systemctl start dirsrv@instance_name
- Certificate System を開始します。
# systemctl stop pki-tomcatd@instance_name.service
- 必要に応じて、証明書ベースの認証を設定します。詳細は、「内部データベースでの SSL/TLS クライアント認証の有効化」 を参照してください。
13.5.3. 内部データベースでの SSL/TLS クライアント認証の有効化
13.5.4. 内部データベースへのアクセス制限
- Directory Server コンソールにログインします。
- Certificate System 内部データベースエントリーを選択して、をクリックします。
- Configuration タブを選択します。
- ナビゲーションツリーで Plug-ins を展開し、Pass-Through Authentication を選択します。
- 右側のペインで、Enable plugin チェックボックスの選択を解除します。
- サーバーを再起動するように要求します。
- Tasks タブをクリックして、 をクリックします。
- Directory Server コンソールを閉じます。
- サーバーが再起動したら、内部データベースインスタンスの Directory Server コンソールを開きます。Login to Directory ダイアログボックスが表示されます。Distinguished Name フィールドが Directory Manager DN を表示し、パスワードを入力します。内部データベースの Directory Server Console は、正しいパスワードを入力する場合のみ開きます。
13.6. セキュリティードメイン設定の表示
ou=Security Domain,dc=example,dc=com
cn=KRAList,ou=Security Domain,dc=example,dc=com objectClass: top objectClass: pkiSecurityGroup cn: KRAList
dn: cn=server.example.com:8443,cn=KRAList,ou=Security Domain,dc=example,dc=com objectClass: top objectClass: pkiSubsystem cn: kra.example.com:8443 host: server.example.com SecurePort: 8443 SecureAgentPort: 8443 SecureAdminPort: 8443 UnSecurePort: 8080 DomainManager: false Clone: false SubsystemName: KRA server.example.com 8443
13.7. サブシステムの SELinux ポリシーの管理
13.7.1. SELinux について
13.7.2. サブシステムの SELinux ポリシーの表示
- system-config-selinux コマンドを実行するか、メインのシステムメニュー用の → → にアクセスしてユーティリティーを開きます。
- インストールされている Certificate System SELinux ポリシーのバージョンを確認するには、左側のバーの Policy Module セクションを参照してください。
- 個々のファイルおよびプロセスに設定したポリシーを表示するには、File Labeling セクションをクリックします。サブシステムのポート割り当てのポリシーを表示するには、Network Port セクションをクリックします。
13.7.3. nCipher netHSM コンテキストの再ラベル付け
例13.1 netHSM SELinux ポリシー
# default labeling for nCipher /opt/nfast/scripts/init.d/(.*) gen_context(system_u:object_r:initrc_exec_t,s0) /opt/nfast/sbin/init.d-ncipher gen_context(system_u:object_r:initrc_exec_t,s0) /opt/nfast(/.*)? gen_context(system_u:object_r:pki_common_t, s0) /dev/nfast(/.*)? gen_context(system_u:object_r:pki_common_dev_t,0)
pki_*_t
ドメインが pki_common_t
と pki_common_dev_t
のラベルが付いたファイルと通信できます。
/opt/nfast
であっても) nCipher 設定のいずれかを変更した場合は、restorecon を実行して、ファイルがすべて適切にラベル付けされていることを確認します。
restorecon -R /dev/nfast restorecon -R /opt/nfast
13.8. 証明書システムのバックアップと復元
- 内部データベース。サブシステムは LDAP データベースを使用してデータを保管します。Directory Server は、独自のバックアップスクリプトと手順を提供します。
- インスタンスディレクトリー。インスタンスディレクトリーには、すべての設定ファイル、セキュリティーデータベース、その他のインスタンスファイルが含まれます。これは、tar や zip などのユーティリティーを使用してバックアップできます。
13.8.1. LDAP 内部データベースのバックアップおよび復元
13.8.1.1. LDAP 内部データベースのバックアップ
db2ldif
ツールは、ldif2db
ツールを使用して復元できる LDIF ファイルを作成します。db2ldif
コマンドは、bak2db
ツールを使用して復元できる LDIF ファイルを作成します。
13.8.1.1.1. db2ldif を使用したバックアップ
--n
オプションで指定した単一のサブシステムデータベースのバックアップを作成します。
/root/
ディレクトリー配下に書き込み権限がないため、書き込みが可能なパスを提供する必要があります。
- PKI サブシステムが使用する各 Directory Server データベースをバックアップします。以下の pki-server ca-db-config-show コマンドを使用して、指定のサブシステムのデータベース名を確認することができます。以下に例を示します。
# db2ldif -V -n pki-tomcat-CA -a /var/lib/dirsrv/slapd-pki1/ldif/pki-ca-backup.ldif Exported ldif file: /var/lib/dirsrv/slapd-pki1/ldif/pki-ca-backup.ldif ldiffile: /var/lib/dirsrv/slapd-pki1/ldif/pki-ca-backup.ldif [05/Nov/2020:10:17:53.835635923 -0500] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [05/Nov/2020:10:17:53.845938266 -0500] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [05/Nov/2020:10:17:53.851851787 -0500] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [05/Nov/2020:10:17:53.874058831 -0500] - INFO - ldbm_back_ldbm2ldif - export pki-tomcat-CA: Processed 67 entries (100%). [05/Nov/2020:10:17:53.884181122 -0500] - INFO - dblayer_pre_close - All database threads now stopped
- 個々のサブシステムデータベースをすべてバックアップする以外に、
userRoot
を-n
オプションとして追加することでメインデータベースをバックアップできます。以下に例を示します。# db2ldif -V -n userRoot -a /var/lib/dirsrv/slapd-pki1/ldif/userRoot.ldif
ldif2db
を使用して LDIF ファイルを復元するには、「ldif2db を使用した復元」 を参照してください。
13.8.1.1.2. db2bak を使用したバックアップ
# db2bak Back up directory: /var/lib/dirsrv/slapd-pki1/bak/pki1-2020_11_05_11_20_21
/var/lib/dirsrv/slapd-<instance_name>/bak
ディレクトリーにバックアップが作成されます。
13.8.1.2. LDAP 内部データベースの復元
ldif2db
またはbak2db
を使用して、データベースを復元してください。
13.8.1.2.1. ldif2db を使用した復元
db2ldif
で LDIF ファイルを作成している場合は、ldif2db コマンドを使用して、Directory Server インスタンスを停止してファイルをインポートします。1 つのデータベースを指定して、バックアップから復元できます。以下に例を示します。
- Directory Server インスタンスを停止します。
# systemctl stop dirsrv@instance_name
-n
オプションで指定されたサブシステムに対して、-i
オプションによって指定したファイルをインポートします。# ldif2db -V -n pki-tomcat-CA -i /var/lib/dirsrv/slapd-pki1/ldif/pki-ca-backup.ldif importing data ... [06/Nov/2020:09:27:07.103094925 -0500] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [06/Nov/2020:09:27:07.118712207 -0500] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 ……... [06/Nov/2020:09:27:09.213947960 -0500] - INFO - import_main_offline - import pki-tomcat-CA: Closing files... [06/Nov/2020:09:27:09.470742715 -0500] - INFO - dblayer_pre_close - All database threads now stopped [06/Nov/2020:09:27:09.479321728 -0500] - INFO - import_main_offline - import pki-tomcat-CA: Import complete. Processed 67 entries in 2 seconds. (33.50 entries/sec)
- Directory Server インスタンスを開始します。
# systemctl start dirsrv@instance_name
13.8.1.2.2. bak2db を使用した復元
db2bak
を使用してバックアップファイルを作成している場合は、Directory Server を停止し、bak2db コマンドを使用してファイルをインポートします。単一のデータベースを指定して、バックアップから復元することもできます。以下に例を示します。
- Directory Server インスタンスを停止します。
# systemctl stop dirsrv@instance_name
-n
オプションで指定したサブシステムのファイルをインポートします。# bak2db /var/lib/dirsrv/slapd-pki1/bak/pki1-2020_11_06_09_40_21/ -n pki-tomcat-CA -V [06/Nov/2020:09:41:02.984808879 -0500] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [06/Nov/2020:09:41:02.991860094 -0500] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 ...... [06/Nov/2020:09:41:12.853686475 -0500] - INFO - dblayer_copy_directory - Restoring file 40 (/var/lib/dirsrv/slapd-pki1/db/pki-tomcat-CA/seeAlso.db) [06/Nov/2020:09:41:12.873881494 -0500] - WARN - dblayer_start - DB already started. [06/Nov/2020:09:41:12.883966616 -0500] - INFO - dblayer_pre_close - All database threads now stopped [06/Nov/2020:09:41:12.888381193 -0500] - INFO - dblayer_restore - Removing staging area /var/lib/dirsrv/slapd-pki1/db/../fribak.
また、-n
オプションを指定せずにコマンドを使用して、バックアップから完全なデータベースを復元することもできます。以下に例を示します。# bak2db /var/lib/dirsrv/slapd-pki1/bak/pki1-2020_11_06_09_40_21/ -V [06/Nov/2020:09:53:01.977785135 -0500] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 [06/Nov/2020:09:53:01.994426925 -0500] - INFO - ldbm_instance_config_cachememsize_set - force a minimal value 512000 ......... [06/Nov/2020:09:53:02.800340285 -0500] - INFO - dblayer_restore - Restoring file 68 (/var/lib/dirsrv/slapd-pki1/db/DBVERSION) [06/Nov/2020:09:53:02.814235053 -0500] - INFO - dblayer_copyfile - Copying /var/lib/dirsrv/slapd-pki1/bak/pki1-2020_11_06_09_40_21/DBVERSION to /var/lib/dirsrv/slapd-pki1/db/DBVERSION [06/Nov/2020:09:53:03.317071092 -0500] - INFO - dblayer_pre_close - All database threads now stopped
- Directory Server インスタンスを開始します。
# systemctl start dirsrv@instance_name
13.8.2. インスタンスディレクトリーのバックアップおよび復元
- サブシステムインスタンスを停止します。
systemctl stop pki-tomcatd@instance_name.service
- ディレクトリーを圧縮ファイルに保存します。
# cd /var/lib/pki/ # tar -chvf /export/archives/pki/instance_name.tar instance_name/
以下に例を示します。# cd /var/lib/pki/ # tar -chvf /tmp/test.tar pki-tomcat/ca/ pki-tomcat/ca/ pki-tomcat/ca/registry/ pki-tomcat/ca/registry/ca/ ...........
- サブシステムインスタンスを再起動します。
systemctl start instance_name
alias
バックアップおよび完全なインスタンスのディレクトリーバックアップ) の両方を使用して、現在のディレクトリーを交換できます。データを復元するには、unzip ツールまたは tar ツールを使用してアーカイブファイルを圧縮解除し、既存のファイルにアーカイブをコピーします。
- アーカイブを展開します。
cd /export/archives/pki/ tar -xvf instance_name.tar
以下に例を示します。# cd /tmp/ # tar -xvf test.tar pki-tomcat/ca/ pki-tomcat/ca/registry/ pki-tomcat/ca/registry/ca/ pki-tomcat/ca/registry/ca/default.cfg .........
- サブシステムインスタンスが停止していない場合は停止します。
systemctl stop pki-tomcatd@instance_name.service
- アーカイブされたファイルをコピーして、インスタンスディレクトリーを復元します。
cp -r /export/archives/pki/instance_name /var/lib/pki/instance_name
以下に例を示します。# cp -r /tmp/pki-tomcat/ca/ /var/lib/pki/pki-tomcat/ca/
- サブシステムインスタンスを再起動します。
systemctl start pki-tomcatd@instance_name.service
13.9. セルフテストの実行
13.9.1. セルフテストの実行
13.9.1.1. コンソールからのセルフテストの実行
- コンソールにログインします。
pkiconsole https://server.example.com:admin_port/subsystem_type
- 左側のペインの上部にあるサブシステム名を選択します。
- Self Tests タブを選択します。
- サブシステムに設定されたセルフテストが実行されます。重大なセルフテストに失敗すると、サーバーが停止します。
- On-Demand Self Tests Results ウインドウが表示され、セルフテストの実行にログイベントが表示されます。
13.9.1.2. TPS セルフテストの実行
- pki tps-selftest-find
- pki tps-selftest-run
- pki tps-selftest-show
13.9.2. セルフテストロギング
selftest.log
) が、起動用セルフテストとオンデマンドセルフテストの両方のレポートが含まれるログディレクトリーに追加されます。このログは、CS.cfg
ファイルのログの設定を変更することで設定されます。詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『セルフテスト設定の修正』のセクションを参照してください。
13.9.3. POSIX システム ACL の設定
13.9.3.1. CA、KRA、OCSP、TKS、および TPS の POSIX システム ACL の設定
- インスタンスを停止します。
systemctl stop pki-tomcatd@instance_name.service
- インスタンスのディレクトリーおよびファイルに対する読み取り可能性を pkiadmin グループに設定します。
# setfacl -R -L -m g:pkiadmin:r,d:g:pkiadmin:r /var/lib/pki/instance_name
- すべてのディレクトリーに実行 (x) ACL パーミッションを適用します。
# find -L /var/lib/pki/instance_name -type d -exec setfacl -L -n -m g:pkiadmin:rx,d:g:pkiadmin:rx {} \;
- インスタンスの signedAudit/ ディレクトリーおよびその関連ファイルから、pkiadmin グループのグループの読み取り性を削除します。
# setfacl -R -L -x g:pkiadmin,d:g:pkiadmin /var/lib/pki/instance_name/logs/signedAudit
- インスタンスの signedAudit/ ディレクトリーとその関連ファイルの pkiaudit グループのグループの読み取り性を設定します。
# setfacl -R -L -m g:pkiaudit:r,d:g:pkiaudit:r /var/lib/pki/instance_name/logs/signedAudit
- signedAudit/ ディレクトリーとそのすべてのサブディレクトリーで実行 (x) ACL パーミッションを再適用します。
# find -L /var/lib/pki/instance_name/logs/signedAudit -type d -exec setfacl -L -n -m g:pkiaudit:rx,d:g:pkiaudit:rx {} \;
- インスタンスを起動します。
systemctl start pki-tomcatd@instance_name.service
- 別のログ (selftest.log) が、起動用セルフテストとオンデマンドセルフテストの両方のレポートが含まれるログディレクトリーに追加されます。
# getfacl /var/lib/pki/instance_name /var/lib/pki/instance_name/subsystem_type/logs/signedAudit/ getfacl: Removing leading '/' from absolute path names # file: var/lib/pki/instance_name # owner: pkiuser # group: pkiuser user::rwx group::rwx group:pkiadmin:r-x mask::rwx other::r-x default:user::rwx default:group::rwx default:group:pkiadmin:r-x default:mask::rwx default:other::r-x # file: var/lib/pki/instance_name/logs/signedAudit # owner: pkiuser # group: pkiaudit user::rwx group::rwx group:pkiaudit:r-x mask::rwx other::--- default:user::rwx default:group::rwx default:group:pkiaudit:r-x default:mask::rwx default:other::---
第14章 証明書システムユーザーおよびグループの管理
14.1. 承認について
- ユーザーは、Certificate System ユーザー ID とパスワードまたは証明書を使用してインターフェイスに対して認証します。
- サーバーは、データベースに保存されているユーザー ID とパスワードが一致するか、データベースに保存されているものに対して証明書をチェックして、ユーザーを認証します。証明書ベースの認証では、サーバーは証明書が有効であることも確認し、証明書の DN をユーザーに関連付けてユーザーエントリーを確認することにより、ユーザーのグループメンバーシップを見つけます。パスワードベースの認証では、サーバーはユーザー ID に対してパスワードを確認してから、そのユーザー ID をグループに含まれるユーザー ID に関連付けることにより、ユーザーのグループメンバーシップを検索します。
- ユーザーが操作を実行しようとすると、承認メカニズムはユーザーのユーザー ID、ユーザーが属するグループ、ユーザーの IP アドレスを、そのユーザー、グループ、または IP アドレスに設定された ACL と比較します。その操作を許可する ACL が存在する場合、操作は続行されます。
14.2. デフォルトグループ
- 管理者。このグループには、管理インターフェイスで利用可能なすべてのタスクへの完全なアクセスが付与されます。
- エージェント。このグループには、エージェントサービスインターフェイスで利用可能なすべてのタスクに完全アクセスできます。
- 監査者。このグループには、署名済み監査ログを表示するためのアクセスが付与されます。このグループには他の権限がありません。
- エンタープライズ管理者。各サブシステムインスタンスには、設定中にセキュリティードメインに参加していると、エンタープライズ管理者としてサブシステム固有のロールが自動的に割り当てられます。これらのロールはセキュリティードメインのサブシステム間で信頼できる関係を自動的に提供し、各サブシステムが他のサブシステムと効率的に対話できるようにします。
14.2.1. 管理者
ロール | 説明 |
---|---|
セキュリティードメインの管理者 |
デフォルトでは、ドメインをホストする CA の CA 管理者はセキュリティードメイン管理者として割り当てられます。
|
エンタープライズ CA 管理者 |
|
エンタープライズ KRA 管理者 |
|
エンタープライズ OCSP 管理者 |
|
エンタープライズ TKS 管理者 |
|
エンタープライズ TPS 管理者 |
|
14.2.2. 監査者
14.2.3. エージェント
- 証明書マネージャーエージェントグループ。
- キーリカバリー認証局エージェントグループ。
- オンライン証明書ステータスマネージャーエージェントグループ。
- トークンキーサービスエージェントのグループ。
- Token Processing System Agents グループ。
14.2.4. エンタープライズグループ
- エンタープライズ CA 管理者
- エンタープライズ KRA 管理者
- エンタープライズ OCSP 管理者
- エンタープライズ TKS 管理者
- エンタープライズ TPS 管理者
14.3. CA、OCSP、KRA、または TKS のユーザーおよびグループの管理
14.3.1. グループの管理
14.3.1.1. 新規グループの作成
- 管理コンソールにログインします。
pkiconsole https://server.example.com:8443/subsystem_type
- 左側のナビゲーションメニューから Users and Groups を選択します。
- Groups タブを選択します。
- 内部データベースにすでに存在するユーザーのみを追加することが可能です。
- ACL を編集して、グループの権限を付与します。詳細は、「ACL の編集」 を参照してください。グループの ACL に ACI が追加されていない場合、グループには Certificate System の一部にアクセスパーミッションがありません。
14.3.1.2. グループのメンバーの変更
- 管理コンソールにログインします。
- 左側のナビゲーションツリーから Users and Groups を選択します。
- Groups タブをクリックします。
- 名前の一覧からグループを選択し、をクリックします。
- 適切な変更を加えます。
- グループの説明を変更するには、Group description フィールドに新しい説明を入力します。
- グループからユーザーを削除するには、ユーザーを選択し、をクリックします。
- ユーザーを追加するには、をクリックします。ダイアログボックスから追加するユーザーを選択し、 をクリックします。
14.3.2. ユーザーの管理 (管理者、エージェント、および監査者)
14.3.2.1. ユーザーの作成
14.3.2.1.1. コマンドラインでのユーザーの作成
- ユーザーアカウントを追加します。たとえば、
example
ユーザーを CA に追加するには、以下を実行します。# pki -d ~/.dogtag/pki-instance_name/ca/alias/ -c password -n caadmin \ ca-user-add example --fullName "Example User" --------------------- Added user "example" --------------------- User ID: example Full name: Example User
このコマンドは、caadmin
ユーザーを使用して新規アカウントを追加します。 - 必要に応じて、グループにユーザーを追加します。たとえば、
example
ユーザーをCertificate Manager Agents
グループに追加するには、次のコマンドを実行します。# pki -d ~/.dogtag/pki-instance_name/ -p password -n "caadmin" \ user-add-membership example Certificate Manager Agents
- 証明書要求を作成します。
- Certificate System 環境に Key Recovery Authority (KRA) が存在する場合は、以下を行います。
# CRMFPopClient -d ~/.dogtag/pki-instance_name/ -p password \ -n "user_name" -q POP_SUCCESS -b kra.transport -w "AES/CBC/PKCS5Padding" \ -v -o ~/user_name.req
このコマンドは、証明書署名要求 (CSR) を~/user_name.req
ファイルにCRMF
形式を保存します。 - 証明書システム環境に Key Recovery Authority (KRA) が存在しない場合は、以下を行います。
- NSS データベースディレクトリーを作成します。
#
export pkiinstance=ca1
#
echo ${pkiinstance}
#
export agentdir=~/.dogtag/${pkiinstance}/agent1.dir
#
echo ${agentdir}
#
pki -d ${agentdir}/ -C ${somepwdfile} client-init
- CSR を
-o
オプションで指定された PKCS-#10 フォーマットファイルに保存し、初期化された NSS データベースディレクトリーへのパスの場合は-d
、パスワードファイルの場合は-P
オプション、パスワードの場合は-p
、サブジェクト DN の場合は-n
を保存します。#
PKCS10Client -d ${agentdir}/ -P ${somepwdfile} -n "cn=agent1,uid=agent1" -o ${agentdir}/agent1.csr
PKCS10Client: Certificate request written into /.dogtag/ca1/agent1.dir/agent1.csr PKCS10Client: PKCS#10 request key id written into /.dogtag/ca1/agent1.dir/agent1.csr.keyId
- 登録リクエストを作成します。
~/cmc.role_crmf.cfg
ファイルを以下の内容で作成します。#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 #Multiple files are supported. They must be separated by space. input=~/user_name.req #output: full path for the CMC request in binary format output=~/cmc.role_crmf.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=PKI Administrator for Example.com #dbdir: directory for cert8.db, key3.db and secmod.db dbdir=~/.dogtag/pki-instance_name/ #password: password for cert8.db which stores the agent #certificate password=password #format: request format, either pkcs10 or crmf format=crmf
直前の手順で使用した環境および CSR 形式に基づいて、パラメーターを設定します。- 以前に作成した設定ファイルを
CMCRequest
ユーティリティーに渡して、CMC 要求を作成します。# CMCRequest ~/cmc.role_crmf.cfg
- CMS (CMC) 要求で Certificate Management を送信します。
~/HttpClient_role_crmf.cfg
ファイルを以下の内容で作成します。# #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=~/cmc.role_crmf.req #output: full path for the response in binary format output=~/cmc.role_crmf.resp #tokenname: name of token where SSL 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=~/.dogtag/pki-instance_name/ #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=PKI Administrator for Example.com #servlet: servlet name servlet=/ca/ee/ca/profileSubmitCMCFull
環境に応じてパラメーターを設定します。- CA に要求を送信します。
# HttpClient ~/HttpClient_role_crmf.cfg Total number of bytes read = 3776 after SSLSocket created, thread token is Internal Key Storage Token client cert is not null handshake happened writing to socket Total number of bytes read = 2523 MIIJ1wYJKoZIhvcNAQcCoIIJyDCCCcQCAQMxDzANBglghkgBZQMEAgEFADAxBggr ... The response in data format is stored in ~/cmc.role_crmf.resp
- 結果を確認します。
# CMCResponse ~/cmc.role_crmf.resp Certificates: Certificate: Data: Version: v3 Serial Number: 0xE Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11 Issuer: CN=CA Signing Certificate,OU=pki-instance_name Security Domain Validity: Not Before: Friday, July 21, 2017 12:06:50 PM PDT America/Los_Angeles Not After: Wednesday, January 17, 2018 12:06:50 PM PST America/Los_Angeles Subject: CN=user_name ... Number of controls is 1 Control #0: CMCStatusInfoV2 OID: {1 3 6 1 5 5 7 7 25} BodyList: 1 Status: SUCCESS
- 必要に応じて、証明書をユーザー自身の
~/.dogtag/pki-instance_name/
データベースにインポートするには、次のコマンドを実行します。# certutil -d ~/.dogtag/pki-instance_name/ -A -t "u,u,u" -n "user_name certificate" -i ~/cmc.role_crmf.resp
- ユーザーレコードに証明書を追加します。
- ユーザーのシリアル番号を検出できる証明書を一覧表示します。たとえば、証明書のサブジェクトに
example
ユーザー名が含まれる証明書を一覧表示するには、次のコマンドを実行します。pki -d ~/.dogtag/pki-instance_name/ -c password -n caadmin ca-user-cert-find example ----------------- 1 entries matched ----------------- Cert ID: 2;6;CN=CA Signing Certificate,O=EXAMPLE;CN=PKI Administrator,E=example@example.com,O=EXAMPLE Version: 2 Serial Number: 0x6 Issuer: CN=CA Signing Certificate,O=EXAMPLE Subject: CN=PKI Administrator,E=example@example.com,O=EXAMPLE ---------------------------- Number of entries returned 1
次の手順では、証明書のシリアル番号が必要です。 - シリアル番号を使用して、証明書リポジトリーから Certificate System データベースのユーザーアカウントに証明書を追加します。たとえば、CA ユーザーの場合は以下を実行します。
pki -c password -n caadmin ca-user-cert-add example --serial 0x6
14.3.2.1.2. コンソールを使用したユーザーの作成
- 管理コンソールにログインします。
pkiconsole https://server.example.com:8443/subsystem_type
- Configuration タブで、Users and Groups を選択します。 をクリックします。
- Edit User Information ダイアログに情報を入力します。情報のほとんどは、ユーザー名、メールアドレス、パスワードなどの標準のユーザー情報です。このウィンドウには、User State と呼ばれるフィールドも含まれ、このフィールドには、ユーザーに関する追加情報を追加するのに使用される文字列を含めることができます。ほとんどの場合、このフィールドは、アクティブユーザーであるかどうかを確認できます。
- ユーザーが属するグループを選択します。ユーザーのグループメンバーシップは、ユーザーが持つ特権を決定します。エージェント、管理者、および監査人を適切なサブシステムグループに割り当てます。
- ユーザーの証明書を保存します。
- CA エンドエンティティーサービスページでユーザー証明書を要求します。
- ユーザープロファイルに対して自動登録が設定されていない場合は、証明書要求を承認します。
- 通知メールで提供される URL を使用して証明書を取得し、base-64 でエンコードされた証明書をローカルファイルまたはクリップボードにコピーします。
- 新しいユーザーエントリーを選択し、をクリックします。
14.3.2.2. 証明書システムユーザー証明書の変更
- 管理コンソールにログインします。
- Users and Groups を選択します。
- ユーザー ID の一覧から編集するユーザーを選択し、をクリックします。
- Import Certificate ウィンドウで、テキストエリアに新しい証明書を貼り付けます。-----BEGIN CERTIFICATE----- および -----END CERTIFICATE----- マーカー行を含めます。
14.3.2.3. 管理者、エージェント、および監査ユーザー証明書の更新
- 「証明書ベースの更新」 の説明に従って、CA のエンドユーザーフォームで管理ユーザー証明書を更新します。これは、最初に発行した証明書 (またはそのクローン) と同じ CA である必要があります。エージェント証明書は、エンドエンティティーページで証明書ベースの更新フォームを使用して更新できます。Self-renew user SSL client certificate。このフォームは、ブラウザーの証明書ストアに保存されている証明書を直接認識して更新します。注記「certutil を使用した証明書の更新」 で説明されているように、certutil を使用して証明書を更新することもできます。ブラウザーに保存されている証明書を使用して更新を開始するのではなく、certutil は元のキーで入力ファイルを使用します。
- 更新されたユーザー証明書を内部 LDAP データベースのユーザーエントリーに追加します。
- サブシステムのコンソールを開きます。
pkiconsole https://server.example.com:admin_port/subsystem_type
- 設定 | ユーザーとグループ | ユーザー | 管理 | 証明書 | インポート
- Configuration タブで、Users and Groups を選択します。
- Users タブで、更新された証明書でユーザーエントリーをダブルクリックして、 をクリックします。
これは、ldapmodify を使用して、uid=admin,ou=people,dc=subsystem-base-DN など、ユーザーエントリーのuserCertificate
属性を置き換え、内部の LDAP データベースでユーザーエントリーに直接更新した証明書を追加しました。
14.3.2.4. 期限切れの管理者、エージェント、および監査者のユーザー証明書の更新
pki
コマンドラインツールも使用できなくなります。このようなシナリオでは、pki-server cert-fix コマンドを使用して、期限切れの証明書を更新できます。
- 有効な CA 証明書があります。
- root 権限がある
手順14.1 期限切れの管理者、エージェント、および監査者のユーザー証明書の更新
- セルフテストを無効にします。
- 次のコマンドを実行します。
#
pki-server selftest-disable -i PKI_instance
- または、CA の
CS.cfg
ファイルから次の行を削除し、CA サブシステムを再起動します。selftests.container.order.startup=CAPresence:critical, SystemCertsVerification:critical
- クライアントの NSS データベースで期限切れの証明書を確認し、証明書のシリアル番号 (証明書 ID) を見つけます。
- ユーザー証明書をリスト表示します。
#
certutil -L -d /root/nssdb/
- 更新する期限切れの証明書のシリアル番号を取得します。
#
certutil -L -d /root/nssdb/ -n Expired_cert | grep Serial
Serial Number: 16 (0x10)
- 証明書を更新します。ローカル LDAP サーバーには、LDAP Directory Manager のパスワードが必要です。
#
pki-server cert-fix --ldap-url ldap://host389 --agent-uid caadmin -i PKI_instance -p PKI_https_port --extra-cert 16
- セルフテストを再度有効にします。
- 次のコマンドを実行します。
#
pki-server selftest-enable -i PKI_instance
- または、次の行を CA の
CS.cfg
ファイルに追加して、CA サブシステムを再起動します。selftests.container.order.startup=CAPresence:critical, SystemCertsVerification:critical
#
pki ca-cert-find
#
pki ca-cert-show 16 --pretty
14.3.2.5. 証明書システムユーザーの削除
- 管理コンソールにログインします。
- 左側のナビゲーションメニューから Users and Groups を選択します。
- ユーザー ID の一覧からユーザーを選択して、をクリックします。
- プロンプトが表示されたら、削除を確認します。
14.4. TPS のユーザーの作成および管理
- エージェント (トークンのステータスの設定やトークンポリシーの変更など、実際のトークン管理操作を実行するエージェント)
- 管理者 (TPS サブシステムのユーザーを管理し、トークンの制御を制限)
- オペレーター (管理制御がないが、TPS からトークン、証明書、およびアクティビティーを表示および一覧表示できる)
https://server.example.com:8443/tps/ui/
でアクセスできます。
14.4.1. ユーザーの一覧表示および検索
14.4.1.1. Web UI での操作
- Accounts タブをクリックします。
- Users メニュー項目をクリックします。ユーザーの一覧が表示されます。
- 特定のユーザーを検索するには、検索フィールドにキーワードを入力して
Enter
を押します。すべてのユーザーを再度一覧表示するには、キーワードを削除してEnter
キーを押します。
14.4.1.2. コマンドラインでの操作
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-user-find
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-user-show username
14.4.2. ユーザーの追加
14.4.2.1. Web UI での操作
- Accounts タブをクリックします。
- Users メニュー項目をクリックします。
- Users ページの Add ボタンをクリックします。
- ユーザー ID、フルネーム、および TPS プロファイルを入力します。
- Save ボタンをクリックします。
14.4.2.1.1. コマンドラインでの操作
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-user-add username --fullName full_name
14.4.3. ユーザーのプロファイルの設定
CS.cfg
に追加され、CA のトークンプロファイルをトークンタイプにマッピングします。トークンマッピングの設定は、「Mapping Resolver の設定」 で説明されています。
- Accounts タブをクリックします。
- Users メニュー項目をクリックします。
- 変更するユーザーのユーザー名をクリックします。
- Edit のリンクをクリックします。
- TPS Profile フィールドにプロファイル名をコンマで区切って入力するか、
All Profiles
を入力します。 - Save ボタンをクリックします。
14.4.4. ユーザーロールの管理
14.4.4.1. Web UI での操作
- Accounts タブをクリックします。
- Groups メニュー項目をクリックします。
- TPS エージェントなど、変更するグループの名前をクリックします。
- このグループにユーザーを追加するには、以下を実行します。
- Add ボタンをクリックします。
- ユーザー ID を入力します。
- Add ボタンをクリックします。
- このグループからユーザーを削除するには、次を実行します。
- ユーザーの横にあるチェックボックスを選択します。
- Remove ボタンをクリックします。
- OK ボタンをクリックします。
14.4.4.2. コマンドラインでの操作
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-group-find
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-group-member-find group_name
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-group-member-add group_name user_name
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-group-member-del group_name user_name
14.4.5. ユーザー証明書の管理
- ユーザー証明書を一覧表示するには、以下を実行します。
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-user-cert-find user_name
- 証明書をユーザーに追加するには、以下を実行します。
- 新規ユーザーのユーザー証明書を取得します。証明書の要求および送信については、5章証明書の要求、登録、および管理 で説明されています。重要TPS 管理者が署名証明書が必要です。使用する推奨プロファイルは、手動のユーザー署名および暗号化証明書の登録です。
- 次のコマンドを実行します。
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-user-cert-add user_name --serial cert_serial_number
- ユーザーから証明書を削除するには、以下を実行します。
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-user-cert-del user_name cert_id
14.4.6. TPS エージェントおよび管理者証明書の更新
- 「証明書ベースの更新」 の説明に従って、CA のエンドユーザーフォームでユーザー証明書を更新します。これは、最初に発行した証明書 (またはそのクローン) と同じ CA である必要があります。エージェント証明書は、エンドエンティティーページの証明書ベースの更新フォーム (Self-renew user SSL client certificate) を使用して更新できます。このフォームは、ブラウザーの証明書ストアに保存されている証明書を直接認識して更新します。注記「certutil を使用した証明書の更新」 で説明されているように、certutil を使用して証明書を更新することもできます。ブラウザーに保存されている証明書を使用して更新を開始するのではなく、certutil は元のキーで入力ファイルを使用します。
- 新しい証明書をユーザーに追加し、「ユーザー証明書の管理」 の説明に従って古い証明書を削除します。
14.4.7. ユーザーの削除
- Accounts タブをクリックします。
- Users メニュー項目をクリックします。
- 削除するユーザーの横にあるチェックボックスを選択します。
- Remove ボタンをクリックします。
- OK ボタンをクリックします。
pki -d client_db_dir -c client_db_password -n admin_cert_nickname tps-user-del user_name
14.5. ユーザーのアクセス制御の設定
14.5.1. アクセス制御について
allow|deny (operation) user|group|IP="name"
allow (read) group="Administrators"
allow (read,modify) group="Administrators"
allow (read) group="Administrators" || group="Auditors"
Allow (read,modify) group="Auditors" || user="BrianC"
group="Administrators" || group!="Auditors"
group="* Managers"
user="BobC" || user!="JaneK"
user="anybody"
user="*johnson"
ipaddress="12.33.45.99" ipaddress!="23.99.09.88"
ipaddress="0:0:0:0:0:0:13.1.68.3"
ipaddress="12.33.45.*"
user="BobC" || group="Auditors" || group="Administrators"
14.5.2. サブシステムのアクセス制御設定の変更
CS.cfg
ファイルを編集してこの機能を設定する方法は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』の『サブシステムのアクセス制御設定の変更』を参照してください。
14.5.3. ACL の追加
- 管理コンソールにログインします。
- Access Control List を選択します。
- Access Control Editor を開きます。をクリックして、
Resource name
およびAvailable rights
フィールドに入力します。- アクセス制御指示 (ACI) を追加するには、をクリックし、ACI 情報を提供します。
- 指定したグループ、ユーザー、または IP アドレスへの操作を許可または拒否するには、Access フィールドから allow または deny ラジオボタンを選択します。アクセスの許可または拒否に関する詳細は、「アクセス制御について」を参照してください。
- 権限を設定します。利用できるオプションは、read および modify です。両方を選択するには、エントリーの選択中に ボタンまたは ボタンを保持します。
- Syntax フィールドでアクセスを許可または拒否されるユーザー、グループ、または IP アドレスを指定します。構文の詳細は、「アクセス制御について」を参照してください。
- Access Control Editor 画面に戻ります。をクリックして、
14.5.4. ACL の編集
- 管理コンソールにログインします。
- 左側のナビゲーションメニューで、Access Control List を選択します。
- リストから編集する ACL を選択し、をクリックします。アクセス制御エディター ウィンドウで ACL が開きます。
- ACI を追加するには、をクリックし、ACI 情報を指定します。ACI を編集するには、ACL Editor 画面の ACI entries テキスト領域で ACI を選択します。 をクリックします。
- 指定したグループ、ユーザー、または IP アドレスへの操作を許可または拒否するには、Access フィールドから allow または deny ラジオボタンを選択します。アクセスの許可または拒否に関する詳細は、「アクセス制御について」を参照してください。
- アクセス制御の権限を設定します。オプションは read および modify です。両方を設定するには、 ボタンまたは ボタンを使用します。
- Syntax フィールドでアクセスを許可または拒否されるユーザー、グループ、または IP アドレスを指定します。構文の詳細は、「アクセス制御について」を参照してください。
第15章 サブシステムログの設定
pki_subsystem_log_path
に指定されているすべてのディレクトリーに配置されます。 通常の監査ログは他のログタイプとともにログディレクトリーに置かれ、署名された監査ログは /var/log/pki/instance_name/subsystem_name/signedAudit
に書き込まれます。ログのデフォルトの場所を変更するには、設定を変更してください。
15.1. Certificate System ログについて
15.1.1. システムログ
system
です。サーバーへの要求に関する情報 (HTTP および HTTPS のすべてのリクエスト) とサーバーからの応答を記録します。このログに記録される情報には、サーバーにアクセスしたクライアントマシンの IP アドレス (IPv4 と IPv6 の両方)、検索、追加、編集などの実行される操作、返されたエントリーの数などのアクセスの結果が含まれます。
id_number processor - [date:time] [number_of_operations] [result] servlet: message
例15.1 TKS システムログ
10439.http-13443-Processor25 - [19/May/2020:14:16:51 CDT] [11] [3] UGSubsystem: Get User Error User not found
15.1.2. トランザクションログ
transactions
で、サブシステムに実行された操作または送信された操作をすべて記録します。
id_number.processor - [date:time] [number_of_operations] [result] servlet: message
例15.2 トランザクションログ
11438.http-8443-Processor25 - [27/May/2020:07:56:18 CDT] [1] [1] archival reqID 4 fromAgent agentID: CA-server.example.com-8443 authenticated by noAuthManager is completed DN requested: UID=recoverykey,E=recoverykey@email.com,CN=recover key serial number: 0x3
15.1.3. デバッグログ
[date:time] [processor]: servlet: message
[10/Jun/2020:05:14:51][main]: Established LDAP connection using basic authentication to host localhost port 389 as cn=Directory Manager
[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestowner$ value=KRA-server.example.com-8443
例15.3 CA 証明書要求ログメッセージ
[06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profileapprovedby$ value=admin [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.cert_request$ value=MIIBozCCAZ8wggEFAgQqTfoHMIHHgAECpQ4wDDEKMAgGA1UEAxMBeKaBnzANBgkqhkiG9w0BAQEFAAOB... [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profile$ value=true [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.cert_request_type$ value=crmf [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestversion$ value=1.0.0 [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_locale$ value=en [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestowner$ value=KRA-server.example.com-8443 [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.dbstatus$ value=NOT_UPDATED [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.subject$ value=uid=jsmith, e=jsmith@example.com [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requeststatus$ value=begin [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.user$ value=uid=KRA-server.example.com-8443,ou=People,dc=example,dc=com [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_key$ value=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDreuEsBWq9WuZ2MaBwtNYxvkLP^M HcN0cusY7gxLzB+XwQ/VsWEoObGldg6WwJPOcBdvLiKKfC605wFdynbEgKs0fChV^M k9HYDhmJ8hX6+PaquiHJSVNhsv5tOshZkCfMBbyxwrKd8yZ5G5I+2gE9PUznxJaM^M HTmlOqm4HwFxzy0RRQIDAQAB [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.authmgrinstname$ value=raCertAuth [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.uid$ value=KRA-server.example.com-8443 [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.userid$ value=KRA-server.example.com-8443 [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestor_name$ value= [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.profileid$ value=caUserCert [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.userdn$ value=uid=KRA-server.example.com-4747,ou=People,dc=example,dc=com [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.requestid$ value=20 [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.auth_token.authtime$ value=1212782378071 [06/Jun/2020:14:59:38][http-8443;-Processor24]: ProfileSubmitServlet: key=$request.req_x509info$ value=MIICIKADAgECAgEAMA0GCSqGSIb3DQEBBQUAMEAxHjAcBgNVBAoTFVJlZGJ1ZGNv^M bXB1dGVyIERvbWFpbjEeMBwGA1UEAxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4X^M DTA4MDYwNjE5NTkzOFoXDTA4MTIwMzE5NTkzOFowOzEhMB8GCSqGSIb3DQEJARYS^M anNtaXRoQGV4YW1wbGUuY29tMRYwFAYKCZImiZPyLGQBARMGanNtaXRoMIGfMA0G^M CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDreuEsBWq9WuZ2MaBwtNYxvkLPHcN0cusY^M 7gxLzB+XwQ/VsWEoObGldg6WwJPOcBdvLiKKfC605wFdynbEgKs0fChVk9HYDhmJ^M 8hX6+PaquiHJSVNhsv5tOshZkCfMBbyxwrKd8yZ5G5I+2gE9PUznxJaMHTmlOqm4^M HwFxzy0RRQIDAQABo4HFMIHCMB8GA1UdIwQYMBaAFG8gWeOJIMt+aO8VuQTMzPBU^M 78k8MEoGCCsGAQUFBwEBBD4wPDA6BggrBgEFBQcwAYYuaHR0cDovL3Rlc3Q0LnJl^M ZGJ1ZGNvbXB1dGVyLmxvY2FsOjkwODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMCBeAw^M HQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMCQGA1UdEQQdMBuBGSRyZXF1^M ZXN0LnJlcXVlc3Rvcl9lbWFpbCQ=
[07/Jul/2020:06:25:40][http-11180-Processor25]: OCSPServlet: OCSP Request: [07/Jul/2020:06:25:40][http-11180-Processor25]: OCSPServlet: MEUwQwIBADA+MDwwOjAJBgUrDgMCGgUABBSEWjCarLE6/BiSiENSsV9kHjqB3QQU
15.1.3.1. インストールログ
/var/log/pki/
ディレクトリーに、名前が pki-subsystem_name-spawn.timestamp.log
の形式で指定します。
例15.4 CA インストールログ
... 2015-07-22 20:43:13 pkispawn : INFO ... finalizing 'pki.server.deployment.scriptlets.finalization' 2015-07-22 20:43:13 pkispawn : INFO ....... cp -p /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg /var/log/pki/pki-tomcat/ca/archive/spawn_deployment.cfg.20150722204136 2015-07-22 20:43:13 pkispawn : DEBUG ........... chmod 660 /var/log/pki/pki-tomcat/ca/archive/spawn_deployment.cfg.20150722204136 2015-07-22 20:43:13 pkispawn : DEBUG ........... chown 26445:26445 /var/log/pki/pki-tomcat/ca/archive/spawn_deployment.cfg.20150722204136 2015-07-22 20:43:13 pkispawn : INFO ....... generating manifest file called '/etc/sysconfig/pki/tomcat/pki-tomcat/ca/manifest' 2015-07-22 20:43:13 pkispawn : INFO ....... cp -p /etc/sysconfig/pki/tomcat/pki-tomcat/ca/manifest /var/log/pki/pki-tomcat/ca/archive/spawn_manifest.20150722204136 2015-07-22 20:43:13 pkispawn : DEBUG ........... chmod 660 /var/log/pki/pki-tomcat/ca/archive/spawn_manifest.20150722204136 2015-07-22 20:43:13 pkispawn : DEBUG ........... chown 26445:26445 /var/log/pki/pki-tomcat/ca/archive/spawn_manifest.20150722204136 2015-07-22 20:43:13 pkispawn : INFO ....... executing 'systemctl enable pki-tomcatd.target' 2015-07-22 20:43:13 pkispawn : INFO ....... executing 'systemctl daemon-reload' 2015-07-22 20:43:13 pkispawn : INFO ....... executing 'systemctl restart pki-tomcatd@pki-tomcat.service' 2015-07-22 20:43:14 pkispawn : INFO END spawning subsystem 'CA' of instance 'pki-tomcat' 2015-07-22 20:43:14 pkispawn : DEBUG
15.1.3.2. Tomcat のエラーとアクセスログ
- admin.timestamp
- catalina.timestamp
- catalina.out
- host-manager.timestamp
- localhost.timestamp
- localhost_access_log.timestamp
- manager.timestamp
15.1.3.3. セルフテストログ
CS.cfg
ファイルの設定を変更することでのみ設定できます。CS.cfg
ファイルを編集してログを設定する方法は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の 『公開キューの有効化』 セクションを参照してください。
15.2. ログの管理
15.2.1. ログ設定の概要
15.2.1.1. ログに記録されるサービス
サービス | 説明 |
---|---|
ACL | アクセス制御リストに関連するイベントをログに記録します。 |
管理 | コンソールとインスタンス間の HTTPS 通信など、管理アクティビティーに関連するイベントをログに記録します。 |
すべて | すべてのサービスに関連するイベントをログに記録します。 |
認証 | 認証モジュールに関連するアクティビティーに関連するイベントをログに記録します。 |
認証局 | Certificate Manager に関連するイベントをログに記録します。 |
データベース | 内部データベース関連のアクティビティーに関連するイベントをログに記録します。 |
HTTP |
サーバーの HTTP アクティビティーに関連するイベントをログに記録します。HTTP イベントは実際には、HTTP サービスを提供するために Certificate System に組み込まれる Apache サーバーに属するエラーログに記録されることに注意してください。
|
キーリカバリー認証局 | KRA に関連するイベントをログに記録します。 |
LDAP | 証明書と CRL の公開に使用される LDAP ディレクトリーを使用してアクティビティーに関連するイベントをログに記録します。 |
OCSP | OCSP ステータスの GET 要求など、OCSP に関連するイベントをログに記録します。 |
その他 | コマンドラインユーティリティーやその他のプロセスなどの他のアクティビティーに関連するイベントをログに記録します。 |
要求キュー | 要求キューアクティビティーに関連するイベントをログに記録します。 |
ユーザーおよびグループ | インスタンスのユーザーおよびグループに関連するイベントをログに記録します。 |
15.2.1.2. ログレベル (メッセージカテゴリー)
ログレベル | メッセージカテゴリー | 説明 |
---|---|---|
0-1 | トレース | これらのメッセージには、より詳細なデバッグ情報が含まれます。このレベルはパフォーマンスに影響する可能性があるため、定期的に使用しないでください。 |
2-5 | デバッグ | これらのメッセージにはデバッグ情報が含まれます。このレベルは、非常に多くの情報を生成するため、通常の使用には推奨されません。 |
6-10 | 情報提供 | これらのメッセージは、証明書システムの初期化完了 や 成功した操作要求 などのステータスメッセージを含む、証明書システムの状態に関する一般的な情報を提供します。 |
11-15 | 警告 | これらのメッセージは警告のみであり、サーバーの通常の操作に障害があることを示すものではありません。 |
> 15 | 失敗 | これらのメッセージは、証明書サービス操作の実行の失敗 (User authentication failed または Certificate revoked) や、取り消せないエラーを引き起こす可能性のある予期しない状況 (リクエストがクライアントからされた同じチャネルでクライアントに対して処理された要求を返信できない) など、サーバーが正常に動作することを妨げるエラーおよび障害を示します。レベルを 15 より上に設定すると、障害のみが記録されるため、ログが最小限に抑えられます。 |
15.2.1.3. バッファー付きおよびバッファーなしのロギング
- バッファーが満杯になった場合。バッファーサイズが bufferSize 設定パラメーターで指定された値以上になると、バッファーが満杯になります。このパラメーターのデフォルト値は 512 KB です。
- バッファーのフラッシュ間隔に到達した場合。最後のバッファーフラッシュからの経過時間、または flushInterval 設定パラメーターで指定された値と同じか大きい場合は、フラッシュ間隔に到達します。このパラメーターのデフォルト値は 5 秒です。
- 現在のログがコンソールから読み取られる場合。サーバーは現在のログについてクエリーされる際に最新のログを取得します。
15.2.1.4. ログファイルローテーション
- 対応するファイルのサイズ制限に到達した場合。対応するログファイルのサイズは、maxFileSize 設定パラメーターで指定された値以下である必要があります。このパラメーターのデフォルト値は 100 KB です。
- 対応するファイルの経過時間制限に到達した場合。対応するログファイルは、rolloverInterval 設定パラメーターで指定された間隔以上です。このパラメーターのデフォルト値は 2592000 秒 (30 日ごと) です。
log
ディレクトリー全体をアーカイブメディアにコピーして、これらのファイルを定期的に一部のバックアップメディアにアーカイブする必要があります。
15.2.2. コンソールでログの設定
CS.cfg
ファイルを使用して設定できます。署名付き監査ログやカスタムログなどの特別なログは、コンソールまたは設定ファイルからも作成できます。
- Configuration タブのナビゲーションツリーで Log を選択します。
- ログイベントリスナー管理 タブには、現在設定されているリスナーが一覧表示されます。新しいログインスタンスを作成するには、Select Log Event Listener Plug-in Implementation ウィンドウの一覧からモジュールプラグインを選択します。をクリックし、
- Log Event Listener Editor ウィンドウでフィールドを設定または変更します。表15.3「ログイベントリスナーフィールド」 に、さまざまなパラメーターを記載しています。
フィールド | 説明 |
---|---|
Log Event Listener ID | リスナーを識別する一意の名前を指定します。この名前には、文字 (aA から zZ)、数字 (0 から 9)、アンダースコア (_)、およびハイフン (-) を使用できますが、他の文字やスペースは使用できません。 |
type | ログファイルのタイプを指定します。システム はエラーおよびシステムログを作成します。トランザクション は監査ログを記録します。 |
enabled | ログがアクティブかどうかを設定します。有効にするログのみがイベントを記録します。値は true または false です。 |
level | テキストフィールドにログレベルを設定します。このレベルは、フィールドに手動で入力する必要があります。選択メニューはありません。Debug、Information、Warning、Failure、Misconfiguration、Catastrophe、および Security を選択できます。詳細は、「ログレベル (メッセージカテゴリー)」を参照してください。 |
fileName | ログファイルへのファイル名を含む完全パスを指定します。サブシステムユーザーには、ファイルへの読み書きパーミッションがなければなりません。 |
bufferSize | ログのキロバイトサイズ (KB) のバッファーサイズを設定します。バッファーがこのサイズに達すると、バッファーの内容はフラッシュされ、ログファイルにコピーされます。デフォルトのサイズは 512 KB です。バッファーロギングの詳細は、「バッファー付きおよびバッファーなしのロギング」 を参照してください。 |
flushInterval | バッファーの内容がフラッシュされてログファイルに追加されるまでの時間を設定します。デフォルトの間隔は 5 秒です。 |
maxFileSize | ローテーションされる前に可能なログファイルのサイズをキロバイト (KB) 単位で設定できます。このサイズに達すると、ファイルはローテーションファイルにコピーされ、ログファイルが新たに開始されます。ログファイルのローテーションに関する詳細は、「ログファイルローテーション」を参照してください。デフォルトのサイズは 2000 KB です。 |
rolloverInterval | アクティブなログファイルをローテートするようにサーバーの頻度を設定します。利用可能なオプションは hourly、daily、weekly、monthly、および yearly です。デフォルトは monthly です。詳細は、「ログファイルローテーション」 を参照してください。 |
15.2.3. CS.cfg ファイルでのログの設定
CS.cfg
ファイルを編集してこのログを設定する方法は、『Red Hat Certificate System の計画、インストール、およびデプロイメントのガイド』 の 『CS.cfg での CRL の更新間隔の設定』 セクションを参照してください。
15.2.4. 監査ログの管理
/var/log/pki/instance_name/subsystem_name/
ディレクトリーと他のタイプのログにありますが、署名済み監査ログは /var/log/pki/instance_name/subsystem_name/signedAudit/
に書き込まれます。ログのデフォルトの場所を変更するには、設定を変更してください。
15.2.4.1. 監査イベントの一覧
15.2.4.2. インストール後の署名監査ロギングの有効化
pki_audit_group
デプロイメントパラメーターを使用して、インスタンスの初回作成時にデフォルトで有効にできます。ただし、インスタンスの作成時に署名された監査ログを設定しなかった場合には、audit ログディレクトリーの所有権を pkiaudit
などの auditor システムユーザーグループに再割り当てすることで、このログを有効にできます。
- インスタンスを停止します。
systemctl stop pki-tomcatd@instance_name.service
- 署名付き監査ログディレクトリーのグループ所有権を、
pkiaudit
のような PKI 監査ログのオペレーティングシステムグループに設定します。これにより、PKI auditors グループのユーザーにsignedAudit
ディレクトリーへの必要な読み取りアクセスが許可され、ログファイルの署名を確認することができます。ユーザー (Certificate System ユーザーアカウント pkiuser を除く) に、このディレクトリーのログファイルへの書き込みアクセス権があるはずです。chgrp -R pkiaudit /var/log/pki/instance_name/subsystem_name/signedAudit
- インスタンスを再起動します。
systemctl start pki-tomcatd@instance_name.service
15.2.4.3. コンソールでの署名監査ログの設定
- コンソールを開きます。注記
CS.cfg
ファイルを編集して監査ログを作成または設定するには、『Red Hat Certificate System 計画、インストール、およびデプロイメントガイド』 の 『CS.cfg ファイルのログの設定』 を参照してください。 - Configuration タブのナビゲーションツリーで Log を選択します。
- ログイベントリスナー管理 タブで、SignedAudit エントリーを選択します。
- Log Event Listener Editor ウィンドウでリセットする必要のある 3 つのフィールドがあります。
- signedAuditCertNickname を入力します。これは、監査ログの署名に使用される証明書のニックネームです。監査署名証明書はサブシステムが設定されているときに作成され、auditSigningCert cert-instance_name subsystem_name のようなニックネームがあります。注記監査署名証明書のニックネームを取得するには、certutil を使用してサブシステムの証明書データベースの証明書を一覧表示します。以下に例を示します。
certutil -L -d /var/lib/pki-tomcat/alias Certificate Authority - Example Domain CT,c, subsystemCert cert-pki-tomcat u,u,u Server-Cert cert-pki-tomcat u,u,u auditSigningCert cert-pki-tomcat CA u,u,Pu
- logSigning フィールドを true に設定して、署名済みロギングを有効にします。
- 監査ログに記録される イベント を設定します。付録E 監査イベント ログ可能なイベントを一覧表示します。ログイベントは、空白のないコンマで区切ります。
- ファイル名、ログレベル、ファイルサイズ、ローテーションスケジュールなど、ログに関するその他の設定を行います。注記デフォルトでは、通常の監査ログは
/var/log/pki/instance_name/subsystem_name/
ディレクトリーと他のタイプのログにありますが、署名済み監査ログは/var/log/pki/instance_name/subsystem_name/signedAudit/
に書き込まれます。ログのデフォルトの場所を変更するには、設定を変更してください。 - ログ設定を保存します。
AuditVerify(1)
を参照してください。
15.2.4.4. 監査ロギングエラーの処理
- サーブレットが無効になり、新しいリクエストを処理しません。
- 保留中のリクエストと新しいリクエストはすべて強制終了されます。
- サブシステムがシャットダウンしています。
15.2.4.5. ログファイルの署名
signtool -d secdb_dir -k cert_nickname -Z output input
- secdb_dir は、CA の証明書、キー、およびセキュリティーモジュールデータベースが含まれるディレクトリーへのパスを指定します。
- cert_nickname は、署名に使用する証明書のニックネームを指定します。
- output は JAR ファイルの名前 (署名された zip ファイル) を指定します。
- input は、ログファイルを含むディレクトリーへのパスを指定します。
15.2.4.6. 監査イベントのフィルタリング
タイプ | 形式 | 例 |
---|---|---|
Presence | (attribute=*) | (ReqID=*) |
Equality | (attribute=value) | (Outcome=Failure) |
Substring | (attribute=initial*any*...*any*final) | (SubjectID=*admin*) |
AND 演算 | (&(filter_1)(filter_2)...(filter_n)) | (&(SubjectID=admin)(Outcome=Failure)) |
OR 演算 | (|(filter_1)(filter_2)...(filter_n)) | (|(SubjectID=admin)(Outcome=Failure)) |
NOT 演算 | (!(filter)) | (!(SubjectID=admin)) |
例15.5 監査イベントのフィルタリング
InfoName
フィールドが rejectReadon または cancelReason に設定されている処理済み証明書要求のイベントと、プロファイル証明書要求およびイベントの失敗したイベントのみを記録するには、以下を実行します。
/var/lib/pki/instance_name/subsystem_type/conf/CS.cfg
ファイルを編集して、以下のパラメーターを設定します。log.instance.SignedAudit.filters.PROFILE_CERT_REQUEST=(Outcome=Failure) log.instance.SignedAudit.filters.CERT_REQUEST_PROCESSED=(|(InfoName=rejectReason)(InfoName=cancelReason))
- Certificate System を再起動します。
# systemctl restart pki-tomcatd@instance_name.service
15.2.5. ログモジュールの管理
classes
ディレクトリーに配置します。実装はクラスパス上になければなりません。
- カスタムジョブクラスを作成します。この例では、カスタムログプラグインは
MyLog.java
と呼ばれます。 - インスタンスの lib ディレクトリーに新しいクラスをコンパイルします。
javac -d . /var/lib/pki/pki-tomcat/lib -classpath $CLASSPATH MyLog.java
- CA がカスタムクラスにアクセスできるように、CA の
WEB-INF
Web ディレクトリーにディレクトリーを作成します。mkdir /var/lib/pki/pki-tomcat/webapps/ca/WEB-INF/classes
- 所有者を Certificate System のシステムユーザー (
pkiuser
) に設定します。chown -R pkiuser:pkiuser /var/lib/pki/pki-tomcat/lib
- プラグインを登録します。
- コンソールにログインします。
- Configuration タブで、ナビゲーションツリーから Logs を選択します。次に、Log Event Listener Plug-in Registration タブを選択します。
- Register Log Event Listener Plug-in Implementation ウィンドウが表示されます。
- プラグインモジュールの名前と、Java™ クラス名を指定します。Java™ クラス名は、実装する Java™ クラスの完全パスです。このクラスがパッケージに含まれる場合は、パッケージ名を含めます。たとえば、
com.customplugins
という名前のパッケージに customLog という名前のクラスを登録すると、クラス名は com.customplugins.customLog になります。
15.3. ログの使用
15.3.1. コンソールでログの表示
- コンソールにログインします。
- Status タブを選択します。
- Logs で表示するログを選択します。
- Display Options セクションで表示設定を行います。
- Entries: 表示するエントリーの最大数。この制限に達すると、Certificate System は検索要求に一致するエントリーを返します。ゼロ (0) はメッセージが返されないことを意味します。フィールドが空の場合、サーバーは見つかった数に関係なく、一致するすべてのエントリーを返します。
- Source: ログメッセージが表示される証明書システムコンポーネントまたはサービスを選択します。All を選択すると、このファイルにログ記録するすべてのコンポーネントによってログに記録されるメッセージが表示されます。
- レベル: メッセージのフィルターに使用するログレベルを表すメッセージカテゴリーを選択します。
- ファイル名: 表示するログファイルを選択します。現在アクティブなシステムログファイルを表示するには、Current を選択します。
- この表には、システムログエントリーが表示されます。エントリーは逆順で、最新のエントリーが一番上に置かれています。パネルの右にあるスクロールバーを使用して、ログエントリーを下方向にスクロールします。各エントリーには、以下の情報が表示されます。
- ソース: メッセージをログに記録したコンポーネントまたはリソース
- level: 対応するエントリーの重大度。
- Date: エントリーがログに記録された日付。
- 時間: エントリーがログに記録された時間。
- 詳細: ログの簡単な説明
- 完全なエントリーを表示するには、エントリーをダブルクリックしてそのエントリーを選択し、をクリックします。
15.3.2. 署名監査ログの使用
15.3.2.1. 監査ログの一覧表示
server.example.com
にホストされる CA の監査ログファイルを一覧表示するには、次のコマンドを実行します。
# pki -h server.example.com -p 8443 -n auditor ca-audit-file-find ----------------- 3 entries matched ----------------- File name: ca_audit.20170331225716 Size: 2883 File name: ca_audit.20170401001030 Size: 189 File name: ca_audit Size: 6705 ---------------------------- Number of entries returned 3 ----------------------------
auditor
ディレクトリーに保存されている auditor ニックネームのあるクライアント証明書を使用します。コマンドで使用するパラメーターおよび代替の認証方法の詳細は、man ページの pki(1) を参照してください。
15.3.2.2. 監査ログのダウンロード
server.example.com
でホストされる CA から監査ログファイルをダウンロードするには、以下を実行します。
- 任意で、CA で利用可能なログファイルを一覧表示します。「監査ログの一覧表示」を参照してください。
- ログファイルをダウンロードします。たとえば、
ca_audit
ファイルをダウンロードします。# pki -U https://server.example.com:8443 -n auditor ca-audit-file-retrieve ca_audit
このコマンドは、CA に対して認証するために、auditor
ディレクトリーに保存されている auditor ニックネームのあるクライアント証明書を使用します。コマンドで使用するパラメーターおよび代替の認証方法の詳細は、man ページの pki(1) を参照してください。
grep
ユーティリティーを使用して、特定のログエントリーを検索できます。
# grep "\[AuditEvent=ACCESS_SESSION_ESTABLISH\]" log_file
15.3.2.3. 署名済み監査ログの確認
- NSS データベースを初期化し、CA 証明書をインポートします。詳細は、「pki CLI の初期化」 および『Red Hat Certificate System 9 計画、インストール、およびデプロイメントのガイド』の『NSS データベースへの証明書のインポート』セクションを参照してください。
- 監査署名証明書が PKI クライアントデータベースにない場合は、インポートします。
- 確認するサブシステムログについて監査署名証明書を検索します。以下に例を示します。
# pki ca-cert-find --name "CA Audit Signing Certificate" --------------- 1 entries found --------------- Serial Number: 0x5 Subject DN: CN=CA Audit Signing Certificate,O=EXAMPLE Status: VALID Type: X.509 version 3 Key Algorithm: PKCS #1 RSA with 2048-bit key Not Valid Before: Fri Jul 08 03:56:08 CEST 2016 Not Valid After: Thu Jun 28 03:56:08 CEST 2018 Issued On: Fri Jul 08 03:56:08 CEST 2016 Issued By: system ---------------------------- Number of entries returned 1 ----------------------------
- 監査署名証明書を PKI クライアントにインポートします。
# pki client-cert-import "CA Audit Signing Certificate" --serial 0x5 --trust ",,P" --------------------------------------------------- Imported certificate "CA Audit Signing Certificate" ---------------------------------------------------
- 監査ログをダウンロードします。「監査ログのダウンロード」を参照してください。
- 監査ログを確認します。
- 検証する監査ログファイルのリストを時系列で含むテキストファイルを作成します。以下に例を示します。
# cat > ~/audit.txt << EOF ca_audit.20170331225716 ca_audit.20170401001030 ca_audit EOF
AuditVerify
ユーティリティーを使用して署名を確認します。以下に例を示します。# AuditVerify -d ~/.dogtag/nssdb/ -n "CA Audit Signing Certificate" \ -a ~/audit.txt Verification process complete. Valid signatures: 10 Invalid signatures: 0
AuditVerify
の使用方法は、AuditVerify(1) man ページを参照してください。
15.3.3. オペレーティングシステムレベルの監査ログの表示
auditd
ロギングフレームワークを設定する必要があります。
ausearch
ユーティリティーを使用するか、sudo
ユーティリティーを使用して特権ユーザーとして使用します。
15.3.3.1. 監査ログ削除イベントの表示
-k
パラメーターを使用して、そのキーに一致するイベントを検索します。
# ausearch -k rhcs_audit_deletion
15.3.3.2. シークレットおよび秘密鍵の NSS データベースへのアクセスの表示
-k
パラメーターを使用して、そのキーに一致するイベントを検索します。
# ausearch -k rhcs_audit_nssdb
15.3.3.3. 時間変更イベントの表示
-k
パラメーターを使用して、そのキーに一致するイベントを検索します。
# ausearch -k rhcs_audit_time_change
15.3.3.4. パッケージ更新イベントの表示
-m
パラメーターを使用して、そのキーに一致するイベントを検索します。
# ausearch -m SOFTWARE_UPDATE
15.3.3.5. PKI 設定変更の表示
-k
パラメーターを使用して、そのキーに一致するイベントを検索します。
# ausearch -k rhcs_audit_config
15.3.4. スマートカードのエラーコード
戻りコード | 説明 |
---|---|
一般的なエラーコード | |
6400 | 特定の診断なし |
6700 | Lc の誤った長さ |
6982 | セキュリティーステータスが満たされない |
6985 | 使用条件が満たされない |
6a86 | 間違った P1 P2 |
6d00 | 無効な命令 |
6e00 | 無効なクラス |
インストール読み込みエラー | |
6581 | メモリー障害 |
6a80 | データフィールドの誤ったパラメーター |
6a84 | 不十分なメモリー容量 |
6a88 | 参照データが見つからない |
削除エラー | |
6200 | アプリケーションを論理的に削除 |
6581 | メモリー障害 |
6985 | 参照データを削除できない |
6a88 | 参照データが見つからない |
6a82 | アプリケーションが見つからない |
6a80 | コマンドデータの値が正しくない |
データ取得エラー | |
6a88 | 参照データが見つからない |
ステータス取得エラー | |
6310 | より多くのデータが利用可能 |
6a88 | 参照データが見つからない |
6a80 | コマンドデータの値が正しくない |
読み込みエラー | |
6581 | メモリー障害 |
6a84 | 不十分なメモリー容量 |
6a86 | 間違った P1/P2 |
6985 | 使用条件が満たされない |
第16章 サブシステム証明書の管理
16.1. 必要なサブシステム証明書
16.1.1. 証明書マネージャー証明書
16.1.1.1. CA 署名キーペアおよび証明書
- Certificate Manager がルート CA の場合、その CA 署名証明書は自己署名の証明書です。つまり、証明書のサブジェクト名と発行者名は同じです。
- Certificate Manager が下位 CA である場合、その CA 署名証明書は別の CA、通常は CA 階層の上位レベル (ルート CA である場合とそうでない場合があります) によって署名されます。Certificate Manager を使用して証明書を発行する前に、ルート CA の署名証明書を個別のクライアントおよびサーバーにインポートする必要があります。
16.1.1.2. OCSP 署名キーペアおよび証明書
16.1.1.3. サブシステム証明書
16.1.1.4. SSL サーバーキーペアおよび証明書
16.1.1.5. Audit ログ署名キーペアおよび証明書
16.1.2. オンライン証明書ステータスマネージャーの証明書
16.1.2.1. OCSP 署名キーペアおよび証明書
16.1.2.2. SSL サーバーキーペアおよび証明書
16.1.2.3. サブシステム証明書
16.1.2.4. Audit ログ署名キーペアおよび証明書
16.1.2.5. オンライン証明書ステータスマネージャー証明書の認識
- Online Certificate Status Manager のサーバー証明書が CRL を公開している CA によって署名されている場合は、何もする必要はありません。
- Online Certificate Status Manager のサーバー証明書が、下位の Certificate Manager の証明書に署名したのと同じルート CA によって署名されている場合、ルート CA は、下位の Certificate Manager の証明書データベースで信頼できる CA としてマークする必要があります。
- Online Certificate Status Manager の SSL サーバー証明書が別のルート CA によって署名されている場合は、ルート CA 証明書を下位の Certificate Manager の証明書データベースにインポートし、信頼できる CA としてマークする必要があります。
16.1.3. キーリカバリー認証局の証明書
16.1.3.1. トランスポートキーペアおよび証明書
16.1.3.2. ストレージキーペア
16.1.3.3. SSL サーバー証明書
16.1.3.4. サブシステム証明書
16.1.3.5. Audit ログ署名キーペアおよび証明書
16.1.4. TKS 証明書
16.1.4.1. SSL サーバー証明書
16.1.4.2. サブシステム証明書
16.1.4.3. Audit ログ署名キーペアおよび証明書
16.1.5. TPS 証明書
16.1.5.1. SSL サーバー証明書
16.1.5.2. サブシステム証明書
16.1.5.3. Audit ログ署名キーペアおよび証明書
16.1.6. サブシステム証明書のキータイプについて
pkispawn
ユーティリティーに渡される設定ファイルでキーのタイプとキーサイズを指定できます。
例16.1 CA のキータイプ関連の設定パラメーター
pkispawn
に渡される設定ファイルで設定できます。
pki_ocsp_signing_key_algorithm=SHA256withRSA pki_ocsp_signing_key_size=2048 pki_ocsp_signing_key_type=rsa pki_ca_signing_key_algorithm=SHA256withRSA pki_ca_signing_key_size=2048 pki_ca_signing_key_type=rsa pki_sslserver_key_algorithm=SHA256withRSA pki_sslserver_key_size=2048 pki_sslserver_key_type=rsa pki_subsystem_key_algorithm=SHA256withRSA pki_subsystem_key_size=2048 pki_subsystem_key_type=rsa pki_admin_keysize=2048 pki_admin_key_size=2048 pki_admin_key_type=rsa pki_audit_signing_key_algorithm=SHA256withRSA pki_audit_signing_key_size=2048 pki_audit_signing_key_type=rsa
- 『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 の『
ユーティリティーの理解
』 セクション - パラメーターおよび例の説明の pki_default.cfg(5) man ページ。
16.1.7. HSM を使用したサブシステム証明書の保存
/var/lib/pki/instance_name/alias
ディレクトリーのローカル管理のデータベースである key3.db
および cert8.db
に保存されます。ただし、Red Hat Certificate System は、ハードウェアセキュリティーモジュール (HSM) もサポートします。この外部デバイスは、ネットワーク上にある集中的な場所に鍵と証明書を保存できます。HSM を使用すると、インスタンスのキーと証明書に簡単にアクセスできるため、クローン作成などの一部の機能が簡単になります。
server.xml
ファイルなどのサブシステム設定にフルネームが使用されます。以下に例を示します。
serverCert="nethsm:Server-Cert cert-instance_ID
16.2. コンソールを使用した証明書の要求
16.2.1. 署名証明書の要求
- サブシステムコンソールを開きます。以下に例を示します。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、ナビゲーションツリーで System Keys and Certificates を選択します。
- 右側のパネルで Local Certificates タブを選択します。
- 証明書要求 ラジオボタンを選択します。
- 要求の署名証明書タイプを選択します。
- ルート CA または下位 CA のいずれかの CA のタイプを選択します。
- キーペアの情報を設定し、キー (トークン) を生成する場所を設定します。これは内部セキュリティーデータベースディレクトリーまたは一覧表示された外部トークンのいずれかになります。新しい証明書を作成するには、新しいキーペアを作成する必要があります。既存のキーペアを使用すると、既存の証明書が更新されるだけです。
- メッセージダイジェストアルゴリズムを選択します。
- サブジェクト名を指定します。サブジェクト DN を構築するための個別の DN 属性の値を入力するか、完全な文字列を入力します。証明書要求フォームは、共通名、組織単位、および要求側の名前フィールドの UTF-8 文字をすべてサポートします。このサポートには、国際化されたドメイン名のサポートは含まれません。
- 証明書の有効期間の開始日と終了日、およびそれらの日付で有効期間が開始および終了する時刻を指定します。デフォルトの有効期間は 5 年間です。
- 証明書の標準拡張機能を設定します。必要な拡張機能はデフォルトで選択されます。デフォルトの選択を変更するには、付録B 証明書および CRL のデフォルト、制約、および拡張 で説明されているガイドラインを参照してください。注記CA 階層の設定には、証明書拡張が必要です。下位 CA には、下位 SSL CA (SSL の証明書を発行できるようにする) または下位電子メール CA (安全な電子メールの証明書を発行できるようにする) のいずれかとして識別する拡張子を含む証明書が必要です。証明書拡張を無効にすると、CA 階層が設定できないことを意味します。
- 基本の制約。関連付けられたフィールドは CA 設定であり、証明書パスの長さの数値設定になります。
- 拡張鍵の使用。
- 認証局キー識別子。
- サブジェクトキー識別子。
- 鍵の使用方法。デフォルトでは、デジタル署名 (ビット 0)、否認防止 (ビット 1)、キー証明書サイン (ビット 5)、および CRL サイン (ビット 6) ビットが設定されています。拡張機能は、PKIX 標準および RFC 2459 によって推奨されているとマークされます。Key Usage 拡張機能の説明は、RFC 2459 を参照してください。
- 拡張機能の Base-64 SEQUENCE。これはカスタム拡張用です。MIME 64 DER でエンコードされた形式のエクステンションをテキストフィールドに貼り付けます。
複数の拡張機能を追加するには、ExtJoiner プログラムを使用します。ツールの使用方法は、『Certificate System コマンドラインツールガイド』を参照してください。 - ウィザードはキーペアを生成し、証明書署名要求を表示します。リクエストは base-64 でエンコードされた PKCS #10 形式であり、マーカーファイル -----BEGIN NEW CERTIFICATE REQUEST----- および -----END NEW CERTIFICATE REQUEST----- でバインドされます。以下に例を示します。
-----BEGIN NEW CERTIFICATE REQUEST----- MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBC6SAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pY2 F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDA wMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFz AVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3Dbndg JARYUc3Vwcml5Yhvfggsvwryw4y7214vAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAM A0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4x -----END NEW CERTIFICATE REQUEST-----
ウィザードは、証明書要求を、/var/lib/pki/instance_name/subsystem_type/conf/
にある設定ディレクトリーに作成したテキストファイルにコピーします。テキストファイルの名前は、要求された証明書の種類によって異なります。設定可能なテキストファイルは 表16.1「証明書署名要求用に作成されたファイル」 に記載されています。表16.1 証明書署名要求用に作成されたファイル ファイル名 証明書署名要求 cacsr.txt CA 署名証明書 ocspcsr.txt 証明書マネージャーの OCSP 署名証明書 ocspcsr.txt OCSP 署名証明書 CA に送信する前に、証明書要求を変更しないでください。リクエストはウィザード経由で自動的に送信することも、クリップボードにコピーして、終了ページを介して CA に手動で送信することもできます。注記ウィザードの自動送信機能は、リモートの Certificate Manager にのみ要求を送信できます。サードパーティーの CA に要求を送信するのに使用できません。サードパーティーの CA に送信するには、証明書要求ファイルを使用します。 - 証明書を取得します。
- Certificate Manager エンドエンティティーを開きます。
https://server.example.com:8443/ca/ee/ca
- Retrieval タブをクリックします。
- 証明書要求の送信時に作成された要求 ID 番号を入力し、をクリックします。
- 次のページには、証明書要求のステータスが表示されます。ステータスが complete すると、証明書へのリンクがあります。Issued certificate のリンクをクリックします。
- 新しい証明書情報は、pretty-print 形式、base-64 エンコード形式、および PKCS #7 形式で表示されます。
- base-64 でエンコードされた証明書 (マーカー行 -----BEGIN CERTIFICATE----- および -----END CERTIFICATE----- を含む) をテキストファイルにコピーします。テキストファイルを保存し、それを使用して証明書のコピーをサブシステムの内部データベースに保存します。「ユーザーの作成」を参照してください。
16.2.2. 他の証明書の要求
- サブシステムコンソールを開きます。以下に例を示します。
pkiconsole https://server.example.com:8443/ca
- Configuration タブで、ナビゲーションツリーで System Keys and Certificates を選択します。
- 右側のパネルで Local Certificates タブを選択します。
- 証明書要求 ラジオボタンを選択します。
- 要求する証明書のタイプを選択します。要求できる証明書のタイプはサブシステムによって異なります。注記その他の証明書を作成することを選択すると、Certificate Type フィールドが有効になります。作成する証明書のタイプを入力します。CRL 署名証明書の caCrlSigning、監査ログ署名証明書の caSignedLogCert、または SSL クライアント証明書用の client を入力します。
- 要求に署名する CA のタイプを選択します。このオプションは、ローカルの CA 署名証明書を使用するか、別の CA に送信するリクエストを作成します。
- キーペアの情報を設定し、キー (トークン) を生成する場所を設定します。これは内部セキュリティーデータベースディレクトリーまたは一覧表示された外部トークンのいずれかになります。新しい証明書を作成するには、新しいキーペアを作成する必要があります。既存のキーペアを使用すると、既存の証明書が更新されるだけです。
- サブジェクト名を指定します。サブジェクト DN を構築するための個別の DN 属性の値を入力するか、完全な文字列を入力します。注記SSL サーバー証明書の場合、共通名は machine_name.domain.domain 形式の Certificate System の完全修飾ホスト名である必要があります。CA 証明書要求フォームは、共通名、組織単位、および要求側の名前フィールドの UTF-8 文字をすべてサポートします。このサポートには、国際化されたドメイン名のサポートは含まれません。
- 証明書の有効期間の開始日と終了日、およびそれらの日付で有効期間が開始および終了する時刻を指定します。デフォルトの有効期間は 5 年間です。
- 証明書の標準拡張機能を設定します。必要な拡張機能はデフォルトで選択されます。デフォルトの選択を変更するには、付録B 証明書および CRL のデフォルト、制約、および拡張 で説明されているガイドラインを参照してください。
- 拡張鍵の使用。
- 認証局キー識別子。
- サブジェクトキー識別子。
- 鍵の使用方法。デフォルトでは、デジタル署名 (ビット 0)、否認防止 (ビット 1)、キー証明書サイン (ビット 5)、および CRL サイン (ビット 6) ビットが設定されています。拡張機能は、PKIX 標準および RFC 2459 によって推奨されているとマークされます。Key Usage 拡張機能の説明は、RFC 2459 を参照してください。
- 拡張機能の Base-64 SEQUENCE。これはカスタム拡張用です。MIME 64 DER でエンコードされた形式のエクステンションをテキストフィールドに貼り付けます。
複数の拡張機能を追加するには、ExtJoiner プログラムを使用します。ツールの使用方法は、『Certificate System コマンドラインツールガイド』を参照してください。 - ウィザードはキーペアを生成し、証明書署名要求を表示します。リクエストは base-64 でエンコードされた PKCS #10 形式であり、マーカーファイル -----BEGIN NEW CERTIFICATE REQUEST----- および -----END NEW CERTIFICATE REQUEST----- でバインドされます。以下に例を示します。
-----BEGIN NEW CERTIFICATE REQUEST----- MIICJzCCAZCgAwIBAgIBAzANBgkqhkiG9w0BAQQFADBC6SAwHgYDVQQKExdOZXRzY2FwZSBDb21tdW5pY2 F0aW9uczngjhnMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyNzE5MDAwMFoXDTk5MDIyMzE5MDA wMnbjdgngYoxIDAeBgNVBAoTF05ldHNjYXBlIENvbW11bmljYXRpb25zMQ8wDQYDVQQLEwZQZW9wbGUxFz AVBgoJkiaJkIsZAEBEwdzdXByaXlhMRcwFQYDVQQDEw5TdXByaXlhIFNoZXR0eTEjMCEGCSqGSIb3Dbndg JARYUc3Vwcml5Yhvfggsvwryw4y7214vAOBgNVHQ8BAf8EBAMCBLAwFAYJYIZIAYb4QgEBAQHBAQDAgCAM A0GCSqGSIb3DQEBBAUAA4GBAFi9FzyJlLmS+kzsue0kTXawbwamGdYql2w4hIBgdR+jWeLmD4CP4x -----END NEW CERTIFICATE REQUEST-----
ウィザードは、証明書要求を、/var/lib/pki/instance_name/subsystem_type/conf/
にある設定ディレクトリーに作成したテキストファイルにコピーします。テキストファイルの名前は、要求された証明書の種類によって異なります。設定可能なテキストファイルは 表16.2「証明書署名要求用に作成されたファイル」 に記載されています。表16.2 証明書署名要求用に作成されたファイル ファイル名 証明書署名要求 kracsr.txt KRA トランスポート証明書 sslcsr.txt SSL サーバー証明書 othercsr.txt Certificate Manager CRL 署名証明書または SSL クライアント証明書などの他の証明書 CA に送信する前に、証明書要求を変更しないでください。リクエストはウィザード経由で自動的に送信することも、クリップボードにコピーして、終了ページを介して CA に手動で送信することもできます。注記ウィザードの自動送信機能は、リモートの Certificate Manager にのみ要求を送信できます。サードパーティーの CA に要求を送信するのに使用できません。サードパーティーの CA に要求を送信するには、証明書要求ファイルのいずれかを使用します。 - 証明書を取得します。
- Certificate Manager エンドエンティティーを開きます。
https://server.example.com:8443/ca/ee/ca
- Retrieval タブをクリックします。
- 証明書要求の送信時に作成された要求 ID 番号を入力し、をクリックします。
- 次のページには、証明書要求のステータスが表示されます。ステータスが complete すると、証明書へのリンクがあります。Issued certificate のリンクをクリックします。
- 新しい証明書情報は、pretty-print 形式、base-64 エンコード形式、および PKCS #7 形式で表示されます。
- base-64 でエンコードされた証明書 (マーカー行 -----BEGIN CERTIFICATE----- および -----END CERTIFICATE----- を含む) をテキストファイルにコピーします。テキストファイルを保存し、それを使用して証明書のコピーをサブシステムの内部データベースに保存します。「ユーザーの作成」を参照してください。
16.3. サブシステム証明書の更新
16.3.1. エンドエンティティーフォームでの証明書のキーの再設定
- 「証明書の更新」 の説明に従って、CA のエンドエンティティー形式で証明書を更新し す。これには、更新するサブシステム証明書のシリアル番号が必要です。
- 「証明書システムデータベースでの証明書のインストール」 の説明に従って、証明書をサブシステムのデータベースにインポートします。証明書は、certutil またはコンソールを使用してインポートできます。以下に例を示します。
certutil -A -n "ServerCert cert-example" -t u,u,u -d /var/lib/pki/instance_name/alias -a -i /tmp/example.cert
16.3.2. コンソールでの証明書の更新
図16.1 サブシステム証明書の更新
16.3.3. certutil を使用した証明書の更新
- トークンデータベースのパスワードを取得します。
cat /var/lib/pki/instance_name/conf/password.conf internal=263163888660
- 証明書を更新しているインスタンスの証明書データベースディレクトリーを開きます。
cd /var/lib/pki/instance_name/alias
- 更新する証明書のキーとニックネームを一覧表示します。証明書を更新するには、生成に使用されるキーペアと、新しい証明書に指定されたサブジェクト名は、古い証明書の証明書と同じである必要があります。
# certutil -K -d . certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" Enter Password or Pin for "NSS Certificate DB": < 0> rsa 69481646e38a6154dc105960aa24ccf61309d37d caSigningCert cert-pki-tomcat CA
alias
ディレクトリーをバックアップとしてコピーし、証明書データベースから元の証明書を削除します。以下に例を示します。certutil -D -n "ServerCert cert-example" -d .
- 既存の証明書の値にオプションを設定して certutil コマンドを実行します。
certutil -d . -R -n "NSS Certificate DB:cert-pki-tomcat CA" -s "cn=CA Authority,o=Example Domain" -a -o example.req2.txt
新しい証明書とキーのペアの生成と証明書の更新の違いは、-n
オプションの値です。新しいリクエストとキーのペアを生成するには、-k
はキータイプを設定してから-g
で使用します。これは、ビット長を設定します。更新要求では、-n
オプションは証明書のニックネームを使用してセキュリティーデータベースに保存された既存のキーペアにアクセスします。パラメーターの詳細は、certutil(1) の man ページを参照してください。 - 「証明書の要求および受信」 の説明に従って、証明書要求を送信して取得し、インストールします。
16.3.4. システム証明書の更新
- システム証明書の有効期限が切れている場合は、以下を行います。
- 一時証明書を作成します。
# pki-server cert-create sslserver --temp
- Certificate System の Network Security Services (NSS) データベースに一時証明書をインポートします。
# pki-server cert-import sslserver
- Certificate System を開始します。
# systemctl start pki-tomcatd@instance_name.service
- 証明書を表示し、期限切れのシステム証明書の ID をメモします。
# pki-server cert-find
- 新しい永続的な証明書を作成します。
# pki-server cert-create certificate_ID
- Certificate System を停止します。
# systemctl stop pki-tomcatd@instance_name.service
- 新しい証明書をインポートして、期限切れの証明書を置き換えます。
# pki-server cert-import certificate_ID
- Certificate System を開始します。
# systemctl start pki-tomcatd@instance_name.service
16.4. サブシステム証明書の名前の変更
CS.cfg
設定ファイルで必要なすべての設定で証明書のニックネームを更新する必要があります。
CS.cfg
ファイルの編集後に必ずサブシステムを再起動します。
CA 署名証明書 |
|
OCSP 署名証明書 |
|
サブシステム証明書 |
|
サーバー証明書 |
|
監査署名証明書 |
|
トランスポート証明書 |
|
ストレージ証明書 |
|
サーバー証明書 |
|
サブシステム証明書 |
|
監査ログ署名証明書 |
|
OCSP 署名証明書 |
|
サーバー証明書 |
|
サブシステム証明書 |
|
監査ログ署名証明書 |
|
KRA 転送証明書[a] |
|
サーバー証明書 |
|
サブシステム証明書 |
|
監査ログ署名証明書 |
|
[a]
TKS 証明書がすべて同じままであっても、 KRA トランスポート証明書のニックネームが変更された場合は、TKS 設定でこれを変更する必要があります。
|
サーバー証明書 |
|
サブシステム証明書 |
|
監査ログ署名証明書 |
|
16.5. ペア間の証明書の使用
16.5.1. ペア間の証明書のインストール
16.5.2. ペア間の証明書の検索
/usr/lib[64]/mozldap/ldapsearch -D "cn=directory manager" -w secret -p 389 -h server.example.com -b "o=server.example.com-pki-ca" -s sub "(crossCertificatePair=*)"
16.6. 証明書データベースの管理
16.6.1. 証明書システムデータベースでの証明書のインストール
16.6.1.1. コンソールを使用した証明書のインストール
- Certificate System サブシステムが使用する証明書のいずれか
- 外部 CA またはその他の Certificate System CA からの信頼済み CA 証明書
- 証明書チェーン
- コンソールを開きます。
pkiconsole https://server.example.com:secure_port/subsystem_type
- Configuration タブで、左側のナビゲーションツリーから System Keys and Certificates を選択します。
- サブシステムのタイプと証明書のタイプに応じて、証明書をインストールできる 2 つのタブがあります。
- CA 証明書 タブは、CA 証明書および証明書チェーンのインストールに使用されます。Certificate Manager の場合、このタブはサードパーティーの CA 証明書またはその他の Certificate System CA 証明書に使用されます。すべてのローカル CA 証明書は、Local Certificates タブにインストールされます。その他のサブシステムでは、すべての CA 証明書およびチェーンがこのタブでインストールされます。
- Local Certificates タブには、すべてのサーバー証明書、サブシステム証明書、および OCSP 署名や KRA トランスポートなどのローカル証明書がインストールされます。
該当するタブを選択します。 - Local Certificates タブで証明書をインストールするには、 をクリックします。CA Certificates タブに証明書をインストールするには、 をクリックします。いずれも Certificate Setup Wizard を開きます。
- ウィザードが開いたら、Install a certificate ラジオボタンを選択し、 をクリックします。
- インストールする証明書のタイプを選択します。ドロップダウンメニューのオプションは、サブシステムのタイプに応じて、証明書の作成に使用できるオプションと同じですが、クロスペア証明書をインストールするための追加オプションがあります。
- -----BEGIN CERTIFICATE----- および -----END CERTIFICATE----- を含む証明書の本文にテキストエリアに貼り付けるか、絶対ファイルの場所を指定します。これはローカルファイルでなければなりません。証明書は以下のようになります。
-----BEGIN CERTIFICATE----- MIICKzCCAZSgAwIBAgIBAzANgkqkiG9w0BAQQFADA3MQswCQYDVQQGEw JVUzERMA8GA1UEChMITmV0c2NhcGUxFTATBgNVBAsTDFN1cHJpeWEncy BDQTAeFw05NzEwMTgwMTM2MjVaFw05OTEwMTgwMTM2MjVaMEgxCzAJBg NVBAYTAlVTMREwDwYDVQQKEwhOZXRzY2FwZTENMAsGA1UECxMEUHawcz EXMBUGA1UEAxMOU3Vwcml5YSBTaGV0dHkwgZ8wDQYJKoZIhdfNAQEBBQ ADgY0AMIGJAoGBAMr6eZiPGfjX3uRJgEjmKiqG7SdATYzBcABu1AVyd7 chRFOGD3wNktbf6hRo6EAmM5R1Askzf8AW7LiQZBcrXpc0k4du+2j6xJ u2MPm8WKuMOTuvzpo+SGXelmHVChEqooCwfdiZywyZNmgaMa2MS6pUkf QVAgMBAAGjNjA0MBEGCWCGSAGG+EIBAQQEAwIAgD -----END CERTIFICATE-----
- ウィザードに、証明書の詳細が表示されます。指紋を確認して、これが正しい証明書であることを確認するか、ボタンをクリックして戻って別のボタンを送信します。証明書のニックネームを指定します。このウィザードは、証明書をインストールします。
- 証明書に署名した CA はサブシステムによって信頼される必要があります。この CA の証明書がサブシステムの証明書データベース (内部または外部) に存在し、信頼されていることを確認してください。CA 証明書がリストされていない場合は、信頼できる CA として証明書を証明書データベースに追加します。CA の証明書がリストされているが信頼されていない場合は、「CA 証明書の信頼設定の変更」 に示すように、信頼設定を信頼済みに変更します。Certificate System 証明書データベースに保存されていない CA によって発行された証明書をインストールする場合は、その CA の証明書チェーンをデータベースに追加します。CA チェーンをデータベースに追加するには、CA チェーンをテキストファイルにコピーし、ウィザードを再起動して、CA チェーンをインストールします。
16.6.1.2. certutil を使用した証明書のインストール
- サブシステムのセキュリティーデータベースディレクトリーを開きます。
cd /var/lib/pki/instance_name/alias
- -A を指定して certutil コマンドを実行して、証明書と、CA が発行した証明書が含まれるファイルを示す -i を追加しします。
certutil -A -n cert-name -t trustargs -d . -a -i certificate_file
注記Certificate System インスタンスの証明書およびキーが HSM に保存されている場合は、-h オプションを使用してトークン名を指定します。以下に例を示します。certutil -A -n "ServerCert cert-instance_name" -t u,u,u -d . -a -i /tmp/example.cert
16.6.1.3. CA 証明書のチェーンについて
16.6.2. データベースコンテンツの表示
cert8.db
は、サブシステム管理コンソールから表示できます。または、certutil ユーティリティーを使用して一覧表示できます。certutil は、TPS サブシステムは管理コンソールを使用しないため、TPS 証明書を表示するのに使用する必要があります。
cert8.db
に一覧表示されている証明書データベースは、サブシステム操作に使用されるサブシステム証明書です。ユーザー証明書は、LDAP 内部データベースのユーザーエントリーと共に保存されます。
16.6.2.1. コンソールを使用したデータベースコンテンツの表示
- サブシステムコンソールを開きます。
pkiconsole https://server.example.com:secure_port/subsystem_type
- Configuration タブで、左側のナビゲーションツリーから System Keys and Certificates を選択します。
- CA Certificates および Local Certificates の 2 つのタブがあります。ここには、さまざまな種類の証明書が一覧表示されます。
- CA 証明書 には、Entrust や Verisign などのサードパーティー CA によって発行された証明書や、外部の Certificate System Certificate Manager など、対応する秘密鍵の資料が利用できない CA 証明書が一覧表示されます。
- ローカル証明書 には、KRA トランスポート証明書や OCSP 署名証明書など、Certificate System サブシステムインスタンスによって保持されている証明書が一覧表示されます。
図16.2 Certificate Database タブ
- Certificate Database Management テーブルには、サブシステムにインストールされている証明書が一覧表示されます。証明書ごとに、以下の情報が提供されます。
- Certificate Name
- Serial Number
- Issuer Names。この証明書の発行者の共通名 (cn) です。
- Token Name (証明書を保持する暗号化トークンの名前)。データベースに保存されている証明書の場合、これは internal になります。
16.6.2.2. certutil を使用したデータベースコンテンツの表示
cd /var/lib/pki/instance_name/alias certutil -L -d . Certificate Authority - Example Domain CT,c, subsystemCert cert-instance name u,u,u Server-Cert cert-instance_name u,u,u
cd /var/lib/pki/instance_name/alias certutil -K -d . Enter Password or Pin for "NSS Certificate DB": <0> subsystemCert cert-instance_name <1> <2> Server-Cert cert-instance_name
16.6.3. データベースからの証明書の削除
16.6.3.1. コンソールを使用した証明書の削除
- サブシステムコンソールを開きます。
pkiconsole https://server.example.com:secure_port/subsystem_type
- Configuration タブで、左側のナビゲーションツリーから System Keys and Certificates を選択します。
- 削除する証明書を選択して、をクリックします。
- プロンプトが表示されたら、削除を確定します。
16.6.3.2. certutil を使用した証明書の削除
- インスタンスの証明書データベースディレクトリーを開きます。
/var/lib/pki/instance_name/alias
- -L オプションを使用して certutil を実行し、データベースの証明書を一覧表示します。以下に例を示します。
certutil -L -d . Certificate Authority - Example Domain CT,c, subsystemCert cert-instance_name u,u,u Server-Cert cert-instance_name u,u,u
- -D オプションを指定して certutil を実行し、証明書を削除します。
certutil -D -d . -n certificate_nickname
以下に例を示します。certutil -D -d . -n "ServerCert cert-instance_name"
- 証明書を再度一覧表示し、証明書が削除されたことを確認します。
certutil -L -d . Certificate Authority - Example Domain CT,c, subsystemCert cert-instance_name u,u,u
16.7. CA 証明書の信頼設定の変更
16.7.1. コンソールからの信頼設定の変更
- サブシステムコンソールを開きます。
pkiconsole https://server.example.com:secure_port/subsystem_type
- Configuration タブで、左側のナビゲーションツリーから System Keys and Certificates を選択します。
- CA certificates タブを選択します。
- 変更する CA 証明書を選択し、をクリックします。
- The Certificate chain is (un)trusted, are you sure you want to (un)trust it? というプロンプトが開きます。yes をクリックすると、証明書チェーンの信頼設定が変更されます。no を押すと、元の信頼関係が保持されます。
16.7.2. certutil を使用した信頼設定の変更
- インスタンスの証明書データベースディレクトリーを開きます。
cd /var/lib/pki/instance_name/alias
- -L オプションを使用して certutil を実行し、データベースの証明書を一覧表示します。以下に例を示します。
certutil -L -d . Certificate Authority - Example Domain CT,c, subsystemCert cert-instance_name u,u,u Server-Cert cert-instance_name u,u,u
- -M オプションを使用して certutil を実行し、証明書の信頼設定を変更します。
certutil -M -n cert_nickname -t trust -d .
以下に例を示します。certutil -M -n "Certificate Authority - Example Domain" -t TCu,TCu,TCu -d .
- 証明書を再度一覧表示し、証明書が削除されたことを確認します。
certutil -L -d . Certificate Authority - Example Domain CTu,CTu,CTu subsystemCert cert-instance_name u,u,u Server-Cert cert-instance_name u,u,u
16.8. サブシステムによって使用されるトークンの管理
16.8.1. トークンの検出
TokenInfo /var/lib/pki/instance_name/alias Database Path: /var/lib/pki/instance_name/alias Found external module 'NSS Internal PKCS #11 Module'
16.8.2. トークンの表示
- インスタンスの
alias
ディレクトリーを開きます。以下に例を示します。cd /var/lib/pki/instance_name/alias
- インストールされている PKCS #11 モジュールに関する情報と、modutil ツールを使用して、対応するトークンに関する情報を表示します。
modutil -dbdir . -nocertdb -list
16.8.3. トークンのパスワードの変更
password.conf
ファイルにトークンパスワードを保存します。このファイルは、トークンパスワードが変更されるたびに手動で更新する必要があります。password.conf
ファイルを介したパスワード管理の詳細は、『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』 を参照してください。
第17章 Red Hat Enterprise Linux 7 での日時の設定
timedatectl
ユーティリティーは、systemd
システムおよびサービスマネージャーの一部として配布されており、システムクロック設定を確認および変更できます。
システムの現在時刻の変更
timedatectl set-time HH:MM:SS
現在日の変更
timedatectl set-time YYYY-MM-DD
第18章 証明書システムの製品バージョンの特定
/usr/share/pki/CS_SERVER_VERSION
ファイルに保存されます。バージョンを表示するには、以下を実行します。
# cat /usr/share/pki/CS_SERVER_VERSION Red Hat Certificate System 9.4 (Batch Update 3)
- http://host_name:port_number/ca/admin/ca/getStatus
- http://host_name:port_number/kra/admin/kra/getStatus
- http://host_name:port_number/ocsp/admin/ocsp/getStatus
- http://host_name:port_number/tks/admin/tks/getStatus
- http://host_name:port_number/tps/admin/tps/getStatus
第19章 Red Hat Certificate System の更新
第20章 トラブルシューティング
- 問: init スクリプトは OK ステータスを返しましたが、その CA インスタンスは応答しません。理由
- 問: pkiconsole を開くことができません。標準出力 (stdout) で Java の例外が見られます。
- 問: pkiconsole の実行を試みましたが、標準出力 (stdout) でソケット例外が取得されました。理由
- 問: 証明書を登録しようとしたら request is not submitted...Subject Name Not Found というエラーが表示される
- 問: 登録した証明書が公開されないのはなぜですか。
- 問: リモートホストから pkiconsole ユーティリティーを開くにはどうすればいいですか
- 問: LDAP サーバーが応答しないときにどうすればよいですか。
catalina.out
、system
、およびデバッグ
ログファイルでインスタンスに対して、発生したエラーを確認します。これは、いくつかの共通エラーを示しています。
catalina.out
ファイルに返されます。
Oct 29, 2010 4:15:44 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on http-9080 java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:243) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:408) Caused by: java.lang.UnsatisfiedLinkError: jss4
libnss3.so
が必要です。以下のコマンドでこれを確認します。
ldd /usr/lib64/libjss4.so
libnss3.so
が見つからない場合は、LD_LIBRARY_PATH
変数の設定を解除し、CA を再起動します。
unset LD_LIBRARY_PATH systemctl restart pki-tomcatd@instance_name.service
server.xml
の設定が間違っている) か、管理者インターフェイスにアクセスするために間違ったポートが付与されたかのいずれかです。
NSS Cipher Supported '0xff04' java.io.IOException: SocketException cannot read on socket at org.mozilla.jss.ssl.SSLSocket.read(SSLSocket.java:1006) at org.mozilla.jss.ssl.SSLInputStream.read(SSLInputStream.java:70) at com.netscape.admin.certsrv.misc.HttpInputStream.fill(HttpInputStream.java:303) at com.netscape.admin.certsrv.misc.HttpInputStream.readLine(HttpInputStream.java:224) at com.netscape.admin.certsrv.connection.JSSConnection.readHeader(JSSConnection.java:439) at com.netscape.admin.certsrv.connection.JSSConnection.initReadResponse(JSSConnection.java:430) at com.netscape.admin.certsrv.connection.JSSConnection.sendRequest(JSSConnection.java:344) at com.netscape.admin.certsrv.connection.AdminConnection.processRequest(AdminConnection.java:714) at com.netscape.admin.certsrv.connection.AdminConnection.sendRequest(AdminConnection.java:623) at com.netscape.admin.certsrv.connection.AdminConnection.sendRequest(AdminConnection.java:590) at com.netscape.admin.certsrv.connection.AdminConnection.authType(AdminConnection.java:323) at com.netscape.admin.certsrv.CMSServerInfo.getAuthType(CMSServerInfo.java:113) at com.netscape.admin.certsrv.CMSAdmin.run(CMSAdmin.java:499) at com.netscape.admin.certsrv.CMSAdmin.run(CMSAdmin.java:548) at com.netscape.admin.certsrv.Console.main(Console.java:1655)
debug
ログに表示されます。たとえば、このプロファイルは、ディレクトリーを認識しないカスタム属性 (MYATTRIBUTE
) を使用します。
[14/Feb/2011:15:52:25][http-1244-Processor24]: BasicProfile: populate() policy setid =userCertSet [14/Feb/2011:15:52:25][http-1244-Processor24]: AuthTokenSubjectNameDefault: populate start [14/Feb/2011:15:52:25][http-1244-Processor24]: AuthTokenSubjectNameDefault: java.io.IOException: Unknown AVA keyword 'MYATTRIBUTE'. [14/Feb/2011:15:52:25][http-1244-Processor24]: ProfileSubmitServlet: populate Subject Name Not Found [14/Feb/2011:15:52:25][http-1244-Processor24]: CMSServlet: curDate=Mon Feb 14 15:52:25 PST 2011 id=caProfileSubmit time=13
debug
ログで、設定が間違っている場所を示しています。たとえば、以下にはマッパーに関連する問題があります。
[31/Jul/2010:11:18:29][Thread-29]: LdapSimpleMap: cert subject dn:UID=me,E=me@example.com,CN=yes [31/Jul/2010:11:18:29][Thread-29]: Error mapping: mapper=com.netscape.cms.publish.mappers.LdapSimpleMap@258fdcd0 error=Cannot find a match in the LDAP server for certificate. netscape.ldap.LDAPException: error result (32); matchedDN = ou=people,c=test; No such object
CS.cfg
ファイル、または CA コンソールの タブで Publishing 設定を確認します。この例では、この問題はマッピングパラメーターにあり、既存の LDAP 接尾辞を指している必要があります。
ca.publish.mapper.instance.LdapUserCertMap.dnPattern=UID=$subj.UID,dc=publish
pkiconsole
ユーティリティーを開くにはどうすればいいですか
pkiconsole
を開く場合があります。このため、管理者は Virtual Network Computing (VNC) 接続を使用できます。
- Red Hat Certificate System サーバーなどで VNC サーバーを設定します。重要
pkiconsole
ユーティリティーは、Federal Information Processing Standard (FIPS) モードが有効になっているサーバーでは実行できません。Certificate System サーバーで FIPS モードが有効になっている場合は、Red Hat Enterprise Linux で別のホストを使用して VNC サーバーを実行します。VNC サーバーのインストールの詳細は、『Red Hat システム管理者ガイド』の『VNC サーバー』セクションを参照してください。 - VNC ビューアーを使用して、VNC サーバーを実行しているホストに接続します。詳細は、『Red Hat システム管理者ガイド』 の 『VNC ビューアー』 セクションを参照してください。
- VNC ウィンドウで
pkiconsole
ユーティリティーを開きます。以下に例を示します。# pkiconsole https://server.example.com:8443/ca
[02/Apr/2019:15:55:41][authorityMonitor]: authorityMonitor: failed to get LDAPConnection. Retrying in 1 second. [02/Apr/2019:15:55:42][authorityMonitor]: In LdapBoundConnFactory::getConn() [02/Apr/2019:15:55:42][authorityMonitor]: masterConn is null. [02/Apr/2019:15:55:42][authorityMonitor]: makeConnection: errorIfDown true [02/Apr/2019:15:55:42][authorityMonitor]: TCP Keep-Alive: true java.net.ConnectException: Connection refused (Connection refused) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206) [02/Apr/2019:15:55:42][authorityMonitor]: Can't create master connection in LdapBoundConnFactory::getConn! Could not connect to LDAP server host example911.redhat.com port 389 Error netscape.ldap.LDAPException: Unable to create socket: java.net.ConnectException: Connection refused (Connection refused) (-1)
# systemctl stop pki-tomcatd-nuxwdog@instance_name.service
# systemctl start pki-tomcatd-nuxwdog@instance_name.service
第21章 サブシステムの制御およびメンテナーンス
21.1. 起動、停止、再起動、およびステータスの取得
systemctl
ユーティリティーを使用して停止および開始できます。
# systemctl start unit_file@instance_name.service
# systemctl stop unit_file@instance_name.service
# systemctl restart unit_file@instance_name.service
# systemctl status unit_file@instance_name.service
- pki-tomcat: ウォッチドッグが無効になっている場合
- pki-tomcat-nuxwdog: ウォッチドッグが有効な場合
21.2. サブシステムのヘルスチェック
- 完全なディスクが起因する監査障害
- HSM 接続の問題が原因での署名失敗
- LDAP サーバー接続の問題
- などになります。
パート V. 参考資料
付録A 証明書プロファイルの入力および出力の参照
A.1. 入力の参照
A.1.1. CMC 証明書要求入力
- 証明書要求のタイプ。このドロップダウンメニューにより、ユーザーが証明書要求のタイプを指定できます。PKCS #10 または CRMF を選択できます。Cryptographic Message Syntax (CMC) 登録を介した Certificate Management Message は、PKCS #10 と CRMF の両方でサポートされています。
- 証明書要求。このテキストエリアで、リクエストを貼り付けます。
例A.1
caAdminCert.cfg:input.i1.class_id=certReqInputImpl
A.1.2. CMC 証明書要求入力
例A.2
caCMCUserCert.cfg:input.i1.class_id=cmcCertReqInputImpl
A.1.3. デュアルキー生成入力
- Key Generation Request Type。このフィールドは、リクエストタイプ crmf として表示される読み取り専用フィールドです。
- キー生成要求。このフィールドは、暗号化証明書と署名証明書の両方のキー生成要求でのキーサイズの選択を設定します。
例A.3
caDualCert.cfg:input.i1.class_id=dualKeyGenInputImpl
A.1.4. ファイル署名入力
- Key Generation Request Type。このフィールドは、リクエストタイプ crmf として表示される読み取り専用フィールドです。
- キー生成要求。この入力でドロップダウンメニューが追加され、キー生成要求で使用する鍵のサイズを選択します。
- URL Of File Being Signed。これにより、署名されるファイルの場所が指定されます。
- Text Being Signed。これでファイル名が指定されます。
例A.4
caAgentFileSigning.cfg:input.i2.class_id=fileSigningInputImpl
A.1.5. イメージ入力
A.1.6. キー生成入力
- Key Generation Request Type。このフィールドは、リクエストタイプ crmf として表示される読み取り専用フィールドです。
- キー生成要求。この入力でドロップダウンメニューが追加され、キー生成要求で使用する鍵のサイズを選択します。
例A.5
caDualCert.cfg:input.i1.class_id=keyGenInputImpl
A.1.7. nsHKeyCertRequest (Token Key) Input
- トークンキー CUID。このフィールドは、トークンデバイスの CUID (通常は一意のユーザー ID) を入力します。
- Token Key User Public Key。このフィールドには、トークンユーザーの公開鍵が含まれている必要があります。
例A.6
caTempTokenDeviceKeyEnrollment.cfg:input.i1.class_id=nsHKeyCertReqInputImpl
A.1.8. nsNKeyCertRequest (トークンユーザーキー) 入力
- トークンキーユーザー UID。このフィールドは、トークンデバイスのユーザーの LDAP エントリーの UID を指定します。
- Token Key User Public Key。このフィールドには、トークンユーザーの公開鍵が含まれている必要があります。
例A.7
caTempTokenUserEncryptionKeyEnrollment.cfg:input.i1.class_id=nsNKeyCertReqInputImpl
A.1.9. Serial Number Renewal 入力
例A.8
caTokenUserEncryptionKeyRenewal.cfg:input.i1.class_id=serialNumRenewInputImpl
A.1.10. 発行先の DN 入力
例A.9
caAdminCert.cfg:input.i3.class_id=subjectDNInputImpl
A.1.11. サブジェクト名入力
- UID (LDAP ディレクトリーのユーザー ID)
- E メール
- Common Name (ユーザー名)
- Organizational Unit (ユーザーが属する組織単位 (
ou
) - Organization (組織名)
- 国 (ユーザーが置かれている国)
例A.10
caDualCert.cfg:input.i2.class_id=subjectNameInputImpl
A.1.12. 送信元情報の入力
- Requester Name
- Requester Email
- Requester Phone
例A.11
caAdminCert.cfg:input.i2.class_id=submitterInfoInputImpl
A.1.13. 一般的な入力
ccm
パラメーターおよび GUID
パラメーターは、パターン化されたサ Subject Alternative Name Extension Default プラグインで使用されます。
例A.12
input.i3.class_id=genericInputImpl input.i3.params.gi_display_name0=ccm input.i3.params.gi_param_enable0=true input.i3.params.gi_param_name0=ccm input.i3.params.gi_display_name1=GUID input.i3.params.gi_param_enable1=true input.i3.params.gi_param_name1=GUID input.i3.params.gi_num=2 … 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.subjAltExtGNEnable_1=true policyset.set1.p6.default.params.subjAltExtPattern_0=$request.ccm$ policyset.set1.p6.default.params.subjAltExtType_0=DNSName policyset.set1.p6.default.params.subjAltExtPattern_1=(Any)1.3.6.1.4.1.311.25.1,0410$request.GUID$ policyset.set1.p6.default.params.subjAltExtType_1=OtherName policyset.set1.p6.default.params.subjAltNameExtCritical=false policyset.set1.p6.default.params.subjAltNameNumGNs=2
A.1.14. Subject Alternative Name Extension 入力
req_san_pattern_#
を使用して URI の番号付きパラメーター、SubjectAltNameExt
拡張を有効にできます。たとえば、以下が含まれる URI などです。
...&req_san_pattern_0=host0.Example.com&req_san_pattern_1=host1.Example.com
host0.Example.com
および host1.Example.com
を以下のプロファイルから SubjectAltNameExt
拡張機能に挿入します。
例A.13
input.i3.class_id=subjectAltNameExtInputImpl input.i3.name=subjectAltNameExtInputImpl policyset.serverCertSet.9.constraint.class_id=noConstraintImpl policyset.serverCertSet.9.constraint.name=No Constraint policyset.serverCertSet.9.default.class_id=subjectAltNameExtDefaultImpl policyset.serverCertSet.9.default.name=Subject Alternative Name Extension Default policyset.serverCertSet.9.default.params.subjAltExtGNEnable_0=true policyset.serverCertSet.9.default.params.subjAltExtPattern_0=$request.req_san_pattern_0$ policyset.serverCertSet.9.default.params.subjAltExtType_0=DNSName policyset.serverCertSet.9.default.params.subjAltExtGNEnable_1=true policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.req_san_pattern_1$ policyset.serverCertSet.9.default.params.subjAltExtType_1=DNSName policyset.serverCertSet.9.default.params.subjAltExtGNEnable_2=false policyset.serverCertSet.9.default.params.subjAltExtPattern_2=$request.req_san_pattern_2$ policyset.serverCertSet.9.default.params.subjAltExtType_2=DNSName policyset.serverCertSet.9.default.params.subjAltNameExtCritical=false policyset.serverCertSet.9.default.params.subjAltNameNumGNs=3
A.2. 出力の参照
A.2.1. 証明書の出力
例A.14
caAdminCert.cfg:output.o1.class_id=certOutputImpl
A.2.2. PKCS #7 出力
例A.15
caAgentFileSigning.cfg:output.o1.class_id=pkcs7OutputImpl
A.2.3. nsNSKeyOutput
A.2.4. CMMF 出力
付録B 証明書および CRL のデフォルト、制約、および拡張
B.1. デフォルトの参照
B.1.1. Authority Info Access 拡張のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
Method_n |
拡張機能が表示されている証明書を発行した CA に関する追加情報を取得するアクセス方法を指定します。以下の値のいずれかになります。
|
LocationType_n | 証明書を発行した CA に関する追加情報を含む場所の一般名タイプを指定します。これは以下のいずれかのタイプになります。
|
Location_n |
証明書を発行した CA に関する追加情報を取得するためのアドレスまたは場所を指定します。
|
Enable_n | この場所を有効にするかどうかを指定します。true を選択してセットとしてマークします。false を選択して無効にします。 |
B.1.2. Authority Key Identifier 拡張機能のデフォルト
- No Constraints は、「No Constraint」 を参照してください。
B.1.3. 認証トークンサブジェクト名のデフォルト
- No Constraints は、「No Constraint」 を参照してください。
B.1.4. 基本的な制約拡張機能のデフォルト
- Basic Constraints 拡張機能制約は、「Basic Constraints 拡張機能制約」を参照してください。
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
IsCA | 証明書サブジェクトが CA であるかどうかを指定します。true の場合、サーバーは PathLen パラメーターをチェックして、証明書に指定したパスの長さを設定します。false の場合、サーバーは証明書のサブジェクトを CA 以外として処理し、PathLen パラメーターに指定された値を無視します。 |
PathLen |
パスの長さ、つまり発行されている従属 CA 証明書の下 (従属) にチェーンできる CA 証明書の最大数を指定します。パスの長さは、証明書の検証時に使用する CA 証明書の数に影響します。このチェーンは、チェーンを検証して上に移動させるエンドエンティティー証明書で始まります。
拡張がエンドエンティティー証明書に設定されている場合、maxPathLen パラメーターは機能しません。
許容値は 0 または n です。値は、CA 署名証明書の Basic Constraint 拡張で指定されたパスの長さよりも短くする必要があります。0 は、従属 CA 証明書の下に従属 CA 証明書を許可しないことを指定します。パスをたどることができるのは、エンドエンティティー証明書のみです。n は、ゼロよりも大きい整数でなければなりません。従属 CA 証明書の下で許可される従属 CA 証明書の最大数を指定します。
フィールドが空白の場合、パスの長さはデフォルトで、発行者の証明書の Basic Constraint 拡張機能で設定されたパスの長さによって決定されます。発行者のパスの長さが無制限の場合は、下位 CA 証明書のパスの長さも無制限になります。発行者のパス長がゼロより大きい整数の場合、下位 CA 証明書のパス長は、発行者のパス長より 1 小さい値に設定されます。たとえば、発行者のパス長が 4 の場合、下位 CA 証明書のパス長は 3 に設定されます。
|
B.1.5. CA 有効性のデフォルト
- Validity 制約の場合は、「Validity 制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
bypassCAnotafterrange | 要求側の CA が、発行側の CA の有効期間を超えて有効期間が延長された証明書を要求できるかどうかのデフォルト値を設定します。 |
range | この証明書の絶対有効期間を日数で指定します。 |
startTime | 現在の時間に基づいて有効期間が始まるタイミングを設定します。 |
B.1.6. 証明書ポリシーの拡張機能のデフォルト
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
numCertPolicies | 定義できるポリシーの数を指定します。デフォルトは 5 です。 |
enable | true を選択してポリシーを有効にします。false を選択してポリシーを無効にします。 |
policyId | ポリシーの OID 識別子を指定します。 |
cpsURI.enable | 拡張機能には、発行者 Certificate Practice Statement への URI を含めることができます。true を選択して URI を有効にします。false を選択して URI を無効にします。 |
CPSURI.value | この値は、CA によって公開される Certification Practice Statement (CPS) へのポインターです。ポインターは URI の形式になります。 |
usernotice.enable | 拡張機能には、発行者の Certificate Practice Statement への URI を含めることも、ユーザー通知などの発行者情報をテキスト形式で埋め込むこともできます。ユーザー通知を有効にするには true を選択します。ユーザー通知を無効にするには、false を選択します。 |
usernotice.noticeReference.noticeNumbers | この任意のユーザー通知パラメーターは、他の場所に保存されているメッセージを指す一連の番号です。 |
usernotice.noticeReference.organization | このオプションのユーザー通知パラメーターは会社名を指定します。 |
usernotice.explicitText.value | この任意のユーザー通知パラメーターには、証明書内のメッセージが含まれます。 |
B.1.7. CRL Distribution Points 拡張機能のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
Type_n | CRL ディストリビューションポイントのタイプを指定します。許容値は DirectoryName、URIName、または RelativeToIssuer です。型は、Name フィールドの値に対応する必要があります。 |
Name_n |
CRL 配布ポイントの名前を指定します。名前は次のいずれかの形式にすることができます。
|
Reasons_n |
配布ポイントで保持される CRL で想定される失効理由を指定します。次の定数のコンマ区切りリストを提供します。
|
IssuerType_n |
ディストリビューション中に保持される CRL を署名した発行者の命名タイプを指定します。発行者名は以下のいずれかの形式になります。
|
IssuerName_n |
CRL に署名した CRL 発行者の名前を指定します。許容値は次のとおりです。
このパラメーターの値は、issuerName フィールドの値に対応している必要があります。
|
B.1.8. Extended Key Usage 拡張機能のデフォルト
使用方法 | OID |
---|---|
サーバー認証 | 1.3.6.1.5.5.7.3.1 |
クライアント認証 | 1.3.6.1.5.5.7.3.2 |
コード署名 | 1.3.6.1.5.5.7.3.3 |
1.3.6.1.5.5.7.3.4 | |
IPsec エンドシステム | 1.3.6.1.5.5.7.3.5 |
IPsec トンネル | 1.3.6.1.5.5.7.3.6 |
IPsec ユーザー | 1.3.6.1.5.5.7.3.7 |
タイムスタンプ | 1.3.6.1.5.5.7.3.8 |
- 拡張鍵の使用に関する制約。「拡張された鍵使用拡張制約」 を参照してください。
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
OID | キー使用目的を識別する OID を指定します。許容値は、ドットで区切られた数値コンポーネント表記で指定された一意の有効な OID です。たとえば、2.16.840.1.113730.1.99 です。キーの使用目的に応じて、OID は PKIX (表B.6「Extended Key Usage 拡張機能の PKIX 使用定義」 にリストされている) またはカスタム OID で指定できます。カスタム OID は、会社で使用するために予約された ID の登録済みサブツリーである必要があります。Certificate System の評価とテストにカスタム OID を使用することは可能ですが、実稼働環境では、OID の定義と ID のサブツリーの登録に関する ISO 規則に準拠しています。 |
B.1.9. Freshest CRL 拡張機能のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
PointEnable_n | true を選択してこのポイントを有効にします。false を選択してこのポイント を無効にします。 |
PointType_n | DirectoryName または URIName のいずれかの発行ポイントのタイプを指定します。 |
PointName_n |
|
PointIssuerName_n |
CRL に署名した発行者の名前を指定します。名前は以下のいずれかの形式になります。
name の値は、PointType_ で指定した形式に準拠する必要があります。
|
PointType_n | CRL に署名した CRL 発行者の一般的な名前タイプを指定します。許容値は次のとおりです。
|
B.1.10. 一般的な拡張機能のデフォルト
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
genericExtOID | 拡張 OID 識別子を指定します。 |
genericExtData | 拡張に含まれるバイナリーデータ。 |
B.1.11. Inhibit Any-Policy 拡張機能のデフォルト
パラメーター | 説明 |
---|---|
Critical | このポリシーは Critical とマークする必要があります。この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
SkipCerts | このパラメーターで any-policy ポリシーが許可されなくなる前に、パスに表示される追加証明書の数を示します。1 の値は、any-policy は、この証明書のサブジェクトによって発行された証明書で処理できますが、パス内の追加の証明書では処理できないことを示します。 |
B.1.12. Issuer Alternative Name 拡張機能のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
issuerAltExtType | これにより、使用する名前拡張のタイプが設定されます。これは以下のいずれかになります。
|
issuerAltExtPattern |
拡張に追加する要求属性値を指定します。属性の値は、サポートされる一般名のタイプに準拠する必要があります。許容値は、証明書要求に含まれる要求属性です。
サーバーがリクエストの属性を見つけると、拡張に属性値を設定し、その拡張を証明書に追加します。複数の属性が指定され、リクエストに属性が存在しない場合、サーバーは Issuer Alternative Name 拡張を証明書に追加しません。リクエストから適切な属性を使用して issuerAlternativeName を形成することができない場合は、トークン式なしでリテラル文字列を使用できます。たとえば、認証局 です。
|
B.1.13. Key Usage 拡張機能のデフォルト
- Key Usage 制約については、「主な使用拡張機能の制約」 を参照してください。
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
digitalSignature | SSL クライアント証明書と S/MIME 署名証明書を許可するかどうかを指定します。true を選択して設定します。 |
nonRepudiation | S/MIME 署名証明書に使用するかどうかを指定します。true を選択して設定します。
警告
このビットの使用は議論の的になっています。証明書に設定する前に、その使用による法的影響を慎重に検討してください。
|
keyEncipherment | サブジェクトの公開鍵を使用して秘密鍵と秘密鍵のどちらを暗号化するかを指定します。これは、SSL サーバー証明書および S/MIME 暗号化証明書に設定されます。true を選択して設定します。 |
dataEncipherment | サブジェクトの公開鍵を使用して、キー資料とは対照的に、拡張を設定するかどうかを指定します。true を選択して設定します。 |
keyAgreement | サブジェクトの公開鍵がキー合意に使用されるたびに拡張を設定するかどうかを指定します。true を選択して設定します。 |
keyCertsign | 公開鍵を使用して他の証明書の署名を検証するかどうかを指定します。この設定は CA 証明書に使用されます。true を選択してオプションを設定します。 |
cRLSign | CRL に署名する CA 署名証明書の拡張を設定するかどうかを指定します。true を選択して設定します。 |
encipherOnly | 公開鍵が鍵共有の実行中にデータを暗号化するためだけのものである場合に、拡張子を設定するかどうかを指定します。このビットが設定されている場合 、keyAgreement も設定する必要があります。true を選択して設定します。 |
decipherOnly | 公開鍵が鍵共有の実行中にデータを暗号化するためだけのものである場合に、拡張子を設定するかどうかを指定します。このビットが設定されている場合 、keyAgreement も設定する必要があります。true を選択して設定します。 |
B.1.14. Name Constraints 拡張機能のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
PermittedSubtreesn.min |
許可されるサブツリーの最小数を指定します。
|
PermittedSubtreesmax_n |
許可されるサブツリーの最大数を指定します。
|
PermittedSubtreeNameChoice_n | 拡張に含める許可されるサブツリーの一般な名前タイプを指定します。許容値は次のとおりです。
|
PermittedSubtreeNameValue_n |
拡張に含める許可されるサブツリーの汎用名を指定します。
|
PermittedSubtreeEnable_n | true を選択して、このサブツリーエントリーを許可します。 |
ExcludedSubtreesn.min |
除外されたサブツリーの最小数を指定します。
|
ExcludedSubtreeMax_n |
除外されたサブツリーの最大数を指定します。
|
ExcludedSubtreeNameChoice_n | 拡張に追加する除外されたサブツリーの一般名を指定します。許容値は次のとおりです。
|
ExcludedSubtreeNameValue_n |
拡張に含める許可されるサブツリーの汎用名を指定します。
|
ExcludedSubtreeEnable_n | true を選択して、この除外されたサブツリーエントリーを有効にします。 |
B.1.15. Netscape Certificate Type 拡張機能のデフォルト
B.1.16. Netscape Comment 拡張機能のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
CommentContent | 証明書に表示するコメントの内容を指定します。 |
B.1.17. デフォルト拡張機能なし
B.1.18. OCSP No Check 機能拡張のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
B.1.19. Policy Constraints 拡張機能のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
reqExplicitPolicy |
明示的なポリシーが必要になる前に、パスで許可される証明書の総数を指定します。これは、受け入れ可能なポリシーが必要になる前に、下位 CA 証明書の下にチェーンできる CA 証明書の数です。
この数は、証明書の検証中に使用される CA 証明書の数に影響します。このチェーンは、チェーンを検証して移動させるエンドエンティティー証明書で始まります。このパラメーターは、拡張がエンドエンティティーの証明書に設定されている場合は有効ではありません。
|
inhibitPolicyMapping |
ポリシーマッピングが許可されなくなる前に、パスで許可される証明書の総数を指定します。
|
B.1.20. Policy Mappers 拡張機能のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
IssuerDomainPolicy_n | 別の CA のポリシーステートメントとマッピングするために、発行元 CA のポリシーステートメントに割り当てられた OID を指定します。たとえば、1.2.3.4.5 です。 |
SubjectDomainPolicy_n | 発行 CA のポリシーステートメントに対応するサブジェクト CA のポリシーステートメントに割り当てられた OID を指定します。たとえば、6.7.8.9.10 です。 |
B.1.21. Private Key Usage Period 拡張機能のデフォルト
パラメーター | 説明 |
---|---|
Critical | この拡張は、常にクリティカルではないはずです。 |
puStartTime | このパラメーターは、開始時間を設定します。デフォルト値は 0 です。これは、拡張機能がアクティベートされた時点から有効期間を開始します。 |
puDurationDays | このパラメーターは、使用状況の期間を設定します。デフォルト値は 365 です。これは、拡張機能がアクティブ化されてから 365 日に有効期間を設定します。 |
B.1.22. 署名アルゴリズムのデフォルト
- アルゴリズム制約の署名は、「アルゴリズム制約の署名」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
signingAlg | この証明書の作成に使用するデフォルトの署名アルゴリズムを指定します。signingAlgsAllowed パラメーターに含まれる値のいずれかを指定すると、エージェントはこの値をオーバーライドすることができます。 |
signingAlgsAllowed | この証明書の署名に使用できる署名アルゴリズムを指定します。アルゴリズムは以下のいずれか 1 つになります。
|
B.1.23. サブジェクト代替名の拡張機能のデフォルト
例B.1 サブジェクト代替名の拡張機能のデフォルト設定
policyset.serverCertSet.9.constraint.name=No Constraint policyset.serverCertSet.9.default.class_id=subjectAltNameExtDefaultImpl policyset.serverCertSet.9.default.name=Subject Alternative Name Extension Default policyset.serverCertSet.9.default.params.subjAltExtGNEnable_0=true policyset.serverCertSet.9.default.params.subjAltExtPattern_0=$request.requestor_email$ policyset.serverCertSet.9.default.params.subjAltExtType_0=RFC822Name policyset.serverCertSet.9.default.params.subjAltExtGNEnable_1=true policyset.serverCertSet.9.default.params.subjAltExtPattern_1=$request.SAN1$ policyset.serverCertSet.9.default.params.subjAltExtType_1=DNSName policyset.serverCertSet.9.default.params.subjAltExtGNEnable_2=true policyset.serverCertSet.9.default.params.subjAltExtPattern_2=http://www.server.example.com policyset.serverCertSet.9.default.params.subjAltExtType_2=URIName policyset.serverCertSet.9.default.params.subjAltExtType_3=OtherName policyset.serverCertSet.9.default.params.subjAltExtPattern_3=(IA5String)1.2.3.4,$server.source$ policyset.serverCertSet.9.default.params.subjAltExtSource_3=UUID4 policyset.serverCertSet.9.default.params.subjAltExtGNEnable_3=true policyset.serverCertSet.9.default.params.subjAltExtType_4=RFC822Name policyset.serverCertSet.9.default.params.subjAltExtGNEnable_4=false policyset.serverCertSet.9.default.params.subjAltExtPattern_4= policyset.serverCertSet.9.default.params.subjAltNameExtCritical=false policyset.serverCertSet.9.default.params.subjAltNameNumGNs=5
ポリシーセットトークン | 説明 |
---|---|
$request.auth_token.cn$ | 証明書を要求したユーザーの LDAP 共通名 (cn ) 属性。 |
$request.auth_token.mail$ | 証明書を更新したユーザーの LDAP メール (mail ) 属性の値。 |
$request.auth_token.tokenCertSubject$ | 証明書サブジェクト名。 |
$request.auth_token.uid$ | 証明書を要求したユーザーの LDAP ユーザー ID (uid ) 属性。 |
$request.auth_token.user$ | |
$request.auth_token.userDN$ | 証明書を要求したユーザーのユーザー DN。 |
$request.auth_token.userid$ | 証明書を要求したユーザーのユーザー ID 属性の値。 |
$request.uid$ | 証明書を要求したユーザーのユーザー ID 属性の値。 |
$request.profileRemoteAddr$ | 要求するユーザーの IP アドレス。これは、クライアントに応じて IPv4 アドレスまたは IPv6 アドレスになります。IPv4 アドレスは、n.n.n.n または n.n.n.n,m.m.m.m の形式にする必要があります。たとえば、128.21.39.40 または 128.21.39.40,255.255.255.00 です。IPv6 アドレスは 128 ビット名前空間を使用します。IPv6 アドレスはコロンで区切られ、ネットマスクはピリオドで区切られます。たとえば、0:0:0:0:0:0:13.1.68.3、FF01::43、0:0:0:0:0:0:13.1.68.3,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0、および FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000 になります。 |
$request.profileRemoteHost$ | ユーザーのマシンのホスト名または IP アドレス。ホスト名は、http://server.example.com などの完全修飾ドメイン名およびプロトコルになります。IPv4 アドレスは、n.n.n.n または n.n.n.n,m.m.m.m の形式にする必要があります。たとえば、128.21.39.40 または 128.21.39.40,255.255.255.00 です。IPv6 アドレスは 128 ビット名前空間を使用します。IPv6 アドレスはコロンで区切られ、ネットマスクはピリオドで区切られます。たとえば、0:0:0:0:0:0:13.1.68.3、FF01::43、0:0:0:0:0:0:13.1.68.3,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0、および FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000 になります。 |
$request.requestor_email$ | 要求を送信したユーザーのメールアドレス。 |
$request.requestowner$ | 要求を送信した人。 |
$request.subject$ | 証明書が発行されるエンティティーのサブジェクト名 DN。たとえば、uid=jsmith, e=jsmith@example.com です。 |
$request.tokencuid$ | 登録の要求に使用されるスマートカードトークンのカード一意の ID (CUID)。 |
$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$ 形式になります。 |
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
Pattern | 拡張に追加する要求属性値を指定します。属性の値は、サポートされる一般名のタイプに準拠する必要があります。サーバーがリクエストの属性を見つけると、拡張に属性値を設定し、その拡張を証明書に追加します。複数の属性が指定され、リクエストに属性が存在しない場合、サーバーは Subject Alternative Name 拡張を証明書に追加しません。許容値は、証明書要求に含まれる要求属性です。たとえば、$request.requestor_email$ です。 |
タイプ |
request 属性の一般的な名前タイプを指定します。
|
ソース | ID を生成するために使用する識別ソースまたはプロトコルを指定します。サポートされるソースは UUID4 で、UUID を作成する乱数を生成します。 |
コンポーネント数 (NumGN) | サブジェクトの別名に含める必要がある名前コンポーネントの数を指定します。 |
B.1.24. サブジェクトディレクトリー属性の拡張機能のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Critical | この拡張機能に critical マークを付けるには true を選択してください。noncritical マークを付けるには false を選択してください。 |
名前 | 属性名。これは、cn 、mail などの LDAP ディレクトリー属性になります。 |
Pattern | 拡張に追加する要求属性値を指定します。属性値は、属性の許可される値に準拠する必要があります。サーバーが属性を見つけると、拡張に属性値を設定し、その拡張を証明書に追加します。複数の属性が指定され、リクエストに属性が存在しない場合、サーバーは Subject Directory Attributes 拡張を証明書に追加しません。たとえば、$request.requestor_email$ です。 |
Enable | その属性が証明書に追加できるかどうかを設定します。true を選択して属性を有効にします。 |
B.1.25. サブジェクト情報アクセス拡張機能のデフォルト
パラメーター | 説明 |
---|---|
Critical | この拡張はクリティカルではないはずです。 |
subjInfoAccessNumADs | 証明書に含まれる情報アクセスセクションの数。 |
subjInfoAccessADMethod_n | アクセスメソッドの OID。 |
subjInfoAccessADMethod_n | アクセスメソッドのタイプ。
|
subjInfoAccessADLocation_n |
タイプ subjInfoAccessADMethod_n を元にした場所
つまり、URI 名の URL。
|
subjInfoAccessADEnable_n | true を選択してこのエクステンションを有効にします。false を選択してこのエクステンションを無効にします。 |
B.1.26. Subject Key Identifier 拡張機能のデフォルト
- Extension Constraint は、「拡張制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
B.1.27. サブジェクト名のデフォルト
- Subject Name 制約の場合は、「Subject Name 制約」を参照してください。
- Unique Subject Name 制約の場合は、「Unique Subject Name 制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
Name | この証明書のサブジェクト名を指定します。 |
Name
パラメーターを、AuthTokenの SubjectName に置き換えます。
policyset.userCertSet.1.default.class_id=subjectNameDefaultImpl policyset.userCertSet.1.default.name=Subject Name Default policyset.userCertSet.1.default.params.name=$request.auth_token.tokenCertSubject$
B.1.28. ユーザーキーのデフォルト
- キー制約については、「主要な制約」 を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
B.1.29. ユーザー署名アルゴリズムのデフォルト
- アルゴリズム制約の署名は、「アルゴリズム制約の署名」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
B.1.30. ユーザーのサブジェクト名のデフォルト
- Subject Name 制約の場合は、「Subject Name 制約」を参照してください。
- Unique Subject Name 制約の場合は、「Unique Subject Name 制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
B.1.31. ユーザーの有効性のデフォルト
- Validity 制約の場合は、「Validity 制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
B.1.32. User Supplied Extension Default
policyset.set1.p6.default.class_id=userExtensionDefaultImpl policyset.set1.p6.default.name=User Supplied Extension Default policyset.set1.p6.default.params.userExtOID=2.5.29.19
- 拡張機能の OID が証明書要求とデフォルトの両方で指定されている場合、拡張機能は制約によって検証され、証明書に適用されます。
- 拡張機能の OID が要求で指定されているが、プロファイルの User Supplied Extension Default で指定されていない場合、ユーザー指定の拡張機能は無視され、証明書はその拡張機能なしで正常に登録されます。
- この拡張機能が対応する OID (拡張機能制約) を持つプロファイルに設定されている場合、そのプロファイルを介して処理される証明書要求には、指定された拡張機能を含める 必要があります。そうでない場合、要求は拒否されます。
userExtOID
パラメーターで指定された OID は、Extended Key Usage Extension 用です。
例B.2 Extended Key Usage Extension の User Supplied Extension Default
policyset.set1.2.constraint.class_id=extendedKeyUsageExtConstraintImpl policyset.set1.2.constraint.name=Extended Key Usage Extension policyset.set1.2.constraint.params.exKeyUsageCritical=false policyset.set1.2.constraint.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.4 policyset.set1.2.default.class_id=userExtensionDefaultImpl policyset.set1.2.default.name=User Supplied Extension Default policyset.set1.2.default.params.userExtOID=2.5.29.37
例B.3 CSR の Multiple User Supplied Extension
- Extended Key Usage Extension の場合:
policyset.serverCertSet.2.constraint.class_id=extendedKeyUsageExtConstraintImpl policyset.serverCertSet.2.constraint.name=Extended Key Usage Extension policyset.serverCertSet.2.constraint.params.exKeyUsageCritical=false policyset.serverCertSet.2.constraint.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.4 policyset.serverCertSet.2.default.class_id=userExtensionDefaultImpl policyset.serverCertSet.2.default.name=User Supplied Extension Default policyset.serverCertSet.2.default.params.userExtOID=2.5.29.37
- Key Usage Extension の場合:以下の形式を使用すると、拡張機能のパラメーターを適用するポリシーを適用できます。
- CSR: value = "true" になければなりません
- CSR: value = "false" に存在してはなりません
- オプション: value = "-"
以下に例を示します。policyset.serverCertSet.13.constraint.class_id=keyUsageExtConstraintImpl policyset.serverCertSet.13.constraint.name=Key Usage Extension Constraint policyset.serverCertSet.13.constraint.params.keyUsageCritical=- policyset.serverCertSet.13.constraint.params.keyUsageCrlSign=false policyset.serverCertSet.13.constraint.params.keyUsageDataEncipherment=- policyset.serverCertSet.13.constraint.params.keyUsageDecipherOnly=- policyset.serverCertSet.13.constraint.params.keyUsageDigitalSignature=- policyset.serverCertSet.13.constraint.params.keyUsageEncipherOnly=- policyset.serverCertSet.13.constraint.params.keyUsageKeyAgreement=true policyset.serverCertSet.13.constraint.params.keyUsageKeyCertSign=- policyset.serverCertSet.13.constraint.params.keyUsageKeyEncipherment=- policyset.serverCertSet.13.constraint.params.keyUsageNonRepudiation=- policyset.serverCertSet.13.default.class_id=userExtensionDefaultImpl policyset.serverCertSet.13.default.name=User Supplied Key Usage Extension policyset.serverCertSet.13.default.params.userExtOID=2.5.29.15
certutil
を使用したユーザー定義拡張による CSR の作成」 を参照してください。
B.1.33. 有効性のデフォルト
- Validity 制約の場合は、「Validity 制約」を参照してください。
- No Constraints は、「No Constraint」 を参照してください。
パラメーター | 説明 |
---|---|
range | この証明書の有効期限を指定します。 |
startTime | 現在の時間に基づいて有効期間が始まるタイミングを設定します。 |
B.2. 制約の参照
B.2.1. Basic Constraints 拡張機能制約
パラメーター | 説明 |
---|---|
basicConstraintsCritical | エクステンションは critical または noncritical のマークを付けるかどうかを指定します。この拡張機能をクリティカルとしてマークする場合は true を選択します。この拡張機能がクリティカルとしてマークされないようにするには、false を選択します。ハイフン - を選択しても、影響度が重大を意味します。 |
basicConstraintsIsCA | 証明書サブジェクトが CA であるかどうかを指定します。true を選択すると、(CA である) このパラメーターに true の値を要求します。false を選択して、このパラメーターの true の値を無効にします。ハイフン - を選択すると、このパラメーターに制約を設定しないことを示します。 |
basicConstraintsMinPathLen |
最小許容パスの長さ、つまり発行されている従属 CA 証明書の下 (従属) にチェーンできる CA 証明書の最大数を指定します。パスの長さは、証明書の検証時に使用する CA 証明書の数に影響します。このチェーンは、チェーンを検証して上に移動させるエンドエンティティー証明書で始まります。
拡張がエンドエンティティー証明書に設定されている場合、このパラメーターは機能しません。
許容値は 0 または n です。値は、CA 署名証明書の Basic Constraint 拡張で指定されたパスの長さよりも短くする必要があります。
0 は、発行されている従属 CA 証明書の下に従属 CA 証明書を許可しないことを指定します。パスをたどることができるのは、エンドエンティティー証明書のみです。
n は、ゼロよりも大きい整数でなければなりません。これは、使用されている従属 CA 証明書の下で許可される従属 CA 証明書の最小数です。
|
basicConstraintsMaxPathLen |
最大許容パスの長さ、つまり発行されている従属 CA 証明書の下 (従属) にチェーンできる CA 証明書の最大数を指定します。パスの長さは、証明書の検証時に使用する CA 証明書の数に影響します。このチェーンは、チェーンを検証して上に移動させるエンドエンティティー証明書で始まります。
拡張がエンドエンティティー証明書に設定されている場合、このパラメーターは機能しません。
許容値は 0 または n です。値は、CA 署名証明書の Basic Constraints 拡張で指定されたパスの長さよりも大きくする必要があります。
0 は、発行されている従属 CA 証明書の下に従属 CA 証明書を許可しないことを指定します。パスをたどることができるのは、エンドエンティティー証明書のみです。
n は、ゼロよりも大きい整数でなければなりません。これは、使用されている従属 CA 証明書の下で許可される従属 CA 証明書の最大数です。
フィールドが空白の場合、パスの長さはデフォルトで、発行者の証明書の Basic Constraint 拡張機能で設定されたパスの長さによって決定されます。発行者のパスの長さが無制限の場合は、下位 CA 証明書のパスの長さも無制限です。発行者のパス長がゼロより大きい整数の場合、下位 CA 証明書のパス長は、発行者のパス長より 1 小さい値に設定されます。たとえば、発行者のパス長が 4 の場合、下位 CA 証明書のパス長は 3 に設定されます。
|
B.2.2. CA Validity 制約
B.2.3. 拡張された鍵使用拡張制約
パラメーター | 説明 |
---|---|
exKeyUsageCritical | true に設定すると、エクステンションは重要であるとマークできます。false に設定すると、拡張は重要でないとしてマークできます。 |
exKeyUsageOIDs | キーの使用目的を特定する許容可能な OID を指定します。複数の OID をコンマ区切りの一覧に追加できます。 |
B.2.4. 拡張制約
パラメーター | 説明 |
---|---|
extCritical | エクステンションは critical または noncritical のマークを付けるかどうかを指定します。true を選択して拡張機能を重要 (Critical) とマークします。false を選択して、非クリティカルにマークします。- を選択して、優先なしを強制します。 |
extOID | 制約を渡すために証明書に存在する必要がある拡張の OID。 |
B.2.5. 主要な制約
KeyParameters
パラメーターには、有効なキーサイズのコンマ区切りリストが含まれ、EC キーの場合は KeyParameters
パラメーターには、使用可能な ECC 曲線のコンマ区切りのリストが含まれています。
パラメーター | 説明 |
---|---|
keyType | キーの種類を指定します。これはデフォルトで - に設定されており、RSA キーシステムを使用します。rsa と ec を選択できます。キータイプが指定され、システムで識別されていない場合、制約は拒否されます。 |
KeyParameters | 特定のキーパラメーターを定義します。キーに設定されるパラメーターは、keyType パラメーターの値によって異なります (つまり、キータイプによって異なります)。
|
B.2.6. 主な使用拡張機能の制約
パラメーター | 説明 |
---|---|
keyUsageCritical | true を選択して、この拡張機能を重要としてマークします。false を選択して、非クリティカルにマークします。設定しない場合は - を選択します。 |
keyUsageDigitalSignature | SSL クライアント証明書と S/MIME 署名証明書を許可するかどうかを指定します。この値を set としてマークするには true を選択します。選択されないようにするには false を選択します。このパラメーターに制約がないことを示するには、ハイフン (-) を選択します。 |
kleyUsageNonRepudiation | S/MIME 署名証明書を設定するかどうかを指定します。この値を set としてマークするには true を選択します。選択されないようにするには false を選択します。このパラメーターに制約がないことを示するには、ハイフン (-) を選択します。
警告
このビットの使用は議論の的になっています。証明書に設定する前に、その使用による法的影響を慎重に検討してください。
|
keyEncipherment | SSL サーバー証明書と S/MIME 暗号化証明書の拡張子を設定するかどうかを指定します。この値を set としてマークするには true を選択します。選択されないようにするには false を選択します。このパラメーターに制約がないことを示するには、ハイフン (-) を選択します。 |
keyUsageDataEncipherment | キーマテリアルの代わりに、サブジェクトの公開キーを使用してユーザーデータを暗号化するときに、拡張子を設定するかどうかを指定します。この値を set としてマークするには true を選択します。選択されないようにするには false を選択します。このパラメーターに制約がないことを示するには、ハイフン (-) を選択します。 |
keyUsageKeyAgreement | サブジェクトの公開鍵がキー合意に使用されるたびに拡張を設定するかどうかを指定します。この値を set としてマークするには true を選択します。選択されないようにするには false を選択します。このパラメーターに制約がないことを示するには、ハイフン (-) を選択します。 |
keyUsageCertsign | この機能がすべての CA 署名証明書に適用されるかどうかを指定します。この値を set としてマークするには true を選択します。選択されないようにするには false を選択します。このパラメーターに制約がないことを示するには、ハイフン (-) を選択します。 |
keyUsageCRLSign | CRL に署名するのに使用する CA 署名証明書の拡張を設定するかどうかを指定します。この値を set としてマークするには true を選択します。選択されないようにするには false を選択します。このパラメーターに制約がないことを示するには、ハイフン (-) を選択します。 |
keyUsageEncipherOnly | 公開鍵を使用してデータの暗号化のみに使用する場合に、拡張機能を設定するかどうかを指定します。このビットが設定されている場合は、keyUsageKeyAgreement も設定する必要があります。この値を set としてマークするには true を選択します。選択されないようにするには false を選択します。このパラメーターに制約がないことを示するには、ハイフン (-) を選択します。 |
keyUsageDecipherOnly | 公開鍵をデータの解読にのみ使用する場合に、拡張子を設定するかどうかを指定します。このビットが設定されている場合は、keyUsageKeyAgreement も設定する必要があります。この値を set としてマークするには true を選択します。選択されないようにするには false を選択します。このパラメーターに制約がないことを示するには、ハイフン (-) を選択します。 |
B.2.7. Netscape Certificate Type 拡張機能の制約
B.2.8. No Constraint
B.2.9. Renewal Grace Period 制約
パラメーター | 説明 |
---|---|
renewal.graceAfter | 証明書の期限が切れた 後、更新用に提出できる期間を日数単位で設定します。証明書の有効期限が切れると、更新要求は拒否されます。値を指定しない場合、制限はありません。 |
renewal.graceBefore | 証明書の期限が切れる 前、更新用に提出できる期間を日数単位で設定します。証明書が有効期限にそれほど近くない場合、更新要求は拒否されます。値を指定しない場合、制限はありません。 |
B.2.10. アルゴリズム制約の署名
パラメーター | 説明 |
---|---|
signingAlgsAllowed | 証明書の署名に指定できる署名アルゴリズムを設定します。アルゴリズムは以下のいずれか 1 つになります。
|
B.2.11. Subject Name 制約
パラメーター | 説明 |
---|---|
Pattern | サブジェクト DN を構築する正規表現または他の文字列を指定します。 |
Subject Name 名と正規表現
Subject Name Constraint の正規表現は、正規表現を照合するための Java 機能によって照合されます。これらの正規表現の形式は、https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html に記載されています。これにより、アスタリスク (*) などのワイルドカードは、任意の数の文字とピリオド (.) が、任意のタイプの文字を検索します。
uid
属性で始まる必要があることを意味します。ピリオドアスタリスク (.*) ワイルドカードを使用すると、uid
の後に任意のタイプと文字数文字を続けることができます。
証明書の要求における Subject Name および UID または CN
サブジェクト DN を構築するために使用されるパターンは、証明書を要求する人の CN または UID に基づくこともできます。Subject Name Constraint は、証明書要求の DN で認識する CN (または UID) のパターンを設定し、Subject Name Default は、その CN に、事前定義されたディレクトリーツリーを使用して証明書のサブジェクト DN を作成します。
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
B.2.12. Unique Key 制約
パラメーター | 説明 |
---|---|
allowSameKeyRenewal |
公開鍵は一意でなく、かつ サブジェクト DN が既存の証明書と一致し、このパラメーターが true に設定されている場合、リクエストは更新と見なされ、受け入れられます。ただし、公開鍵が重複していて、既存の Subject DN と一致しない場合、要求は拒否されます。
このパラメーターが false に設定されていると、重複した公開鍵リクエストは拒否されます。
|
B.2.13. Unique Subject Name 制約
パラメーター | 説明 |
---|---|
enableKeyUsageExtensionChecking | キーの使用設定が異なる限り、証明書が同じサブジェクト名を持つことを許可するオプションの設定。これは true または false です。デフォルトは true で、重複したサブジェクト名を許可します。 |
B.2.14. Validity 制約
notBefore
パラメーターは受け入れず、notBefore
時間よりも早い時間を提供する notAfter
パラメーターは受け入れません。
パラメーター | 説明 |
---|---|
range | 有効期間の範囲。日数を設定する整数です。notBefore 時間と notAfter 時間の差 (日数) は範囲値よりも短くする必要があります。そうでない場合、この制約は拒否されます。 |
notBeforeCheck | 範囲が猶予期間内ではないことを確認します。ブール値パラメーター NotBeforeCheck が true に設定されている場合、システムは、notBefore 時間が、現在の時間に notBeforeGracePeriod 値を加えた値より大きくないことを確認します。notBeforeTime が、現在の時間と notBeforeGracePeriod 値の間になければ、この制約は拒否されます。 |
notBeforeGracePeriod | notBefore 時間後の猶予期間 (秒単位)。notBeforeTime が、現在の時間と notBeforeGracePeriod 値の間になければ、この制約は拒否されます。この制約は、notBeforeCheck パラメーターが true に設定されている場合にのみ確認されます。 |
notAfterCheck | 指定された時間が期限切れの期間後にないかどうかを確認します。ブール値パラメーターが notAfterCheck を true に設定されている場合、システムは notAfter 時間は現在の時間より大きくありません。現在の時間がこの notAfter 時間を超えると、この制約は拒否されます。 |
B.3. 標準仕様の X.509 v3 証明書拡張機能リファレンス
例B.4 Pretty-Print 証明書拡張機能の例
Data: Version: v3 Serial Number: 0x1 Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Issuer: CN=Certificate Manager,OU=netscape,O=ExampleCorp,L=MV,ST=CA,C=US Validity: Not Before: Friday, February 21, 2005 12:00:00 AM PST America/Los_Angeles Not After: Monday, February 21, 2007 12:00:00 AM PST America/Los_Angeles Subject: CN=Certificate Manager,OU=netscape,O=ExampleCorp,L=MV,ST=CA,C=US Subject Public Key Info: Algorithm: RSA - 1.2.840.113549.1.1.1 Public Key: Exponent: 65537 Public Key Modulus: (2048 bits) : E4:71:2A:CE:E4:24:DC:C4:AB:DF:A3:2E:80:42:0B:D9: CF:90:BE:88:4A:5C:C5:B3:73:BF:49:4D:77:31:8A:88: 15:A7:56:5F:E4:93:68:83:00:BB:4F:C0:47:03:67:F1: 30:79:43:08:1C:28:A8:97:70:40:CA:64:FA:9E:42:DF: 35:3D:0E:75:C6:B9:F2:47:0B:D5:CE:24:DD:0A:F7:84: 4E:FA:16:29:3B:91:D3:EE:24:E9:AF:F6:A1:49:E1:96: 70:DE:6F:B2:BE:3A:07:1A:0B:FD:FE:2F:75:FD:F9:FC: 63:69:36:B6:5B:09:C6:84:92:17:9C:3E:64:C3:C4:C9 Extensions: Identifier: Netscape Certificate Type - 2.16.840.1.113730.1.1 Critical: no Certificate Usage: SSL CA Secure Email CA ObjectSigning CA Identifier: Basic Constraints - 2.5.29.19 Critical: yes Is CA: yes Path Length Constraint: UNLIMITED Identifier: Subject Key Identifier - 2.5.29.14 Critical: no Key Identifier: 3B:46:83:85:27:BC:F5:9D:8E:63:E3:BE:79:EF:AF:79: 9C:37:85:84 Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: 3B:46:83:85:27:BC:F5:9D:8E:63:E3:BE:79:EF:AF:79: 9C:37:85:84 Identifier: Key Usage: - 2.5.29.15 Critical: yes Key Usage: Digital Signature Key CertSign Crl Sign Signature: Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Signature: AA:96:65:3D:10:FA:C7:0B:74:38:2D:93:54:32:C0:5B: 2F:18:93:E9:7C:32:E6:A4:4F:4E:38:93:61:83:3A:6A: A2:11:91:C2:D2:A3:48:07:6C:07:54:A8:B8:42:0E:B4: E4:AE:42:B4:B5:36:24:46:4F:83:61:64:13:69:03:DF: 41:88:0B:CB:39:57:8C:6B:9F:52:7E:26:F9:24:5E:E7: BC:FB:FD:93:13:AF:24:3A:8F:DB:E3:DC:C9:F9:1F:67: A8:BD:0B:95:84:9D:EB:FC:02:95:A0:49:2C:05:D4:B0: 35:EA:A6:80:30:20:FF:B1:85:C8:4B:74:D9:DC:BB:50
B.3.1. authorityInfoAccess
B.3.2. authorityKeyIdentifier
- keyIdentifier フィールドに設定される明示的なキー識別子
- authorityCertSerialNumber フィールドで設定、シリアル番号、authorityCertSerialNumber フィールドで設定、証明書を識別。
B.3.3. basicConstraints
OID
2.5.29.19
Criticality
PKIX Part 1 では、この拡張が critical とマークされている必要があります。この拡張機能は、その重要度に関係なく評価されます。
B.3.4. certificatePoliciesExt
OID
2.5.29.32
Criticality
この拡張機能は、重要な場合と重要でない場合があります。
B.3.5. CRLDistributionPoints
OID
2.5.29.31
Criticality
PKIX では、この拡張機能を非クリティカルとマークし、すべての証明書でサポートすることが推奨されます。
B.3.6. extKeyUsage
OID
2.5.29.37
Criticality
この拡張機能がクリティカルとマークされている場合、証明書は指定された目的の 1 つにのみ使用する必要があります。クリティカルとマークされていない場合は、キーを識別するために使用できるアドバイザリーフィールドとして扱われますが、証明書の使用は指定された目的に制限されません。
使用 | OID |
---|---|
サーバー認証 | 1.3.6.1.5.5.7.3.1 |
クライアント認証 | 1.3.6.1.5.5.7.3.2 |
コード署名 | 1.3.6.1.5.5.7.3.3 |
1.3.6.1.5.5.7.3.4 | |
タイムスタンプ | 1.3.6.1.5.5.7.3.8 |
OCSP 署名 |
1.3.6.1.5.5.7.3.9[a]
|
[a]
OCSP 署名は PKIX Part 1 では定義されていませんが、RFC 2560 『X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP』 では定義されていません。
|
使用 | OID |
---|---|
証明書トラストリスト署名 | 1.3.6.1.4.1.311.10.3.1 |
Microsoft Server Gated Crypto (SGC) | 1.3.6.1.4.1.311.10.3.3 |
Microsoft 暗号化ファイルシステム | 1.3.6.1.4.1.311.10.3.4 |
Netscape SGC | 2.16.840.1.113730.4.1 |
B.3.7. issuerAltName 拡張
OID
2.5.29.18
Criticality
PKIX Part 1 は、この拡張を非クリティカルとしてマークすることを推奨します。
B.3.8. keyUsage
- SSL クライアント証明書、S/MIME 署名証明書、およびオブジェクト署名証明書用の digitalSignature (0)。
- 一部の S/MIME 署名証明書およびオブジェクト署名証明書用の nonRepudiation (1)警告このビットの使用は議論の的になっています。証明書に設定する前に、その使用による法的影響を慎重に検討してください。
- これは、SSL サーバー証明書および S/MIME 暗号化証明書の keyEncipherment (2) に設定されます。
- dataEncipherment (3) サブジェクトの公開鍵を使用して、鍵情報ではなくユーザーデータを暗号化するとき。
- keyAgreement (4) サブジェクトの公開鍵がキー合意に使用される場合。
- すべての CA 署名証明書用の keyCertSign (5)。
- CRL の署名に使用される CA 署名証明書の cRLSign (6)。
- encipherOnly (7) 公開鍵がデータの暗号化にのみ使用される場合。このビットが設定されている場合 、keyAgreement も設定する必要があります。
- decipherOnly (8) 公開鍵がデータの暗号化にのみ使用される場合。このビットが設定されている場合 、keyAgreement も設定する必要があります。
OID
2.5.29.15
Criticality
この拡張機能は、重要な場合と重要でない場合があります。PKIX Part 1 を使用する場合は、クリティカルなマークを付けることが推奨されます。
証明書の目的 | 必要な鍵使用量のビット |
---|---|
CA 署名 |
|
SSL クライアント | digitalSignature |
SSL Server | keyEncipherment |
S/MIME 署名 | digitalSignature |
S/MIME 暗号化 | keyEncipherment |
証明書の署名 | keyCertSign |
オブジェクトの署名 | digitalSignature |
B.3.9. nameConstraints
OID
2.5.29.30
Criticality
PKIX Part 1 では、この拡張が critical とマークされている必要があります。
B.3.10. OCSPNocheck
OID
1.3.6.1.5.5.7.48.4
Criticality
この拡張はクリティカルではありません。
B.3.11. policyConstraints
OID
2.5.29.36
Criticality
この拡張機能は、重要な場合と重要でない場合があります。
B.3.12. policyMappings
OID
2.5.29.33
Criticality
この拡張はクリティカルでない必要があります。
B.3.13. privateKeyUsagePeriod
OID
2.5.29.16
B.3.14. subjectAltName
OID
2.5.29.17
Criticality
証明書の subject フィールドが空の場合は、この拡張機能にクリティカルのマークが付けられている必要があります。
B.3.15. subjectDirectoryAttributes
OID
2.5.29.9
Criticality
PKIX Part 1 では、この拡張が非クリティカルなものとしてマークされている必要があります。
B.3.16. subjectKeyIdentifier
OID
2.5.29.14
Criticality
この拡張機能は常にクリティカルではありません。
B.4. CRL 拡張機能
B.4.1. CRL 拡張について
B.4.1.1. CRL 拡張の構造
- 拡張のオブジェクト識別子 (OID)。この識別子は、拡張子を一意に識別します。また、値フィールドの ASN.1 タイプの値や、値が解釈される方法も決定します。拡張機能が CRL に表示されると、OID は拡張機能 ID フィールド (extnID) として示されます。また、対応する ASN.1 エンコード構造は、オクテット文字列の値 (extnValue) として示されます。例は 例B.4「Pretty-Print 証明書拡張機能の例」 で示されます。
- critical というフラグまたはブール値フィールドこのフィールドに割り当てられた true 値または false 値は、拡張機能が CRL にとってクリティカルか非クリティカルかを示します。
- 拡張機能が重要であり、拡張機能の ID に基づいて拡張機能を理解しないアプリケーションに CRL が送信された場合は、アプリケーションが CRL を拒否する必要があります。
- 拡張機能が重要ではなく、拡張機能の ID に基づいて拡張機能を理解しないアプリケーションに CRL が送信された場合、アプリケーションは拡張機能を無視して CRL を受け入れることができます。
- 拡張の値の DER エンコーディングを含む octet 文字列。
B.4.1.2. CRL および CRL エントリー拡張のサンプル
Certificate Revocation List: Data: Version: v2 Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Issuer: CN=Certificate Authority,O=Example Domain This Update: Wednesday, July 29, 2009 8:59:48 AM GMT-08:00 Next Update: Friday, July 31, 2009 8:59:48 AM GMT-08:00 Revoked Certificates: 1-3 of 3 Serial Number: 0x11 Revocation Date: Thursday, July 23, 2009 10:07:15 AM GMT-08:00 Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: Privilege_Withdrawn Serial Number: 0x1A Revocation Date: Wednesday, July 29, 2009 8:50:11 AM GMT-08:00 Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: Certificate_Hold Identifier: Invalidity Date - 2.5.29.24 Critical: no Invalidity Date: Sun Jul 26 23:00:00 GMT-08:00 2009 Serial Number: 0x19 Revocation Date: Wednesday, July 29, 2009 8:50:49 AM GMT-08:00 Extensions: Identifier: Revocation Reason - 2.5.29.21 Critical: no Reason: Key_Compromise Identifier: Invalidity Date - 2.5.29.24 Critical: no Invalidity Date: Fri Jul 24 23:00:00 GMT-08:00 2009 Extensions: Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1 Critical: no Access Description: Method #0: ocsp Location #0: URIName: http://example.com:9180/ca/ocsp Identifier: Issuer Alternative Name - 2.5.29.18 Critical: no Issuer Names: DNSName: example.com Identifier: Authority Key Identifier - 2.5.29.35 Critical: no Key Identifier: 50:52:0C:AA:22:AC:8A:71:E3:91:0C:C5:77:21:46:9C: 0F:F8:30:60 Identifier: Freshest CRL - 2.5.29.46 Critical: no Number of Points: 1 Point 0 Distribution Point: [URIName: http://server.example.com:8443/ca/ee/ca/getCRL?op=getDeltaCRL&crlIssuingPoint=MasterCRL] Identifier: CRL Number - 2.5.29.20 Critical: no Number: 39 Identifier: Issuing Distribution Point - 2.5.29.28 Critical: yes Distribution Point: Full Name: URIName: http://example.com:9180/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL Only Contains User Certificates: no Only Contains CA Certificates: no Indirect CRL: no Signature: Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5 Signature: 47:D2:CD:C9:E5:F5:9D:56:0A:97:31:F5:D5:F2:51:EB: 1F:CF:FA:9E:63:D4:80:13:85:E5:D8:27:F0:69:67:B5: 89:4F:59:5E:69:E4:39:93:61:F2:E3:83:51:0B:68:26: CD:99:C4:A2:6C:2B:06:43:35:36:38:07:34:E4:93:80: 99:2F:79:FB:76:E8:3D:4C:15:5A:79:4E:E5:3F:7E:FC: D8:78:0D:1D:59:A0:4C:14:42:B7:22:92:89:38:3A:4C: 4A:3A:06:DE:13:74:0E:E9:63:74:D0:2F:46:A1:03:37: 92:F0:93:D9:AA:F8:13:C5:06:25:02:B0:FD:3B:41:E7: 62:6F:67:A3:9F:F5:FA:03:41:DA:8D:FD:EA:2F:E3:2B: 3E:F8:E9:CC:3B:9F:E4:ED:73:F2:9E:B9:54:14:C1:34: 68:A7:33:8F:AF:38:85:82:40:A2:06:97:3C:B4:88:43: 7B:AF:5D:87:C4:47:63:4A:11:65:E3:75:55:4D:98:97: C2:2E:62:08:A4:04:35:5A:FE:0A:5A:6E:F1:DE:8E:15: 27:1E:0F:87:33:14:16:2E:57:F7:DC:77:BE:D2:75:AB: A9:7C:42:1F:84:6D:40:EC:E7:ED:84:F8:14:16:28:33: FD:11:CD:C5:FC:49:B7:7B:39:57:B3:E6:36:E5:CD:B6
ertificate Revocation List:
Data:
Version: v2
Signature Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
Issuer: CN=Certificate Authority,O=SjcRedhat Domain
This Update: Wednesday, July 29, 2009 9:02:28 AM GMT-08:00
Next Update: Thursday, July 30, 2009 9:02:28 AM GMT-08:00
Revoked Certificates:
Serial Number: 0x1A
Revocation Date: Wednesday, July 29, 2009 9:00:48 AM GMT-08:00
Extensions:
Identifier: Revocation Reason - 2.5.29.21
Critical: no
Reason: Remove_from_CRL
Serial Number: 0x17
Revocation Date: Wednesday, July 29, 2009 9:02:16 AM GMT-08:00
Extensions:
Identifier: Revocation Reason - 2.5.29.21
Critical: no
Reason: Certificate_Hold
Identifier: Invalidity Date - 2.5.29.24
Critical: no
Invalidity Date: Mon Jul 27 23:00:00 GMT-08:00 2009
Extensions:
Identifier: Authority Info Access: - 1.3.6.1.5.5.7.1.1
Critical: no
Access Description:
Method #0: ocsp
Location #0: URIName: http://server.example.com:8443/ca/ocsp
Identifier: Delta CRL Indicator - 2.5.29.27
Critical: yes
Base CRL Number: 39
Identifier: Issuer Alternative Name - 2.5.29.18
Critical: no
Issuer Names:
DNSName: a-f8.sjc.redhat.com
Identifier: Authority Key Identifier - 2.5.29.35
Critical: no
Key Identifier:
50:52:0C:AA:22:AC:8A:71:E3:91:0C:C5:77:21:46:9C:
0F:F8:30:60
Identifier: CRL Number - 2.5.29.20
Critical: no
Number: 41
Identifier: Issuing Distribution Point - 2.5.29.28
Critical: yes
Distribution Point:
Full Name:
URIName: http://server.example.com:8443/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL
Only Contains User Certificates: no
Only Contains CA Certificates: no
Indirect CRL: no
Signature:
Algorithm: SHA1withRSA - 1.2.840.113549.1.1.5
Signature:
68:28:DA:90:D5:39:CB:6D:BE:42:04:77:C9:E4:09:60:
C1:97:A6:99:AB:A0:5B:A2:F3:8B:5E:4E:D6:05:70:B0:
87:1F:D7:0E:4B:C6:B2:DE:8B:92:D8:7C:3B:36:1C:79:
96:2A:64:E6:7A:25:1D:E7:40:62:48:7A:24:C9:9D:11:
A6:7F:BB:6B:03:A0:9C:1D:BC:1C:EE:9A:4B:A6:48:2C:
3B:5E:2B:B1:70:3C:C3:42:96:28:26:AB:82:18:F2:E9:
F2:55:48:A8:7E:7F:FE:D4:3D:0B:EA:A2:2F:4E:E6:C3:
C3:C1:6A:E5:C6:85:5B:42:B1:70:2A:C6:E1:D9:0C:AF:
DA:01:22:FF:80:6E:2E:A7:E5:34:DC:AF:E6:C2:B5:B3:
1B:FC:28:36:8A:91:4A:22:E7:03:A5:ED:4E:62:0C:D9:
7F:81:BB:80:99:B8:61:2A:02:C6:9C:41:2E:01:82:21:
80:82:69:52:BD:B2:AA:DB:0F:80:0A:7E:2A:F3:15:32:
69:D2:40:0D:39:59:93:75:A2:ED:24:70:FB:EE:19:C0:
BE:A2:14:36:D0:AC:E8:E2:EE:23:83:DD:BC:DF:38:1A:
9E:37:AF:E3:50:D9:47:9D:22:7C:36:35:BF:13:2C:16:
A2:79:CF:05:41:88:8E:B6:A2:4E:B3:48:6D:69:C6:38
B.4.2. 標準 X.509 v3 CRL 拡張機能リファレンス
B.4.2.1. CRL の拡張機能
B.4.2.1.1. authorityInfoAccess
パラメーター | 説明 |
---|---|
enable | ルールを有効または無効するかどうかを指定します。デフォルトでは、この拡張機能は無効になっています。 |
critical | 拡張がクリティカルとマークされるかどうかを設定します。デフォルトは非クリティカルです。 |
numberOfAccessDescriptions |
0 から任意の正の整数までのアクセス記述の数を示します。デフォルトは 0 です。
このパラメーターを 0 以外の整数に設定する場合は、数値を設定し、OK をクリックしてウィンドウを閉じます。ルールの編集ウィンドウを再度開き、ポイントを設定するフィールドが存在します。
|
accessMethodn | このパラメーターで許可される値は caIssuers のみです。caIssuers メソッドは、利用可能な情報に CRL の署名の検証に使用できる証明書がリストされている場合に使用されます。AIA 拡張が CRL に含まれる場合、他の方法は使用しないでください。 |
accessLocationTypen | n アクセスの説明のアクセス場所を指定します。オプションは DirectoryName または URI です。 |
accessLocationn |
accessLocationType が DirectoryName に設定されている場合、値は証明書のサブジェクト名と同様に、X.500 名の形式の文字列である必要があります。たとえば、 CN=CACentral,OU=Research Dept,O=Example Corporation,C=US となります。
accessLocationType が URI に設定されている場合、名前は URI である必要があります。URI は絶対パス名で、ホストを指定する必要があります。例: http://testCA.example.com/get/crls/here/。
|
B.4.2.1.2. authorityKeyIdentifier
パラメーター | 説明 |
---|---|
enable | ルールを有効または無効するかどうかを指定します。デフォルトでは、この拡張機能は無効になっています。 |
critical | 拡張がクリティカルとマークされるかどうかを設定します。デフォルトは非クリティカルです。 |
B.4.2.1.3. CRLNumber
OID
2.5.29.20
Criticality
この拡張は重要ではありません。
パラメーター
パラメーター | 説明 |
---|---|
enable | ルールが有効であるかどうかを指定します (デフォルト)。 |
critical | 拡張がクリティカルとマークされるかどうかを設定します。デフォルトは非クリティカルです。 |
B.4.2.1.4. deltaCRLIndicator
OID
2.5.29.27
Criticality
PKIX では、その拡張が存在する場合はこの拡張が必須でなければなりません。
パラメーター
パラメーター | 説明 |
---|---|
enable | ルールが有効かどうかを指定します。デフォルトでは無効になっています。 |
critical | 拡張機能がクリティカル、または非クリティカルを設定します。デフォルトでは、これはクリティカルになっています。 |
B.4.2.1.5. FreshestCRL
OID
2.5.29.46
Criticality
PKIX では、この拡張機能は非クリティカルである必要があります。
パラメーター
パラメーター | 説明 |
---|---|
enable | 拡張機能ルールが有効かどうかを指定します。デフォルトでは、これは無効になっています。 |
critical | 拡張にクリティカルまたは非クリティカルのマークを付けます。デフォルトはクリティカルではありません。 |
numPoints | デルタ CRL の発行ポイントの数を、0 から任意の正の整数に指定します。デフォルトは 0 です。これを 0 以外の整数に設定する場合は、数値を設定してから をクリックしてウィンドウを閉じます。ルールの編集ウィンドウを再度開き、これらのポイントを設定するフィールドが存在するようになります。 |
pointTypen | n 発行ポイントの発行ポイントのタイプを指定します。numPoints で指定する数字ごとに、pointType パラメーターの等しい数があります。オプションは DirectoryName または URIName です。 |
pointNamen |
pointType が directoryName に設定されている場合、値は証明書のサブジェクト名と同様に、X.500 名の形式の文字列である必要があります。たとえば、CN=CACentral,OU=Research Dept,O=Example Corporation,C=US となります。
pointType が URIName に設定されている場合、名前は URI である必要があります。URI は絶対パス名で、ホストを指定する必要があります。例: http://testCA.example.com/get/crls/here/。
|
B.4.2.1.6. issuerAltName
OID
2.5.29.18
パラメーター
パラメーター | 説明 |
---|---|
enable | 拡張ルールが有効であるかどうかを設定します。デフォルトでは無効になっています。 |
critical | 拡張がクリティカルかどうかを設定します。デフォルトでは、これは非クリティカルになります。 |
numNames | 拡張で許可される代替名または ID の合計数を設定します。それぞれの名前には、設定パラメーター (nameType および name) のセットがあります。これには適切な値が必要です。そうでない場合、ルールはエラーを返します。このフィールドで指定された値を変更して、ID の総数を変更します。拡張機能に含めることができる ID の総数に制限はありません。設定パラメーターの各セットは、このフィールドの値から派生した整数によって区別されます。たとえば、numNames パラメーターが 2 に設定されている場合、派生整数は 0 と 1 です。 |
nameTypen |
general-name タイプを指定します。次のいずれかになります。
|
namen |
一般名の値を指定します。許可される値は、nameType フィールドで指定された名前の種類によって異なります。
|
B.4.2.1.7. issuingDistributionPoint
OID
2.5.29.28
Criticality
PKIX では、その拡張が存在する場合はこの拡張が必須でなければなりません。
パラメーター
パラメーター | 説明 |
---|---|
enable | 拡張機能を有効にするかどうかを設定します。デフォルトは無効です。 |
critical | 拡張機能をクリティカル、デフォルト、または非クリティカルとしてマークします。 |
pointType |
以下から発行配布ポイントのタイプを指定します。
|
pointName |
発行されたディストリビューションポイントの名前を指定します。分散ポイントの名前は、pointType パラメーターに指定された値によって異なります。
注記
CRL は、CRL 発行ポイントに対応するディレクトリーエントリーに格納される場合があります。これは、CA のディレクトリーエントリーとは異なる場合があります。
|
onlySomeReasons |
ディストリビューションポイントに関連付けられた理由コードを指定します。
許容値は、理由コード (unspecified、keyCompromise、cACompromise、affiliationChanged、asuperseded、cessationOfOperation、certificateHold、および removeFromCRL) の組み合わせです。ディストリビューションポイントにすべての理由コード (デフォルト) を含む失効した証明書が含まれている場合は、フィールドを空白のままにします。
|
onlyContainsCACerts | 設定されている場合に限り、ディストリビューションポイントにユーザー証明書が含まれることを指定します。デフォルトでは、これは設定されていません。つまり、ディストリビューションポイントにはすべての種類の証明書が含まれています。 |
indirectCRL | ディストリビューションポイントに間接 CRL が含まれていることを指定します。デフォルトでは選択されていません。 |
B.4.2.2. CRL エントリー拡張
B.4.2.2.1. certificateIssuer
OID
2.5.29.29
B.4.2.2.2. invalidityDate
OID
2.5.29.24
パラメーター
パラメーター | 説明 |
---|---|
enable | 拡張機能ルールを有効にするか無効にするかを設定します。デフォルトでは、これは有効になります。 |
critical | 拡張機能をクリティカルまたは非クリティカルとしてマークします。デフォルトでは、これは非クリティカルではありません。 |
B.4.2.2.3. CRLReason
OID
2.5.29.21
パラメーター
パラメーター | 説明 |
---|---|
enable | 拡張機能ルールを有効にするか無効にするかを設定します。デフォルトでは、これは有効になります。 |
critical | 拡張にクリティカルまたは非クリティカルのマークを付けます。デフォルトでは、これはクリティカルではありません。 |
B.4.3. Netscape で定義された証明書拡張のリファレンス
B.4.3.1. netscape-cert-type
- ビット 0 - SSL クライアント証明書
- ビット 1 - SSL サーバー証明書
- ビット 2 - S/MIME 証明書
- ビット 3 - オブジェクト署名証明書
- ビット 4 - 予約
- ビット 5 - SSL CA 証明書
- ビット 6 - S/MIME CA 証明書
- ビット 7 - オブジェクト署名 CA 証明書
OID
2.16.840.1.113730.1.1
B.4.3.2. netscape-comment
OID
2.16.840.1.113730.13
付録C 公開モジュールのリファレンス
C.1. パブリッシャープラグインモジュール
C.1.1. FileBasedPublisher
パラメーター | 説明 |
---|---|
Publisher ID | パブリッシャーの名前、スペースを含まない英数字の文字列を指定します。例: PublishCertsToFile |
directory | Certificate Manager がファイルを作成するディレクトリーへの完全なパスを指定します。パスは絶対パスにすることも、Certificate System インスタンスディレクトリーからの相対パスにすることもできます。たとえば、/export/CS/certificates です。 |
C.1.2. LdapCaCertPublisher
パラメーター | 説明 |
---|---|
caCertAttr | CA 証明書を公開する LDAP ディレクトリー属性を指定します。これは、caCertificate;binary でなければなりません。 |
caObjectClass | ディレクトリー内の CA のエントリーのオブジェクトクラスを指定します。これは pkiCA または certificationAuthority でなければなりません。 |
C.1.3. LdapUserCertPublisher
パラメーター | 説明 |
---|---|
certAttr | Certificate Manager が証明書を公開するマップされたエントリーのディレクトリー属性を指定します。これは userCertificate;binary である必要があります。 |
C.1.4. LdapCrlPublisher
パラメーター | 説明 |
---|---|
crlAttr | 証明書マネージャーが CRL を公開するマップされたエントリーのディレクトリー属性を指定します。これは certificateRevocationList;binary でなければなりません。 |
C.1.5. LdapDeltaCrlPublisher
パラメーター | 説明 |
---|---|
crlAttr | Certificate Manager がデルタ CRL を公開するマップされたエントリーのディレクトリー属性を指定します。これは deltaRevocationList;binary である必要があります。 |
C.1.6. LdapCertificatePairPublisher
パラメーター | 説明 |
---|---|
crossCertPairAttr | CA 証明書を公開する LDAP ディレクトリー属性を指定します。これは crossCertificatePair;binary でなければなりません。 |
caObjectClass | ディレクトリー内の CA のエントリーのオブジェクトクラスを指定します。これは pkiCA または certificationAuthority でなければなりません。 |
C.1.7. OCSPPublisher
パラメーター | 説明 |
---|---|
host | Online Certificate Status Manager の完全修飾ホスト名を指定します。 |
ポート | Online Certificate Status Manager が Certificate Manager をリッスンしているポート番号を指定します。これは Online Certificate Status Manager の SSL ポート番号です。 |
path | CRL を公開するためのパスを指定します。これはデフォルトのパス /ocsp/agent/ocsp/addCRL でなければなりません。 |
enableClientAuth | クライアント (証明書ベースの) 認証を使用して OCSP サービスにアクセスするかどうかを設定します。 |
ニックネーム | クライアント認証に使用する OCSP サービスのデータベース内の証明書のニックネームを指定します。これは、enableClientAuth オプションが true に設定されている場合にのみ使用されます。 |
C.2. マッパープラグインモジュール
C.2.1. LdapCaSimpleMap
- CRL の LdapCrlMap (「LdapCrlMap」 を参照)
- CA の LdapCaCertMap (「LdapCaCertMap」 を参照)
パラメーター | 説明 |
---|---|
createCAEntry |
選択した場合は CA のエントリーを作成します (デフォルト)。
選択した場合、Certificate Manager は最初にディレクトリーに CA のエントリーを作成しようとします。Certificate Manager がエントリーの作成に成功すると、CA の証明書をエントリーに公開しようとします。このチェックボックスを選択しないと、公開するためにエントリーがすでに存在している必要があります。
|
dnPattern |
Certificate Manager が公開ディレクトリーで CA のエントリーを検索するために構築するために使用する DN パターンを指定します。dnPattern の値は、コンマで区切られた AVAs の一覧です。AVA は、Certificate Manager が、(cn=$subj.cn など) の証明書のサブジェクト名または制約から派生する変数 (o=Example Corporation など) です。
CA 証明書に cn コンポーネントがない場合に、サブジェクト名のコンポーネントで、CA 証明書マッピングの DN パターンを調整して、CA 証明書が公開されるディレクトリー内のエントリーの DN を反映します。たとえば、CA 証明書のサブジェクト DN が o=Example Corporation で、ディレクトリーの CA エントリーが cn=Certificate Authority, o=Example Corporation の場合、パターンは cn=Certificate Authority, o=$subj.o になります。
上記の例では、$req は証明書要求の属性、$subj は証明書のサブジェクト名の属性、$ext は証明書の拡張子の属性を取ります。
|
C.2.1.1. LdapCaCertMap
uid=$subj.cn,ou=people,o=$subj.o
C.2.1.2. LdapCrlMap
uid=$subj.cn,ou=people,o=$subj.o
C.2.2. LdapDNExactMap
C.2.3. LdapSimpleMap
- 例 1: uid=CertMgr, o=Example Corporation
- 例 2: cn=$subj.cn,ou=$subj.ou,o=$subj.o,c=US
- 例 3: uid=$req.HTTP_PARAMS.uid, e=$ext.SubjectAlternativeName.RFC822Name,ou=$subj.ou
C.2.4. LdapSubjAttrMap
パラメーター | 説明 |
---|---|
certSubjNameAttr | 証明書のサブジェクト名を値として含む LDAP 属性の名前を指定します。デフォルトは certSubjectName ですが、任意の LDAP 属性に設定できます。 |
searchBase | 属性検索を開始するベース DN を指定します。許容値は、o=example.com, c=US などの LDAP エントリーの有効な DN です。 |
C.2.5. LdapDNCompsMap
- CA 証明書と CRL を公開するためのディレクトリー内の CA のエントリー。
- エンドエンティティー証明書を公開するためのディレクトリーのエンドエンティティー。
- uid は、ディレクトリー内のユーザーのユーザー ID を表します。
- cn は、ディレクトリー内のユーザーの共通名を表します。
- ou は、ディレクトリー内の組織単位を表します。
- o は、ディレクトリー内の組織を表します。
- l は地域 (都市) を表します。
- st は状態を表します。
- c は国を表します。
cn=Jane Doe, ou=Sales, o=Example Corporation, l=Mountain View, st=California, c=US
cn=Jane Doe, ou=Sales, o=Example Corporation, c=US
- サブジェクト名には、dnComps パラメーターで指定されたすべてのコンポーネントを含める必要はありません。この例の l および st など、サーバーは、サブジェクト名の一部ではないコンポーネントを無視します。
- 未指定のコンポーネントは、DN の構築には使用されません。例では、ou コンポーネントが含まれていない場合、サーバーはこの DN をディレクトリー検索のベースとして使用します。
cn=Jane Doe, o=Example Corporation, c=US
C.2.5.1. LdapDNCompsMap の設定パラメーター
- フォーム化された DN が null の場合、サーバーはサブツリーの baseDN の値を使用します。正式な DN とベース DN の両方が null の場合、サーバーはエラーをログに記録します。
- フィルターが null の場合、サーバーは検索に baseDN の値を使用します。フィルターとベース DN の両方が null の場合、サーバーはエラーをログに記録します。
パラメーター | 説明 |
---|---|
baseDN | 公開ディレクトリー内のエントリーの検索を開始する DN を指定します。dnComps フィールドが空の場合、サーバーはベース DN 値を使用してディレクトリーの検索を開始します。 |
dnComps |
公開ディレクトリーのどこで、Certificate Manager が CA またはエンドエンティティーの情報と一致する LDAP エントリーの検索を開始するかを指定します。
たとえば、dnComps が、DN の o 属性および c 属性を使用する場合、サーバーは、ディレクトリーで o=org、c=country エントリーから検索を開始し、org と country を証明書の DN の値に置き換えます。
dnComps フィールドが空の場合、サーバーは、baseDN フィールドを確認し、filterComps パラメーター値により指定されるフィルターに一致するエントリーの DN によって指定されるディレクトリーツリーを検索します。
許容値は、有効な DN コンポーネントまたは属性をコンマで区切って指定します。
|
filterComps |
Certificate Manager が検索結果からエントリーをフィルタリングするために使用するコンポーネントを指定します。サーバーは filterComps 値を使用して、サブツリーの LDAP 検索フィルターを形成します。サーバーは、証明書のサブジェクト名からこれらの属性の値を収集することにより、フィルターを構築します。フィルターを使用して、LDAP ディレクトリー内のエントリーを検索して照合します。
サーバーが証明書から収集した情報と一致するエントリーをディレクトリー内で複数検出した場合、検索は成功し、サーバーはオプションで検証を実行します。たとえば、filterComps が電子メールおよびユーザー ID 属性を使用するように設定されていると (filterComps=e,uid)、サーバーはディレクトリーを検索して、電子メールとユーザー ID の値が証明書から収集された情報と一致するエントリーを検索します。
許容値は、コンマで区切られた証明書 DN 内の有効なディレクトリー属性です。フィルターの属性名は、LDAP ディレクトリー内の属性名ではなく、証明書の属性名である必要があります。たとえば、ほとんどの証明書には、ユーザーの電子メールアドレスの e 属性があります。LDAP は、その属性の mail を呼び出します。
|
C.3. ルールインスタンス
C.3.1. LdapCaCertRule
パラメーター | 値 | 説明 |
---|---|---|
type | cacert | 公開される証明書のタイプを指定します。 |
predicate | パブリッシャーの述語を指定します。 | |
enable | はい | ルールを有効にします。 |
mapper | LdapCaCertMap | ルールで使用するマッパーを指定します。マッパーの詳細は、「LdapCaCertMap」を参照してください。 |
publisher | LdapCaCertPublisher | ルールで使用するパブリッシャーを指定します。パブリッシャーの詳細は、「LdapCaCertPublisher」 を参照してください。 |
C.3.2. LdapXCertRule
パラメーター | 値 | 説明 |
---|---|---|
type | xcert | 公開される証明書のタイプを指定します。 |
predicate | パブリッシャーの述語を指定します。 | |
enable | はい | ルールを有効にします。 |
mapper | LdapCaCertMap | ルールで使用するマッパーを指定します。マッパーの詳細は、「LdapCaCertMap」を参照してください。 |
publisher | LdapCrossCertPairPublisher | ルールで使用するパブリッシャーを指定します。このパブリッシャーのの詳細は、「LdapCertificatePairPublisher」 を参照してください。 |
C.3.3. LdapUserCertRule
パラメーター | 値 | 説明 |
---|---|---|
type | certs | 公開される証明書のタイプを指定します。 |
predicate | パブリッシャーの述語を指定します。 | |
enable | はい | ルールを有効にします。 |
mapper | LdapUserCertMap | ルールで使用するマッパーを指定します。マッパーの詳細は、「LdapSimpleMap」を参照してください。 |
publisher | LdapUserCertPublisher | ルールで使用するパブリッシャーを指定します。パブリッシャーの詳細は、「LdapUserCertPublisher」 を参照してください。 |
C.3.4. LdapCRLRule
パラメーター | 値 | 説明 |
---|---|---|
type | crl | 公開される証明書のタイプを指定します。 |
predicate | パブリッシャーの述語を指定します。 | |
enable | はい | ルールを有効にします。 |
mapper | LdapCrlMap | ルールで使用するマッパーを指定します。マッパーの詳細は、「LdapCrlMap」を参照してください。 |
publisher | LdapCrlPublisher | ルールで使用するパブリッシャーを指定します。パブリッシャーの詳細は、「LdapCrlPublisher」 を参照してください。 |
付録D ACL リファレンス
D.1. ACL 設定ファイルについて
/var/lib/pki/instance_name/conf/subsystem/acl.ldif
ファイルにあります。
resourceACLS
属性として定義されます。これは、保護されているサブシステムの領域を識別する属性と、その後設定されているすべての特定のアクセス制御のリストで識別されます。
resourceACLS: class_name:all rights: allow|deny (rights) type=target description
例D.1 証明書プロファイルの一覧を表示するデフォルト ACL
resourceACLS: certServer.ca.profiles:list:allow (list) group="Certificate Manager Agents":Certificate Manager agents may list profiles
acl.ldif
ファイルと独自に定義された ACL があります。
allow|deny (rights) user|group
resourceACLS
属性値の各領域は、表D.1「ACL 属性値のセクション」 で定義されます。
値 | 説明 |
---|---|
class_name | ACI が適用されるプラグインクラス。 |
すべての操作 | ACI 定義に含まれるすべての操作の一覧。1 つの ACI には複数の操作があり、1 つの resourceACLS 属性に複数の ACI があります。 |
allow|deny | アクションがターゲットユーザーまたはグループに対して許可されているか、ターゲットユーザーまたはグループに対して拒否されているか。 |
(operations) | 許可または拒否されている操作。 |
type=target | これが適用されるユーザーを特定するターゲット。これは一般的にユーザー (user="name" など) またはグループ (group="group" など) です。条件が複数ある場合は、二重パイプ (||) 演算子 (論理 "or") と二重アンパサンド (&&) 演算子 (論理 "and") を使用して条件を設定することができます。たとえば、group="group1" || "group2" となります。 |
説明 | ACL が実行していることの説明。 |
D.2. 共通 ACL
acl.ldif
ファイルで同じ ACL が発生するのが一般的です。これらは、設定ファイルまたは設定がすべてのサブシステムインスタンスによって共通に保持されるという意味で、共有 ACL ではありません。他のすべてのインスタンス設定と同様に、これらの ACL は、インスタンス固有の acl.ldif
ファイルで、他のサブシステムインスタンスとは独立して維持されます。
D.2.1. certServer.acl.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | ACL リソースを表示し、ACL リソース、ACL リストエバリュエーター、および ACL エバリュエータータイプを一覧表示します。 | 許可 |
| |||
modify | ACL エバリュエーターの追加、削除、および更新。 | 許可 | 管理者 |
D.2.2. certServer.admin.certificate
allow (import) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
import | CA 管理者証明書をインポートして、シリアル番号で証明書を取得します。 | 許可 | 全ユーザー |
D.2.3. certServer.auth.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | 認証プラグイン、認証タイプ、設定済みの認証マネージャープラグイン、および認証インスタンスを表示します。認証マネージャープラグインおよび認証マネージャーインスタンスを一覧表示します。 | 許可 |
| |||
modify | 認証プラグインおよび認証インスタンスを追加または削除します。認証インスタンスを変更します。 | 許可 | 管理者 |
D.2.4. certServer.clone.configuration
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | 元のインスタンス設定を表示します。 | 許可 | エンタープライズ管理者 |
modify | 元のインスタンス設定を変更します。 | 許可 | エンタープライズ管理者 |
D.2.5. certServer.general.configuration
allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | 管理用の運用環境、LDAP 設定、SMTP 設定、サーバー統計、暗号化、トークン名、証明書のサブジェクト名、証明書のニックネーム、サーバーによって読み込むすべてのサブシステム、CA 証明書、およびすべての証明書を表示します。 | 許可 |
| |||
modify | LDAP データベース、SMTP、および暗号化の設定を変更します。インポート証明書の発行、証明書のインストール、CA 証明書の信頼と信頼解除、クロスペア証明書のインポート、および証明書の削除。サーバーの再起動および停止操作を実行します。すべてのトークンにログインして、トークンのステータスを確認します。オンデマンドでセルフテストを実行します。証明書情報を取得します。証明書サブジェクト名を処理します。証明書サブジェクト名、証明書キーの長さ、および証明書拡張機能を検証します。 | 許可 | 管理者 |
D.2.6. certServer.log.configuration
allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | ログプラグインの情報、ログプラグイン設定、およびログインスタンス設定を表示します。ログプラグインおよびログインスタンスを一覧表示します (NTpixel を除く)。 | 許可 |
| |||
modify | ログプラグインおよびログインスタンスを追加し、削除します。ログロールオーバーパラメーターやログレベルなど、ログインスタンスを変更します。 | 許可 | 管理者 |
D.2.7. certServer.log.configuration.fileName
allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents";deny (modify) user=anybody
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | ログインスタンスの fileName パラメーターの値を表示します。 | 許可 |
| |||
modify | ログインスタンスの fileName パラメーターの値を表示します。 | 却下 | 全ユーザー |
D.2.8. certServer.log.content.system
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | ログの内容を表示します。すべてのログを一覧表示します。 | 許可 |
|
D.2.9. certServer.log.content.transactions
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | ログの内容を表示します。すべてのログを一覧表示します。 | 許可 |
|
D.2.10. certServer.log.content.signedAudit
allow (read) group="Auditors"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |
---|---|---|---|---|
read | ログの内容を表示します。ログを一覧表示します。 | 許可 |
|
D.2.11. certServer.registry.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | 管理レジストリー、サポートされているポリシー制約、プロファイルプラグインの設定、およびプロファイルプラグインのリストを表示します。 | 許可 |
| |||
modify | 個々のプロファイル実装プラグインを登録します。 | 許可 | 管理者 |
D.3. 証明書マネージャー固有の ACL
D.3.1. certServer.admin.ocsp
allow (modify,read) group="Enterprise OCSP Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
modify | OCSP 設定、OCSP ストア設定、およびデフォルトの OCSP ストアを変更します。 | 許可 | エンタープライズ OCSP 管理者 |
read | OCSP 設定を読み取ります。 | 許可 | エンタープライズ OCSP 管理者 |
D.3.2. certServer.ca.certificate
allow (import,unrevoke,revoke,read) group="Certificate Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
import | シリアル番号で証明書を取得します。 | 許可 | Certificate Manager Agent |
unrevoke | 証明書のステータスを失効から変更します。 | 許可 | Certificate Manager Agent |
revoke | 証明書のステータスを失効に変更します。 | 許可 | Certificate Manager Agent |
read | リクエスト ID に基づいて証明書を取得し、リクエスト ID またはシリアル番号に基づいて証明書の詳細を表示します。 | 許可 | Certificate Manager Agent |
D.3.3. certServer.ca.certificates
allow (revoke,list) group="Certificate Manager Agents"|| group="Registration Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | ||
---|---|---|---|---|---|
revoke | 証明書を取り消すか、または証明書失効リスト要求を承認します。TPS から証明書を取り消します。失効要求に関する追加データのプロンプトを表示します。 | 許可 |
| ||
list | 検索に基づいて証明書を一覧表示します。シリアル番号の範囲に基づいて証明書の範囲の詳細を取得します。 | 許可 |
|
D.3.4. certServer.ca.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | CRL プラグイン情報、一般的な CA 設定、CA コネクター設定、CRL 発行ポイント設定、CRL プロファイル設定、要求通知設定、失効通知設定、キュー内要求通知設定、および CRL 拡張設定を表示します。CRL 拡張設定および CRL 発行ポイント設定を一覧表示します。 | 許可 |
| |||
modify | CRL 発行ポイントを追加し、削除します。一般的な CA 設定、CA コネクター設定、CRL 発行ポイント設定、CRL 設定、要求通知設定、失効通知設定、キュー内要求通知設定、および CRL 拡張設定を変更します。 | 許可 | 管理者 |
D.3.5. certServer.ca.connector
allow (submit) group="Trusted Managers"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
submit | リモート信頼できるマネージャーからのリクエストを送信します。 | 許可 | 信頼できるマネージャー |
D.3.6. certServer.ca.connectorInfo
allow (read) group="Enterprise KRA Administrators";allow (modify) group="Enterprise KRA Administrators" || group="Subsystem Group"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | ||
---|---|---|---|---|---|
read | コネクタープラグイン設定を読み取ります。 | 許可 | エンタープライズ KRA 管理者 | ||
modify | コネクタープラグイン設定を変更します。 | 許可 |
|
D.3.7. certServer.ca.crl
allow (read,update) group="Certificate Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | CRL を表示し、CA CRL 処理に関する詳細情報を取得します。 | 許可 | Certificate Manager Agent |
update | CRL を更新します。 | 許可 | Certificate Manager Agent |
D.3.8. certServer.ca.directory
allow (update) group="Certificate Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
update | CA 証明書、CRL、およびユーザー証明書を LDAP ディレクトリーに公開します。 | 許可 | Certificate Manager Agent |
D.3.9. certServer.ca.group
allow (modify,read) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
modify | インスタンスのユーザーおよびグループエントリーを作成、編集、削除します。属性内でユーザー証明書の追加または変更 | 許可 | 管理者 |
read | インスタンスのユーザーおよびグループエントリーを表示します。 | 許可 | 管理者 |
D.3.10. certServer.ca.ocsp
allow (read) group="Certificate Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | OCSP 使用状況の統計を取得します。 | 許可 | Certificate Manager Agent |
D.3.11. certServer.ca.profile
allow (read,approve) group="Certificate Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | 証明書プロファイルの詳細を表示します。 | 許可 | Certificate Manager Agent |
approve | 証明書プロファイルを承認し、有効にします。 | 許可 | Certificate Manager Agent |
D.3.12. certServer.ca.profiles
allow (list) group="Certificate Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
list | 証明書プロファイルの一覧表示。 | 許可 | Certificate Manager Agent |
D.3.13. certServer.ca.registerUser
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
modify | 新しいエージェントを登録します。 | 許可 | エンタープライズ管理者 |
read | 既存のエージェント情報を読み取ります。 | 許可 | エンタープライズ管理者 |
D.3.14. certServer.ca.request.enrollment
allow (submit) user="anybody";allow (read,execute,assign,unassign) group="Certificate Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | 登録リクエストを表示します。 | 許可 | Certificate Manager Agent |
execute | リクエストの承認状態を変更します。 | 許可 | Certificate Manager Agent |
submit | リクエストを送信します。 | 許可 | Anybody |
assign | Certificate Manager エージェントに要求を割り当てます。 | 許可 | Certificate Manager Agent |
unassign | 要求の割り当てを変更します。 | 許可 | Certificate Manager Agent |
D.3.15. certServer.ca.request.profile
allow (approve,read) group="Certificate Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
approve | 証明書プロファイルベースの証明書要求の承認状態を変更します。 | 許可 | Certificate Manager Agent |
read | 証明書プロファイルベースの証明書要求を表示します。 | 許可 | Certificate Manager Agent |
D.3.16. certServer.ca.requests
allow (list) group="Certificate Manager Agents"|| group="Registration Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | ||
---|---|---|---|---|---|
list | 要求の範囲の詳細を取得し、複雑なフィルターを使用して証明書を検索します。 | 許可 |
|
D.3.17. certServer.ca.systemstatus
allow (read) group="Certificate Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | 統計を表示します。 | 許可 | Certificate Manager Agent |
D.3.18. certServer.ee.certchain
allow (download,read) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
download | CA の証明書チェーンをダウンロードします。 | 許可 | 全ユーザー |
read | CA の証明書チェーンを表示します。 | 許可 | 全ユーザー |
D.3.19. certServer.ee.certificate
allow (renew,revoke,read,import) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
renew | 既存の証明書を更新する要求を送信します。 | 許可 | 全ユーザー |
revoke | ユーザー証明書の失効要求を送信します。 | 許可 | 全ユーザー |
read | 証明書のシリアル番号または要求 ID に基づいて証明書を取得して表示します。 | 許可 | 全ユーザー |
import | シリアル番号に基づいて証明書をインポートします。 | 許可 | 全ユーザー |
D.3.20. certServer.ee.certificates
allow (revoke,list) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
revoke | 取り消しする証明書の一覧を送信します。 | 許可 |
取り消される証明書の対象は、CA に認証するために提示された証明書と一致させる必要があります。
|
list | 指定の基準に一致する証明書を検索します。 | 許可 | 全ユーザー |
D.3.21. certServer.ee.crl
allow (read,add) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | 証明書失効リストを取得および表示します。 | 許可 | 全ユーザー |
add | CRL を OCSP サーバーに追加します。 | 許可 | 全ユーザー |
D.3.22. certServer.ee.profile
allow (submit,read) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
submit | 証明書プロファイルを使用して証明書要求を送信します。 | 許可 | 全ユーザー |
read | 証明書プロファイルの詳細の表示 | 許可 | 全ユーザー |
D.3.23. certServer.ee.profiles
allow (list) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
list | 証明書プロファイルの一覧表示。 | 許可 | 全ユーザー |
D.3.24. certServer.ee.request.ocsp
allow (submit) ipaddress=".*"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
submit | OCSP 要求を送信します。 | 許可 | すべての IP アドレス |
D.3.25. certServer.ee.request.revocation
allow (submit) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
submit | 証明書を取り消す要求を送信します。 | 許可 | 全ユーザー |
D.3.26. certServer.ee.requestStatus
allow (read) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | その要求に対して発行された証明書の要求およびシリアル番号を取得します。 | 許可 | 全ユーザー |
D.3.27. certServer.job.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | 基本的なジョブ設定、ジョブインスタンス設定、ジョブプラグイン設定を表示します。ジョブプラグインおよびジョブインスタンスを一覧表示します。 | 許可 |
| |||
modify | ジョブプラグインおよびジョブインスタンスを追加および削除します。ジョブプラグインとジョブインスタンスを変更します。 | 許可 | 管理者 |
D.3.28. certServer.profile.configuration
allow (read) group="Administrators" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | 証明書プロファイルのデフォルトと制約、入力、出力、入力設定、出力設定、デフォルト設定、ポリシー制約設定、および証明書プロファイルインスタンス設定を表示します。証明書プロファイルプラグインおよび証明書プロファイルインスタンスを一覧表示します。 | 許可 |
| |||
modify | 証明書プロファイルのデフォルトおよび制約、入力、出力、および証明書プロファイルインスタンスの追加、変更、削除を行います。デフォルトのポリシー制約設定を追加および変更します。 | 許可 | 管理者 |
D.3.29. certServer.publisher.configuration
allow (read) group="Administrators" || group="Auditors" || group="Certificate Manager Agents" || group="Registration Manager Agents" || group="Key Recovery Authority Agents" || group="Online Certificate Status Manager Agents";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | LDAP サーバーの宛先情報、パブリッシャープラグイン設定、パブリッシャーインスタンス設定、マッパープラグイン設定、マッパーインスタンス設定、ルールプラグイン設定、およびルールインスタンス設定を表示します。パブリッシャープラグインとインスタンス、ルールプラグインとインスタンス、およびマッパープラグインとインスタンスを一覧表示します。 | 許可 |
| |||
modify | パブリッシャープラグイン、パブリッシャーインスタンス、マッパープラグイン、マッパーインスタンス、ルールプラグイン、およびルールインスタンスを追加および削除します。パブリッシャーインスタンス、マッパーインスタンス、ルールインスタンス、および LDAP サーバーの宛先情報を変更します。 | 許可 | 管理者 |
D.3.30. certServer.securitydomain.domainxml
allow (read) user="anybody";allow (modify) group="Subsystem Group"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | ||
---|---|---|---|---|---|
read | セキュリティードメイン設定を表示します。 | 許可 | Anybody | ||
modify | インスタンス情報を変更し、インスタンスを追加および削除して、セキュリティードメイン設定を変更します。 | 許可 |
|
D.4. キーリカバリー認証局固有の ACL
D.4.1. certServer.job.configuration
allow (read) group="Administrators" || group="Key Recovery Authority Agents" || group="Auditors";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | 基本的なジョブ設定、ジョブインスタンス設定、ジョブプラグイン設定を表示します。ジョブプラグインおよびジョブインスタンスを一覧表示します。 | 許可 |
| |||
modify | ジョブプラグインおよびジョブインスタンスを追加および削除します。ジョブプラグインとジョブインスタンスを変更します。 | 許可 | 管理者 |
D.4.2. certServer.kra.certificate.transport
allow (read) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | KRA インスタンスのトランスポート証明書を表示します。 | 許可 | 全ユーザー |
D.4.3. certServer.kra.configuration
allow (read) group="Administrators" || group="Auditors" || group="Key Recovery Authority Agents" || allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | 必要なリカバリーエージェントの承認の数を確認します。 | 許可 |
| |||
modify | 必要なリカバリーエージェントの承認の数を変更します。 | 許可 | 管理者 |
D.4.4. certServer.kra.connector
allow (submit) group="Trusted Managers"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
submit | 新しい鍵のアーカイブ要求を送信します (TMS 以外)。 | 許可 | 信頼できるマネージャー |
D.4.5. certServer.kra.GenerateKeyPair
allow (execute) group="Key Recovery Authority Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
実行 | サーバー側のキー生成 (TMS のみ) を実行します。 | 許可 | KRA エージェント |
D.4.6. certServer.kra.getTransportCert
allow (download) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
download | KRA トランスポート証明書を取得します。 | 許可 | エンタープライズ管理者 |
D.4.7. certServer.kra.group
allow (modify,read) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |
---|---|---|---|---|
modify | インスタンスのユーザーおよびグループエントリーを作成、編集、削除します。 | 許可 | 管理者 | |
read | インスタンスのユーザーおよびグループエントリーを表示します。 | 許可 |
|
D.4.8. certServer.kra.key
allow (read,recover,download) group="Key Recovery Authority Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | 重要なアーカイブ記録に関する公開情報を表示します。 | 許可 | KRA エージェント |
recover | データベースからキー情報を取得してリカバリー操作を実行します。 | 許可 | KRA エージェント |
download | エージェントサービスページからキー情報をダウンロードします。 | 許可 | KRA エージェント |
D.4.9. certServer.kra.keys
allow (list) group="Key Recovery Authority Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
list | アーカイブされた鍵の範囲を検索し、一覧表示します。 | 許可 | KRA エージェント |
D.4.10. certServer.kra.registerUser
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
modify | 新規ユーザーを登録します。 | 許可 | エンタープライズ管理者 |
read | 既存のユーザー情報を読み込みます。 | 許可 | エンタープライズ管理者 |
D.4.11. certServer.kra.request
allow (read) group="Key Recovery Authority Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | 鍵のアーカイブまたはリカバリー要求を表示します。 | 許可 | KRA エージェント |
D.4.12. certServer.kra.request.status
allow (read) group="Key Recovery Authority Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | エージェントサービスページでキーリカバリー要求のステータスを取得します。 | 許可 | KRA エージェント |
D.4.13. certServer.kra.requests
allow (list) group="Key Recovery Authority Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
list | キーアーカイブおよびリカバリー要求の範囲の詳細を取得します。 | 許可 | KRA エージェント |
D.4.14. certServer.kra.systemstatus
allow (read) group="Key Recovery Authority Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | 統計を表示します。 | 許可 | KRA エージェント |
D.4.15. certServer.kra.TokenKeyRecovery
allow (submit) group="Key Recovery Authority Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
submit | トークンリカバリーのキーリカバリー要求を送信または開始します。 | 許可 | KRA エージェント |
D.5. オンライン証明書ステータスマネージャー固有の ACL
D.5.1. certServer.ee.crl
allow (read) user="anybody"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | 証明書失効リストを取得および表示します。 | 許可 | 全ユーザー |
D.5.2. certServer.ee.request.ocsp
allow (submit) ipaddress=".*"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
submit | OCSP 要求を送信します。 | 許可 | すべての IP アドレス |
D.5.3. certServer.ocsp.ca
allow (add) group="Online Certificate Status Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
Add | 新しい CA に対する OCSP 要求に応答するように OCSP レスポンダーに指示します。 | 許可 | OCSP Manager エージェント |
D.5.4. certServer.ocsp.cas
allow (list) group="Online Certificate Status Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
list | OCSP レスポンダーに CRL を公開する Certificate Manager の一覧を表示します。 | 許可 | エージェント |
D.5.5. certServer.ocsp.certificate
allow (validate) group="Online Certificate Status Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
validate | 指定の証明書の状態を検証します。 | 許可 | OCSP エージェント |
D.5.6. certServer.ocsp.configuration
allow (read) group="Administrators" || group="Online Certificate Status Manager Agents" || group="Auditors";allow (modify) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | |||
---|---|---|---|---|---|---|
read | OCSP プラグインの情報、OCSP 設定、および OCSP ストア設定を表示します。OCSP ストアの設定を一覧表示します。 | 許可 |
| |||
modify | OCSP 設定、OCSP ストア設定、およびデフォルトの OCSP ストアを変更します。 | 許可 | 管理者 |
D.5.7. certServer.ocsp.crl
allow (add) group="Online Certificate Status Manager Agents" || group="Trusted Managers"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ | ||
---|---|---|---|---|---|
add | 新しい CRL を、OCSP レスポンダーが管理するものに追加します。 | 許可 |
|
D.5.8. certServer.ocsp.group
allow (modify,read) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
modify | インスタンスのユーザーおよびグループエントリーを作成、編集、削除します。 | 許可 | 管理者 |
read | インスタンスのユーザーおよびグループエントリーを表示します。 | 許可 | 管理者 |
D.5.9. certServer.ocsp.info
allow (read) group="Online Certificate Status Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
read | OCSP レスポンダー情報を表示します。 | 許可 | OCSP エージェント |
D.6. トークンキーサービス固有の ACL
D.6.1. certServer.tks.encrypteddata
allow(execute) group="Token Key Service Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
実行 | TKS に保存されている暗号化されたデータ。 | 許可 | TKS エージェント |
D.6.2. certServer.tks.group
allow (modify,read) group="Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
modify | インスタンスのユーザーおよびグループエントリーを作成、編集、削除します。 | 許可 | 管理者 |
read | インスタンスのユーザーおよびグループエントリーを表示します。 | 許可 | 管理者 |
D.6.3. certServer.tks.importTransportCert
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
modify | トランスポート証明書を更新します。 | 許可 | エンタープライズ管理者 |
read | トランスポート証明書をインポートします。 | 許可 | エンタープライズ管理者 |
D.6.4. certServer.tks.keysetdata
allow (execute) group="Token Key Service Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
実行 | コンマ区切りのキーセットデータを作成します。 | 許可 | TKS エージェント |
D.6.5. certServer.tks.registerUser
allow (modify,read) group="Enterprise CA Administrators" || group="Enterprise KRA Administrators" || group="Enterprise OCSP Administrators" || group="Enterprise TKS Administrators" || group="Enterprise TPS Administrators"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
modify | 新しいエージェントを登録します。 | 許可 | エンタープライズ管理者 |
read | 既存のエージェント情報を読み取ります。 | 許可 | エンタープライズ管理者 |
D.6.6. certServer.tks.sessionkey
allow (execute) group="Token Key Service Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
実行 | TKS が生成するセッションキーを作成します。 | 許可 | TKS エージェント |
D.6.7. certServer.tks.randomdata
allow (execute) group="Token Key Service Manager Agents"
操作 | 説明 | アクセスの許可または拒否 | 対象のユーザーまたはグループ |
---|---|---|---|
実行 | ランダムなデータを生成します。 | 許可 | TKS エージェント |
付録E 監査イベント
- スレッドの Java 識別子。以下に例を示します。
0.localhost-startStop-1
- イベントが発生したタイムスタンプ。以下に例を示します。
[21/Jan/2019:17:53:00 IST]
- ログソース (14 は SIGNED_AUDIT)。
[14]
- 現在のログレベル (6 はセキュリティー関連のイベント)。『Red Hat Certificate System 9 計画、インストール、およびデプロイメントのガイド』の『ログレベル (メッセージカテゴリー)』セクションを参照してください。以下に例を示します。
[6]
- ログイベントに関する情報 (ログイベント固有です。特定のログイベントの各フィールドに関する情報は 「監査イベントの説明」 を参照してください。以下に例を示します。
[AuditEvent=AUDIT_LOG_STARTUP][SubjectID=$System$][Outcome=Success] audit function startup
E.1. 監査イベントの説明
####################### SIGNED AUDIT EVENTS ############################# # Common fields: # - Outcome: "Success" or "Failure" # - SubjectID: The UID of the user responsible for the operation # "$System$" or "SYSTEM" if system-initiated operation (e.g. log signing). # ######################################################################### # Required Audit Events # # Event: ACCESS_SESSION_ESTABLISH with [Outcome=Failure] # Description: This event is used when access session failed to establish. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientIP: Client IP address. # - ServerIP: Server IP address. # - SubjectID: Client certificate subject DN. # - Outcome: Failure # - Info: Failure reason. # LOGGING_SIGNED_AUDIT_ACCESS_SESSION_ESTABLISH_FAILURE=\ <type=ACCESS_SESSION_ESTABLISH>:[AuditEvent=ACCESS_SESSION_ESTABLISH]{0} access session establish failure # # Event: ACCESS_SESSION_ESTABLISH with [Outcome=Success] # Description: This event is used when access session was established successfully. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientIP: Client IP address. # - ServerIP: Server IP address. # - SubjectID: Client certificate subject DN. # - Outcome: Success # LOGGING_SIGNED_AUDIT_ACCESS_SESSION_ESTABLISH_SUCCESS=\ <type=ACCESS_SESSION_ESTABLISH>:[AuditEvent=ACCESS_SESSION_ESTABLISH]{0} access session establish success # # Event: ACCESS_SESSION_TERMINATED # Description: This event is used when access session was terminated. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientIP: Client IP address. # - ServerIP: Server IP address. # - SubjectID: Client certificate subject DN. # - Info: The TLS Alert received from NSS # - Outcome: Success # - Info: The TLS Alert received from NSS # LOGGING_SIGNED_AUDIT_ACCESS_SESSION_TERMINATED=\ <type=ACCESS_SESSION_TERMINATED>:[AuditEvent=ACCESS_SESSION_TERMINATED]{0} access session terminated # # Event: AUDIT_LOG_SIGNING # Description: This event is used when a signature on the audit log is generated (same as "flush" time). # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: Predefined to be "$System$" because this operation # associates with no user. # - Outcome: Success # - sig: The base-64 encoded signature of the buffer just flushed. # LOGGING_SIGNED_AUDIT_AUDIT_LOG_SIGNING_3=[AuditEvent=AUDIT_LOG_SIGNING][SubjectID={0}][Outcome={1}] signature of audit buffer just flushed: sig: {2} # # Event: AUDIT_LOG_STARTUP # Description: This event is used at audit function startup. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: # LOGGING_SIGNED_AUDIT_AUDIT_LOG_STARTUP_2=<type=AUDIT_LOG_STARTUP>:[AuditEvent=AUDIT_LOG_STARTUP][SubjectID={0}][Outcome={1}] audit function startup # # Event: AUTH with [Outcome=Failure] # Description: This event is used when authentication fails. # In case of TLS-client auth, only webserver env can pick up the TLS violation. # CS authMgr can pick up certificate mismatch, so this event is used. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: # - Outcome: Failure # (obviously, if authentication failed, you won't have a valid SubjectID, so # in this case, SubjectID should be $Unidentified$) # - AuthMgr: The authentication manager instance name that did # this authentication. # - AttemptedCred: The credential attempted and failed. # LOGGING_SIGNED_AUDIT_AUTH_FAIL=<type=AUTH>:[AuditEvent=AUTH]{0} authentication failure # # Event: AUTH with [Outcome=Success] # Description: This event is used when authentication succeeded. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of user who has been authenticated # - Outcome: Success # - AuthMgr: The authentication manager instance name that did # this authentication. # LOGGING_SIGNED_AUDIT_AUTH_SUCCESS=<type=AUTH>:[AuditEvent=AUTH]{0} authentication success # # Event: AUTHZ with [Outcome=Failure] # Description: This event is used when authorization has failed. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of user who has failed to be authorized for an action # - Outcome: Failure # - aclResource: The ACL resource ID as defined in ACL resource list. # - Op: One of the operations as defined with the ACL statement # e.g. "read" for an ACL statement containing "(read,write)". # - Info: # LOGGING_SIGNED_AUDIT_AUTHZ_FAIL=<type=AUTHZ>:[AuditEvent=AUTHZ]{0} authorization failure # # Event: AUTHZ with [Outcome=Success] # Description: This event is used when authorization is successful. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of user who has been authorized for an action # - Outcome: Success # - aclResource: The ACL resource ID as defined in ACL resource list. # - Op: One of the operations as defined with the ACL statement # e.g. "read" for an ACL statement containing "(read,write)". # LOGGING_SIGNED_AUDIT_AUTHZ_SUCCESS=<type=AUTHZ>:[AuditEvent=AUTHZ]{0} authorization success # # Event: CERT_PROFILE_APPROVAL # Description: This event is used when an agent approves/disapproves a certificate profile set by the # administrator for automatic approval. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id of the CA agent who approved the certificate enrollment profile # - Outcome: # - ProfileID: One of the profiles defined by the administrator # and to be approved by an agent. # - Op: "approve" or "disapprove". # LOGGING_SIGNED_AUDIT_CERT_PROFILE_APPROVAL_4=<type=CERT_PROFILE_APPROVAL>:[AuditEvent=CERT_PROFILE_APPROVAL][SubjectID={0}][Outcome={1}][ProfileID={2}][Op={3}] certificate profile approval # # Event: CERT_REQUEST_PROCESSED # Description: This event is used when certificate request has just been through the approval process. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of the agent who approves, rejects, or cancels # the certificate request. # - Outcome: # - ReqID: The request ID. # - InfoName: "certificate" (in case of approval), "rejectReason" # (in case of reject), or "cancelReason" (in case of cancel) # - InfoValue: The certificate (in case of success), a reject reason in # text, or a cancel reason in text. # - CertSerialNum: # LOGGING_SIGNED_AUDIT_CERT_REQUEST_PROCESSED=<type=CERT_REQUEST_PROCESSED>:[AuditEvent=CERT_REQUEST_PROCESSED]{0} certificate request processed # # Event: CERT_SIGNING_INFO # Description: This event indicates which key is used to sign certificates. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: Success # - SKI: Subject Key Identifier of the certificate signing certificate # - AuthorityID: (applicable only to lightweight CA) # LOGGING_SIGNED_AUDIT_CERT_SIGNING_INFO=<type=CERT_SIGNING_INFO>:[AuditEvent=CERT_SIGNING_INFO]{0} certificate signing info # # Event: CERT_STATUS_CHANGE_REQUEST # Description: This event is used when a certificate status change request (e.g. revocation) # is made (before approval process). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id of uer who performed the action # - Outcome: # - ReqID: The request ID. # - CertSerialNum: The serial number (in hex) of the certificate to be revoked. # - RequestType: "revoke", "on-hold", "off-hold" # LOGGING_SIGNED_AUDIT_CERT_STATUS_CHANGE_REQUEST=<type=CERT_STATUS_CHANGE_REQUEST>:[AuditEvent=CERT_STATUS_CHANGE_REQUEST]{0} certificate revocation/unrevocation request made # # Event: CERT_STATUS_CHANGE_REQUEST_PROCESSED # Description: This event is used when certificate status is changed (revoked, expired, on-hold, # off-hold). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of the agent that processed the request. # - Outcome: # - ReqID: The request ID. # - RequestType: "revoke", "on-hold", "off-hold" # - Approval: "complete", "rejected", or "canceled" # (note that "complete" means "approved") # - CertSerialNum: The serial number (in hex). # - RevokeReasonNum: One of the following number: # reason number reason # -------------------------------------- # 0 Unspecified # 1 Key compromised # 2 CA key compromised (should not be used) # 3 Affiliation changed # 4 Certificate superceded # 5 Cessation of operation # 6 Certificate is on-hold # - Info: # LOGGING_SIGNED_AUDIT_CERT_STATUS_CHANGE_REQUEST_PROCESSED=<type=CERT_STATUS_CHANGE_REQUEST_PROCESSED>:[AuditEvent=CERT_STATUS_CHANGE_REQUEST_PROCESSED]{0} certificate status change request processed # # Event: CLIENT_ACCESS_SESSION_ESTABLISH with [Outcome=Failure] # Description: This event is when access session failed to establish when Certificate System acts as client. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientHost: Client hostname. # - ServerHost: Server hostname. # - ServerPort: Server port. # - SubjectID: SYSTEM # - Outcome: Failure # - Info: # LOGGING_SIGNED_AUDIT_CLIENT_ACCESS_SESSION_ESTABLISH_FAILURE=\ <type=CLIENT_ACCESS_SESSION_ESTABLISH>:[AuditEvent=CLIENT_ACCESS_SESSION_ESTABLISH]{0} access session failed to establish when Certificate System acts as client # # Event: CLIENT_ACCESS_SESSION_ESTABLISH with [Outcome=Success] # Description: This event is used when access session was established successfully when # Certificate System acts as client. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientHost: Client hostname. # - ServerHost: Server hostname. # - ServerPort: Server port. # - SubjectID: SYSTEM # - Outcome: Success # LOGGING_SIGNED_AUDIT_CLIENT_ACCESS_SESSION_ESTABLISH_SUCCESS=\ <type=CLIENT_ACCESS_SESSION_ESTABLISH>:[AuditEvent=CLIENT_ACCESS_SESSION_ESTABLISH]{0} access session establish successfully when Certificate System acts as client # # Event: CLIENT_ACCESS_SESSION_TERMINATED # Description: This event is used when access session was terminated when Certificate System acts as client. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - ClientHost: Client hostname. # - ServerHost: Server hostname. # - ServerPort: Server port. # - SubjectID: SYSTEM # - Outcome: Success # - Info: The TLS Alert received from NSS # LOGGING_SIGNED_AUDIT_CLIENT_ACCESS_SESSION_TERMINATED=\ <type=CLIENT_ACCESS_SESSION_TERMINATED>:[AuditEvent=CLIENT_ACCESS_SESSION_TERMINATED]{0} access session terminated when Certificate System acts as client # # Event: CMC_REQUEST_RECEIVED # Description: This event is used when a CMC request is received. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of user that triggered this event. # If CMC requests is signed by an agent, SubjectID should # be that of the agent. # In case of an unsigned request, it would bear $Unidentified$. # - Outcome: # - CMCRequest: Base64 encoding of the CMC request received # LOGGING_SIGNED_AUDIT_CMC_REQUEST_RECEIVED_3=<type=CMC_REQUEST_RECEIVED>:[AuditEvent=CMC_REQUEST_RECEIVED][SubjectID={0}][Outcome={1}][CMCRequest={2}] CMC request received # # Event: CMC_RESPONSE_SENT # Description: This event is used when a CMC response is sent. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of user that triggered this event. # - Outcome: # - CMCResponse: Base64 encoding of the CMC response sent # LOGGING_SIGNED_AUDIT_CMC_RESPONSE_SENT_3=<type=CMC_RESPONSE_SENT>:[AuditEvent=CMC_RESPONSE_SENT][SubjectID={0}][Outcome={1}][CMCResponse={2}] CMC response sent # # Event: CMC_SIGNED_REQUEST_SIG_VERIFY # Description: This event is used when agent signed CMC certificate requests or revocation requests # are submitted and signature is verified. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: the user who signed the CMC request (success case) # - Outcome: # - ReqType: The request type (enrollment, or revocation). # - CertSubject: The certificate subject name of the certificate request. # - SignerInfo: A unique String representation for the signer. # LOGGING_SIGNED_AUDIT_CMC_SIGNED_REQUEST_SIG_VERIFY=<type=CMC_SIGNED_REQUEST_SIG_VERIFY>:[AuditEvent=CMC_SIGNED_REQUEST_SIG_VERIFY]{0} agent signed CMC request signature verification # # Event: CMC_USER_SIGNED_REQUEST_SIG_VERIFY # Description: This event is used when CMC (user-signed or self-signed) certificate requests or revocation requests # are submitted and signature is verified. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: the user who signed the CMC request (success case) # - Outcome: # - ReqType: The request type (enrollment, or revocation). # - CertSubject: The certificate subject name of the certificate request. # - CMCSignerInfo: A unique String representation for the CMC request signer. # - info: # LOGGING_SIGNED_AUDIT_CMC_USER_SIGNED_REQUEST_SIG_VERIFY_FAILURE=<type=CMC_USER_SIGNED_REQUEST_SIG_VERIFY>:[AuditEvent=CMC_USER_SIGNED_REQUEST_SIG_VERIFY]{0} User signed CMC request signature verification failure LOGGING_SIGNED_AUDIT_CMC_USER_SIGNED_REQUEST_SIG_VERIFY_SUCCESS=<type=CMC_USER_SIGNED_REQUEST_SIG_VERIFY>:[AuditEvent=CMC_USER_SIGNED_REQUEST_SIG_VERIFY]{0} User signed CMC request signature verification success # # Event: CONFIG_ACL # Description: This event is used when configuring ACL information. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_ACL_3=<type=CONFIG_ACL>:[AuditEvent=CONFIG_ACL][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] ACL configuration parameter(s) change # # Event: CONFIG_AUTH # Description: This event is used when configuring authentication. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # --- Password MUST NOT be logged --- # LOGGING_SIGNED_AUDIT_CONFIG_AUTH_3=<type=CONFIG_AUTH>:[AuditEvent=CONFIG_AUTH][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] authentication configuration parameter(s) change # # Event: CONFIG_CERT_PROFILE # Description: This event is used when configuring certificate profile # (general settings and certificate profile). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_CERT_PROFILE_3=<type=CONFIG_CERT_PROFILE>:[AuditEvent=CONFIG_CERT_PROFILE][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] certificate profile configuration parameter(s) change # # Event: CONFIG_CRL_PROFILE # Description: This event is used when configuring CRL profile # (extensions, frequency, CRL format). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_CRL_PROFILE_3=<type=CONFIG_CRL_PROFILE>:[AuditEvent=CONFIG_CRL_PROFILE][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] CRL profile configuration parameter(s) change # # Event: CONFIG_DRM # Description: This event is used when configuring KRA. # This includes key recovery scheme, change of any secret component. # Applicable subsystems: KRA # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # --- secret component (password) MUST NOT be logged --- # LOGGING_SIGNED_AUDIT_CONFIG_DRM_3=<type=CONFIG_DRM>:[AuditEvent=CONFIG_DRM][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] DRM configuration parameter(s) change # # Event: CONFIG_OCSP_PROFILE # Description: This event is used when configuring OCSP profile # (everything under Online Certificate Status Manager). # Applicable subsystems: OCSP # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_OCSP_PROFILE_3=<type=CONFIG_OCSP_PROFILE>:[AuditEvent=CONFIG_OCSP_PROFILE][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] OCSP profile configuration parameter(s) change # # Event: CONFIG_ROLE # Description: This event is used when configuring role information. # This includes anything under users/groups, add/remove/edit a role, etc. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_ROLE=<type=CONFIG_ROLE>:[AuditEvent=CONFIG_ROLE]{0} role configuration parameter(s) change # # Event: CONFIG_SERIAL_NUMBER # Description: This event is used when configuring serial number ranges # (when requesting a serial number range when cloning, for example). # Applicable subsystems: CA, KRA # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_SERIAL_NUMBER_1=<type=CONFIG_SERIAL_NUMBER>:[AuditEvent=CONFIG_SERIAL_NUMBER][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] serial number range update # # Event: CONFIG_SIGNED_AUDIT # Description: This event is used when configuring signedAudit. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: id of administrator who performed the action # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_SIGNED_AUDIT=<type=CONFIG_SIGNED_AUDIT>:[AuditEvent=CONFIG_SIGNED_AUDIT]{0} signed audit configuration parameter(s) change # # Event: CONFIG_TRUSTED_PUBLIC_KEY # Description: This event is used when: # 1. "Manage Certificate" is used to edit the trustness of certificates # and deletion of certificates # 2. "Certificate Setup Wizard" is used to import CA certificates into the # certificate database (Although CrossCertificatePairs are stored # within internaldb, audit them as well) # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: ID of administrator who performed this configuration # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_CONFIG_TRUSTED_PUBLIC_KEY=<type=CONFIG_TRUSTED_PUBLIC_KEY>:[AuditEvent=CONFIG_TRUSTED_PUBLIC_KEY]{0} certificate database configuration # # Event: CRL_SIGNING_INFO # Description: This event indicates which key is used to sign CRLs. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: # - SKI: Subject Key Identifier of the CRL signing certificate # LOGGING_SIGNED_AUDIT_CRL_SIGNING_INFO=<type=CRL_SIGNING_INFO>:[AuditEvent=CRL_SIGNING_INFO]{0} CRL signing info # # Event: DELTA_CRL_GENERATION # Description: This event is used when delta CRL generation is complete. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: $Unidentified$ # - Outcome: "Success" when delta CRL is generated successfully, "Failure" otherwise. # - CRLnum: The CRL number that identifies the CRL # - Info: # - FailureReason: # LOGGING_SIGNED_AUDIT_DELTA_CRL_GENERATION=<type=DELTA_CRL_GENERATION>:[AuditEvent=DELTA_CRL_GENERATION]{0} Delta CRL generation # # Event: FULL_CRL_GENERATION # Description: This event is used when full CRL generation is complete. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: "Success" when full CRL is generated successfully, "Failure" otherwise. # - CRLnum: The CRL number that identifies the CRL # - Info: # - FailureReason: # LOGGING_SIGNED_AUDIT_FULL_CRL_GENERATION=<type=FULL_CRL_GENERATION>:[AuditEvent=FULL_CRL_GENERATION]{0} Full CRL generation # # Event: PROFILE_CERT_REQUEST # Description: This event is used when a profile certificate request is made (before approval process). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: The UID of user that triggered this event. # If CMC enrollment requests signed by an agent, SubjectID should # be that of the agent. # - Outcome: # - CertSubject: The certificate subject name of the certificate request. # - ReqID: The certificate request ID. # - ProfileID: One of the certificate profiles defined by the # administrator. # LOGGING_SIGNED_AUDIT_PROFILE_CERT_REQUEST_5=<type=PROFILE_CERT_REQUEST>:[AuditEvent=PROFILE_CERT_REQUEST][SubjectID={0}][Outcome={1}][ReqID={2}][ProfileID={3}][CertSubject={4}] certificate request made with certificate profiles # # Event: PROOF_OF_POSSESSION # Description: This event is used for proof of possession during certificate enrollment processing. # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: id that represents the authenticated user # - Outcome: # - Info: some information on when/how it occurred # LOGGING_SIGNED_AUDIT_PROOF_OF_POSSESSION_3=<type=PROOF_OF_POSSESSION>:[AuditEvent=PROOF_OF_POSSESSION][SubjectID={0}][Outcome={1}][Info={2}] proof of possession # # Event: OCSP_ADD_CA_REQUEST_PROCESSED # Description: This event is used when an add CA request to the OCSP Responder is processed. # Applicable subsystems: OCSP # Enabled by default: Yes # Fields: # - SubjectID: OCSP administrator user id # - Outcome: "Success" when CA is added successfully, "Failure" otherwise. # - CASubjectDN: The subject DN of the leaf CA cert in the chain. # LOGGING_SIGNED_AUDIT_OCSP_ADD_CA_REQUEST_PROCESSED=<type=OCSP_ADD_CA_REQUEST_PROCESSED>:[AuditEvent=OCSP_ADD_CA_REQUEST_PROCESSED]{0} Add CA for OCSP Responder # # Event: OCSP_GENERATION # Description: This event is used when an OCSP response generated is complete. # Applicable subsystems: CA, OCSP # Enabled by default: Yes # Fields: # - SubjectID: $NonRoleUser$ # - Outcome: "Success" when OCSP response is generated successfully, "Failure" otherwise. # - FailureReason: # LOGGING_SIGNED_AUDIT_OCSP_GENERATION=<type=OCSP_GENERATION>:[AuditEvent=OCSP_GENERATION]{0} OCSP response generation # # Event: OCSP_REMOVE_CA_REQUEST_PROCESSED with [Outcome=Failure] # Description: This event is used when a remove CA request to the OCSP Responder is processed and failed. # Applicable subsystems: OCSP # Enabled by default: Yes # Fields: # - SubjectID: OCSP administrator user id # - Outcome: Failure # - CASubjectDN: The subject DN of the leaf CA certificate in the chain. # LOGGING_SIGNED_AUDIT_OCSP_REMOVE_CA_REQUEST_PROCESSED_FAILURE=<type=OCSP_REMOVE_CA_REQUEST_PROCESSED>:[AuditEvent=OCSP_REMOVE_CA_REQUEST_PROCESSED]{0} Remove CA for OCSP Responder has failed # # Event: OCSP_REMOVE_CA_REQUEST_PROCESSED with [Outcome=Success] # Description: This event is used when a remove CA request to the OCSP Responder is processed successfully. # Applicable subsystems: OCSP # Enabled by default: Yes # Fields: # - SubjectID: OCSP administrator user id # - Outcome: "Success" when CA is removed successfully, "Failure" otherwise. # - CASubjectDN: The subject DN of the leaf CA certificate in the chain. # LOGGING_SIGNED_AUDIT_OCSP_REMOVE_CA_REQUEST_PROCESSED_SUCCESS=<type=OCSP_REMOVE_CA_REQUEST_PROCESSED>:[AuditEvent=OCSP_REMOVE_CA_REQUEST_PROCESSED]{0} Remove CA for OCSP Responder is successful # # Event: OCSP_SIGNING_INFO # Description: This event indicates which key is used to sign OCSP responses. # Applicable subsystems: CA, OCSP # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: # - SKI: Subject Key Identifier of the OCSP signing certificate # - AuthorityID: (applicable only to lightweight CA) # LOGGING_SIGNED_AUDIT_OCSP_SIGNING_INFO=<type=OCSP_SIGNING_INFO>:[AuditEvent=OCSP_SIGNING_INFO]{0} OCSP signing info # # Event: ROLE_ASSUME # Description: This event is used when a user assumes a role. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: # - Outcome: # - Role: One of the valid roles: # "Administrators", "Certificate Manager Agents", or "Auditors". # Note that customized role names can be used once configured. # LOGGING_SIGNED_AUDIT_ROLE_ASSUME=<type=ROLE_ASSUME>:[AuditEvent=ROLE_ASSUME]{0} assume privileged role # # Event: SECURITY_DOMAIN_UPDATE # Description: This event is used when updating contents of security domain # (add/remove a subsystem). # Applicable subsystems: CA # Enabled by default: Yes # Fields: # - SubjectID: CA administrator user ID # - Outcome: # - ParamNameValPairs: A name-value pair # (where name and value are separated by the delimiter ;;) # separated by + (if more than one name-value pair) of config params changed. # LOGGING_SIGNED_AUDIT_SECURITY_DOMAIN_UPDATE_1=<type=SECURITY_DOMAIN_UPDATE>:[AuditEvent=SECURITY_DOMAIN_UPDATE][SubjectID={0}][Outcome={1}][ParamNameValPairs={2}] security domain update # # Event: SELFTESTS_EXECUTION # Description: This event is used when self tests are run. # Applicable subsystems: CA, KRA, OCSP, TKS, TPS # Enabled by default: Yes # Fields: # - SubjectID: $System$ # - Outcome: # LOGGING_SIGNED_AUDIT_SELFTESTS_EXECUTION_2=<type=SELFTESTS_EXECUTION>:[AuditEvent=SELFTESTS_EXECUTION][SubjectID={0}][Outcome={1}] self tests execution (see selftests.log for details)
用語集
A
- agent (エージェント)
- Certificate System マネージャーで エージェントサービス (agent services) の管理を許可されたグループに属するユーザー。Certificate Manager エージェント、キーリカバリー認証局エージェント (Key Recovery Authority agent)も参照してください。
- APDU
- アプリケーションプロトコルデータユニット。スマートカードとスマートカードリーダーとの間の通信に使用される通信ユニット (バイトに類似)。
- アクセス制御 (access control)
- 特定ユーザーが実行できるものを制御するプロセス。たとえば、サーバーへのアクセス制御は通常、パスワードまたは証明書によって確立された ID と、そのエンティティーが実行できることに関するルールに基づいています。アクセス制御リスト (ACL) も参照してください。
- アクセス制御リスト (ACL)
- サーバーが特定のリソースへのアクセス要求を受け取ったときに評価されるアクセスルールの階層を定義するアクセス制御エントリーのコレクション。アクセス制御手順 (access control instructions, ACI) を参照してください。
- アクセス制御手順 (access control instructions, ACI)
- アクセスを要求するサブジェクトを識別する方法、または特定のサブジェクトに対して許可または拒否される権限を指定するアクセスルール。アクセス制御リスト (ACL) を参照してください。
- エージェントサービス (agent services)
- 1.エージェントに必要な特権が割り当てられた Certificate System サブシステムが提供する HTML ページを通じて、Certificate System agent (エージェント) が管理できるサービス。2.このようなサービスを管理するための HTML ページ。
- エージェント承認登録の設定 (agent-approved enrollment)
- 証明書の発行前に、エージェントによる要求を承認するのに必要な登録。
- 属性値アサーション (attribute value assertion, AVA)
- attribute = value の形式のアサーションで、attribute は o (組織) または uid (ユーザー ID) などのタグ、value は Red Hat, Inc.やログイン名などの値です。AVA は、証明書の サブジェクト名 (subject name) と呼ばれる、証明書の賢明を識別する 識別名 (distinguished name, DN) を形成するために使用されます。
- 監査ログ (autdit log)
- さまざまなシステムイベントを記録するログこのログは署名して、改ざんされなかった証明を提供でき、auditor ユーザーのみが読み取りできます。
- 監査者 (auditor)
- 署名付き監査ログを表示できる特権ユーザー。
- 管理者 (administrator)
- 1 つ以上の Certificate System マネージャーをインストールおよび設定し、それらの特権ユーザーまたはエージェントをセットアップする人。agent (エージェント) も併せて参照してください。
- 自動登録 (automated enrollment)
- 人の介入なしに、エンドエンティティー登録の自動認証を可能にする Certificate System サブシステムを設定する方法。この形式の認証では、認証モジュールの処理を正常に完了した証明書要求が、プロファイル処理と証明書の発行に対して自動的に承認されます。
- 認可 (authorization)
- サーバーが制御するリソースにアクセスするパーミッション。承認は通常、リソースに関連付けられた ACL がサーバーによって評価された後に行われます。アクセス制御リスト (ACL) を参照してください。
- 認証 (authentication)
- 自信を持って識別すること。コンピューター化された送信の当事者が偽者ではないことを保証すること。認証には通常、パスワード、証明書、PIN、またはその他の情報を使用して、コンピューターネットワーク上で ID を検証することが含まれます。パスワードベースの認証 (password-based authentication)、証明書ベースの認証 (certificate-based authentication)、クライアント認証 (client authentication)、サーバー認証 (server authentication) も参照してください。
- 認証モジュール (authentication module)
- ルールのセット (として実装されますJava™クラス) エンドエンティティー、エージェント、管理者、または Certificate System サブシステムと対話する必要があるその他のエンティティーを認証するため。通常のエンドユーザー登録の場合は、ユーザーが登録フォームで要求された情報を入力した後、登録サーブレットはそのフォームに関連付けられた認証モジュールを使用して情報を検証し、ユーザーの ID を認証します。サーブレット (servlet) を参照してください。
- 高度暗号化標準 (Advanced Encryption Standard, AES)
- Advanced Encryption Standard (AES) は、その前身の Data Encryption Standard (DES) と同様に、FIPS 承認の対称鍵暗号化標準です。AES は 2002 年に米国政府によって採用されました。AES-128、AES-192、および AES-256 の 3 つのブロック暗号を定義します。NIST (National Institute of Standards and Technology) は、米国で AES 標準を定義しています。FIPS PUB 197。詳細は、http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf を参照してください。
B
- バインド DN (bind DN)
- Red Hat Directory Server への認証にパスワードとともに使用される識別名 (DN) の形式のユーザー ID。
C
- CA サーバーキー (CA server key)
- CA サービスを提供するサーバーの SSL サーバーキー。
- CA 署名鍵 (CA signing key)
- CA 証明書の公開鍵に対応する秘密鍵。CA は、その署名キーを使用して証明書および CRL に署名します。
- CA 証明書 (CA certificate)
- CA 階層 (CA hierarchy)
- ルート CA が下位 CA に証明書を発行する権限を委任する CA の階層。下位 CA は、発行ステータスを他の CA に委譲して階層を拡張することもできます。認証局 (certificate authority, CA)、subordinate CA、root CA も参照してください。
- Certificate Manager
- 認証局として機能する独立した Certificate System サブシステム。Certificate Manager インスタンスは、証明書を発行、更新、および取り消します。証明書は、CRL とともに LDAP ディレクトリーに公開できます。エンドエンティティーからのリクエストを受け入れます。認証局 (certificate authority, CA) を参照してください。
- Certificate Manager エージェント
- Certificate Manager のエージェントサービスの管理が許可されているグループに所属するユーザーです。これらのサービスには、証明書要求にアクセスして変更 (承認および拒否) し、証明書を発行する機能が含まれています。
- Certificate Request Message Format (CRMF)
- X.509 証明書の管理に関連するメッセージに使用される形式。この形式は CMMF のサブセットです。証明書管理メッセージ形式 (Certificate Management Message Formats, CMMF) も参照してください。詳細は、https://tools.ietf.org/html/rfc2511 を参照してください。
- Certificate System
- Certificate System コンソール
- 1 つの Certificate System インスタンスで開くことができるコンソール。Certificate System コンソールを使用すると、Certificate System 管理者は、対応する Certificate System インスタンスの設定設定を制御できます。
- Certificate System サブシステム
- 5 つの Certificate System マネージャーの 1 つ: Certificate Manager、Online Certificate Status Manager、キーリカバリー認証局、Token Key Service、または Token Processing System。
- CMC
- 暗号化メッセージ構文 (CMC) を介した証明書管理メッセージ を参照してください。
- CMC 登録 (CMC Enrollment)
- 署名された登録または署名された失効要求のいずれかを、エージェントの署名証明書を使用して Certificate Manager に送信できるようにする機能。これらの要求は Certificate Manager によって自動的に処理されます。
- CMMF
- CRL
- 証明書失効リスト (certificate revocation list, CRL) を参照してください。
- CRMF
- Certificate Request Message Format (CRMF) を参照してください。
- CSP
- クライアント SSL 証明書 (client SSL certificate)
- SSL プロトコルを使用してサーバーにクライアントを識別するために使用する証明書。セキュアソケットレイヤー (Secure Sockets Layer, SSL) を参照してください。
- クライアント認証 (client authentication)
- 名前とパスワード、または証明書とデジタル署名されたデータなどを使用して、サーバーに対してクライアントを識別するプロセス。証明書ベースの認証 (certificate-based authentication)、パスワードベースの認証 (password-based authentication)、サーバー認証 (server authentication) を参照してください。
- チェーン認証局 (chained CA)
- リンクされた CA (linked CA) を参照してください。
- ペア間の証明書 (cross-pair certificate)
- ある CA から別の CA に発行され、信頼の輪を形成するために両方の CA によって保存される証明書。2 つの CA は相互に証明書を発行し、両方のクロスペア証明書を証明書ペアとして格納します。
- 信頼チェーン (chain of trust)
- 証明書チェーン (certificate chain) を参照してください。
- 暗号アルゴリズム (cryptographic algorithm)
- encryption や 復号化 (decryption) などの暗号化操作を実行するために使用される一連のルールまたは方向。
- 暗号モジュール (cryptographic module)
- PKCS #11 モジュール を参照してください。
- 暗号化 (cipher)
- 暗号アルゴリズム (cryptographic algorithm) を参照してください。
- 暗号化サービスプロバイダー (cryptographic service provider, CSP)
- PKCS #11 で定義されているような標準インターフェイスを使用してそのようなサービスを要求するソフトウェアに代わって、キー生成、キーストレージ、暗号化などの暗号化サービスを実行する暗号化モジュール。
- 暗号化メッセージ構文 (CMC) を介した証明書管理メッセージ
- Certificate Manager への証明書の要求を伝えるために使用するメッセージ形式。Internet Engineering Task Force (IETF) PKIX の作業グループから提案された標準。詳細は、https://tools.ietf.org/html/draft-ietf-pkix-cmc-02 を参照してください。
- 暗号化メッセージ構文 (Cryptographic Message Syntax, CS)
- CMMF などの任意のメッセージにデジタル署名、ダイジェスト、認証、または暗号化するために使用される構文。
- 相互認証 (cross-certification)
- 異なる証明書階層またはチェーン内の 2 つの CA による証明書交換クロス認定は、両方の階層に対応できるように信頼チェーンを拡張します。認証局 (certificate authority, CA) も参照してください。
- 証明書 (certificate)
- X.509 標準に準拠してフォーマットされたデジタルデータで、個人、会社などのエンティティー名 (証明書の サブジェクト名 (subject name)) を指定し、証明書に含まれる 公開鍵 (public key) もそのエンティティーに属することを証明するもの。証明書は発行され、認証局 (certificate authority, CA) により署名されます。証明書の有効性は、公開鍵暗号 (public-key cryptography) の手法で CA の デジタル署名 (digital signature) を確認して検証できます。公開鍵インフラストラクチャー (public-key infrastructure, PKI) 内で信頼されるために、証明書は、PKI に登録されているその他のエンティティーによって信頼されている CA により発行および署名される必要があります。
- 証明書のフィンガープリント (certificate fingerprint)
- 証明書に関連付けられた 一方向ハッシュ (one-way hash)。番号は証明書自体の一部ではありませんが、証明書の内容にハッシュ関数を適用することによって生成されます。証明書の内容が 1 文字でも変更されると、同じ関数で異なる番号が生成されます。したがって、証明書のフィンガープリントを使用して、証明書が改ざんされていないことを確認できます。
- 証明書の拡張 (certificate extensions)
- X.509 v3 証明書には、証明書に任意の数の追加フィールドを追加できる拡張フィールドが含まれています。証明書拡張機能は、代替サブジェクト名や使用制限などの情報を証明書に追加する方法を提供します。PKIX ワーキンググループによって、いくつかの標準拡張機能が定義されています。
- 証明書チェーン (certificate chain)
- 連続した認証局によって署名された証明書の階層セット。CA 証明書は 認証局 (certificate authority, CA) を識別し、その認証局が発行した証明書の署名に使用されます。CA 証明書は、親 CA の CA 証明書により署名され、root CA まで署名できます。Certificate System により、エンドエンティティーが証明書チェーンのすべての証明書を取得できるようになります。
- 証明書プロファイル (certificate profile)
- 特定のタイプの登録を定義する一連の設定設定。証明書プロファイルは、証明書プロファイルの認証方法とともに、特定のタイプの登録のポリシーを設定します。
- 証明書ベースの認証 (certificate-based authentication)
- 証明書および公開鍵暗号に基づく認証。パスワードベースの認証 (password-based authentication) も併せて参照してください。
- 証明書失効リスト (certificate revocation list, CRL)
- X.509 標準で定義されているように、認証局 (certificate authority, CA) により生成され署名されたシリアル番号ごとに取り消された証明書のリスト。
- 証明書管理メッセージ形式 (Certificate Management Message Formats, CMMF)
- エンドエンティティーから Certificate Manager に証明書要求と失効要求を伝達し、エンドエンティティーにさまざまな情報を送信するために使用されるメッセージ形式。Internet Engineering Task Force (IETF) PKIX の作業グループから提案された標準。CMMF は、別の提案された標準 暗号化メッセージ構文 (CMC) を介した証明書管理メッセージ に含まれています。詳細は、https://tools.ietf.org/html/draft-ietf-pkix-cmmf-02 を参照してください。
- 認証局 (certificate authority, CA)
- 証明書が特定を意図している個人またはエンティティーの身元を検証した後、証明書 (certificate) を発行する信頼されたエンティティー。CA は証明書を更新し、取り消し、CRL を生成します。証明書の発行者フィールドで指定されたエンティティーは、常に CA です。認証局は、独立したサードパーティー、または Red Hat Certificate System などの証明書発行サーバーソフトウェアを使用する個人または組織にすることができます。
D
- キーリカバリー認証局
- エンドエンティティーの RSA 暗号化キーの長期アーカイブとリカバリーを管理する任意の独立した Certificate System サブシステム。Certificate Manager は、新しい証明書を発行する前に、キーリカバリー機関を使用してエンドエンティティーの暗号化キーをアーカイブするように設定できます。キーリカバリー機関は、エンドエンティティーが機密性の高い電子メールなど、組織がいつかリカバリーする必要のあるデータを暗号化している場合にのみ役立ちます。デュアルキーペアをサポートするエンドエンティティーでのみ使用できます。2 つの個別のキーペアで、1 つは暗号化用、もう 1 つはデジタル署名用です。
- キーリカバリー認証局のストレージキー (Key Recovery Authority storage key)
- キーリカバリー機関の秘密トランスポートキーで復号された後、エンドエンティティーの暗号化キーを暗号化するためにキーリカバリー機関によって使用される特別なキー。ストレージキーがキーリカバリー機関を離れることはありません。
- キーリカバリー認証局のトランスポート証明書 (Key Recovery Authority transport certificate)
- エンドエンティティーがキーリカバリー機関に転送するためにエンティティーの暗号化キーを暗号化するために使用する公開キーを認証します。キーリカバリー機関は、認証された公開鍵に対応する秘密鍵を使用して、ストレージ鍵で暗号化する前に、エンドエンティティーの鍵を復号します。
- キーリカバリー認証局エージェント (Key Recovery Authority agent)
- 要求キューの管理や HTML ベースの管理ページを使用したリカバリー操作の許可など、キーリカバリー機関のエージェントサービスの管理を許可されたグループに属するユーザー。
- キーリカバリー認証局リカバリーエージェント (Key Recovery Authority recovery agent)
- キーリカバリー認証局 のストレージキーの一部を所有している m of n 人の 1 人。
- デジタル ID (digital ID)
- 証明書 (certificate) を参照してください。
- デジタル署名 (digital signature)
- デジタル署名を作成するため、署名ソフトウェアは最初に、新しく発行された証明書など、署名するデータから 一方向ハッシュ (one-way hash) を作成します。次に、一方向ハッシュは署名者の秘密鍵で暗号化されます。作成されるデジタル署名は、署名されるデータごとに一意になります。1 つのコンマがメッセージに追加されていても、そのメッセージのデジタル署名が変更されます。署名者の公開鍵を使用したデジタル署名の復号に成功し、同じデータの別のハッシュと比較することで、改ざんの検出 (tamper detection) が可能になります。公開鍵を含む証明書の 証明書チェーン (certificate chain) の検証により、署名側の認証が提供されます。否認防止 (nonrepudiation)、encryptionも参照してください。
- デュアルキーペア (dual key pair)
- 2 つの個別の証明書に対応する、2 つの公開鍵と秘密鍵のペア (合計 4 つの鍵)。一方のペアの秘密鍵は署名操作に使用され、もう一方のペアの公開鍵と秘密鍵は暗号化および復号操作に使用されます。各ペアは個別の 証明書 (certificate) に対応します。暗号鍵 (encryption key)、公開鍵暗号 (public-key cryptography)、署名鍵 も参照してください。
- デルタ CRL (delta CRL)
- 最後の完全な CRL が発行されてから取り消された証明書の一覧を含む CRL。
- 分散ポイント (distribution points)
- 証明書セットを定義するのに CRL に使用されます。各ディストリビューションポイントは、発行する証明書のセットにより定義されます。CRL は、特定のディストリビューションポイント用に作成できます。
- 復号化 (decryption)
- 暗号化されたデータのスクランブル解除。encryption を参照してください。
- 識別名 (distinguished name, DN)
- 証明書の件名を特定する一連の AVA。属性値アサーション (attribute value assertion, AVA) を参照してください。
E
- encryption
- その意味を偽装する方法で情報をスクランブルします。復号化 (decryption) を参照してください。
- extensions フィールド
- 証明書の拡張 (certificate extensions) を参照してください。
- エンドエンティティー (end entity)
- 公開鍵インフラストラクチャー (public-key infrastructure, PKI)、人、ルーター、サーバー、またはその他のエンティティーで、証明書 (certificate) を使用してそれ自体を特定します。
- エンロールメント (enrollment)
- 公開鍵インフラストラクチャー (public-key infrastructure, PKI) で使用する X.509 証明書を要求および受信するプロセス。登録 としても知られています。
- 傍受 (eavesdropping)
- 情報が意図されていないエンティティーによってネットワークを介して送信された情報の不正な傍受。
- 暗号鍵 (encryption key)
- 暗号化のみに使用される秘密鍵。暗号化鍵とその同等の公開鍵、および 署名鍵 とその同等の公開鍵は、デュアルキーペア (dual key pair) を設定します。
- 楕円曲線暗号 (Elliptic Curve Cryptography, ECC)
- 暗号鍵の基礎となる数学的な問題に対して、楕円曲線を用いて加算対数を作成する暗号アルゴリズム。ECC 暗号は、RSA 暗号よりも効率的に使用でき、本質的に複雑であるため、RSA 暗号よりも小さいビットで強力です。
F
- Federal Bridge Certificate Authority (FBCA)
- 2 つの CA が相互にクロスペア証明書を発行し、2 つのクロスペア証明書を単一の証明書ペアとして格納することにより、信頼の輪を形成する設定。
- FIPS PUBS 140
- FIPS PUBS (Federal Information Standards Publications) 140 は、データの暗号化と復号、またはデジタル署名の作成や検証などの他の暗号化操作を実行する暗号化モジュール、ハードウェア、またはソフトウェアの実装に関する米国政府の標準です。米国政府に販売される多くの製品は、1 つ以上の FIPS 標準に準拠する必要があります。http://www.nist.gov/itl/fipscurrent.cfm を参照してください。
- ファイアウォール (firewall)
- 2 つ以上のネットワーク間の境界を強制するシステムまたはシステムの組み合わせ。
- フィンガープリント (fingerprint)
- 証明書のフィンガープリント (certificate fingerprint) を参照してください。
I
- IP スプーフィング (IP spoofing)
- クライアント IP アドレスの禁止。
- なりすまし (impersonation)
- ネットワークを介して送信される情報の意図された受信者を装う行為。なりすましには、スプーフィング (spoofing) と 詐称 (misrepresentation) の 2 つの形式があります。
- 中間認証局 (intermediate CA)
- ルート CA と 証明書チェーン (certificate chain) で発行した証明書との間の証明書のある CA。
- 入力 (input)
- 証明書プロファイル機能のコンテキストでは、特定の証明書プロファイルの登録フォームを定義します。各入力が設定され、この登録用に設定されたすべての入力から登録フォームが動的に作成されます。
J
- JAR ファイル (JAR file)
- Java™ アーカイブ (JAR) 形式 (archive (JAR) format) に従って編成されたファイルの圧縮コレクションのデジタルエンベロープ。
- Java™ アーカイブ (JAR) 形式 (archive (JAR) format)
- デジタル署名、インストーラスクリプト、およびその他の情報をディレクトリー内のファイルに関連付けるための一連の規則。
- Java™ セキュリティーサービス (JSS)
- あJava™ネットワークセキュリティーサービス (NSS) によって実行されるセキュリティー操作を制御するためのインターフェイス。
- Java™ ネイティブインターフェイス (JNI) (Native Interface)
- 特定のプラットフォーム上の Java™ 仮想マシン (JVM) の異なる実装間でバイナリー互換性を提供する標準的なプログラミングインターフェイスで、単一のプラットフォーム用に C や C++ などの言語で記述された既存のコードを Java™ にバインドできるようにします。http://java.sun.com/products/jdk/1.2/docs/guide/jni/index.html を参照してください。
- Java™ 暗号アーキテクチャー (Cryptography Architecture, JCA)
- 暗号化サービス用に Sun Microsystems によって開発された API 仕様および参照。http://java.sun.com/products/jdk/1.2/docs/guide/security/CryptoSpec.Introduction を参照してください。
- Java™ 開発キット (Development Kit, JDK)
- Java™ プログラミング言語を使用してアプリケーションとアプレットを開発するために Sun Microsystems が提供するソフトウェア開発キット。
K
- KEA
- 鍵交換アルゴリズム (Key Exchange Algorithm, KEA) を参照してください。
- 鍵 (key)
- データを暗号化または復号化するために、暗号アルゴリズム (cryptographic algorithm) が使用する多数の数値。たとえば、あるユーザーの 公開鍵 (public key) にあるユーザーは、そのユーザー専用のメッセージを暗号化できます。その後、メッセージは対応する プライベートキー を使用して復号化する必要があります。
- 鍵交換 (key exchange)
- クライアントとサーバーが SSL セッション時に両方で使用する対称鍵を決定するために実行する手順。
- 鍵交換アルゴリズム (Key Exchange Algorithm, KEA)
- 米国政府が鍵交換に使用するアルゴリズム。
L
- Lightweight Directory Access Protocol (LDAP)
- TCP/IP および複数のプラットフォームで実行されるためのディレクトリーサービスプロトコル。LDAP は、X.500 ディレクトリーへのアクセスに使用される Directory Access Protocol (DAP) の簡易バージョンです。LDAP は IETF の変更制御下にあり、インターネット要件を満たすために進化しています。
- リンクされた CA (linked CA)
- 公開サードパーティーの CA によって署名される証明書が内部でデプロイされる 認証局 (certificate authority, CA)。内部 CA は、発行する証明書のルート CA として機能し、サードパーティー CA は、同じサードパーティールート CA にリンクされている他の CA によって発行された証明書のルート CA として機能します。チェーン CA としても知られており、異なるパブリック CA で使用される他の用語も使用します。
M
- MD5
- Ronald Rivest によって開発されたメッセージダイジェストアルゴリズム。一方向ハッシュ (one-way hash) も参照してください。
- メッセージダイジェスト (message digest)
- 一方向ハッシュ (one-way hash) を参照してください。
- 手動認証 (manual authentication)
- 各証明書要求の人間による承認を必要とする Certificate System サブシステムを設定する方法。この形式の認証では、サーブレットは、認証モジュールの処理が成功した後、証明書要求を要求キューに転送します。次に、適切な権限を持つエージェントは、プロファイルの処理と証明書の発行を続行する前に、各要求を個別に承認する必要があります。
- 詐称 (misrepresentation)
- そうではない個人または組織としてのエンティティーの提示。たとえば、Web サイトが実際にはクレジットカードでの支払いを行いますが、商品を送信しないサイトである場合、その Web サイトは家具店のふりをする可能性があります。虚偽表示は なりすまし (impersonation) の 1 つの形式です。スプーフィング (spoofing) も参照してください。
N
- non-TMS
- トークン以外の管理システム。スマートカードを直接処理 しない サブシステム (CA、および任意で KRA と OCSP) の設定を指します。
トークン管理システム参照
- ネットワークセキュリティーサービス (Network Security Services, NSS)
- セキュリティー対応の通信アプリケーションのクロスプラットフォーム開発をサポートするように設計されたライブラリーのセット。NSS ライブラリーを使用して構築されたアプリケーションは、認証、改ざん検出、および暗号化のための セキュアソケットレイヤー (Secure Sockets Layer, SSL) プロトコル、および暗号化トークンインターフェイスのための PKCS #11 プロトコルをサポートします。NSS は、ソフトウェア開発キットとして個別に利用できます。
- 否認防止 (nonrepudiation)
- メッセージの送信を拒否するためのメッセージの送信者による信頼性。デジタル署名 (digital signature) は、否認防止の形式を 1 つ提供します。
O
- OCSP
- オンライン証明書ステータスプロトコル
- オブジェクトの署名 (object signing)
- ソフトウェア開発者が Java コード、JavaScript スクリプト、またはあらゆる種類のファイルに署名し、ユーザーが署名者を識別し、署名されたコードによってローカルシステムリソースへのアクセスを制御できるようにするファイル署名の方法。
- オブジェクト署名証明書
- オブジェクトの署名 (object signing) に関連し、関連付けられた秘密鍵がオブジェクトの署名に使用される証明書。
- 一方向ハッシュ (one-way hash)
- 1.ハッシュアルゴリズムを使用して任意の長さのデータから生成された固定長の数。メッセージダイジェストとも呼ばれる数字は、ハッシュされたデータに固有のものです。1 文字を削除または変更しても、データの変更は異なります。2.ハッシュされたデータの内容をハッシュから推測することはできません。
- 出力 (output)
- 証明書プロファイル機能のコンテキストでは、特定の証明書プロファイルの証明書登録が成功した結果のフォームを定義します。各出力が設定され、この登録に設定されたすべての出力からフォームを動的に作成します。
- 操作 (operation)
- アクセス制御命令で許可または拒否されている、読み取りや書き込みなどの特定の操作。
P
- PKCS #10
- 証明書要求を制御する公開鍵暗号標準規格。
- PKCS #11
- スマートカードなどの暗号化トークンを管理する公開鍵暗号化標準。
- PKCS #11 モジュール
- PKCS #11 インターフェイスを介して、暗号化サービス (暗号化や復号など) を提供する暗号化デバイスのドライバー。暗号化モジュール または 暗号化サービスプロバイダー とも呼ばれる PKCS #11 モジュールは、ハードウェアまたはソフトウェアのいずれかで実装できます。PKCS #11 モジュールには、常に 1 つ以上のスロットがあり、スマートカードなどの物理リーダーの形式で物理ハードウェアスロットとして、またはソフトウェアの概念スロットとして実装できます。PKCS #11 モジュールの各スロットには、トークンを追加できます。このトークンは、暗号化サービスを実際に提供し、必要に応じて証明書と鍵を保存するハードウェアまたはソフトウェアのデバイスです。Red Hat は、Certificate System とともに、ビルトイン PKCS #11 モジュールを提供します。
- PKCS #12
- 鍵の移植性を管理する公開鍵暗号化標準。
- PKCS #7
- 署名と暗号化を制御する公開鍵暗号標準。
- POA (proof-of-archival)
- キーのシリアル番号、キーリカバリー機関の名前、対応する証明書の サブジェクト名 (subject name)、およびアーカイブの日付など、アーカイブされたエンドエンティティーキーに関する情報を含む秘密キーリカバリー機関のトランスポートキーで署名されたデータ。署名されたアーカイブ証明データは、キーのアーカイブ操作が成功した後、キーリカバリー機関から Certificate Manager に返される応答です。キーリカバリー認証局のトランスポート証明書 (Key Recovery Authority transport certificate) も併せて参照してください。
- パスワードベースの認証 (password-based authentication)
- 名前とパスワードによる確実な識別。認証 (authentication)、証明書ベースの認証 (certificate-based authentication) も参照してください。
- プライベートキー
- 公開鍵暗号で使用されるキーペアの 1 つ。秘密鍵は秘密を保持し、対応する 公開鍵 (public key) で暗号化されたデータの復号に使用されます。
- 公開鍵 (public key)
- 公開鍵暗号で使用されるキーペアの 1 つ。公開鍵は自由に配布され、証明書 (certificate) の一部として公開されます。これは通常、公開鍵の所有者に送信されるデータを暗号化するために使用され、所有者は対応する プライベートキー でデータを復号化します。
- 公開鍵インフラストラクチャー (public-key infrastructure, PKI)
- ネットワーク環境での公開鍵暗号化と X.509 v3 証明書の使用を容易にする標準とサービス。
- 公開鍵暗号 (public-key cryptography)
- エンティティーがその ID を電子的に検証したり、電子データに署名して暗号化したりできるようにする、確立された技術と標準のセット。公開鍵と秘密鍵の 2 つの鍵が関係します。公開鍵 (public key) は、特定の ID にキーを関連付ける証明書の一部として公開されます。対応する秘密鍵はシークレットに保存されます。公開鍵で暗号化したデータは、秘密鍵でのみ復号できます。
R
- RC2, RC4
- Rivest による RSA データセキュリティー向けに開発された暗号化アルゴリズム。暗号アルゴリズム (cryptographic algorithm) も併せて参照してください。
- Red Hat Certificate System
- 証明書を作成、デプロイ、および管理するための高度に設定可能なソフトウェアコンポーネントとツールのセット。Certificate System は、さまざまな物理的な場所にあるさまざまな Certificate System インスタンスにインストールできる 5 つの主要なサブシステム (Certificate Manager、Online Certificate Status Manager、キーリカバリー認証局、Token Key Service, and Token Processing System) で設定されています。
- root CA
- 証明書チェーンの上部に自己署名証明書が含まれている 認証局 (certificate authority, CA)。CA 証明書 (CA certificate)、subordinate CA も併せて参照してください。
- RSA アルゴリズム (RSA algorithm)
- Rivest-Shamir-Adleman の略で、暗号化と認証の両方の公開鍵アルゴリズムです。Ronald Rivest、Adi Shamir、および Leonard Adleman により開発され、1978 で導入されました。
- RSA キー交換 (RSA key exchange)
- RSA アルゴリズムに基づいた SSL の鍵交換アルゴリズム。
- 登録 (registration)
- エンロールメント (enrollment) を参照してください。
S
- SHA
- セキュアなハッシュアルゴリズム (米国政府が使用するハッシュ関数)。
- SSL
- セキュアソケットレイヤー (Secure Sockets Layer, SSL) を参照してください。
- subordinate CA
- 証明書が別の下位 CA またはルート CA によって署名されている認証局。CA 証明書 (CA certificate)、root CA を参照してください。
- サブジェクト (subject)
- 証明書 (certificate) で識別されるエンティティー。特に、証明書のサブジェクトフィールドには、認定されたエンティティーを一意に識別する サブジェクト名 (subject name) が含まれます。
- サブジェクト名 (subject name)
- サンドボックス (sandbox)
- Java™ コードが動作する必要がある、注意して定義された制限の Java™ 用語。
- サーバー SSL 証明書 (server SSL certificate)
- セキュアソケットレイヤー (Secure Sockets Layer, SSL) プロトコルを使用して、クライアントにサーバーを識別するために使用する証明書。
- サーバー認証 (server authentication)
- クライアントにサーバーを特定するプロセス。クライアント認証 (client authentication) も併せて参照してください。
- サーブレット (servlet)
- Certificate System サブシステムに代わってエンドエンティティーとの特定の種類の相互作用を処理する Java™ コード。たとえば、証明書の登録、失効、およびキーリカバリー要求は、それぞれ別のサーブレットで処理されます。
- シングルサインオン (single sign-on)
- 1.Certificate System において、内部データベースとトークンのパスワードを保管することにより、Red Hat Certificate System へのサインオン方法を簡素化するパスワード。ユーザーがログインするたびに、この単一のパスワードを入力する必要があります。2.ユーザーが 1 台のコンピューターに一度ログインし、ネットワーク内のさまざまなサーバーによって自動的に認証される機能。部分的なシングルサインオンソリューションは、さまざまなサーバーで使用されるパスワードを自動的に追跡するメカニズムなど、さまざまな形式をとることができます。証明書は、公開鍵インフラストラクチャー (public-key infrastructure, PKI) 内のシングルサインオンをサポートします。ユーザーは、ローカルクライアントの秘密鍵データベースに一度ログインし、クライアントソフトウェアが動作している限り、証明書ベースの認証 (certificate-based authentication) を使用して、ユーザーがアクセスを許可されている組織内の各サーバーにアクセスすることができます。
- スプーフィング (spoofing)
- 他人のふりをします。たとえば、あるユーザーがメールアドレス jdoe@example.com やコンピューターから、www.redhat.com と呼ばれるサイトとして誤って特定できます。なりすましは、なりすまし (impersonation) の 1 つの形です。詐称 (misrepresentation)も参照してください。
- スマートカード (smart card)
- マイクロプロセッサーを搭載し、キーや証明書などの暗号化情報を格納し、暗号化操作を実行する小さなデバイス。スマートカードは、一部またはすべて PKCS #11 インターフェイスを実装します。
- スロット (slot)
- PKCS #11 モジュール の一部 (ハードウェアまたはソフトウェアのいずれか)。これには トークン (token) が含まれています。
- セキュアなチャンネル
- TPS とスマートカード間のセキュリティーアソシエーション。TKS とスマートカード APDU によって生成された共有マスターキーに基づいて暗号化された通信を可能にします。
- セキュアソケットレイヤー (Secure Sockets Layer, SSL)
- クライアントとサーバーとの間の相互認証と、認証および暗号化された接続の確立を可能にするプロトコル。SSL は、TCP/IP より上で、HTTP、LDAP、IMAP、NNTP、およびその他の高レベルネットワークプロトコルより下で実行されます。
- セキュリティードメイン (security domain)
- PKI サブシステムの集中リポジトリーまたはインベントリー。その主な目的は、サブシステム間の信頼できる関係を自動的に確立することにより、新しい PKI サービスのインストールと設定を容易にすることです。
- セルフテスト
- インスタンスの起動時とオンデマンドの両方の Certificate System インスタンスをテストする機能。
- 対象暗号化 (symmetric encryption)
- 同じ暗号化キーを使用して特定のメッセージを暗号化および復号する暗号化方式。
- 署名アルゴリズム (signature algorithm)
- デジタル署名の作成に使用される暗号化アルゴリズム。Certificate System は、MD5 および SHA 署名アルゴリズムに対応します。暗号アルゴリズム (cryptographic algorithm)、デジタル署名 (digital signature) も併せて参照してください。
- 署名付き監査ログ (signed audit log)
- 監査ログ (autdit log) を参照してください。
- 署名証明書
- 公開鍵がデジタル署名の作成に使用される秘密鍵に対応する証明書。たとえば、Certificate Manager には、発行する証明書の署名に使用する秘密鍵に対応する公開鍵を持つ署名証明書が必要です。
- 署名鍵
- 署名用途に使用する秘密鍵署名鍵とその同等の公開鍵、および 暗号鍵 (encryption key) とその同等の公開鍵は、デュアルキーペア (dual key pair) を設定します。
T
- token key service (トークンキーサービス、TKS)
- スマートカードの APDU およびトークン CUID などの他の共有情報に基づいて、スマートカードごとに特定の個別のキーを取得するトークン管理システムのサブシステム。
- ツリー階層 (tree hierarchy)
- LDAP ディレクトリーの階層構造。
- トークン (token)
- PKCS #11 モジュール の スロット (slot) に関連付けられたハードウェアまたはソフトウェアのデバイス暗号化サービスを提供し、必要に応じて証明書および鍵を保存します。
- トークン処理システム (token processing system, TPS)
- Enterprise Security Client とスマートカードを直接対話して、これらのスマートカードのキーと証明書を管理するサブシステム。
- トークン管理システム (TMS)
- 相互に関連するサブシステム (CA、TKS、TPS、および任意で KRA) は、スマートカード (トークン) の証明書を管理するために使用されます。
- 信頼 (trust)
- 個人または他のエンティティーに確定します。公開鍵インフラストラクチャー (public-key infrastructure, PKI) では、信頼とは、証明書のユーザーと、その証明書を発行した 認証局 (certificate authority, CA) との間の関係を指します。CA が信頼されている場合は、その CA が発行する有効な証明書を信頼できます。
- 改ざんの検出 (tamper detection)
- 電子形式で受信したデータが同じデータの元のバージョンと完全に対応することを保証するメカニズム。
V
- 仮想プライベートネットワーク (virtual private network, VPN)
- 企業の地理的に離れた部署を接続する方法。VPN を使用すると、部署間は暗号化されたチャンネルを介して通信できるため、通常はプライベートネットワークに制限される認証済みの機密トランザクションが可能になります。
索引
シンボル
- アクティブなログ
- デフォルトのファイルの場所, サブシステムログの設定
- メッセージカテゴリー, ログに記録されるサービス
- アーカイブ
- ローテーションされたログファイル, ログファイルローテーション
- エラーログ
- エンドエンティティー証明書
- エンドエンティティー証明書パブリッシャー, LdapUserCertPublisher
- エージェント
- エージェントサービスインターフェイスも参照してください。, エージェント
- ユーザーを直接登録, 証明書失効ページ
- 作成, ユーザーの作成
- 修正
- グループメンバーシップ, グループのメンバーの変更
- 削除, 証明書システムユーザーの削除
- 定義されたロール, エージェント
- エージェント証明書
- オンライン証明書ステータスマネージャー
- エージェント
- 作成, ユーザーの作成
- キーペアおよび証明書
- SSL サーバー証明書, SSL サーバーキーペアおよび証明書
- サブシステム証明書, サブシステム証明書
- 署名証明書, OCSP 署名キーペアおよび証明書
- 管理者
- 作成, ユーザーの作成
- キューの公開, 公開キューの有効化
- 有効化, 公開キューの有効化
- キーリカバリー認証局
- エージェント
- 作成, ユーザーの作成
- キーペアおよび証明書
- サブシステム証明書, サブシステム証明書
- ストレージキーペア, ストレージキーペア
- トランスポート証明書, トランスポートキーペアおよび証明書
- 一覧, キーリカバリー認証局の証明書
- 管理者
- 作成, ユーザーの作成
- グループ
- メンバーの変更, グループのメンバーの変更
- コマンドラインユーティリティー
- サブシステム証明書, サブシステム証明書, サブシステム証明書, サブシステム証明書
- ジョブ
- ジョブ通知メッセージの設定, CA 通知メッセージのカスタマイズ, 自動ジョブの設定
- スケジューラーの有効化, ジョブスケジューラーの設定
- スケジュールの指定, 自動ジョブの頻度設定
- プラグインの実装と比較, 自動ジョブについて
- 組み込みモジュール
- unpublishExpiredCerts, unpublishExpiredCerts (UnpublishExpiredJob)
- 頻度の設定, ジョブスケジューラーの設定
- ジョブモジュール
- 新規登録, ジョブモジュールの登録
- ストレージキーペア, ストレージキーペア
- タイミングログローテーション, ログファイルローテーション
- テンプレート
- 通知の場合, CA 通知メッセージのカスタマイズ
- ディレクトリー
- 期限切れの証明書の削除, unpublishExpiredCerts (UnpublishExpiredJob)
- ディレクトリーの公開
- 定義, LDAP 公開
- トランスポート証明書, トランスポートキーペアおよび証明書
- 信頼設定の変更, CA 証明書の信頼設定の変更
- 削除, データベースからの証明書の削除
- 詳細表示, コンソールを使用したデータベースコンテンツの表示
- トークン
- インストールされているトークンの表示, トークンの表示
- パスワードの変更, トークンのパスワードの変更
- 管理, サブシステムによって使用されるトークンの管理
- トークンのサブシステム
- Enterprise Security Client, Certificate System サブシステムのレビュー
- トークンキーサービス
- トークン管理システム
- Enterprise Security Client, Enterprise Security Client
- ニックネーム
- CA 署名証明書, CA 署名キーペアおよび証明書
- OCSP 署名証明書, OCSP 署名キーペアおよび証明書
- SSL サーバー証明書, SSL サーバーキーペアおよび証明書, SSL サーバーキーペアおよび証明書
- TLS 署名証明書の場合, OCSP 署名キーペアおよび証明書
- サブシステム証明書, サブシステム証明書, サブシステム証明書, サブシステム証明書
- 署名証明書, OCSP 署名キーペアおよび証明書
- バックアップ, 証明書システムのバックアップと復元
- バッファーされたログ, バッファー付きおよびバッファーなしのロギング
- バッファーされていないロギング, バッファー付きおよびバッファーなしのロギング
- パブリッシャー
- パブリッシャーモジュール
- ファイルベースのパブリッシャー, FileBasedPublisher
- ブリッジ証明書, ペア間の証明書の使用
- プラグインモジュール
- CRL 拡張の場合
- CRLReason, Freshest CRL 拡張機能のデフォルト
- ジョブのスケジュールの場合
- unpublishExpiredCerts, unpublishExpiredCerts (UnpublishExpiredJob)
- 公開
- FileBasedPublisher, FileBasedPublisher
- LdapCaCertPublisher, LdapCaCertPublisher, LdapCertificatePairPublisher
- LdapCaSimpleMap, LdapCaSimpleMap
- LdapCrlPublisher, LdapCrlPublisher
- LdapDNCompsMap, LdapDNCompsMap
- LdapUserCertPublisher, LdapUserCertPublisher
- OCSPPublisher, OCSPPublisher
- 発行者代替名, Issuer Alternative Name 拡張機能のデフォルト
- プロファイル
- プロファイルの仕組み , 登録プロファイル
- ペア間の証明書, ペア間の証明書の使用
- ホスト名
- 通知に使用するメールサーバー, 証明書システム通知用のメールサーバーの設定
- ポート
- 通知に使用するメールサーバー用, 証明書システム通知用のメールサーバーの設定
- マッパー
- インストール時に作成, マッパーの作成, LdapCaSimpleMap, LdapSimpleMap
- マッパーモジュール
- ユーザー
- 作成, ユーザーの作成
- ユーザー証明書
- ログ
- Certificate System コンソールからの管理, コンソールでログの表示
- バッファーリングと非バッファーリング, バッファー付きおよびバッファーなしのロギング
- ログに記録されるサービス, ログに記録されるサービス
- ログの種類, サブシステムログの設定
- Audit, トランザクションログ
- エラー, Tomcat のエラーとアクセスログ
- ログファイル
- デフォルトの場所, サブシステムログの設定
- ローテーションされたファイルのアーカイブ, ログファイルローテーション
- ローテーションのタイミング, ログファイルローテーション
- ローテーションファイルの署名, ログファイルの署名
- ログレベル, ログレベル (メッセージカテゴリー)
- デフォルト選択, ログレベル (メッセージカテゴリー)
- メッセージカテゴリーとどのように関連するか。, ログレベル (メッセージカテゴリー)
- 右レベルの選択の重要性, ログレベル (メッセージカテゴリー)
- ログのフラッシュ間隔, バッファー付きおよびバッファーなしのロギング
- ログファイルの場所の特定
- ファイルのアーカイブ, ログファイルローテーション
- ファイルの署名, ログファイルの署名
- 時間の設定方法, ログファイルローテーション
- ログモジュール
- 削除, ログモジュールの管理
- 新規登録, ログモジュールの管理
- ロール
- agent, エージェント
- 使用するマッパー
- CA 証明書, LdapCaSimpleMap
- DN コンポーネント, LdapDNCompsMap
- 信頼できるマネージャー
- 修正
- グループメンバーシップ, グループのメンバーの変更
- 削除, 証明書システムユーザーの削除
- 修正
- 特権ユーザーのグループメンバーシップ, グループのメンバーの変更
- 停止
- サブシステムインスタンス, PKI インスタンスの起動、停止、および再起動
- 管理者の sudo パーミッション, Certificate System Service の sudo パーミッションの設定
- 公開
- CRL, 証明書の失効について
- キュー, 公開キューの有効化
- (参照 キューの公開)
- コンテンツの表示, ファイルに公開される証明書および CRL の表示
- 証明書
- ファイルへ, ファイルへの公開
- 公開できるパブリッシャー
- OCSP レスポンダー, OCSPPublisher
- ディレクトリー内の CA のエントリー, LdapCaCertPublisher, LdapCrlPublisher, LdapCertificatePairPublisher
- ディレクトリー内のユーザーのエントリー。, LdapUserCertPublisher
- ファイル, FileBasedPublisher
- 内部データベース
- schema, LDAP データベースの設定
- それは何のために使われますか。, LDAP データベースの設定
- インストールされている場合, LDAP データベースの設定
- デフォルトのホスト名, 内部データベース設定の変更
- ホスト名の変更に関する注意事項, 内部データベース設定の変更
- 他の Directory Server インスタンスと区別する方法, 内部データベースへのアクセス制限
- 名前の形式, 内部データベースへのアクセス制限
- 定義, LDAP データベースの設定
- 再起動
- サブシステムインスタンス, PKI インスタンスの起動、停止、および再起動
- Java セキュリティーマネージャーなし, Java Security Manager を使用しないサブシステムインスタンスの起動
- 管理者の sudo パーミッション, Certificate System Service の sudo パーミッションの設定
- 削除
- パブリッシャーモジュール, カスタムマッパーの登録およびプラグインモジュールの公開
- マッパーモジュール, カスタムマッパーの登録およびプラグインモジュールの公開
- ログモジュール, ログモジュールの管理
- 特権ユーザー, 証明書システムユーザーの削除
- 認証モジュール, カスタム認証プラグインの登録
- 名前拡張モジュール
- 命名規則
- 内部データベースインスタンスの場合, 内部データベースへのアクセス制限
- 場所
- アクティブなログファイル, サブシステムログの設定
- 変更
- グループメンバー, グループのメンバーの変更
- 証明書の信頼設定, CA 証明書の信頼設定の変更
- なぜ変更するか, CA 証明書の信頼設定の変更
- 復元, インスタンスディレクトリーのバックアップおよび復元
- 拡張機能, CA 証明書での制限の設定 , 証明書および CRL のデフォルト、制約、および拡張
- authorityInfoAccess, authorityInfoAccess
- authorityKeyIdentifier, CA 証明書での制限の設定 , authorityKeyIdentifier, authorityKeyIdentifier
- basicConstraints, basicConstraints
- CA 証明書、および, CA 証明書での制限の設定
- certificateIssuer, certificateIssuer
- certificatePolicies, certificatePoliciesExt
- cRLDistributionPoints, CRLDistributionPoints
- CRLNumber, CRLNumber
- CRLReason, CRLReason
- deltaCRLIndicator, deltaCRLIndicator
- extKeyUsage, extKeyUsage
- invalidityDate, invalidityDate
- issuerAltName, issuerAltName 拡張, issuerAltName
- issuingDistributionPoint, issuingDistributionPoint
- keyUsage, keyUsage
- nameConstraints, nameConstraints
- netscape-cert-type, netscape-cert-type
- Netscape-defined, Netscape で定義された証明書拡張のリファレンス
- policyConstraints, policyConstraints
- policyMappings, policyMappings
- privateKeyUsagePeriod, privateKeyUsagePeriod
- subjectAltName, subjectAltName
- subjectDirectoryAttributes, subjectDirectoryAttributes
- X.509 CRL (要約), 標準 X.509 v3 CRL 拡張機能リファレンス
- X.509 証明書、要約, 標準仕様の X.509 v3 証明書拡張機能リファレンス
- 例, 標準仕様の X.509 v3 証明書拡張機能リファレンス
- 参加するツール, 署名証明書の要求, 他の証明書の要求
- 生成するツール, 署名証明書の要求, 他の証明書の要求
- 暗号化ファイルシステム (EFS), Extended Key Usage 拡張機能のデフォルト
- 期限切れの証明書
- ディレクトリーからの削除, unpublishExpiredCerts (UnpublishExpiredJob)
- 特権ユーザー
- タイプ
- エージェント, エージェント
- 削除, 証明書システムユーザーの削除
- 権限の変更
- グループメンバーシップ, グループのメンバーの変更
- 登録
- カスタム OID, 標準仕様の X.509 v3 証明書拡張機能リファレンス
- ジョブモジュール, ジョブモジュールの登録
- パブリッシャーモジュール, カスタムマッパーの登録およびプラグインモジュールの公開
- マッパーモジュール, カスタムマッパーの登録およびプラグインモジュールの公開
- ログモジュール, ログモジュールの管理
- 認証モジュール, カスタム認証プラグインの登録
- 監査ログ
- 定義, トランザクションログ
- 監査者
- 作成, ユーザーの作成
- 管理
- 証明書データベース, 証明書データベースの管理
- 管理者
- sudo パーミッション, Certificate System Service の sudo パーミッションの設定
- 作成, ユーザーの作成
- 修正
- グループメンバーシップ, グループのメンバーの変更
- 削除, 証明書システムユーザーの削除
- 提供されるツール
- Certificate System コンソール, CA、OCSP、KRA、および TKS サブシステムに対する pkiconsole の使用
- 署名
- ローテーションされたログファイル, ログファイルの署名
- 署名アルゴリズム, 証明書の署名アルゴリズムの設定
- ECC 証明書, 証明書の署名アルゴリズムの設定
- RSA 証明書, 証明書の署名アルゴリズムの設定
- 署名証明書, OCSP 署名キーペアおよび証明書
- ニックネーム, OCSP 署名キーペアおよび証明書
- 信頼設定の変更, CA 証明書の信頼設定の変更
- 削除, データベースからの証明書の削除
- 詳細表示, コンソールを使用したデータベースコンテンツの表示
- 証明書
- LDAP ディレクトリーへの公開
- 必要なスキーマ, LDAP ディレクトリーの設定
- インストール, 証明書システムデータベースでの証明書のインストール
- ファイルへの公開, ファイルへの公開
- 取り消し方法, 証明書の失効理由
- 失効の理由, 証明書の失効理由
- 拡張機能, CA 証明書での制限の設定 , 証明書および CRL のデフォルト、制約、および拡張
- 署名アルゴリズム, 証明書の署名アルゴリズムの設定
- 証明書のインストール, 証明書システムデータベースでの証明書のインストール
- 証明書のダウンロード, 証明書システムデータベースでの証明書のインストール
- 証明書のリクエスト
- CA 署名証明書, コンソールを使用した証明書の要求
- certutil の使用, 証明書署名リクエストの作成
- ECC 証明書, 証明書署名リクエストの作成
- KRA トランスポート証明書, コンソールを使用した証明書の要求
- OCSP 署名証明書, コンソールを使用した証明書の要求
- SSL クライアント証明書, コンソールを使用した証明書の要求
- SSL サーバー証明書, コンソールを使用した証明書の要求
- エンドエンティティーページ経由, End-Entities ページでの証明書の要求および受信
- エージェント証明書, End-Entities ページでの証明書の要求および受信
- コンソールからの操作, コンソールを使用した証明書の要求
- ユーザー証明書, End-Entities ページでの証明書の要求および受信
- 証明書の取り消し
- 証明書の取り消し理方法, 証明書の失効理由
- 証明書の取り消し理由, 証明書の失効理由
- 証明書の更新, 更新を有効にするためのプロファイルの設定
- 証明書を呼び出す理由, 証明書の失効理由
- 証明書システムの復元, インスタンスディレクトリーのバックアップおよび復元
- 証明書セットアップウィザード
- 証明書のインストールに使用, コンソールを使用した証明書のインストール
- 証明書チェーンのインストールに使用, コンソールを使用した証明書のインストール
- 証明書チェーン
- インストール理由, CA 証明書のチェーンについて
- 証明書データベースでのインストール, コンソールを使用した証明書のインストール
- 証明書データベース
- 含まれるもの, 証明書データベースの管理
- 管理方法, 証明書データベースの管理
- 維持される場所, 証明書データベースの管理
- 証明書プロファイル
- 署名アルゴリズム, 証明書の署名アルゴリズムの設定
- 証明書失効
- 理由, 証明書の失効理由
- 証明書を取り消すことができるユーザー, 証明書の失効理由
- 認証中, ユーザーが開始した失効
- 認証
- コンソールからの管理, PIN ベースの登録の設定
- 証明書失効リスト中, ユーザーが開始した失効
- 認証モジュール
- ユーザー登録を開始したエージェント, 証明書失効ページ
- 削除, カスタム認証プラグインの登録
- 新規登録, カスタム認証プラグインの登録
- 軌道
- サブシステムインスタンス, PKI インスタンスの起動、停止、および再起動
- Java セキュリティーマネージャーなし, Java Security Manager を使用しないサブシステムインスタンスの起動
- 管理者の sudo パーミッション, Certificate System Service の sudo パーミッションの設定
- 追加
- 拡張機能
- CRL, CRL 拡張機能の設定
- 通知
- メールサーバーの設定
- hostname, 証明書システム通知用のメールサーバーの設定
- ポート, 証明書システム通知用のメールサーバーの設定
- 証明書の非公開についてエージェントに, unpublishExpiredCerts (UnpublishExpiredJob)
- 通知に使用するメールサーバー, 証明書システム通知用のメールサーバーの設定
A
- authorityInfoAccess, authorityInfoAccess
- authorityKeyIdentifier, CA 証明書での制限の設定 , authorityKeyIdentifier, authorityKeyIdentifier
B
- base-64 でエンコードされたファイル
- コンテンツの表示, ファイルに公開される証明書および CRL の表示
- basicConstraints, basicConstraints
C
- CA
- ECC 署名アルゴリズムの設定, 証明書の署名アルゴリズムの設定
- SCEP 登録の有効化, SCEP 登録の有効化
- SCEP 設定, SCEP のセキュリティー設定の設定
- CA 署名証明書, 証明書の失効について, CA 署名キーペアおよび証明書
- ニックネーム, CA 署名キーペアおよび証明書
- リクエスト, コンソールを使用した証明書の要求
- 信頼設定の変更, CA 証明書の信頼設定の変更
- 削除, データベースからの証明書の削除
- 詳細表示, コンソールを使用したデータベースコンテンツの表示
- CA 証明書パブリッシャー, LdapCaCertPublisher, LdapCertificatePairPublisher
- CA 証明書マッパー, LdapCaSimpleMap
- certificate
- コンテンツの表示, ファイルに公開される証明書および CRL の表示
- Certificate Manager
- エージェント
- 作成, ユーザーの作成
- キーペアおよび証明書
- CA 署名証明書, CA 署名キーペアおよび証明書
- OCSP 署名証明書, OCSP 署名キーペアおよび証明書
- SSL サーバー証明書, SSL サーバーキーペアおよび証明書
- TLS CA 署名証明書, OCSP 署名キーペアおよび証明書
- サブシステム証明書, サブシステム証明書
- シリアル番号の範囲, 証明書の発行における CA の制限の変更
- ディレクトリーを公開するための手動更新, ディレクトリーの証明書および CRL の更新
- 管理者
- 作成, ユーザーの作成
- 設定
- 通知用の SMTP 設定, 証明書システム通知用のメールサーバーの設定
- Certificate System
- バックアップ, 証明書システムのバックアップと復元
- 復元, インスタンスディレクトリーのバックアップおよび復元
- Certificate System のバックアップ, 証明書システムのバックアップと復元
- Certificate System コンソール
- Configuration タブ, CA、OCSP、KRA、および TKS サブシステムに対する pkiconsole の使用
- Status タブ, CA、OCSP、KRA、および TKS サブシステムに対する pkiconsole の使用
- ログの管理, コンソールでログの表示
- 認証の設定, ディレクトリーベースの認証の設定, PIN ベースの登録の設定
- Certificate System データ
- 保存される場所, LDAP データベースの設定
- certificateIssuer, certificateIssuer
- certificatePolicies, certificatePoliciesExt
- certutil
- 証明書のリクエスト, 証明書署名リクエストの作成
- Configuration タブ, CA、OCSP、KRA、および TKS サブシステムに対する pkiconsole の使用
- CRL
- LDAP ディレクトリーへの公開, CRL の公開, LDAP 公開
- 必要なスキーマ, LDAP ディレクトリーの設定
- エクステンション固有のモジュール, CRL 拡張について
- コンテンツの表示, ファイルに公開される証明書および CRL の表示
- サポートされるエクステンション, 証明書の失効について
- ファイルへの公開, ファイルへの公開
- 公開, 証明書の失効について
- 定義, 証明書の失効について
- 拡張機能, 標準 X.509 v3 CRL 拡張機能リファレンス
- 更新期間の入力, 各発行ポイントの CRL の設定
- 生成された場合, 証明書の失効について
- 発行ポイントまたは配布ポイント, CRL 発行ポイント
- 自動更新が行われる場合, 証明書の失効について
- 複数の更新時間の入力, 各発行ポイントの CRL の設定
- 誰がこれを生成するか, 証明書の失効について
- CRL ディストリビューションポイント拡張, CRL 発行ポイント
- CRL パブリッシャー, LdapCrlPublisher
- CRL 拡張モジュール
- CRLReason, Freshest CRL 拡張機能のデフォルト
- CRL 拡張機能の設定, CRL 拡張機能の設定
- cRLDistributionPoints, CRLDistributionPoints
- CRLNumber, CRLNumber
- CRLReason, CRLReason
D
- deltaCRLIndicator, deltaCRLIndicator
- DER でエンコードされたファイル
- コンテンツの表示, ファイルに公開される証明書および CRL の表示
- DN コンポーネントマッパー, LdapDNCompsMap
E
- ECC
- リクエスト, 証明書署名リクエストの作成
- 設定, 証明書の署名アルゴリズムの設定
- enrollment
- 開始したエージェント, 証明書失効ページ
- Enterprise Security Client, Enterprise Security Client
- Extended Key Usage Extension
- 暗号化されたファイルシステムの OID, Extended Key Usage 拡張機能のデフォルト
- extKeyUsage, extKeyUsage
F
- Federal Bridge Certificate Authority, ペア間の証明書の使用
I
- invalidityDate, invalidityDate
- IPv6
- および SCEP 証明書, ルーターの SCEP 証明書の生成
- issuerAltName, issuerAltName 拡張, issuerAltName
- issuingDistributionPoint, issuingDistributionPoint
K
- keyUsage, keyUsage
- KRA トランスポート証明書
- リクエスト, コンソールを使用した証明書の要求
L
- LDAP 公開
- 定義, LDAP 公開
- 手動更新, ディレクトリーの証明書および CRL の更新
- これを実行できるユーザー, ディレクトリーの証明書および CRL の更新
- 実行するタイミング, ディレクトリーでの証明書の手動による更新
N
- nameConstraints, nameConstraints
- netscape-cert-type, netscape-cert-type
O
- OCSP パブリッシャー, OCSPPublisher
- OCSP 署名証明書, OCSP 署名キーペアおよび証明書
- ニックネーム, OCSP 署名キーペアおよび証明書
- リクエスト, コンソールを使用した証明書の要求
P
- PIN ジェネレーターツール
- ユーザーへの PIN の配信, PIN ベースの登録の設定
- policyConstraints, policyConstraints
- policyMappings, policyMappings
- privateKeyUsagePeriod, privateKeyUsagePeriod
R
- RSA
- 設定, 証明書の署名アルゴリズムの設定
S
- SCEP
- nonce サイズの設定, SCEP のセキュリティー設定の設定
- 別の認証証明書の使用, SCEP のセキュリティー設定の設定
- 有効化, SCEP 登録の有効化
- 許可されるアルゴリズムの設定, SCEP のセキュリティー設定の設定
- SCEP 証明書
- および IPv6, ルーターの SCEP 証明書の生成
- SMTP の設定, 証明書システム通知用のメールサーバーの設定
- SSL クライアント証明書
- リクエスト, コンソールを使用した証明書の要求
- SSL サーバー証明書, SSL サーバーキーペアおよび証明書, SSL サーバーキーペアおよび証明書
- ニックネーム, SSL サーバーキーペアおよび証明書, SSL サーバーキーペアおよび証明書
- リクエスト, コンソールを使用した証明書の要求
- 信頼設定の変更, CA 証明書の信頼設定の変更
- 削除, データベースからの証明書の削除
- 詳細表示, コンソールを使用したデータベースコンテンツの表示
- Status タブ, CA、OCSP、KRA、および TKS サブシステムに対する pkiconsole の使用
- subjectAltName, subjectAltName
- subjectDirectoryAttributes, subjectDirectoryAttributes
- subjectKeyIdentifier
- subjectKeyIdentifier, subjectKeyIdentifier
- sudo
T
- TLS CA 署名証明書, OCSP 署名キーペアおよび証明書
- ニックネーム, OCSP 署名キーペアおよび証明書
- TPS
- プロファイルの設定, ユーザーのプロファイルの設定
- ユーザー, TPS のユーザーの作成および管理
付録F 改訂履歴
改訂履歴 | |||
---|---|---|---|
改訂 9.7-0 | Tue Sep 29 2020 | ||
| |||
改訂 9.6-0 | Wed Sep 16 2020 | ||
| |||
改訂 9.5-0 | Tue Aug 06 2019 | ||
| |||
改訂 9.4-0 | Thu Oct 25 2018 | ||
| |||
改訂 9.3-1 | Thu May 03 2018 | ||
| |||
改訂 9.3-0 | Tue Apr 10 2018 | ||
| |||
改訂 9.2-0 | Tue Aug 01 2017 | ||
| |||
改訂 9.1-1 | Thu Mar 09 2017 | ||
| |||
改訂 9.1-0 | Mon Aug 15 2016 | ||
| |||
改訂 9.0-0 | Mon Aug 15 2016 | ||
|