7.5. インストール後のタスク

7.5.1. Red Hat Certificate System の日付/時刻の設定
リンクのコピー

RHCS を実行するための時間を正しく設定しておくことが重要です。Red Hat Certificate System 管理ガイド の日時の設定セクションを参照してください。

7.5.2. 実際の CA から発行された DS 証明書を取得する
リンクのコピー

実際の CA によって発行された DS 証明書を取得するには、pki CLI (man pki-client を実行) コマンドを使用してこのプロセスを実行します。

このセクションでは、localhost という名前の DS インスタンスがすでに存在していることを前提としています。

このセクションでは、次の 2 つの条件について説明します。

DS インスタンスにはまだ SSL サーバー証明書 (ブートストラップなど) がなく、ここで実際のサーバー証明書を作成する。
DS インスタンスにはブートストラップ SSL サーバー証明書があり、それを置き換える必要がある。

証明書を発行するために、実際の信頼済み CA が利用可能であることを前提としています。

7.5.2.1. CA 署名証明書のエクスポート
リンクのコピー

pki-server cert-export ca_signing --cert-file ca_signing.crt

7.5.2.2. DS サーバー証明書の作成
リンクのコピー

7.5.2.2.1. DS サーバーの CSR の生成
リンクのコピー

DS 管理者として、以下を実行します。

$ pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-request \
    --subject "CN=server.example.com" \
    --subjectAltName "critical, DNS:server.example.com" \
    --csr ds_server.csr

注記: 証明書のサブジェクト DN と SAN が、システムのホスト名と一致していることを確認してください。

7.5.2.2.2. DS サーバー証明書要求の送信:
リンクのコピー

DS 管理者として、以下を実行します。

$ pki ca-cert-request-submit --profile caServerCert --csr-file ds_server.csr

7.5.2.2.3. 証明書要求の承認:
リンクのコピー

PKI エージェントとして、以下を実行します。

$ pki -n caadmin ca-cert-request-approve <request ID>

7.5.2.3. 証明書の取得
リンクのコピー

DS 管理者ユーザーとして証明書を取得します。

$  pki ca-cert-export <certificate ID> --output-file ds_server.crt

7.5.2.4. DS インスタンスの停止
リンクのコピー

NSS データベースを変更する前に、DS インスタンスを停止します。

$ dsctl localhost stop

7.5.2.5. CA 署名証明書のインポート
リンクのコピー

DS 管理者として、CA 署名証明書を DS インスタンスの nssdb にインポートします。

# pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-import \
    --cert ca_signing.crt \
    --trust CT,C,C \
    "CA Signing Cert"

7.5.2.6. DS ブートストラップ証明書の削除
リンクのコピー

すでに boostrap DS 証明書がある場合は、それを削除します。

$ certutil -F -d /etc/dirsrv/slapd-localhost \
    -f /etc/dirsrv/slapd-localhost/pwdfile.txt \
    -n Server-Cert
$ certutil -D -d /etc/dirsrv/slapd-localhost \
    -f /etc/dirsrv/slapd-localhost/pwdfile.txt \
    -n Self-Signed-CA

7.5.2.7. DS サーバー証明書のインポート:
リンクのコピー

$ pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-import \
    --cert ds_server.crt \
    Server-Cert

DS サーバー証明書を検証するには、以下を実行します。

$ certutil -L -d /etc/dirsrv/slapd-localhost -n Server-Cert
...
    Certificate Trust Flags:
        SSL Flags:
            User
        Email Flags:
            User
        Object Signing Flags:
            User

7.5.2.8. SSL 接続の有効化
リンクのコピー

このセクションは、以前に DS で SSL を有効にしていない場合にのみ適用されます。

DS インスタンスで SSL 接続を有効にするには、以下を実行します。
```
$ dsconf localhost config replace nsslapd-security=on
```
DS インスタンスを起動します。
```
$ dsctl localhost start
```

SSL 接続を確認します。

$ LDAPTLS_REQCERT=never ldapsearch \
    -H ldaps://$HOSTNAME:636 \
    -x \
    -D "cn=Directory Manager" \
    -w Secret.123 \
    -b "" \
    -s base

7.5.2.9. PKI インスタンスから DS ブートストラップ署名証明書を削除する
リンクのコピー

DS ブートストラップ証明書を置き換える場合は、PKI 管理者として PKI を停止し、次のように PKI nssdb から DS ブートストラップ署名証明書を削除します。

$ certutil -F -d /var/lib/pki/pki-tomcat/conf/alias \
    -f /var/lib/pki/pki-tomcat/conf/alias/pwdfile.txt \
    -n ds_signing

PKI を起動します。

7.5.3. ブートストラップ証明書を使用して DS で SSL 接続を有効にする
リンクのコピー

すでにアクティブな信頼済み CA があり、DS のサーバー証明書を発行する必要がある場合は、このセクションを参照してください。

pki CLI (man pki-client を実行) コマンドを使用してこのプロセスを実行し、ブートストラップ DS 自己署名証明書とそれによって発行されるブートストラップサーバー証明書を作成して、DS で SSL 接続を有効にします。

このセクションでは、localhost という名前の DS インスタンスがすでに存在し、証明書がなく、SSL 接続が無効になっていることを前提としています。

注記: 新しい DS バージョンでは、証明書が作成され、SSL 接続がデフォルトで有効になっているため、通常はこの手順に従う必要はありません。

7.5.3.1. DS 署名証明書の作成
リンクのコピー

次のコマンドで DS 署名 CSR を生成します。

$ pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-request \
    --subject "CN=DS Signing Certificate" \
    --ext /usr/share/pki/server/certs/ca_signing.conf \
    --csr ds_signing.csr

DS 署名証明書を発行します。

$ pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-issue \
    --csr ds_signing.csr \
    --ext /usr/share/pki/server/certs/ca_signing.conf \
    --cert ds_signing.crt

DS 署名証明書をインポートします。

$ pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-import \
    --cert ds_signing.crt \
    --trust CT,C,C \
    Self-Signed-CA

DS 署名証明書を確認します。

$ certutil -L -d /etc/dirsrv/slapd-localhost -n Self-Signed-CA
...
    Certificate Trust Flags:
        SSL Flags:
            Valid CA
            Trusted CA
            User
            Trusted Client CA
        Email Flags:
            Valid CA
            Trusted CA
            User
        Object Signing Flags:
            Valid CA
            Trusted CA
            User

7.5.3.2. DS サーバー証明書の作成
リンクのコピー

次のコマンドで DS サーバーの CSR を生成します。

$ pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-request \
    --subject "CN=$HOSTNAME" \
    --subjectAltName "critical, DNS:$HOSTNAME" \
    --ext /usr/share/pki/server/certs/sslserver.conf \
    --csr ds_server.csr

DS サーバー証明書を発行します。

$ pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-issue \
    --issuer Self-Signed-CA \
    --csr ds_server.csr \
    --ext /usr/share/pki/server/certs/sslserver.conf \
    --cert ds_server.crt

DS サーバー証明書のインポート:

$ pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-import \
    --cert ds_server.crt \
    Server-Cert

DS サーバー証明書を確認します。

$ certutil -L -d /etc/dirsrv/slapd-localhost -n Server-Cert
...
    Certificate Trust Flags:
        SSL Flags:
            User
        Email Flags:
            User
        Object Signing Flags:
            User

7.5.3.3. SSL 接続の有効化
リンクのコピー

DS インスタンスで SSL 接続を有効にするには、以下を実行します。
```
$ dsconf localhost config replace nsslapd-security=on
```
DS インスタンスを再起動します。
```
$ dsctl localhost restart
```

SSL 接続を確認します。

$ LDAPTLS_REQCERT=never ldapsearch \
    -H ldaps://$HOSTNAME:636 \
    -x \
    -D "cn=Directory Manager" \
    -w Secret.123 \
    -b "" \
    -s base

7.5.3.4. 関連情報
リンクのコピー

7.5.4. CS から DS への TLS 相互認証を有効にする
リンクのコピー

注記

このセクションでは、ルート CA をインストールして実行する必要があります。ブートストラップ自己署名 LDAP サーバー証明書を使用している場合は、最初にそれを「実際の CA から発行された DS 証明書を取得する」のとおり置き換えます。以下の手順は、インストールの完了後に実行します。

TLS クライアント認証を有効にすることを選択した場合は、CS サブシステムのインストール時に基本的な TLS サーバー認証を設定して実行すると、逆戻りして、特定のサブシステムから LDAP サーバーへのクライアント認証の有効化を試みることができます。

クライアント認証の設定には 2 つの部分があります。最初の部分は、TLS の相互認証を必要とする LDAP ディレクトリーを設定します。この手順は、Red Hat Directory Server 管理ガイド の証明書ベースのクライアント認証の使用を参照してください。

以下の点に注意してください。

pkispawn は、すでに内部 Directory Server 上に pkidbuser を自動的に作成しており、そこにはアウトバウンド TLS クライアント認証に使用される CS "インスタンスのサブシステム証明書" (たとえば subsystemCert cert-pki-ca) がユーザーエントリーに格納されています。したがって、TLS クライアント認証用に別の LDAP ユーザーまたは別の証明書を作成する必要はありません。

/etc/dirsrv/slapd-instance_name/certmap.conf のコンテンツを作成する場合は、以下の形式を使用します。

certmap rhcs <certificate issuer DN>
		rhcs:CmapLdapAttr seeAlso
		rhcs:verifyCert on

以下に例を示します。

certmap rhcs CN=CA Signing Certificate,OU=pki-tomcat-ca,O=pki-tomcat-ca-SD
		rhcs:CmapLdapAttr seeAlso
		rhcs:verifyCert on

設定後に、Directory Server を再起動します。

2 番目の部分は、Red Hat Certificate System インスタンスに設定を追加して、TLS 相互認証を使用して内部 LDAP サーバーと通信するために使用するポートと証明書を認識できるようにすることです。これには、<instance directory>/<subsystem type>/conf/CS.cfg にある RHCS インスタンスの CS.cfg ファイルを編集する必要があります。たとえば、/var/lib/pki/ instance_name/ca/conf/CS.cfg です。

CS.cfg で、RHCS インスタンスのサブシステム証明書のニックネームを internaldb.ldapauth.clientCertNickname に追加し、未使用のエントリーを 2 つ削除します。

internaldb.ldapauth.bindDN
		internaldb.ldapauth.bindPWPrompt

以下に例を示します。

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

インストール後のステップの最後に CS インスタンスを再起動します。

注記

特定の LDAP インスタンスに合わせて、internaldb.basedn および internaldb.database パラメーターを設定する必要があります。

コンプライアンスのために、internaldb.ldapauth.authtype=SslClientAuth および internaldb.ldapconn.secureConn=true を設定する必要があり、internaldb.ldapauth.clientCertNickname の値は、NSS DB で LDAP に対して認証するには、TLS クライアント証明書のニックネームと一致させる必要があります。

その他の値はすべて、環境または可用性の要件を反映するために必要に応じて変更できます。

7.5.5. セッションタイムアウトの設定
リンクのコピー

さまざまなタイムアウト設定がシステムに存在し、終了前に TLS セッションがアイドル状態の意地する時間に影響を与える可能性があります。詳細は、「セッションタイムアウト」を参照してください。

7.5.6. CRL または証明書の公開
リンクのコピー

CRL 公開は、OCSP サービスを提供する際に重要です。証明書の公開は任意になりますが、多くの場合、サイトで必要になります。詳細は、Red Hat Certificate System 管理ガイド の証明書および CRL の公開セクションを参照してください。

7.5.7. 証明書登録プロファイル (CA) の設定
リンクのコピー

RHCS には、証明書登録プロファイルのカスタマイズを可能にするリッチプロファイルフレームワークがあります。システムで使用できるデフォルトのプロファイルを有効またはにしたり、既存のプロファイルを変更したり、独自のプロファイルを作成することが非常に一般的です。詳細は、15章証明書プロファイルの設定 を参照してください。

7.5.8. CRL 配布ポイントを使用した CA の登録プロファイル設定
リンクのコピー

必要なプロファイルを有効にして、CRL 配布ポイントを追加します。これらは、上記のセクションの設定に対応するプロファイルです。

/var/lib/pki/<ca instance directory/ca/profiles/ca/ ディレクトリーにある caCMCserverCertWithCRLDP.cfg プロファイル (RSA キーを使用した登録用) を開き、次のように更新します。

vi /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg
…
enable=true
…
policyset.serverCertSet.10.default.params.crlDistPointsPointName_0=http://rhcs10.example.com:8085/crl/ServerCertCRL.crl
…

/var/lib/pki/<ca instance directory/ca/profiles/ca/ ディレクトリーにある caCMCECserverCertWithCRLDP.cfg (ECC キーを使用した登録用) を開き、次のように更新します。

vi /var/lib/pki/rhcs10-ECC-RootCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg
…
enable=true
…
policyset.serverCertSet.10.default.params.crlDistPointsPointName_0=http://rhcs10.example.com:20085/crl/ServerCertCRL.crl
…

user:group の所有権を設定します。

chown -R pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg
chown -R pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg

CA の CS.cfg に新しいプロファイルを登録します。

各プロファイルに次の行を追加します。

profile.caCMCserverCertWithCRLDP.class_id=caEnrollImpl
profile.caCMCserverCertWithCRLDP.config=/var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg

profile.caCMCECserverCertWithCRLDP.class_id=caEnrollImpl
profile.caCMCECserverCertWithCRLDP.config=/var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg

profile.list エントリーを編集して、2 つの新しいプロファイルを追加します。例::

profile.list=caCMCserverCertWithCRLDP,caCMCECserverCertWithCRLDP,acmeServerCert,caCMCserverCert,caCMCECserverCert, …

7.5.9. CRL 配布ポイントのサポートを設定する
リンクのコピー

注記

CRL 配布ポイント、その必要性、最適な配置場所の詳細は、CA での自動失効チェックの有効化を参照してください。

CRL 配布ポイントのサポートを設定するために、例として、ファイルベースの CRL パブリッシャーと CRL のパーティショニングの設定方法を説明します。また、証明書登録プロファイルを有効化し、CRL 配布ポイント拡張機能を使用して証明書を発行する方法も説明します。最後に、CA の LDAP サーバーの一時的な Server-Cert を、CRL 配布ポイントプロファイルから発行された証明書に置き換える方法を説明します。

次の変更に進む前に、RootCA インスタンスを停止します。

pki-server stop rhcs10-RSA-RootCA

7.5.9.1. サーバー証明書 CRL ファイルの公開をサポートする CA セットアップ
リンクのコピー

注記

編集する前の設定ファイルのコピーを保存してから次に進んでください。

cp /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg  /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg.bak.<date>

7.5.9.1.1. ファイルベースのパブリッシャーを設定する: crlFilePublisher
リンクのコピー

このセクションの設定では、crlFilePublisher と呼ばれるファイルベースの CRL パブリッシャーが作成されます。正しく設定されている場合、CRL は /var/lib/pki/rhcs10-RSA-RootCA/crl ディレクトリーに DER 形式で保存されます。

ファイルベースのパーティション化された CRL を公開するための CRL ディレクトリーを作成します。
```
mkdir /var/lib/pki/rhcs10-RSA-RootCA/crl
chown pkiuser.pkiuser /var/lib/pki/rhcs10-RSA-RootCA/crl
```

CA の CS.cfg に以下を追加します。

ca.publish.publisher.instance.crlFilePublisher.Filename.b64=false
ca.publish.publisher.instance.crlFilePublisher.Filename.der=true
ca.publish.publisher.instance.crlFilePublisher.crlLinkExt=crl
ca.publish.publisher.instance.crlFilePublisher.directory=/var/lib/pki/rhcs10-RSA-RootCA/crl
ca.publish.publisher.instance.crlFilePublisher.latestCrlLink=true
ca.publish.publisher.instance.crlFilePublisher.maxAge=0
ca.publish.publisher.instance.crlFilePublisher.maxFullCRLs=0
ca.publish.publisher.instance.crlFilePublisher.pluginName=FileBasedPublisher
ca.publish.publisher.instance.crlFilePublisher.timeStamp=LocalTime
ca.publish.publisher.instance.crlFilePublisher.zipCRLs=false
ca.publish.publisher.instance.crlFilePublisher.zipLevel=9

7.5.9.1.2. ファイルベースの公開ルールを設定する: FileCrlRule
リンクのコピー

このセクションの設定では、FileCrlRule と呼ばれるファイルベースの公開ルールが作成されます。述語は、ServerCertCRL と呼ばれるパーティション化された CRL (プロファイル経由で発行された証明書の CRL パーティション設定をセットアップするで定義されています) への発行ポイントを指定します。

CA の CS.cfg に以下を追加します。

ca.publish.rule.instance.FileCrlRule.enable=true
ca.publish.rule.instance.FileCrlRule.mapper=NoMap
ca.publish.rule.instance.FileCrlRule.pluginName=Rule
ca.publish.rule.instance.FileCrlRule.predicate=issuingPointId==ServerCertCRL
ca.publish.rule.instance.FileCrlRule.publisher=crlFilePublisher
ca.publish.rule.instance.FileCrlRule.type=crl

7.5.9.1.3. LDAP ベースの公開ルールを変更する: LdapCrlRule
リンクのコピー

この設定では、マスター (完全) CRL に述語 LdapCrlRule を明示的に設定します。適切な OCSP サポートのために、マスター CRL は OCSP レスポンダーに継続的に提供されます。

CA の CS.cfg で以下を変更します。

ca.publish.rule.instance.LdapCrlRule.predicate=issuingPointId==MasterCRL

7.5.9.1.4. プロファイル経由で発行された証明書の CRL パーティション設定をセットアップする
リンクのコピー

このセクションの設定は、上記で定義した FileCrlRule で利用できる小さなサブセットに CRL を分割する方法を示しています。CRL は、profileList パラメーターで指定された証明書登録プロファイルによってパーティション化されます。複数のプロファイルには、コンマ区切りのリストを使用できます (例: caCMCserverCertWithCRLDP.cfg および caCMCECserverCertWithCRLDP.cfg)。

CA の CS.cfg に以下を追加します。

ca.crl.ServerCertCRL.allowExtensions=true
ca.crl.ServerCertCRL.alwaysUpdate=false
ca.crl.ServerCertCRL.autoUpdateInterval=240
ca.crl.ServerCertCRL.caCertsOnly=false
ca.crl.ServerCertCRL.cacheUpdateInterval=15
ca.crl.ServerCertCRL.class=com.netscape.ca.CRLIssuingPoint
ca.crl.ServerCertCRL.dailyUpdates=1:00
ca.crl.ServerCertCRL.description=CA's Certificate Revocation List containing certificates issued via the caCMCserverCertWithCRLDP and caCMCECserverCertWithCRLDP enrollment profile
ca.crl.ServerCertCRL.enable=true
ca.crl.ServerCertCRL.enableCRLCache=false
ca.crl.ServerCertCRL.enableCRLUpdates=true
ca.crl.ServerCertCRL.enableCacheRecovery=true
ca.crl.ServerCertCRL.enableCacheTesting=false
ca.crl.ServerCertCRL.enableDailyUpdates=true
ca.crl.ServerCertCRL.enableUpdateInterval=true
ca.crl.ServerCertCRL.extendedNextUpdate=true
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.accessLocation0=""
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.accessLocationType0=URI
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.accessMethod0=caIssuers
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.class=com.netscape.cms.crl.CMSAuthInfoAccessExtension
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.critical=false
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.enable=false
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.numberOfAccessDescriptions=1
ca.crl.ServerCertCRL.extension.AuthorityInformationAccess.type=CRLExtension
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.class=com.netscape.cms.crl.CMSAuthorityKeyIdentifierExtension
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.critical=false
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.enable=false
ca.crl.ServerCertCRL.extension.AuthorityKeyIdentifier.type=CRLExtension
ca.crl.ServerCertCRL.extension.CRLNumber.class=com.netscape.cms.crl.CMSCRLNumberExtension
ca.crl.ServerCertCRL.extension.CRLNumber.critical=false
ca.crl.ServerCertCRL.extension.CRLNumber.enable=true
ca.crl.ServerCertCRL.extension.CRLNumber.type=CRLExtension
ca.crl.ServerCertCRL.extension.CRLReason.class=com.netscape.cms.crl.CMSCRLReasonExtension
ca.crl.ServerCertCRL.extension.CRLReason.critical=false
ca.crl.ServerCertCRL.extension.CRLReason.enable=true
ca.crl.ServerCertCRL.extension.CRLReason.type=CRLEntryExtension
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.class=com.netscape.cms.crl.CMSDeltaCRLIndicatorExtension
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.critical=true
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.enable=false
ca.crl.ServerCertCRL.extension.DeltaCRLIndicator.type=CRLExtension
ca.crl.ServerCertCRL.extension.FreshestCRL.class=com.netscape.cms.crl.CMSFreshestCRLExtension
ca.crl.ServerCertCRL.extension.FreshestCRL.critical=false
ca.crl.ServerCertCRL.extension.FreshestCRL.enable=false
ca.crl.ServerCertCRL.extension.FreshestCRL.numPoints=0
ca.crl.ServerCertCRL.extension.FreshestCRL.pointName0=""
ca.crl.ServerCertCRL.extension.FreshestCRL.pointType0=""
ca.crl.ServerCertCRL.extension.FreshestCRL.type=CRLExtension
ca.crl.ServerCertCRL.extension.InvalidityDate.class=com.netscape.cms.crl.CMSInvalidityDateExtension
ca.crl.ServerCertCRL.extension.InvalidityDate.critical=false
ca.crl.ServerCertCRL.extension.InvalidityDate.enable=true
ca.crl.ServerCertCRL.extension.InvalidityDate.type=CRLEntryExtension
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.class=com.netscape.cms.crl.CMSIssuerAlternativeNameExtension
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.critical=false
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.enable=false
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.name0=""
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.nameType0=""
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.numNames=0
ca.crl.ServerCertCRL.extension.IssuerAlternativeName.type=CRLExtension
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.class=com.netscape.cms.crl.CMSIssuingDistributionPointExtension
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.critical=true
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.enable=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.indirectCRL=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.onlyContainsCACerts=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.onlyContainsUserCerts=false
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.onlySomeReasons=""
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.pointName=
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.pointType=
ca.crl.ServerCertCRL.extension.IssuingDistributionPoint.type=CRLExtension
ca.crl.ServerCertCRL.includeExpiredCerts=false
ca.crl.ServerCertCRL.includeExpiredCertsOneExtraTime=false
ca.crl.ServerCertCRL.minUpdateInterval=0
ca.crl.ServerCertCRL.nextAsThisUpdateExtension=0
ca.crl.ServerCertCRL.nextUpdateGracePeriod=0
ca.crl.ServerCertCRL.profileCertsOnly=true
ca.crl.ServerCertCRL.profileList=caCMCserverCertWithCRLDP,caCMCECserverCertWithCRLDP
ca.crl.ServerCertCRL.publishOnStart=false
ca.crl.ServerCertCRL.saveMemory=false
ca.crl.ServerCertCRL.signingAlgorithm=SHA256withRSA
ca.crl.ServerCertCRL.updateSchema=1

注記

ECC CA の場合は、SHA512withEC に以下を設定します。

ca.crl.ServerCertCRL.signingAlgorithm=SHA512withEC

7.5.9.2. CA で CRL HTTP サービスを設定する
リンクのコピー

CRL 配布ポイントが提供する CRL はファイルに公開されます (上記のセクションを参照)。このファイルは、以下に示すように CA の server.xml に追加している非 SSL Tomcat サービスによって提供されます。

/var/lib/pki/rhcs10-RSA-RootCA/conf/server.xml ファイル内で、Catalina サービスの前に次の CRL サービスを追加します。

<Service name="CRL">
  <Connector port="8085" protocol="HTTP/1.1" connectionTimeout="80000"
   maxParameterCount="1000" name="Unsecure" maxHttpHeaderSize="8192"
   acceptCount="100" maxThreads="15" minSpareThreads="25"
   enableLookups="false" disableUploadTimeout="true"/>
  <Engine name="CRL" defaultHost="localhost">
    <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
      <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
       prefix="localhost_crl_access_log" suffix=".txt" pattern="common"/>
    </Host>
  </Engine>
</Service>

上記の CRL サービスでは、使用されていないコネクターポート番号を選択します。たとえば、ルート CA の HTTP ポートが 8080 の場合は、8085 を選択します。SELinux およびファイアウォール用のポートが追加されていることを確認します。以下はその例です。
```
semanage port -a -t http_port_t -p tcp 8085
firewall-cmd --permanent --add-port=8085/tcp
firewall-cmd --reload
```
注記
選択したポートが別の SELinux コンテキストに事前に割り当てられている場合は、次のようなエラーメッセージが表示されます。
ValueError: Port tcp/8085 already defined
次のコマンドを使用して、CRL HTTP ポートが事前に割り当てられているかどうかを検索して確認することもできます。
# semanage port -l | grep <port>
割り当て済みの場合は別のポートを選択することが推奨されます。しかし、同じポートを使用する必要がある場合は、次の操作を実行できます。
# semanage port -m -t http_port_t -p tcp 8085
サーバーを再起動すると、CA の conf ディレクトリーの下に CRL/localhost ディレクトリーが作成されます (存在しない場合に限る)。ただし、crl.xml ファイルの追加を準備するために、次の手順を実行します。
```
mkdir -p  /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost
chown -R pkiuser:pkiuser /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost
```
/var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost の下に crl.xml ファイルを作成し、次のコンテンツを追加します。
```
<Context docBase="/var/lib/pki/rhcs10-RSA-RootCA/crl">
 <Resources allowLinking="true" cachingAllowed="false" />
</Context>
```

crl.xml ファイルの user:group 所有権を設定します。

chown pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-RootCA/conf/CRL/localhost/crl.xml

注記

登録プロファイルに設定されている CRL 配布ポイントは http://rhcs10.example.com:8085/crl/ServerCertCRL.crl のようになります (完全な例は後続のセクションを参照してください)。

重要

ファイルベースの CRL パブリッシャーは、証明書の発行や失効の頻度が低い、より小さな CRL にのみ推奨されます。このセクションで説明する CA スタートアップセットアップのなど、必要な場合にのみ推奨されます。

7.5.9.3. CRL 配布ポイントを使用した CA の登録プロファイル設定
リンクのコピー

必要なプロファイルを有効にして、CRL 配布ポイントを追加します。これらは、上記のセクションの設定に対応するプロファイルです。

/var/lib/pki/<ca instance directory/ca/profiles/ca/ directory ディレクトリーにある caCMCserverCertWithCRLDP.cfg プロファイル (RSA キーを使用した登録用) を開き、次のように更新します。

# vi /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg
…
enable=true
…
policyset.serverCertSet.10.default.params.crlDistPointsPointName_0=http://rhcs10.example.com:8085/crl/ServerCertCRL.crl
…

/var/lib/pki/<ca instance directory/ca/profiles/ca/ ディレクトリーにある caCMCECserverCertWithCRLDP.cfg (ECC キーを使用した登録用) を開き、次のように更新します。

# vi /var/lib/pki/rhcs10-ECC-RootCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg
…
enable=true
…
policyset.serverCertSet.10.default.params.crlDistPointsPointName_0=http://rhcs10.example.com:20085/crl/ServerCertCRL.crl
…

user:group の所有権を設定します。

chown -R pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg
chown -R pkiuser:pkiuser  /var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg

CA の CS.cfg に新しいプロファイルを登録します。

各プロファイルに次の行を追加します。

profile.caCMCserverCertWithCRLDP.class_id=caEnrollImpl
profile.caCMCserverCertWithCRLDP.config=/var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCserverCertWithCRLDP.cfg

profile.caCMCECserverCertWithCRLDP.class_id=caEnrollImpl
profile.caCMCECserverCertWithCRLDP.config=/var/lib/pki/rhcs10-RSA-RootCA/ca/profiles/ca/caCMCECserverCertWithCRLDP.cfg

profile.list エントリーを編集して、2 つの新しいプロファイルを追加します。例::

profile.list=caCMCserverCertWithCRLDP,caCMCECserverCertWithCRLDP,acmeServerCert,caCMCserverCert,caCMCECserverCert, …

7.5.9.4. より迅速な CRL 更新のための設定
リンクのコピー

サーバー証明書の筆耕頻度は高くないため、失効した場合はすぐに CRL を更新するべきです。CA の CS.cfg を編集します。

ca.crl.ServerCertCRL.alwaysUpdate=true

7.5.9.5. CA 設定の更新後に CA を起動する
リンクのコピー

設定が完了したら、CA を再起動します。

pki-server restart rhcs10-RSA-RootCA

注記

CRL 配布ポイントが動作していることを確認するには、CRL 配布ポイントの検証に従います。

7.5.10. CRL 配布ポイントの検証
リンクのコピー

プロファイル caCMCserverCertWithCRLDP を使用してルート CA のディレクトリーサーバーの server-cert を置き換えた場合、起動時に CA が内部ディレクトリーサーバーとの接続を開始するときに、CRL 配布ポイントが CA によって参照されるようになります。

このセクションでは、CA の CRL 配布ポイントの設定を確認するための基本的な方法 (CRL 配布ポイントのサポートを設定するを参照) を説明します。

検証の前に、次のように失効チェックを有効にする必要があります。

証明書失効チェックを有効にするには、それぞれの /var/lib/pki/rhcs10-RSA-RootCA/conf/server.xml ファイルで以下を実行します。
1. enableOCSP または enableRevocationCheck を true に設定します。
  enableOCSP=true or enableRevocationCheck=true
2. さらに、次の 2 つのパラメーターと割り当てられた値を削除します。
  ocspResponderURL ocspResponderCertNickname
CA の CS.cfg ファイルを編集し、以下を false に設定して、従来の失効チェック方法を無効にします。
```
auths.revocationChecking.enabled=false
```
RootCA インスタンスを起動します。
```
pki-server start rhcs10-RSA-RootCA
```

7.5.10.1. CRL 配布ポイントの検証
リンクのコピー

CRL 配布ポイントを確認するには、以下を実行します。

ファイルベースの CRL の公開を確認します。

# ls -l /var/lib/pki/rhcs10-RSA-RootCA/crl
total 8
-rw-r--r--. 1 pkiuser pkiuser 574 Jun 20 18:08 ServerCertCRL-20240620-180859.der
-rw-r--r--. 1 pkiuser pkiuser 613 Jun 20 18:09 ServerCertCRL-20240620-180938.der
lrwxrwxrwx. 1 pkiuser pkiuser  68 Jun 20 18:09 ServerCertCRL.crl -> /var/lib/pki/rhcs10-RSA-RootCA/crl/ServerCertCRL-20240620-180938.der

CRL の内容を表示し、検証します。

# BtoA /var/lib/pki/rhcs10-RSA-RootCA/crl/ServerCertCRL.crl /var/lib/pki/rhcs10-RSA-RootCA/crl/ServerCertCRL.bin
# PrettyPrintCrl /var/lib/pki/rhcs10-RSA-RootCA/crl/ServerCertCRL.bin
Certificate Revocation List:
        Data:
            Version:  v2
            Signature Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Issuer: CN=CA Signing Certificate,OU=rhcs10-RSA-RootCA,O=Example-rhcs10-RSA-RootCA
            This Update: Thursday, June 20, 2024 6:09:38 PM EDT America/New_York
            Next Update: Thursday, June 20, 2024 9:00:00 PM EDT America/New_York
            Revoked Certificates:
                Serial Number: 0xF6FDEF3
                Revocation Date: Thursday, June 20, 2024 6:09:38 PM EDT America/New_York
                Extensions:
                    Identifier: Revocation Reason - 2.5.29.21
                        Critical: no
                        Reason: Certificate_Hold
        Extensions:
            Identifier: CRL Number - 2.5.29.20
                Critical: no
                Number: 21
        Signature:
            Algorithm: SHA256withRSA - 1.2.840.113549.1.1.11
            Signature:
                69:38:47:5D:E4:50:17:C5:6C:60:3F:1B:D8:B4:62:4D:
                8B:11:FC:31:E4:26:6B:07:B6:BB:2C:7E:48:10:F4:DD:
                0A:67:17:CB:DF:4E:1A:50:BE:4F:8F:61:B4:91:AE:DA:
                E5:58:D5:FE:54:D9:94:B3:38:E1:B6:2C:19:C4:93:54:
                D5:5E:8B:61:4F:89:52:5A:F7:F5:1B:2F:59:19:AD:23:
                1F:6F:3C:93:17:F3:1A:1C:0B:9A:D2:8F:01:76:08:6E:
                DA:DD:6F:2D:75:54:D3:D4:40:9A:2B:5D:8B:D5:BB:8B:
                AF:89:E4:13:A7:F1:8A:AF:0A:72:26:E3:3D:FE:B3:90:
                2B:F7:88:57:E9:8B:E7:82:B6:D3:F3:80:CD:F7:87:77:
                69:AF:39:90:5E:46:9C:C2:C4:FA:44:01:77:6D:8F:2D:
                5A:BD:B9:39:3F:E4:99:E7:F9:FD:2D:CD:FA:87:C1:42:
                A4:D0:3B:87:0B:28:30:2D:2A:68:F2:68:7C:00:A8:4B:
                AC:38:49:5A:03:D1:B2:CE:45:D8:C1:6A:3F:42:F0:04:
                F6:CC:43:83:E8:19:41:6F:0A:64:95:C3:57:8F:54:53:
                31:40:58:D4:CD:29:0E:0A:D9:15:E9:08:0C:B8:74:F4:
                82:B4:4E:51:8F:1C:86:A3:2E:BF:BB:F8:4A:DD:17:07:
                37:27:0F:8B:5C:5E:75:28:B4:0C:DE:F2:38:B9:0E:AE:
                73:06:A1:3D:36:85:54:74:E6:C3:4B:78:80:9F:76:42:
                85:D2:94:FF:A0:0C:7D:23:61:AB:4E:7A:D0:5B:EC:CF:
                91:E9:CB:80:C4:A1:EB:86:FB:D8:E6:65:AC:48:D0:9F:
                8B:95:07:A9:CA:D7:34:A9:7B:32:25:1E:F4:21:A8:06:
                44:73:B4:99:79:B5:69:77:D1:18:3B:40:C5:20:AF:5C:
                8E:D0:65:AE:34:CF:1F:90:82:97:33:7F:90:E6:D9:BC:
                49:8F:BE:59:22:FE:09:E5:FA:F2:5F:31:77:6D:F8:99

重要

CRL ファイル (ソフトリンクファイル ServerCertCRL.crl と、それに関連付けられた der ファイル) は削除しないでください。

CRL ファイルが見つからない、または誤って /var/lib/pki/rhcs10-RSA-RootCA/crl/ から削除されているため CA が起動できない状況が発生した場合は、以下の手順に従って CRL ファイルを再生成します。

CA サービスを停止します。
```
pki-server stop rhcs10-RSA-RootCA
```
CA の server.xml で、enableRevocationCheck または enableOCSP パラメーターを false に設定します (現在 true に設定されている場合)。
CA の CS.cfg で ca.crl.ServerCertCRL.publishOnStart= パラメーターを true に設定します。
欠落している CRL ファイルを再生成するには、CA サービスを開始します。
```
pki-server start rhcs10-RSA-RootCA
```
CRL ファイルを復元した後、CA サービスをもう一度停止します。
CA の CS.cfg で ca.crl.ServerCertCRL.publishOnStart= パラメーターを false に戻します。
CA の server.xml で enableRevocationCheck または enableOCSP パラメーターを true に設定します。
変更を適用するには、CA サービスを再度開始します。

これらの手順に従うことで、欠落している CRL ファイルが正常に復元され、CA が正しく起動されます。

7.5.11. アクセスバナーの有効化
リンクのコピー

ユーザーインターフェイスバナーを有効にするには、「アクセスバナーの有効化」を参照してください。

7.5.12. Watchdog サービスの有効化
リンクのコピー

ウォッチドッグ (nuxwdog) サービスは、セキュアなシステムパスワード管理を提供します。詳細は、「Watchdog サービスの有効化」を参照してください。

7.5.13. CMC 登録および失効の設定 (CA)
リンクのコピー

証明書の登録と失効は CMC で行うことができます。

CMC Shared Token Feature の有効化に関する詳細は、「CMC 共有シークレット機能の有効化」を参照してください。
PopLinkWittness 機能を有効にする方法は、「PopLinkWittnessV2 機能の有効化」を参照してください。
Web ユーザーインターフェイスの CMCRevoke を有効にする方法は、「Web ユーザーインターフェイスの CMCRevoke の有効化」を参照してください。

7.5.14. Java コンソールの TLS クライアント認証
リンクのコピー

Certificate System 管理者が Java コンソールにログインするときにユーザー TLS クライアント証明書を提示するように要求するには、「TLS クライアント証明書認証を使用するための pkiconsole 要件の設定」を参照してください。

注記

pkiconsole は非推奨になりました。

7.5.15. ロールユーザーの作成
リンクのコピー

ブートストラップユーザーを削除できるように、実際のロールユーザーを作成します。

ユーザーを作成して異なる特権ロールに割り当てて、Certificate System を管理するには、18章ロールユーザーの作成 を参照してください。

7.5.16. Bootstrap ユーザーの削除
リンクのコピー

実際のロールユーザーが作成されると、インストール時に自動的に作成されたブートストラップユーザーは不要になりました。このアカウントを削除するには、個人個人に割り当てられている新しい管理者アカウントを作成したことを確認してから、19章Bootstrap ユーザーの削除 を参照してください。

7.5.17. マルチロールサポートの無効化
リンクのコピー

ブートストラップユーザーが削除された後にマルチロールサポートを無効にするには、「マルチロールサポートの無効化」を参照してください。

7.5.18. KRA の設定
リンクのコピー

7.5.18.1. キーリカバリー認証局 (KRA) に複数のエージェント承認の要件を追加する
リンクのコピー

複数の KRA エージェントがキーリカバリーを承認するための要件を設定するには、Red Hat Certificate System 管理ガイド のコマンドラインでのエージェント承認キーリカバリーの設定を参照してください。

7.5.18.2. KRA 暗号化設定の設定
リンクのコピー

キーの暗号化/ラップアルゴリズムを設定する場合は、「KRA 操作の暗号化」を参照してください。

7.5.19. ユーザーインターフェイスを使用するようにユーザーを設定する
リンクのコピー

ユーザーが承認されたユーザーインターフェイスを使用する前に、初期化を行う必要があります。ユーザー (管理ロールなど) は、ユーザーインターフェイスにアクセスするためにクライアントを設定するために必要です。Red Hat Certificate System 管理ガイド のクライアント NSS データベースの初期化セクションを参照してください。

7.5.20. 署名付き監査ログの有効化
リンクのコピー

デフォルトでは、監査ロギングはインストール時に有効になります。ただし、インストール後に、ログ署名を手動で有効にする必要があります。

現在の監査ロギング設定を表示するには、以下を実行します。

# pki-server subsystem-audit-config-show
  Enabled: True
  Log File: audit_signing_log_file
  Buffer Size (bytes): 512
  Flush Interval (seconds): 5
  Max File Size (bytes): 2000
  Rollover Interval (seconds): 2592000
  Expiration Time (seconds): 0
  Log Signing: False
  Signing Certificate: audit_signing_certificate

署名付き監査ログを有効にするには、以下を実行します。

pki-server ユーティリティーを使用して、--logSigning オプションを true に設定します。
```
# pki-server subsystem-audit-config-mod --logSigning True
  ...
  Log Signing: True
  ...
```

インスタンスを再起動します。

# systemctl restart pki-tomcatd@instance_name.service

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

# systemctl start pki-tomcatd-nuxwdog@instance_name.service

7.5.21. 暗号リストの更新
リンクのコピー

Red Hat Certificate System では、サーバーまたはクライアントとして機能するときに、受け入れ可能な暗号に制限を設定できます。これらの暗号制御は、さまざまな場所で設定されます。

RHCS インスタンスは、別のエンティティーからの要求を受け入れるときにサーバーとして機能しています。以下に例を示します。

RHCS cli が証明書登録のために CA と通信する場合 (この場合の CA はサーバー)
RHCS 管理者が pkiconsole を使用して CA と通信する場合 (この場合の CA はサーバーです)
CA が鍵のアーカイブのために KRA と対話するとき (この場合、KRA はサーバーで、CA はクライアントです)

RHCS インスタンスは、別のサーバーに接続しようとするときにクライアントとして機能しています。以下に例を示します。

CA が鍵のアーカイブのために KRA と対話する場合 (この場合、CA はクライアントであり、KRA はサーバーです)
CA が内部 LDAP データベースと通信する場合 (この場合、CA はクライアントであり、Directory Server はサーバーです)

次のセクションでは、これらのさまざまなシナリオで暗号を設定する方法を説明します。

7.5.21.1. サーバーとして機能する CS インスタンスの暗号の設定
リンクのコピー

特定のインスタンスに必要な暗号のセットは、<CS instance directory>/conf/server.xml ファイルの SSLHostConfig 要素によって定義されます。

各 CS インスタンスを設定するには、以下の手順に従ってください。

重要

編集する前に、元の server.xml ファイルを server.xml.orig などにバックアップします。

server.xml ファイルを編集し、メイン SSL ポートの Connector 宣言に移動して、SSLHostConfig 要素を見つけます。

次の設定で SSLHostConfig 要素を変更します。

<SSLHostConfig sslProtocol="TLS" protocols="TLSv1.2" certificateVerification="optional" ciphers="ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384">

上記の暗号リストは、OpenSSL 形式でこの RHCS リリースで要求される暗号のセットを表します。

ciphers=" … ": 任意の制限付き暗号 (TLS など) を確立します。この形式では、暗号名はコロンで区切られます。
protocol = "…": 必要な TLS バージョンを確立します (たとえば、1.2)。

7.5.21.2. クライアントとして機能する CS インスタンスの暗号の設定
リンクのコピー

CS インスタンスがクライアントとして機能する場合、インスタンスの CS.cfg 設定ファイルに必要な暗号のリストを追加します。すべてのクライアントインスタンスを、そのロールに基づき関連するものとして設定します。

重要

編集する前に、元の CS.cfg ファイルを CS.cfg.orig などにバックアップします。

CS インスタンスが内部 LDAP データベースのクライアントとして機能している場合。
次の行を <instance directory>/<instance type>/conf/CS.cfg ファイルに追加します。
```
tcp.clientCiphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
```
注記
内部 LDAP データベースで目的の暗号が有効になっていることを確認するには、DS インスタンスの暗号の設定に従ってください。

CA インスタンスが KRA のクライアントとして機能している場合。

次の行を <instance directory>/ca/conf/CS.cfg ファイルに追加します。

ca.connector.KRA.clientCiphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TPS インスタンスが CA、KRA、または TKS のクライアントとして機能している場合。

次の行を <instance directory>/tps/conf/CS.cfg ファイルに追加します。

tps.connector.<ca|kra|tks id>.clientCiphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

注記

以下のように、変更を有効にするには、各サーバーインスタンスを再起動する必要があります。

# pki-server restart rhcs10-RSA-RootCA
# pki-server restart rhcs10-RSA-SubCA
# pki-server restart rhcs10-RSA-OCSP-rootca
# pki-server restart rhcs10-RSA-OCSP-subca
# pki-server restart rhcs10-RSA-KRA

Nuxwdog ウォッチドッグを使用している場合は以下を使用します。

# systemctl restart rhcs10-RSA-RootCA
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca.service
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service

7.5.21.3. DS インスタンスの暗号の設定
リンクのコピー

デフォルトでは、Directory Server インスタンスは OS で有効になっている暗号を継承します。暗号リストが Certificate System のものと一致するように設定する場合は、各 DS インスタンスに対して次の手順を実行します。

DS ホスト dir.example.com で以下を実行します。

目的の暗号を有効にします (DS インスタンスの SSL 以外のポートを使用します)。

# dsconf -D "cn=Directory Manager" ldap://dir.example.com:7389 security ciphers set "+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"

DS インスタンスを再起動します。

# dsctl slapd-CC-RSA-SubCA-LDAP stop

# dsctl slapd-CC-RSA-SubCA-LDAP start

有効な暗号を一覧表示して確認します。

# dsconf -D "cn=Directory Manager" ldap://dir.example.com:7389 security ciphers list --enabled

Enter password for cn=Directory Manager on ldap://dir.example.com:7389:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

7.5.22. KRA、TKS、TPS の OAEP サポートを有効にする
リンクのコピー

RHCS では、古い PKCS#1 アルゴリズムに代わって、Optimal Asymmetric Encryption Padding (OAEP) キーラッピングアルゴリズムがサポートされるようになりました。新しい HSM デバイスと、それ以降の FIPS 対応バージョンの NSS では、頻繁にこのアルゴリズムを使用する必要があります。主に、KRA との最終的なやり取りがある場合に実行されます。KRA のトランスポート証明書は、AES 対称鍵をはじめとする他の鍵の公開鍵をラップするために使用されます。OAEP を使用する場合、ラッピングシーケンスとアンラッピングシーケンスの終端で OAEP を使用する必要があります。ラッピングはおそらくクライアント側で実行され、アンラッピングは RHCS KRA などのサーバーやその他のサブシステム側で実行されます。

OAEP が最もよく使用されるシナリオは 2 つあります。

KRA、TPS、TKS などの RHCS サブシステム内。
いずれかの RHCS サブシステムと対話するさまざまなコマンドラインツール経由での使用。

クライアントとサーバーの対話では、両方の終端で OAEP ラッピングを使用するか、まったく使用しない必要があります。たとえば、KRA が OAEP 用に設定されている場合、KRA と対話するコマンドラインツールは、トランスポート証明書を使用してキーをラップする際に OAEP を使用する必要があります。

Red Hat の JSS 暗号バインディングコンポーネントは以前から OAEP をサポートしているため、OAEP を使用するように感嘆にクライアントまたはサーバーを設定できます。Certificate System サブシステムの実際の選択はバイナリーです。つまり、同様のシナリオであっても、OAEP ですべてを実行するか (要求された場合)、OAEP では何も実行しないかを選択する必要があります。サーバーが OAEP 用に設定されているかどうかが明確で、デフォルトが存在する場合、クライアントプログラムのユーザーは、使用されている、または使用されていないコマンドラインパラメーターに基づき、クライアントの操作方法を決定できます。

このセクションでは、OAEP 用のサブシステム設定について説明します。このサブシステムの設定は、pkispawn が RHCS サブシステムインスタンスを正常に作成した後に実行されます。

注記

Thales Luna の限定サポート: Red Hat では、Thales HSM ユニットが OAEP 経由の AES キーラッピング/アンラッピングをサポートしていることを確認できていません。サポートされていない場合、このアルゴリズムのサポートを必要とする機能は機能しないことに注意してください。これらの機能には、KRA: 鍵のアーカイブとリカバリー、登録用の CMC SharedToken 認証メカニズム、インストール中における TKS TPS 共有秘密の自動転送が含まれます。

注記: OAEP でのコマンドラインインターフェイスの使用例については、管理ガイドを参照してください。

7.5.22.1. KRA
リンクのコピー

KRA は、OAEP を利用する主要な Certificate System サブシステムの 1 つです。これは、KRA トランスポート証明書が、クライアントプログラムによってキーをラップするために頻繁に使用され、その後 KRA 自体によってアンラップされるためです。

このセクションには、ファームウェア v12.72.1 を搭載した Entrust nShield Connect XC ユニットなど、AES キーのラッピング/アンラッピング操作をサポートする HSM デバイスに対応するための OAEP 以外の設定が含まれています。

サブシステムが含まれるホスト上で、次の操作を (root として) 実行します。

KRA を停止します。

pki-server stop <subsystem instance name>

/var/lib/pki/<subsystem instance name>/CS.cfg 設定ファイルを編集し、次の 3 行を追加します。
```
keyWrap.useOAEP=true
kra.legacyPKCS12=false
kra.nonLegacyAlg=AES/None/PKCS5Padding/Kwp/256
```
上記の最初の行は OAEP に関連し、最後の 2 つの設定は OAEP シナリオでの適切な KRA 操作を可能にするための補足的な設定です。上記の状況では、AES ベースの “KWP” アルゴリズムが使用されます。

KRA を起動します。

pki-server start <subsystem instance name>

7.5.22.2. TKS
リンクのコピー

サブシステムが含まれるホスト上で、次の操作を (root として) 実行します。

TKS を停止します。

pki-server stop <subsystem instance name>

/var/lib/pki/<subsystem instance name>/CS.cfg 設定ファイルを編集し、次のエントリーを追加します。
```
keyWrap.useOAEP=true
```

TKS を起動します。

pki-server start <subsystem instance name>

7.5.22.3. TPS
リンクのコピー

トークン管理システムを使用する場合、TPS と TKS は連携して動作します。正常に動作するには、両方のサブシステムで OAEP を有効にする必要があります。TKS と TPS の通常のインストール順序では、最初に TKS がインストールされ、次に TPS がインストールされます。次の手順は、TKS が OAEP 用に設定されていることが明らかな場合に適用されます。

サブシステムが含まれるホスト上で、次の操作を (root として) 実行します。

TKS を停止します。

pki-server stop <subsystem instance name>

/var/lib/pki/<subsystem instance name>/CS.cfg 設定ファイルを編集し、次のエントリーを追加します。
```
keyWrap.useOAEP=true
```

TKS を起動します。

pki-server start <subsystem instance name>

7.5.1. Red Hat Certificate System の日付/時刻の設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.2. 実際の CA から発行された DS 証明書を取得するリンクのコピーリンクがクリップボードにコピーされました!

7.5.2.1. CA 署名証明書のエクスポートリンクのコピーリンクがクリップボードにコピーされました!

7.5.2.2. DS サーバー証明書の作成リンクのコピーリンクがクリップボードにコピーされました!

7.5.2.2.1. DS サーバーの CSR の生成リンクのコピーリンクがクリップボードにコピーされました!

7.5.2.2.2. DS サーバー証明書要求の送信:リンクのコピーリンクがクリップボードにコピーされました!

7.5.2.2.3. 証明書要求の承認:リンクのコピーリンクがクリップボードにコピーされました!

7.5.2.3. 証明書の取得リンクのコピーリンクがクリップボードにコピーされました!

7.5.2.4. DS インスタンスの停止リンクのコピーリンクがクリップボードにコピーされました!

7.5.2.5. CA 署名証明書のインポートリンクのコピーリンクがクリップボードにコピーされました!

7.5.2.6. DS ブートストラップ証明書の削除リンクのコピーリンクがクリップボードにコピーされました!

7.5.2.7. DS サーバー証明書のインポート:リンクのコピーリンクがクリップボードにコピーされました!

7.5.2.8. SSL 接続の有効化リンクのコピーリンクがクリップボードにコピーされました!

7.5.2.9. PKI インスタンスから DS ブートストラップ署名証明書を削除するリンクのコピーリンクがクリップボードにコピーされました!

7.5.2.10. 関連情報リンクのコピーリンクがクリップボードにコピーされました!

7.5.3. ブートストラップ証明書を使用して DS で SSL 接続を有効にするリンクのコピーリンクがクリップボードにコピーされました!

7.5.3.1. DS 署名証明書の作成リンクのコピーリンクがクリップボードにコピーされました!

7.5.3.2. DS サーバー証明書の作成リンクのコピーリンクがクリップボードにコピーされました!

7.5.3.3. SSL 接続の有効化リンクのコピーリンクがクリップボードにコピーされました!

7.5.3.4. 関連情報リンクのコピーリンクがクリップボードにコピーされました!

7.5.4. CS から DS への TLS 相互認証を有効にするリンクのコピーリンクがクリップボードにコピーされました!

7.5.5. セッションタイムアウトの設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.6. CRL または証明書の公開リンクのコピーリンクがクリップボードにコピーされました!

7.5.7. 証明書登録プロファイル (CA) の設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.8. CRL 配布ポイントを使用した CA の登録プロファイル設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.9. CRL 配布ポイントのサポートを設定するリンクのコピーリンクがクリップボードにコピーされました!

7.5.9.1. サーバー証明書 CRL ファイルの公開をサポートする CA セットアップリンクのコピーリンクがクリップボードにコピーされました!

7.5.9.1.1. ファイルベースのパブリッシャーを設定する: crlFilePublisherリンクのコピーリンクがクリップボードにコピーされました!

7.5.9.1.2. ファイルベースの公開ルールを設定する: FileCrlRuleリンクのコピーリンクがクリップボードにコピーされました!

7.5.9.1.3. LDAP ベースの公開ルールを変更する: LdapCrlRuleリンクのコピーリンクがクリップボードにコピーされました!

7.5.9.1.4. プロファイル経由で発行された証明書の CRL パーティション設定をセットアップするリンクのコピーリンクがクリップボードにコピーされました!

7.5.9.2. CA で CRL HTTP サービスを設定するリンクのコピーリンクがクリップボードにコピーされました!

7.5.9.3. CRL 配布ポイントを使用した CA の登録プロファイル設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.9.4. より迅速な CRL 更新のための設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.9.5. CA 設定の更新後に CA を起動するリンクのコピーリンクがクリップボードにコピーされました!

7.5.10. CRL 配布ポイントの検証リンクのコピーリンクがクリップボードにコピーされました!

7.5.10.1. CRL 配布ポイントの検証リンクのコピーリンクがクリップボードにコピーされました!

7.5.11. アクセスバナーの有効化リンクのコピーリンクがクリップボードにコピーされました!

7.5.12. Watchdog サービスの有効化リンクのコピーリンクがクリップボードにコピーされました!

7.5.13. CMC 登録および失効の設定 (CA)リンクのコピーリンクがクリップボードにコピーされました!

7.5.14. Java コンソールの TLS クライアント認証リンクのコピーリンクがクリップボードにコピーされました!

7.5.15. ロールユーザーの作成リンクのコピーリンクがクリップボードにコピーされました!

7.5.16. Bootstrap ユーザーの削除リンクのコピーリンクがクリップボードにコピーされました!

7.5.17. マルチロールサポートの無効化リンクのコピーリンクがクリップボードにコピーされました!

7.5.18. KRA の設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.18.1. キーリカバリー認証局 (KRA) に複数のエージェント承認の要件を追加するリンクのコピーリンクがクリップボードにコピーされました!

7.5.18.2. KRA 暗号化設定の設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.19. ユーザーインターフェイスを使用するようにユーザーを設定するリンクのコピーリンクがクリップボードにコピーされました!

7.5.20. 署名付き監査ログの有効化リンクのコピーリンクがクリップボードにコピーされました!

7.5.21. 暗号リストの更新リンクのコピーリンクがクリップボードにコピーされました!

7.5.21.1. サーバーとして機能する CS インスタンスの暗号の設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.21.2. クライアントとして機能する CS インスタンスの暗号の設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.21.3. DS インスタンスの暗号の設定リンクのコピーリンクがクリップボードにコピーされました!

7.5.22. KRA、TKS、TPS の OAEP サポートを有効にするリンクのコピーリンクがクリップボードにコピーされました!

7.5.22.1. KRAリンクのコピーリンクがクリップボードにコピーされました!

7.5.22.2. TKSリンクのコピーリンクがクリップボードにコピーされました!

7.5.22.3. TPSリンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

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

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

7.5.1. Red Hat Certificate System の日付/時刻の設定
リンクのコピー

7.5.2. 実際の CA から発行された DS 証明書を取得する
リンクのコピー

7.5.2.1. CA 署名証明書のエクスポート
リンクのコピー

7.5.2.2. DS サーバー証明書の作成
リンクのコピー

7.5.2.2.1. DS サーバーの CSR の生成
リンクのコピー

7.5.2.2.2. DS サーバー証明書要求の送信:
リンクのコピー

7.5.2.2.3. 証明書要求の承認:
リンクのコピー

7.5.2.3. 証明書の取得
リンクのコピー

7.5.2.4. DS インスタンスの停止
リンクのコピー

7.5.2.5. CA 署名証明書のインポート
リンクのコピー

7.5.2.6. DS ブートストラップ証明書の削除
リンクのコピー

7.5.2.7. DS サーバー証明書のインポート:
リンクのコピー

7.5.2.8. SSL 接続の有効化
リンクのコピー

7.5.2.9. PKI インスタンスから DS ブートストラップ署名証明書を削除する
リンクのコピー

7.5.2.10. 関連情報
リンクのコピー

7.5.3. ブートストラップ証明書を使用して DS で SSL 接続を有効にする
リンクのコピー

7.5.3.1. DS 署名証明書の作成
リンクのコピー

7.5.3.2. DS サーバー証明書の作成
リンクのコピー

7.5.3.3. SSL 接続の有効化
リンクのコピー

7.5.3.4. 関連情報
リンクのコピー

7.5.4. CS から DS への TLS 相互認証を有効にする
リンクのコピー

7.5.5. セッションタイムアウトの設定
リンクのコピー

7.5.6. CRL または証明書の公開
リンクのコピー

7.5.7. 証明書登録プロファイル (CA) の設定
リンクのコピー

7.5.8. CRL 配布ポイントを使用した CA の登録プロファイル設定
リンクのコピー

7.5.9. CRL 配布ポイントのサポートを設定する
リンクのコピー

7.5.9.1. サーバー証明書 CRL ファイルの公開をサポートする CA セットアップ
リンクのコピー

7.5.9.1.1. ファイルベースのパブリッシャーを設定する: crlFilePublisher
リンクのコピー

7.5.9.1.2. ファイルベースの公開ルールを設定する: FileCrlRule
リンクのコピー

7.5.9.1.3. LDAP ベースの公開ルールを変更する: LdapCrlRule
リンクのコピー

7.5.9.1.4. プロファイル経由で発行された証明書の CRL パーティション設定をセットアップする
リンクのコピー

7.5.9.2. CA で CRL HTTP サービスを設定する
リンクのコピー

7.5.9.3. CRL 配布ポイントを使用した CA の登録プロファイル設定
リンクのコピー

7.5.9.4. より迅速な CRL 更新のための設定
リンクのコピー

7.5.9.5. CA 設定の更新後に CA を起動する
リンクのコピー

7.5.10. CRL 配布ポイントの検証
リンクのコピー

7.5.10.1. CRL 配布ポイントの検証
リンクのコピー

7.5.11. アクセスバナーの有効化
リンクのコピー

7.5.12. Watchdog サービスの有効化
リンクのコピー

7.5.13. CMC 登録および失効の設定 (CA)
リンクのコピー

7.5.14. Java コンソールの TLS クライアント認証
リンクのコピー

7.5.15. ロールユーザーの作成
リンクのコピー

7.5.16. Bootstrap ユーザーの削除
リンクのコピー

7.5.17. マルチロールサポートの無効化
リンクのコピー

7.5.18. KRA の設定
リンクのコピー

7.5.18.1. キーリカバリー認証局 (KRA) に複数のエージェント承認の要件を追加する
リンクのコピー

7.5.18.2. KRA 暗号化設定の設定
リンクのコピー

7.5.19. ユーザーインターフェイスを使用するようにユーザーを設定する
リンクのコピー

7.5.20. 署名付き監査ログの有効化
リンクのコピー

7.5.21. 暗号リストの更新
リンクのコピー

7.5.21.1. サーバーとして機能する CS インスタンスの暗号の設定
リンクのコピー

7.5.21.2. クライアントとして機能する CS インスタンスの暗号の設定
リンクのコピー

7.5.21.3. DS インスタンスの暗号の設定
リンクのコピー

7.5.22. KRA、TKS、TPS の OAEP サポートを有効にする
リンクのコピー

7.5.22.1. KRA
リンクのコピー

7.5.22.2. TKS
リンクのコピー

7.5.22.3. TPS
リンクのコピー