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

13.2. CS.cfg ファイル

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

以下に例を示します。 

/var/lib/pki/ instance_name/ca/conf
Copy to Clipboard Toggle word wrap

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

警告

設定パラメーターに精通していない場合や、変更がサーバーに許容されていることを認識せずに、設定ファイルを直接編集しないでください。設定ファイルが正しく変更されていないと、Certificate System は起動に失敗します。設定が間違っていると、データが失われる可能性があります。

CS.cfg ファイルを変更するには、以下の手順に従います。

  1. サブシステムインスタンスを停止します。 

    # pki-server stop instance_name
    Copy to Clipboard Toggle word wrap

    または (nuxwdog watchdog を使用している場合) 

    # systemctl stop pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

    設定ファイルは、インスタンスの起動時にキャッシュに保存されます。コンソールを介してインスタンスに加えた変更は、ファイルのキャッシュバージョンに変更されます。サーバーが停止または再起動されると、キャッシュに保存されている設定ファイルがディスクに書き込まれます。設定ファイルを編集する前にサーバーを停止すると、サーバーが停止するとキャッシュバージョンの変更が上書きされます。

  2. /var/lib/pki/ instance_name/subsystem_type/conf ディレクトリーを開きます。
  3. テキストエディターで CS.cfg ファイルを開きます。
  4. ファイル内のパラメーターを編集して、変更を保存します。

  5. サブシステムインスタンスを開始します。 

    # pki-server start instance_name
    Copy to Clipboard Toggle word wrap

    または (nuxwdog watchdog を使用している場合) 

    # systemctl start pki-tomcatd-nuxwdog@instance_name.service
    Copy to Clipboard Toggle word wrap

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

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

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

設定パラメーターの値を適切にフォーマットする必要があるため、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
Copy to Clipboard Toggle word wrap
重要

ポート設定などの情報は CS.cfg ファイルに 含まれ ますが、CS.cfg には 設定 されません。サーバー設定が server.xml ファイルに設定されます。

CS.cfg および server.xml のポートは、稼働中の RHCS インスタンスと一致している 必要があります。

13.2.3.2. Logging settings
リンクのコピー

サブシステムのタイプによって、設定可能なログにはいくつかのタイプがあります。各タイプのログには、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/lib/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
Copy to Clipboard Toggle word wrap

これらのパラメーターとその値の詳細は、「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
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 のセキュアな設定とパラメーターの説明は、「CS から DS への 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

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

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

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

LDAP のセキュアな設定とパラメーターの説明は、「CS から DS への TLS 相互認証を有効にする」 を参照してください。「CS から DS への TLS 相互認証を有効にする」 の一部として行われること以外に追加の設定は必要ありません。

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

登録プロセスには、発行した証明書をディレクトリーまたはファイルに公開します。したがって、基本的には、最初の証明書要求を閉じます。ただし、外部ネットワークに証明書を公開すると、発行プロセスが大幅に遅くなり、リクエストが開いたままになります。

この状況を回避するために、管理者は 公開キュー を有効にできます。パブリッシュキューは、別のリクエストキューを使用するリクエスト操作および登録操作 (外部の LDAP ディレクトリーを伴う可能性がある) を分離します。要求キューはすぐに更新され、登録プロセスが完了したことを示します。一方、公開キューがネットワークトラフィックの一時停止時に情報を送信します。

公開キューは、承認された証明書ごとに新しいスレッドを開くのではなく、生成された証明書を公開する定義済みの制限された数のスレッドを設定します。

パブリッシュキューはデフォルトで無効になっています。公開を有効にするとともに、CA コンソールで有効にすることができます。

注記

パブリッシュキューはデフォルトで無効になっていますが、コンソールで LDAP 公開が有効な場合にはキューが自動的に有効になります。それ以外の場合は、キューを手動で有効にできます。

図13.1 公開キューの有効化

公開キュー
13.2.3.7.1. CS.cfg ファイルを編集して公開キューを有効化および設定する
リンクのコピー

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

13.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 は、さまざまな鍵セットの鍵情報を設定します。

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

Certificate System が発行した証明書で、DN は証明書を所有するエンティティーを特定します。いずれの場合も、Certificate System が Directory Server に接続されている場合、証明書内の DN の形式はディレクトリー内の DN の形式と一致する必要があります。名前が完全に一致する必要はありません。証明書マッピングにより、証明書のサブジェクト DN をディレクトリー内の DN とは異なるものにすることができます。

Certificate System の DN は、X.509 標準で定義されたコンポーネントまたは属性に基づいています。表13.8「値タイプに許可される文字」 は、デフォルトでサポートされる属性をリスト表示しています。属性のセットは拡張可能です。

Expand
表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
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 は、最小の文字セットから最大の文字セットへ、次の順序で文字列を文字ごとに変換します。

    • PrintableString
    • 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
13.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. 証明書の発行時に、発行先名を確認します。証明書には、サブジェクト名に新しい属性値が表示されるはずです。
13.2.3.9.2. DER エンコード順序の変更
リンクのコピー

異なるクライアントが異なるエンコーディングをサポートしているため、DirectoryString の DER エンコーディングの順序を変更して、文字列を設定できます。

DirectoryString の DER エンコーディング順序を変更する構文は以下の通りです。 

X500Name.directoryStringEncodingOrder=encoding_list_separated_by_commas
Copy to Clipboard Toggle word wrap

エンコーディング値は以下のとおりです。

  • PrintableString
  • IA5String
  • UniversalString
  • BMPString
  • UTF8String

たとえば、DER エンコーディング順序は次のようになります。 

X500Name.directoryStringEncodingOrder=PrintableString,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 としてエンコードする必要があります。

13.2.3.10. CRL の署名に各種証明書を使用するための CA 設定
リンクのコピー

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 Enrollment" プロファイルなどの適切なプロファイルを選択します。このページには、次の形式の URL が含まれます。 

    https://hostname:port/ca/ee/ca
    Copy to Clipboard Toggle word wrap
  3. 要求が送信されたら、エージェントサービスページにログインします。
  4. 必要な拡張機能に関する要求を確認します。CRL 署名証明書には、crlSigning ビットが設定された Key Usage 拡張が含まれている必要があります。
  5. 要求を承認します。
  6. CRL 署名証明書が生成されたら、コンソールの システムキーおよび証明書 を使用して、Certificate Manager のデータベースに証明書をインストールします。

  7. Certificate Manager を停止します。 

    # pki-server stop instance_name
    Copy to Clipboard Toggle word wrap

  8. 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 は、キーペアの生成に使用されるトークンの名前と証明書です。内部/ソフトウェアトークンを使用する場合は、Internal Key Storage Token を値として使用します。

      たとえば、エントリーは以下のようになります。 

      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. 変更を保存して、ファイルを閉じます。

  9. Certificate Manager を再起動します。 

    # pki-server restart instance_name
    Copy to Clipboard Toggle word wrap

    これで、Certificate Manager は CRL 署名証明書を使用して、生成した CRL に署名できるようになりました。

13.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

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

より詳細で具体的な更新スケジュールが必要な場合にのみ、これから逸脱してください。残りのセクションでは、その実行方法を示します。

CS.cfg ファイルで完全な CRL および delta CRL の設定を行うには、パラメーターを編集する必要があります。

Expand
表13.9 CRL 拡張間隔パラメーター
パラメーター説明許可される値

updateSchema

完全な CRL ごとに生成されるデルタ CRL 数の比率を設定します。

整数値

enableDailyUpdates

設定された時間に基づいて CRL 更新の設定を有効または無効にします。

true または false

enableUpdateInterval

設定された間隔に基づいて CRL 更新の設定を有効または無効にします。

true または false

dailyUpdates

CRL の更新時間を設定します。

コンマ区切りの時間リスト

autoUpdateInterval

CRL を更新する間隔を分単位で設定します。

整数値

autoUpdateInterval.effectiveAtStart

現在スケジュールされている nextUpdate の時刻を待つのではなく、システムが自動更新の新しい値をすぐに使用できるようにします

true または false

nextUpdateGracePeriod

CRL の有効期間に分単位を追加し、公開またはレプリケーション期間全体で CRL が有効である状態にする期間を追加します。

整数値

refreshInSec

クローン OCSP のスレッドの周期を秒単位で設定して、LDAP で CRL の更新を確認します。

整数値

重要

autoUpdateInterval.effectiveAtStart パラメーターでは、新しい値を適用するためにシステムを再起動する必要があります。このパラメーターのデフォルト値は false です。これは、自分が何をしているかを確信しているユーザーのみが変更する必要があります。

手順: 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: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
      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 更新に通知する頻度を秒単位で設定します。

      パラメーターの詳細は、表13.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 の値と再同期されます。

13.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 ファイルを編集したら、必ず更新された設定を読み込むためにサブシステムを再起動します。

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

注記

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

© 2026 Red Hatトップに戻る