検索
サポートコンソール開発者トライアルの開始お問い合わせ

13.2. CS.cfg ファイル

download PDF
Certificate System サブシステムのランタイムプロパティーは、一連の設定パラメーターで管理されます。これらのパラメーターは、起動時にサーバーが読み込む CS.cfg ファイルに保存されます。
CS.cfg (ASCII ファイル) が作成され、サブシステムの初回インストール時に適切な設定パラメーターが入力されます。インスタンスの機能の変更方法は、サブシステムコンソールで変更することが推奨されます。これが推奨される方法です。管理コンソールで行った変更は、設定ファイルに反映されます。
CS.cfg 設定ファイルを直接編集することもできます。場合によっては、サブシステムを管理する最も簡単な方法となる場合があります。

13.2.1. CS.cfg ファイルの検索

Certificate System サブシステムの各インスタンスには、独自の設定ファイル CS.cfg があります。各サブシステムインスタンスのファイルの内容は、サブシステムの設定方法、追加の設定および設定 (新規プロファイルの追加、セルフテストの有効化など)、サブシステムのタイプによって異なります。
CS.cfg ファイルは、インスタンスの設定ディレクトリーにあります。 
/var/lib/pki/instance_name/subsystem_type/conf
以下に例を示します。 
/var/lib/pki/instance_name/ca/conf

13.2.2. 設定ファイルの編集

警告
設定パラメーターに精通していない場合や、変更がサーバーに許容されていることを認識せずに、設定ファイルを直接編集しないでください。設定ファイルが正しく変更されていないと、Certificate System は起動に失敗します。設定が間違っていると、データが失われる可能性があります。
CS.cfg ファイルを変更するには、以下の手順に従います。
  1. サブシステムインスタンスを停止します。 
    # systemctl stop pki-tomcatd@instance_name.service
    または (nuxwdog watchdog を使用している場合) 
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    設定ファイルは、インスタンスの起動時にキャッシュに保存されます。コンソールを介してインスタンスに加えた変更は、ファイルのキャッシュバージョンに変更されます。サーバーが停止または再起動されると、キャッシュに保存されている設定ファイルがディスクに書き込まれます。設定ファイルを編集する前にサーバーを停止すると、サーバーが停止するとキャッシュバージョンの変更が上書きされます。
  2. /var/lib/pki/instance_name/subsystem_type/conf ディレクトリーを開きます。
  3. テキストエディターで CS.cfg ファイルを開きます。
  4. ファイル内のパラメーターを編集して、変更を保存します。
  5. サブシステムインスタンスを開始します。 
    # systemctl start pki-tomcatd@instance_name.service
    または (nuxwdog watchdog を使用している場合) 
    # systemctl start pki-tomcatd-nuxwdog@instance_name.service

13.2.3. CS.cfg 設定ファイルの概要

各サブシステムインスタンスには、設定用のプラグインや Java クラスなど、インスタンスのすべての設定が含まれる独自のメイン設定ファイル CS.cfg があります。パラメーターと特定の設定はサブシステムのタイプによって異なりますが、一般的に CS.cfg ファイルはサブシステムインスタンスの以下の部分を定義します。
  • 名前、ポート割り当て、インスタンスディレクトリー、ホスト名などの基本サブシステムインスタンス情報
  • ログ
  • インスタンスのユーザーディレクトリー (authorization) に対して認証するプラグインおよびメソッド
  • インスタンスが属するセキュリティードメイン
  • サブシステム証明書
  • サブシステムインスタンスによって使用される他のサブシステム
  • サブシステムによって使用されるデータベースタイプおよびインスタンス
  • TKS のキープロファイル、CA の証明書プロファイル、KRA のキーリカバリーに必要なエージェントなどの PKI 関連タスクの設定
設定パラメーターの多く (PKI タスクのパラメーターを除く) は、すべて Java ベースのコンソールを使用するため、CA、OCSP、KRA、および TKS 間でほとんど同じです。したがって、コンソールで管理できる設定には、同様のパラメーターがあります。
CS.cfg ファイルは、基本的な parameter=value 形式です。 
#comment
parameter=value
CS.cfg ファイルでは、パラメーターブロックの多くに pound (#) 文字でコメントアウトされた記述的なコメントがあります。コメント、空白行、不明なパラメーター、またはスペルミスのパラメーターはサーバーによって無視されます。
注記
TPS のバグが原因で、CS.cfg ファイルでコメントアウトされている行が無視されなくなります。TPS CS.cfg ファイルの行をコメントアウトするのではなく、それらの行を削除するだけです。
インスタンスの同じ領域を設定するパラメーターは、同じブロックにグループ化される傾向があります。

例13.1 CS.cfg ファイルのログ設定

log.instance.System._000=##
log.instance.System._001=## System Logging
log.instance.System._002=##
log.instance.System.bufferSize=512
log.instance.System.enable=true
log.instance.System.expirationTime=0
log.instance.System.fileName=/var/lib/pki-ca/logs/system
log.instance.System.flushInterval=5
log.instance.System.level=3
log.instance.System.maxFileSize=2000
log.instance.System.pluginName=file
log.instance.System.rolloverInterval=2592000
log.instance.System.type=system
機能の一部は、サブシステムにアクセスするためにセルフテスト、ジョブ、認可などのプラグインを使用して実装されます。これらのパラメーターの場合、プラグインインスタンスには、一意の識別子 (サブシステムに対して呼び出される同じプラグインのインスタンスが複数存在する可能性があるため)、実装プラグイン名、および Java クラスがあります。

例13.2 サブシステム認証設定

authz.impl._000=##
authz.impl._001=## authorization manager implementations
authz.impl._002=##
authz.impl.BasicAclAuthz.class=com.netscape.cms.authorization.BasicAclAuthz
authz.instance.BasicAclAuthz.pluginName=BasicAclAuthz
注記
設定パラメーターの値を適切にフォーマットする必要があるため、2 つのルールを考慮する必要があります。
  • ローカライズする必要のある値は、UTF8 文字である必要があります。
  • CS.cfg ファイルは、パラメーター値のスラッシュ (/) をサポートします。値にバックスラッシュ (\) が必要な場合は、スラッシュでエスケープする必要があります。つまり、2 つのバックスラッシュを続けて使用する必要があります。
以下のセクションでは、CS.cfg ファイル設定およびパラメーターのスナップショットです。これらは、完全な参考資料や CS.cfg ファイルパラメーターの例ではありません。また、各サブシステム設定ファイルで利用可能なパラメーターと使用されるパラメーターは異なりますが、類似しています。

13.2.3.1. サブシステムの基本設定

基本的な設定は、サブシステムの機能や動作に直接関係することなく、インスタンス自体に固有のものです。これには、インスタンス名、root ディレクトリー、プロセスのユーザー ID、およびポート番号の設定が含まれます。インスタンスの初回インストールまたは設定時に割り当てられる設定の多くは、pkispawn で示されます。

例13.3 CA の基本インスタンスパラメーター: pkispawn ファイル ca.cfg

[DEFAULT]
pki_admin_password=Secret.123
pki_client_pkcs12_password=Secret.123
pki_ds_password=Secret.123
# Optionally keep client databases
pki_client_database_purge=False
# Separated CA instance name and ports
pki_instance_name=pki-ca
 pki_http_port=18080
pki_https_port=18443
# This Separated CA instance will be its own security domain
pki_security_domain_https_port=18443

[Tomcat]
# Separated CA Tomcat ports
pki_ajp_port=18009
pki_tomcat_server_port=18005
重要
ポート設定などの情報は CS.cfg ファイルに 含まれ ますが、CS.cfgには 設定 されません。サーバー設定が server.xml ファイルに設定されます。
CS.cfg および server.xml のポートは、稼働中の RHCS インスタンスと一致している必要があります。

13.2.3.2. ログ設定

サブシステムのタイプによって、設定可能なログにはいくつかのタイプがあります。各タイプのログには、CS.cfg ファイルに独自の設定エントリーがあります。
たとえば、CA にはトランザクションログ用のこのエントリーがあります。これにより、ログローテーション、バッファーログ、ログレベルなどの設定が可能になります。 
log.instance.Transactions._000=##
log.instance.Transactions._001=## Transaction Logging
log.instance.Transactions._002=##
log.instance.Transactions.bufferSize=512
log.instance.Transactions.enable=true
log.instance.Transactions.expirationTime=0
log.instance.Transactions.fileName=/var/log/pki/pki-tomcat/ca/logs/transactions
log.instance.Transactions.flushInterval=5
log.instance.Transactions.level=1
log.instance.Transactions.maxFileSize=2000
log.instance.Transactions.pluginName=file
log.instance.Transactions.rolloverInterval=2592000
log.instance.Transactions.type=transaction
これらのパラメーターとその値の詳細は、「Certificate System ログの設定」を参照してください。監査ログが有効になっている限り、これらの値はコンプライアンスには影響しません。

13.2.3.3. 認証および認可の設定

CS.cfg ファイルには、ユーザーがサブシステムインスタンス (認証) にアクセスする方法や、認証された各ユーザーの承認 (認証) されるアクションを設定します。
CS サブシステムは、認証プラグインを使用して、サブシステムにログインする方法を定義します。
以下の例は、SharedSecretという名前の JAVA プラグインをインスタンス化する SharedToken という名前の認証インスタンスを示しています。 
auths.impl.SharedToken.class=com.netscape.cms.authentication.SharedSecret
auths.instance.SharedToken.pluginName=SharedToken
auths.instance.SharedToken.dnpattern=
auths.instance.SharedToken.ldap.basedn=ou=People,dc=example,dc=org
auths.instance.SharedToken.ldap.ldapauth.authtype=BasicAuth
auths.instance.SharedToken.ldap.ldapauth.bindDN=cn=Directory Manager
auths.instance.SharedToken.ldap.ldapauth.bindPWPrompt=Rule SharedToken
auths.instance.SharedToken.ldap.ldapauth.clientCertNickname=
auths.instance.SharedToken.ldap.ldapconn.host=server.example.com
auths.instance.SharedToken.ldap.ldapconn.port=636
auths.instance.SharedToken.ldap.ldapconn.secureConn=true
auths.instance.SharedToken.ldap.ldapconn.version=3
auths.instance.SharedToken.ldap.maxConns=
auths.instance.SharedToken.ldap.minConns=
auths.instance.SharedToken.ldapByteAttributes=
auths.instance.SharedToken.ldapStringAttributes=
auths.instance.SharedToken.shrTokAttr=shrTok
一部の認証設定では、LDAP データベースを使用してユーザーエントリーを保存する認証方法を選択できます。その場合、データベース設定は、以下に示すようにプラグインとともに設定されます。 
authz.impl.DirAclAuthz.class=com.netscape.cms.authorization.DirAclAuthz
authz.instance.DirAclAuthz.ldap=internaldb
authz.instance.DirAclAuthz.pluginName=DirAclAuthz
authz.instance.DirAclAuthz.ldap._000=##
authz.instance.DirAclAuthz.ldap._001=## Internal Database
authz.instance.DirAclAuthz.ldap._002=##
authz.instance.DirAclAuthz.ldap.basedn=dc=server.example.com-pki-ca
authz.instance.DirAclAuthz.ldap.database=server.example.com-pki-ca
authz.instance.DirAclAuthz.ldap.maxConns=15
authz.instance.DirAclAuthz.ldap.minConns=3
authz.instance.DirAclAuthz.ldap.ldapauth.authtype=SslClientAuth
authz.instance.DirAclAuthz.ldap.ldapauth.bindDN=cn=Directory Manager
authz.instance.DirAclAuthz.ldap.ldapauth.bindPWPrompt=Internal LDAP Database
authz.instance.DirAclAuthz.ldap.ldapauth.clientCertNickname=
authz.instance.DirAclAuthz.ldap.ldapconn.host=localhost
authz.instance.DirAclAuthz.ldap.ldapconn.port=11636
authz.instance.DirAclAuthz.ldap.ldapconn.secureConn=true
authz.instance.DirAclAuthz.ldap.multipleSuffix.enable=false
LDAP のセキュアな設定とパラメーターの説明は、「TLS クライアント認証の有効化」 を参照してください。パラメーターパスは表示される内容とは異なりますが、両方の場所で同じ名前と値が許可されます。
CA は、ユーザーリクエストの承認メカニズムも必要です。これは、承認の設定と同様に、適切な認証プラグインを特定し、そのためにインスタンスを設定して行います。 
auths.impl.AgentCertAuth.class=com.netscape.cms.authentication.AgentCertAuthentication
auths.instance.AgentCertAuth.agentGroup=Certificate Manager Agents
auths.instance.AgentCertAuth.pluginName=AgentCertAuth

13.2.3.4. サブシステム証明書の設定

複数のサブシステムには、設定ファイルの各サブシステム証明書のエントリーがあります。 
ca.sslserver.cert=MIIDmDCCAoCgAwIBAgIBAzANBgkqhkiG9w0BAQUFADBAMR4wHAYDVQQKExVSZWR...
ca.sslserver.certreq=MIICizCCAXMCAQAwRjEeMBwGA1UEChMVUmVkYnVkY29tcHV0ZXIgRG9tYWluMSQwIgYDV...
ca.sslserver.nickname=Server-Cert cert-pki-ca
ca.sslserver.tokenname=Internal Key Storage Token

13.2.3.5. 必要なサブシステムの設定

少なくとも、各サブシステムは CA に依存するため、CA (およびその他の必要なサブシステム) をサブシステムの設定で設定する必要があります。別のサブシステムへの接続の前に conn. を付けてから、サブシステムのタイプと番号が付けられます。 
conn.ca1.clientNickname=subsystemCert cert-pki-tps
conn.ca1.hostadminport=server.example.com:8443
conn.ca1.hostagentport=server.example.com:8443
conn.ca1.hostport=server.example.com:9443
conn.ca1.keepAlive=true
conn.ca1.retryConnect=3
conn.ca1.servlet.enrollment=/ca/ee/ca/profileSubmitSSLClient
conn.ca1.servlet.renewal=/ca/ee/ca/profileSubmitSSLClient
conn.ca1.servlet.revoke=/ca/subsystem/ca/doRevoke
conn.ca1.servlet.unrevoke=/ca/subsystem/ca/doUnrevoke
conn.ca1.timeout=100

13.2.3.6. データベース設定

すべてのサブシステムは LDAP ディレクトリーを使用してそれらの情報を保存します。この内部データベースは internaldb パラメーターで設定されますが、その他の設定オプションが多数ある tokendb パラメーターで設定した TPS を除きます。 
internaldb._000=##
internaldb._000=##
internaldb._001=## Internal Database
internaldb._002=##
internaldb.basedn=o=pki-tomcat-ca-SD
internaldb.database=pki-tomcat-ca
internaldb.maxConns=15
internaldb.minConns=3
internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.clientCertNickname=HSM-A:subsystemCert pki-tomcat-ca
internaldb.ldapconn.host=example.com
internaldb.ldapconn.port=11636
internaldb.ldapconn.secureConn=true
internaldb.multipleSuffix.enable=false
LDAP のセキュアな設定とパラメーターの説明は、「TLS クライアント認証の有効化」を参照してください。「TLS クライアント認証の有効化」と 以外の設定は必要ありません。

13.2.3.7. キューの有効化および設定

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

図13.1 公開キューの有効化

公開キューの有効化
13.2.3.7.1. CS.cfg ファイルを編集して、Queue の有効化と設定
CS.cfg ファイルを編集してパブリッシュキューを有効にすると、管理者はパブリッシュ操作に使用するスレッドの数やキューページサイズなど、パブリッシュする他のオプションを設定できます。
  1. 設定ファイルを編集できるように CA サーバーを停止します。 
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
  2. CA の CS.cfg ファイルを開きます。 
    # vim /var/lib/pki/instance_name/ca/conf/CS.cfg
  3. ca.publish.queue.enable を true に設定します。パラメーターが存在しない場合は、パラメーターで行を追加します。 
    ca.publish.queue.enable=true
  4. その他の関連するパブリッシュキューパラメーターを設定します。
    • ca.publish.queue.maxNumberOfThreads パブリッシュ操作に対して開くことができるスレッドの最大数を設定します。デフォルトは 3 です。
    • ca.publish.queue.priorityLevel は、パブリッシュ操作の優先度を設定します。優先度の値の範囲は、-2 (最も低い優先度) から 2 (最も高い優先度) までです。ゼロ (0) は通常の優先度で、デフォルトはデフォルトです。
    • ca.publish.queue.pageSize は、パブリッシュキューページに格納できるリクエストの最大数を設定します。デフォルトは 40 です。
    • ca.publish.queue.saveStatus は、指定された公開操作の数ごとにステータスを保存する間隔を設定します。これにより、CA が再起動またはクラッシュした場合にパブリッシュキューを復元できます。デフォルトは 200 ですが、CA の再起動時にゼロ以外の番号がキューを復旧します。このパラメーターを 0 に設定すると、キューの復元が無効になります。 
    ca.publish.queue.maxNumberOfThreads=1
	ca.publish.queue.priorityLevel=0
	ca.publish.queue.pageSize=100
	ca.publish.queue.saveStatus=200
    ヒント
    ca.publish.queue.enable を false に設定し、ca.publish.queue.maxNumberOfThreads を 0 に設定すると、公開キューと、発行した証明書の公開に別のスレッドが使用されます。
  5. CA サーバーを起動します。 
    # systemctl start pki-tomcatd-nuxwdog@instance_name.service

13.2.3.8. PKI タスクの設定

CS.cfg ファイルは、すべてのサブシステムに PKI タスクを設定するのに使用されます。パラメーターは、重複のないサブシステムごとに異なります。
たとえば、KRA には、鍵を復元するために必要な数のエージェントの設定があります。 
kra.noOfRequiredRecoveryAgents=1
各サブシステムの CS.cfg ファイルを確認して、PKI タスク設定について理解してください。ファイル内のコメントは、さまざまなパラメーターが何であるかを学習するための適切なガイドです。
  • CA 設定ファイルには、すべての証明書プロファイルおよびポリシー設定と、CRL を生成するルールがリスト表示されます。
  • TPS は、さまざまなトークン操作を設定します。
  • TKS は、さまざまな鍵タイプからの鍵を取得するプロファイルをリスト表示します。
  • OCSP は、さまざまな鍵セットの鍵情報を設定します。

13.2.3.9. CA 発行証明書の DN 属性の変更

Certificate System が発行した証明書で、DN は証明書を所有するエンティティーを特定します。いずれの場合も、Certificate System が Directory Server に接続されている場合、証明書内の DN の形式はディレクトリー内の DN の形式と一致する必要があります。名前が完全に一致する必要はありません。証明書マッピングにより、証明書のサブジェクト DN をディレクトリー内の DN とは異なるものにすることができます。
Certificate System の DN は、X.509 標準で定義されたコンポーネントまたは属性に基づいています。表13.8「値タイプに許可される文字」 は、デフォルトでサポートされる属性をリスト表示しています。属性のセットは拡張可能です。
表13.8 値タイプに許可される文字
属性 値のタイプ オブジェクト識別子
cn DirectoryString 2.5.4.3
ou DirectoryString 2.5.4.11
o DirectoryString 2.5.4.10
c PrintableString、2 文字 2.5.4.6
l DirectoryString 2.5.4.7
st DirectoryString 2.5.4.8
street DirectoryString 2.5.4.9
title DirectoryString 2.5.4.12
uid DirectoryString 0.9.2342.19200300.100.1.1
mail IA5String 1.2.840.113549.1.9.1
dc IA5String 0.9.2342.19200300.100.1.2.25
serialnumber PrintableString 2.5.4.5
unstructuredname IA5String 1.2.840.113549.1.9.2
unstructuredaddress PrintableString 1.2.840.113549.1.9.8
デフォルトでは、Certificate System は、表13.8「値タイプに許可される文字」 で特定される属性に対応します。サポートされる属性のリストは、新しい属性を作成または追加することで拡張できます。X.500Name 属性またはコンポーネントを追加する構文は次のとおりです。 
X500Name.NEW_ATTRNAME.oid=n.n.n.n
X500Name.NEW_ATTRNAME.class=string_to_DER_value_converter_class
値コンバータークラスは文字列を ASN.1 値に変換します。このクラスは netscape.security.x509.AVAValueConverter インターフェイスを実装する必要があります。文字列から値へのコンバータークラスは、次のいずれかになります。
  • Netscape.security.x509.PrintableConverter は、文字列を PrintableString 値に変換します。この文字列は、出力可能な文字のみでなければなりません。
  • Netscape.security.x509.IA5StringConverter は文字列を IA5String 値に変換します。この文字列は IA5String 文字のみである必要があります。
  • netscape.security.x509.DirStrConverter は文字列を DirectoryString に変換します。この文字列は RFC 2253 に従って DirectoryString 形式になることが予想されます。
  • netscape.security.x509.GenericValueConverter は、最小の文字セットから最大の文字セットへ、次の順序で文字列を文字ごとに変換します。
    • PrintableString
    • IA5String
    • BMPString
    • 汎用文字列
属性エントリーは、以下のようになります。 
X500Name.MY_ATTR.oid=1.2.3.4.5.6
X500Name.MY_ATTR.class=netscape.security.x509.DirStrConverter
13.2.3.9.1. 新規属性またはカスタム属性の追加
Certificate System スキーマに新規またはプロプライエタリー属性を追加するには、以下を行います。
  1. Certificate Manager を停止します。 
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
  2. /var/lib/pki/cs_instance/conf/ ディレクトリーを開きます。
  3. 設定ファイル CS.cfg を開きます。
  4. 設定ファイルに新しい属性を追加します。
    たとえば、DirectoryString である MYATTR1、IA5String である MYATTR2、PrintableString である MYATTR3 の 3 つのプロプライエタリー属性を追加するには、設定ファイルの最後に以下の行を追加します。 
    X500Name.attr.MYATTR1.oid=1.2.3.4.5.6
X500Name.attr.MYATTR1.class=netscape.security.x509.DirStrConverter
X500Name.attr.MYATTR2.oid=11.22.33.44.55.66
X500Name.attr.MYATTR2.class=netscape.security.x509.IA5StringConverter
X500Name.attr.MYATTR3.oid=111.222.333.444.555.666
X500Name.attr.MYATTR3.class=netscape.security.x509.PrintableConverter
  5. 変更を保存して、ファイルを閉じます。
  6. Certificate Manager を再起動します。 
    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
  7. 登録ページを再読み込みして変更を確認します。フォームに新しい属性が表示されるはずです。
  8. 新しい属性が有効になっていることを確認するには、手動登録フォームを使用して証明書を要求します。
    新しい属性に値を入力します。これにより、証明書のサブジェクト名に表示されることを確認できます。たとえば、以下の値を入力して、新しい属性の値を入力し、サブジェクト名で確認します。 
    MYATTR1: a_value
MYATTR2: a.Value
MYATTR3: aValue
cn: John Doe
o: Example Corporation
  9. エージェントサービスページを開き、要求を承認します。
  10. 証明書の発行時に、発行先名を確認します。証明書には、サブジェクト名に新しい属性値が表示されるはずです。
13.2.3.9.2. DER エンコード順序の変更
異なるクライアントが異なるエンコーディングをサポートしているため、DirectoryString の DER エンコーディングの順序を変更して、文字列を設定できます。
DirectoryString の DER-エンコーディング順序を変更する構文は以下の通りです。 
X500Name.directoryStringEncodingOrder=encoding_list_separated_by_commas
エンコーディング値は以下のとおりです。
  • PrintableString
  • IA5String
  • UniversalString
  • BMPString
  • UTF8String
たとえば、DER エンコーディング順序は次のようになります。 
X500Name.directoryStringEncodingOrder=PrintableString,BMPString
DirectoryString エンコーディングを変更するには、以下を行います。
  1. Certificate Manager を停止します。 
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
  2. /var/lib/pki/cs_instance/conf/ ディレクトリーを開きます。
  3. CS.cfg 設定ファイルを開きます。
  4. 設定ファイルにエンコーディング順序を追加します。
    たとえば、PrintableString と UniversalString の 2 つのエンコーディング値を指定し、エンコーディング順序が最初に PrintableString、次に UniversalString を指定するには、設定ファイルの最後に以下の行を追加します。 
    X500Name.directoryStringEncodingOrder=PrintableString,UniversalString
  5. 変更を保存して、ファイルを閉じます。
  6. Certificate Manager を開始します。 
    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
  7. エンコーディングの順序が有効であることを確認するには、手動登録フォームを使用して証明書を登録します。cn には John_Doe を使用します。
  8. エージェントサービスページを開き、要求を承認します。
  9. 証明書が発行されたら、dumpasn1 ツールを使用して証明書のエンコーディングを検証します。
    サブジェクト名の cn コンポーネントは、UniversalString としてエンコードする必要があります。
  10. cn に John Smith を使用して新しい要求を作成して提出します。
    サブジェクト名の cn コンポーネントは、PrintableString としてエンコードする必要があります。

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

Certificate Manager は、証明書および証明書失効リスト (CRL) の署名に OCSP 署名証明書に対応するキーペアを使用します。別のキーペアを使用して Certificate Manager が生成する CRL に署名するには、CRL 署名証明書を作成できます。Certificate Manager の CRL 署名証明書は、署名するか、または自己発行する必要があります。
Certificate Manager が異なるキーペアで CRL に署名できるようにするには、以下を行います。
  1. Certificate Manager の CRL 署名証明書を要求します。
    または、次のようなキーペアを生成できるツールを使用します。たとえば、certutil ツールを使用してキーペアを生成し、キーペアの証明書を要求し、Certificate Manager の証明書データベースに証明書をインストールします。certutil ツールの詳細は http://www.mozilla.org/projects/security/pki/nss/tools/ を参照してください。
  2. 証明書要求を作成したら、Certificate Manager エンドページを介して証明書を送信し、Manual OCSP Manager Signing Certificate registration プロファイルなどの適切なプロファイルを選択します。このページには、次の形式の URL が含まれます。 
    		https://hostname:port/ca/ee/ca
  3. 要求が送信されたら、エージェントサービスページにログインします。
  4. 必要な拡張機能について要求を確認します。CRL 署名証明書には、crlSigning ビットが設定された キー使用法 拡張が含まれている必要があります。
  5. 要求を承認します。
  6. CRL 署名証明書が生成されたら、コンソールの システムキーおよび証明書 を使用して、Certificate Manager のデータベースに証明書をインストールします。
  7. Certificate Manager を停止します。 
    # systemctl stop pki-tomcatd@instance_name.service
  8. Certificate Manager の設定を更新して、新しいキーペアと証明書を認識します。
    1. Certificate Manager インスタンス設定ディレクトリーに移動します。 
      # cd /var/lib/pki/instance-name/ca/conf/
    2. CS.cfg ファイルを開き、以下の行を追加します。 
      ca.crl_signing.cacertnickname=nickname cert-instance_ID
ca.crl_signing.defaultSigningAlgorithm=signing_algorithm
ca.crl_signing.tokenname=token_name
      ニックネーム は、CRL 署名証明書に割り当てられた名前です。
      instance_ID は、Certificate Manager インスタンスの名前です。
      インストールされた CA が RSA ベースの CA の場合には、signing_algorithm は SHA256withRSA、SHA384withRSA または SHA512withRSA になります。インストールされている CA が EC ベースの CA の場合、signing_algorithm は SHA256withEC、SHA384withEC、SHA512withEC になります。
      token_name は、キーペアの生成に使用されるトークンの名前と証明書です。内部/ソフトウェアトークンを使用する場合は、内部キーストレージトークン を値として使用します。
      たとえば、エントリーは以下のようになります。 
      ca.crl_signing.cacertnickname=crlSigningCert cert-pki-ca
ca.crl_signing.defaultSigningAlgorithm=SHAMD512withRSA
ca.crl_signing.tokenname=Internal Key Storage Token
    3. 変更を保存して、ファイルを閉じます。
  9. Certificate Manager を再起動します。 
    # systemctl restart pki-tomcatd@instance_name.service
    これで、Certificate Manager は CRL 署名証明書を使用して、生成した CRL に署名できるようになりました。

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

CRL キャッシュは、メモリーに保持されている失効情報のコレクションから証明書失効情報を取得できるようにする単純なメカニズムです。最適なパフォーマンスを得るには、すでにデフォルトの動作を表すこの機能を有効にすることが推奨されます。次の設定情報 (デフォルト) は、情報提供の目的で、または変更が必要な場合に表示されます。
  1. 認証局サーバーを停止します。 
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
  2. CA 設定ディレクトリーを開きます。 
    # cd /var/lib/instance_name/conf/
  3. CS.cfg ファイルを編集して、enableCRLCache パラメーターおよび enableCacheRecovery パラメーターを true に設定します。 
    ca.crl.MasterCRL.enableCRLCache=true
ca.crl.MasterCRL.enableCacheRecovery=true
  4. CA サーバーを起動します。 
    # systemctl start pki-tomcatd-nuxwdog@instance_name.service

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

以下では、CRL システムを柔軟に設定して目的の動作を反映する方法について説明します。ゴールは、2 種類のスケジュールに応じて CRL 更新を設定することが目的です。1 つのタイプは明示的な時間のリストを許可し、もう 1 つのタイプは更新間の時間間隔の長さで設定されます。また、共にドリフトを考慮して考慮できるハイブリッドシナリオもあります。以下の注記のエントリーは、実際にボックスシナリオのデフォルトを示しています。
デフォルトのシナリオは以下のとおりです。 
ca.crl.MasterCRL.updateSchema=3
ca.crl.MasterCRL.enableDailyUpdates=true
ca.crl.MasterCRL.enableUpdateInterval=true
ca.crl.MasterCRL.autoUpdateInterval=240
ca.crl.MasterCRL.dailyUpdates=1:00
ca.crl.MasterCRL.nextUpdateGracePeriod=0
より詳細で具体的な更新スケジュールが必要な場合にのみ、これから逸脱してください。残りのセクションでは、その実行方法を示します。
CS.cfg ファイルで完全な CRL および delta CRL の設定を行うには、パラメーターを編集する必要があります。
表13.9 CRL 拡張間隔パラメーター
パラメーター 説明 許可される値
updateSchema 完全な CRL ごとに生成されるデルタ CRL 数の比率を設定します。 整数値
enableDailyUpdates 設定された時間に基づいて CRL 更新の設定を有効または無効にします。 true または false
enableUpdateInterval 設定された間隔に基づいて CRL 更新の設定を有効または無効にします。 true または false
dailyUpdates CRL の更新時間を設定します。 コンマ区切りの時間リスト
autoUpdateInterval CRL を更新する間隔を分単位で設定します。 整数値
nextUpdateGracePeriod CRL の有効期間に分単位を追加し、公開またはレプリケーション期間全体で CRL が有効である状態にする期間を追加します。 整数値
refreshInSec クローン OCSP のスレッドの周期を秒単位で設定して、LDAP で CRL の更新を確認します。 整数値

手順13.1 CS.cfg での CRL 更新間隔の設定方法

  1. 認証局サーバーを停止します。 
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
  2. CA 設定ディレクトリーに移動します。 
    # cd /var/lib/instance_name/conf/
  3. CS.cfg ファイルを編集し、次の行を追加して更新間隔を設定します。 
    ca.crl.MasterCRL.updateSchema=3
    デフォルトの間隔は 1 です。これは、CRL が生成されるたびに完全な CRL が生成されることを意味します。updateSchema の間隔は、任意の整数に設定できます。
  4. 周期的な間隔を指定するか、更新を実行する時間を設定して、更新頻度を設定します。
    • enableDailyUpdates パラメーターを有効にして設定する時間を指定し、dailyUpdates パラメーターに希望する時間を追加します。 
      ca.crl.MasterCRL.enableDailyUpdates=true
	ca.crl.MasterCRL.enableUpdateInterval=false
	ca.crl.MasterCRL.dailyUpdates=0:50,04:55,06:55
      このフィールドは、CRL を更新する必要がある毎日の時間を設定します。複数回指定するには、01:50,04:55,06:55 などのコンマ区切りリストを入力します。複数日のスケジュールを入力するには、コンマ区切りのリストを入力して同じ日の時間を設定し、セミコロンで区切ったリストを入力して異なる日の時間を識別します。たとえば、01:50,04:55,06:55;02:00,05:00,17:00 を設定して、サイクルの 1 日目の 午前 1:50、4:55、および 6:55、そして 2 日目の午前 2:00、5:00、および午後 5:00 に失効を設定します。
      enableUpdateInterval パラメーターを有効にして間隔を指定し、autoUpdateInterval パラメーターに必要な間隔を分単位で追加します。 
      ca.crl.MasterCRL.enableDailyUpdates=false
	ca.crl.MasterCRL.enableUpdateInterval=true
	ca.crl.MasterCRL.autoUpdateInterval=240
  5. 環境に応じて以下のパラメーターを設定します。
    • OCSP サブシステムなしで CA を実行する場合は、以下を設定します。 
      ca.crl.MasterCRL.nextUpdateGracePeriod=0
    • OCSP サブシステムで CA を実行する場合は、以下を設定します。 
      ca.crl.MasterCRL.nextUpdateGracePeriod=time_in_minutes
      ca.crl.MasterCRL.nextUpdateGracePeriod パラメーターは時間 (分単位) を定義します。この値は、CA が新しい CRL を OCSP に伝播するのに十分な大きさである必要があります。パラメーターをゼロ以外の値に設定する必要があります。
      お使いの環境に OCSP クローンが追加されている場合は、以下も設定します。 
      ocsp.store.defStore.refreshInSec=time_in_seconds
      ocsp.store.defStore.refreshInSec パラメーターは、マスター OCSP インスタンスからの LDAP レプリケーション更新を使用して、クローン OCSP インスタンスが CRL 更新に通知する頻度を秒単位で設定します。
    パラメーターの詳細は、表13.9「CRL 拡張間隔パラメーター」を参照してください。
  6. CA サーバーを起動します。 
    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
注記
間隔ごとに CRL を更新するとドリフトが発生する場合があります。通常、ドリフトは手動更新と CA の再起動時に実行されます。
ドリフトのスケジュールを防ぐには、enableDailyUpdates パラメーターと enableUpdateInterval パラメーターを true に設定し、必要な値を autoUpdateInterval および dailyUpdates に追加します。 
ca.crl.MasterCRL.enableDailyUpdates=true
ca.crl.MasterCRL.enableUpdateInterval=true
ca.crl.MasterCRL.autoUpdateInterval=240
ca.crl.MasterCRL.dailyUpdates=1:00
間隔別に CRL を更新する場合は、dailyUpdates 値を 1 つだけ受け入れます。
間隔を更新すると、24 時間ごとに dailyUpdates の値と再同期され、スケジュールのドリフトを防ぐことができます。

13.2.3.13. サブシステムのアクセス制御設定の変更

デフォルトでは、アクセス制御ルールは最初に拒否ルールを評価してから、許可ルールを評価することで適用されます。この順序を変更するには、CS.cfg の authz.evaluateOrder パラメーターを変更します。 
authz.evaluateOrder=deny,allow
さらに、アクセス制御ルールは、ローカルの web.xml ファイル (基本 ACL) から評価することも、LDAP データベースを確認すると、より複雑な ACL にアクセスすることもできます。authz.sourceType パラメーターは、使用する承認のタイプを特定します。 
authz.sourceType=web.xml
注記
CS.cfg ファイルの編集後には、更新された設定を読み込むためにサブシステムを常に再起動します。

13.2.3.14. リクエスト番号とシリアル番号の範囲の設定

クローンシステムでランダムなシリアル番号を使用しない場合、管理者は /etc/pki/instance_name/subsystem/CS.cfg ファイルで、リクエストおよびシリアル番号に Certificate System が使用する範囲を指定できます。 
dbs.beginRequestNumber=1001001007001
			dbs.endRequestNumber=11001001007000
			dbs.requestIncrement=10000000000000
			dbs.requestLowWaterMark=2000000000000
			dbs.requestCloneTransferNumber=10000
			dbs.requestDN=ou=ca, ou=requests
			dbs.requestRangeDN=ou=requests, ou=ranges
			dbs.beginSerialNumber=1001001007001
			dbs.endSerialNumber=11001001007000
			dbs.serialIncrement=10000000000000
			dbs.serialLowWaterMark=2000000000000
			dbs.serialCloneTransferNumber=10000
			dbs.serialDN=ou=certificateRepository, ou=ca
			dbs.serialRangeDN=ou=certificateRepository, ou=ranges
			dbs.beginReplicaNumber=1
			dbs.endReplicaNumber=100
			dbs.replicaIncrement=100
			dbs.replicaLowWaterMark=20
			dbs.replicaCloneTransferNumber=5
			dbs.replicaDN=ou=replica
			dbs.replicaRangeDN=ou=replica, ou=ranges
			dbs.ldap=internaldb
			dbs.newSchemaEntryAdded=true
注記
Certificate System は、範囲で BigInteger の値をサポートします。

13.2.3.15. TLS クライアント証明書認証を使用するための pkiconsole 要件の設定

各サブシステムの CS.cfg ファイルを編集し、authType パラメーターを検索して、以下のように設定します。 
authType=sslclientauth
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.