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

9.2. CS.cfg ファイル

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

9.2.1. CS.cfg ファイルの検索
リンクのコピー

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

9.2.2. 設定ファイルの編集
リンクのコピー

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

9.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
Copy to Clipboard Toggle word wrap
CS.cfg ファイルでは、パラメーターブロックの多くに pound (#)文字でコメントアウトされた説明的なコメントがあります。コメント、空白行、不明なパラメーター、またはスペルミスのパラメーターはサーバーによって無視されます。
注記
TPS のバグにより、CS.cfg ファイルでコメントアウトされている行を無視するのを防ぎます。TPS CS.cfg ファイルの行をコメントアウトするのではなく、それらの行を削除するだけです。
インスタンスの同じ領域を設定するパラメーターは、同じブロックにグループ化される傾向があります。

例9.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/pki-tomcat/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
Copy to Clipboard Toggle word wrap
機能の一部は、サブシステムにアクセスするためにセルフテスト、ジョブ、認可などのプラグインを使用して実装されます。これらのパラメーターの場合、プラグインインスタンスには、一意の識別子 (サブシステムに対して呼び出される同じプラグインのインスタンスが複数存在する可能性があるため)、実装プラグイン名、および Java クラスがあります。

例9.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
Copy to Clipboard Toggle word wrap
注記
設定パラメーターの値を適切にフォーマットする必要があるため、2 つのルールを考慮する必要があります。
  • ローカライズする必要のある値は、UTF8 文字である必要があります。
  • CS.cfg ファイルは、パラメーター値のスラッシュ(/)をサポートします。値にバックスラッシュ (\) が必要な場合は、スラッシュでエスケープする必要があります。つまり、2 つのバックスラッシュを続けて使用する必要があります。
以下のセクションでは、CS.cfg ファイル設定およびパラメーターのスナップショットです。これらは完全な参照または CS.cfg ファイルパラメーターの例ではありません。また、各サブシステム設定ファイルで利用可能なパラメーターと使用されるパラメーターは異なりますが、類似しています。

9.2.3.1. CA の基本インスタンスパラメーター: pkispawn ファイル ca.cfg
リンクのコピー

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

例9.3 CA の基本的なインスタンスパラメーター

[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
Copy to Clipboard Toggle word wrap
重要
ポート設定などの情報は CS.cfg ファイルに 含ま れますが、CS.cfg には 設定 されません。サーバー設定は server.xml ファイルに設定されます。
CS.cfg および server.xml のポートは、稼働中の RHCS インスタンスと一致している 必要があり ます。

9.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-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
Copy to Clipboard Toggle word wrap
これらのパラメーターとその値の詳細は、「証明書システムログの設定」を参照してください。監査ログが有効になっている限り、これらの値はコンプライアンスには影響しません。

9.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
Copy to Clipboard Toggle word wrap
一部の認証設定では、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
Copy to Clipboard Toggle word wrap
LDAP のセキュアな設定とパラメーターの説明は、「TLS クライアント認証の有効化」 を参照してください。パラメーターパスは表示される内容とは異なりますが、両方の場所で同じ名前と値が許可されます。
CA は、ユーザーリクエストの承認メカニズムも必要です。これは、承認の設定と同様に、適切な認証プラグインを特定し、そのためにインスタンスを設定して行います。 
auths.impl.AgentCertAuth.class=com.netscape.cms.authentication.AgentCertAuthentication
auths.instance.AgentCertAuth.agentGroup=Certificate Manager Agents
auths.instance.AgentCertAuth.pluginName=AgentCertAuth
Copy to Clipboard Toggle word wrap

9.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
Copy to Clipboard Toggle word wrap

9.2.3.5. 必要なサブシステムの設定
リンクのコピー

少なくとも、各サブシステムは CA に依存するため、CA (およびその他の必要なサブシステム) をサブシステムの設定で設定する必要があります。別のサブシステムへの接続の前に conn. を付けてから、サブシステムのタイプと番号が付けられます。 
conn.ca1.clientNickname=subsystemCert cert-pki-tps
conn.ca1.hostadminport=server.example.com:9445
conn.ca1.hostagentport=server.example.com:9444
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
Copy to Clipboard Toggle word wrap

9.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
Copy to Clipboard Toggle word wrap
LDAP のセキュアな設定とパラメーターの説明は、「TLS クライアント認証の有効化」を参照してください。「TLS クライアント認証の有効化」 の一部として行われること以外に追加の設定は必要ありません。

9.2.3.7. キューの有効化および設定
リンクのコピー

CS.cfg ファイルを編集してパブリッシュキューを有効にすると、管理者はパブリッシュ操作に使用するスレッドの数やキューページサイズなど、パブリッシュする他のオプションを設定できます。
  1. 設定ファイルを編集できるように CA サーバーを停止します。 
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  2. CA の CS.cfg ファイルを開きます。 
    vim /var/lib/pki/instance_name/ca/conf/CS.cfg
    Copy to Clipboard Toggle word wrap
  3. ca.publish.queue.enable を true に設定します。パラメーターが存在しない場合は、パラメーターで行を追加します。 
    ca.publish.queue.enable=true
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    ヒント
    ca.publish.queue.enable を false に設定し、ca.publish.queue.maxNumberOfThreads を 0 に設定すると、公開キューと、発行した証明書の公開に別のスレッドが使用されます。
  5. CA サーバーを起動します。 
    systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

9.2.3.8. PKI タスクの設定
リンクのコピー

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

9.2.3.9. CA 発行証明書の DN 属性の変更
リンクのコピー

Certificate System が発行した証明書で、DN は証明書を所有するエンティティーを特定します。いずれの場合も、Certificate System が Directory Server に接続されている場合、証明書内の DN の形式はディレクトリー内の DN の形式と一致する必要があります。名前が完全に一致する必要はありません。証明書マッピングにより、証明書のサブジェクト DN をディレクトリー内の DN とは異なるものにすることができます。
Certificate System の DN は、X.509 標準で定義されたコンポーネントまたは属性に基づいています。表9.8「値タイプに許可される文字」 は、デフォルトでサポートされる属性を一覧表示しています。属性のセットは拡張可能です。
Expand
表9.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 は、表9.8「値タイプに許可される文字」. で特定される属性に対応します。サポートされる属性の一覧は、新しい属性を作成または追加することで拡張できます。X.500Name 属性またはコンポーネントを追加する構文は次のとおりです。 
X500Name.NEW_ATTRNAME.oid=n.n.n.n
X500Name.NEW_ATTRNAME.class=string_to_DER_value_converter_class
Copy to Clipboard Toggle word wrap
値コンバータークラスは文字列を 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 は、最小の文字セットから最大の文字セットへ、以下の順序で文字列文字を文字ごとに変換します。
    • 印刷可能
    • IA5String
    • BMPString
    • 汎用文字列
属性エントリーは、以下のようになります。 
X500Name.MY_ATTR.oid=1.2.3.4.5.6
X500Name.MY_ATTR.class=netscape.security.x509.DirStrConverter
Copy to Clipboard Toggle word wrap
9.2.3.9.1. 新規属性またはカスタム属性の追加
リンクのコピー
Certificate System スキーマに新規またはプロプライエタリー属性を追加するには、以下を行います。
  1. Certificate Manager を停止します。 
    systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  5. 変更を保存して、ファイルを閉じます。
  6. Certificate Manager を再起動します。 
    systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  7. 登録ページを再読み込みして変更を確認します。フォームに新しい属性が表示されるはずです。
  8. 新しい属性が有効になっていることを確認するには、手動登録フォームを使用して証明書を要求します。
    新しい属性に値を入力します。これにより、証明書のサブジェクト名に表示されることを確認できます。たとえば、以下の値を入力して、新しい属性の値を入力し、サブジェクト名で確認します。 
    MYATTR1: a_value
MYATTR2: a.Value
MYATTR3: aValue
cn: John Doe
o: Example Corporation
    Copy to Clipboard Toggle word wrap
  9. エージェントサービスページを開き、要求を承認します。
  10. 証明書の発行時に、発行先名を確認します。証明書には、サブジェクト名に新しい属性値が表示されるはずです。
9.2.3.9.2. DER エンコード順序の変更
リンクのコピー
DirectoryString の DER エンコーディング順序を変更して、異なるクライアントが異なるエンコーディングをサポートしているため、文字列を設定できます。
DirectoryString の DER エンコーディング順序を変更する構文は次のとおりです。 
X500Name.directoryStringEncodingOrder=encoding_list_separated_by_commas
Copy to Clipboard Toggle word wrap
エンコーディング値は以下のとおりです。
  • 印刷可能
  • IA5String
  • UniversalString
  • BMPString
  • UTF8String
たとえば、DER エンコーディング順序は次のようになります。 
X500Name.directoryStringEncodingOrder=Printable,BMPString
Copy to Clipboard Toggle word wrap
DirectoryString エンコーディングを変更するには、以下を実行します。
  1. Certificate Manager を停止します。 
    systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  2. /var/lib/pki/cs_instance/conf/ ディレクトリーを開きます。
  3. CS.cfg 設定ファイルを開きます。
  4. 設定ファイルにエンコーディング順序を追加します。
    たとえば、PrintableString と UniversalString の 2 つのエンコーディング値を指定し、エンコーディング順序が最初に PrintableString、次に UniversalString を指定するには、設定ファイルの最後に以下の行を追加します。 
    X500Name.directoryStringEncodingOrder=PrintableString, UniversalString
    Copy to Clipboard Toggle word wrap
  5. 変更を保存して、ファイルを閉じます。
  6. Certificate Manager を開始します。 
    systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  7. エンコーディングの順序が有効であることを確認するには、手動登録フォームを使用して証明書を登録します。cn には John_Doe を使用します。
  8. エージェントサービスページを開き、要求を承認します。
  9. 証明書が発行されたら、dumpasn1 ツールを使用して証明書のエンコーディングを検証します。
    サブジェクト名の cn コンポーネントは UniversalString としてエンコードする必要があります。
  10. cn に John Smith を使用して新しいリクエストを作成して提出します。
    サブジェクト名の cn コンポーネントは、PrintableString としてエンコードする必要があります。

9.2.3.10. 異なる証明書を使用するように CA を設定して CRL を署名
リンクのコピー

Certificate Manager は、証明書および証明書失効リスト (CRL) の署名に OCSP 署名証明書に対応するキーペアを使用します。別のキーペアを使用して Certificate Manager が生成する CRL に署名するには、CRL 署名証明書を作成できます。Certificate Manager の CRL 署名証明書は、署名するか、または自己発行する必要があります。
Certificate Manager が異なるキーペアで CRL に署名できるようにするには、以下を行います。
  1. CMC を使用して、Certificate Manager の CRL 署名証明書を要求してインストールします。システム証明書の要求の詳細については、5.3.2.1 を参照してください。システム証明書とサーバー証明書の取得 (Red Hat Certificate System の管理ガイド)。
    証明書の取得に使用されるプロファイルは keyUsageExtDefaultImpl クラス ID を使用し、対応する keyUsageCrlSign パラメーターを true に設定する必要があります。 
    policyset.userCertSet.6.default.class_id=keyUsageExtDefaultImpl
policyset.userCertSet.6.default.params.keyUsageCrlSign=true
    Copy to Clipboard Toggle word wrap
  2. CRL 署名証明書が生成されたら、コンソールの システムキーおよび証明書 を使用して、Certificate Manager のデータベースに証明書をインストールします。
  3. Certificate Manager を停止します。 
    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
  4. Certificate Manager の設定を更新して、新しいキーペアと証明書を認識します。
    1. Certificate Manager インスタンス設定ディレクトリーに移動します。 
      ]# cd /var/lib/pki/instance_name/ca/conf/
      Copy to Clipboard Toggle word wrap
    2. CS.cfg ファイルを開き、以下の行を追加します。 
      ca.crl_signing.cacertnickname=nickname cert-instance_ID
ca.crl_signing.defaultSigningAlgorithm=signing_algorithm
ca.crl_signing.tokenname=token_name
      Copy to Clipboard Toggle word wrap
      ニックネーム は、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
      Copy to Clipboard Toggle word wrap
    3. 変更を保存して、ファイルを閉じます。
  5. Certificate Manager を再起動します。 
    # systemctl restart pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap
    これで、Certificate Manager は CRL 署名証明書を使用して、生成した CRL に署名できるようになりました。

9.2.3.11. CS.cfg のキャッシュからの CRL 生成の設定
リンクのコピー

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

9.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
Copy to Clipboard Toggle word wrap
より詳細で具体的な更新スケジュールが必要な場合にのみ、これから逸脱してください。残りのセクションでは、その実行方法を示します。
CS.cfg ファイルで完全な CRL およびデルタ CRL の設定を行うには、パラメーターを編集する必要があります。
Expand
表9.9 CRL 拡張間隔パラメーター
パラメーター 説明 許可される値
updateSchema 完全な CRL ごとに生成されるデルタ CRL 数の比率を設定します。 整数値
enableDailyUpdates 設定された時間に基づいて CRL 更新の設定を有効または無効にします。 true または false
enableUpdateInterval 設定された間隔に基づいて CRL 更新の設定を有効または無効にします。 true または false
dailyUpdates CRL の更新時間を設定します。 コンマ区切りの時間リスト
autoUpdateInterval CRL を更新する間隔を分単位で設定します。 整数値
nextUpdateGracePeriod CRL の有効期間に分単位を追加し、公開またはレプリケーション期間全体で CRL が有効である状態にする期間を追加します。 整数値
refreshInSec クローン OCSP のスレッドの周期を秒単位で設定して、LDAP で CRL の更新を確認します。 整数値

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

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

9.2.3.13. サブシステムのアクセス制御設定の変更
リンクのコピー

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

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

各サブシステムの CS.cfg ファイルを編集し、authType パラメーターを検索し、以下のように設定します。 
authType=sslclientauth
Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat