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


pkispawn ユーティリティーを使用したインストールが完了したら、サイトの設定に応じて、さらに設定をカスタマイズすることができます。詳細は、パートIII「Certificate System の設定」で説明してください。

このセクションでは、デプロイメントのセキュリティーを強化するために、パートIII「Certificate System の設定」 からの操作のリストを紹介します。

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 署名証明書のエクスポート

Copy to Clipboard Toggle word wrap
pki-server cert-export ca_signing --cert-file ca_signing.crt

7.5.2.2. DS サーバー証明書の作成

7.5.2.2.1. DS サーバーの CSR の生成

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

Copy to Clipboard Toggle word wrap
$ 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 管理者として、以下を実行します。

Copy to Clipboard Toggle word wrap
$ pki ca-cert-request-submit --profile caServerCert --csr-file ds_server.csr
7.5.2.2.3. 証明書要求の承認:

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

Copy to Clipboard Toggle word wrap
$ pki -n caadmin ca-cert-request-review <request ID> --action approve

7.5.2.3. 証明書の取得

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

Copy to Clipboard Toggle word wrap
$  pki ca-cert-export <certificate ID> --output-file ds_server.crt

7.5.2.4. DS インスタンスの停止

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

Copy to Clipboard Toggle word wrap
$ dsctl localhost stop

7.5.2.5. CA 署名証明書のインポート

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

Copy to Clipboard Toggle word wrap
# 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 証明書がある場合は、それを削除します。

Copy to Clipboard Toggle word wrap
$ certutil -F -d /etc/dirsrv/slapd-localhost \
    -f /etc/dirsrv/slapd-localhost/pwdfile.txt \
    -n Server-Cert
$ certutil -F -d /etc/dirsrv/slapd-localhost \
    -f /etc/dirsrv/slapd-localhost/pwdfile.txt \
    -n Self-Signed-CA

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

Copy to Clipboard Toggle word wrap
$ pki \
    -d /etc/dirsrv/slapd-localhost \
    -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
    nss-cert-import \
    --cert ds_server.crt \
    Server-Cert

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

Copy to Clipboard Toggle word wrap
$ 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 を有効にしていない場合にのみ適用されます。

  1. DS インスタンスで SSL 接続を有効にするには、以下を実行します。

    Copy to Clipboard Toggle word wrap
    $ dsconf localhost config replace nsslapd-security=on
  2. DS インスタンスを起動します。

    Copy to Clipboard Toggle word wrap
    $ dsctl localhost start
  3. SSL 接続を確認します。

    Copy to Clipboard Toggle word wrap
    $ 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 ブートストラップ署名証明書を削除します。

Copy to Clipboard Toggle word wrap
$ 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.2.10. 関連情報

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 署名証明書の作成

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

    Copy to Clipboard Toggle word wrap
    $ 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
  2. DS 署名証明書を発行します。

    Copy to Clipboard Toggle word wrap
    $ 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
  3. DS 署名証明書をインポートします。

    Copy to Clipboard Toggle word wrap
    $ 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
  4. DS 署名証明書を確認します。

    Copy to Clipboard Toggle word wrap
    $ 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 サーバー証明書の作成

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

    Copy to Clipboard Toggle word wrap
    $ 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
  2. DS サーバー証明書を発行します。

    Copy to Clipboard Toggle word wrap
    $ 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
  3. DS サーバー証明書のインポート:

    Copy to Clipboard Toggle word wrap
    $ pki \
        -d /etc/dirsrv/slapd-localhost \
        -C /etc/dirsrv/slapd-localhost/pwdfile.txt \
        nss-cert-import \
        --cert ds_server.crt \
        Server-Cert
  4. DS サーバー証明書を確認します。

    Copy to Clipboard Toggle word wrap
    $ 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 接続の有効化

  1. DS インスタンスで SSL 接続を有効にするには、以下を実行します。

    Copy to Clipboard Toggle word wrap
    $ dsconf localhost config replace nsslapd-security=on
  2. DS インスタンスを再起動します。

    Copy to Clipboard Toggle word wrap
    $ dsctl localhost restart
  3. SSL 接続を確認します。

    Copy to Clipboard Toggle word wrap
    $ 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 のコンテンツを作成する場合は、以下の形式を使用します。

    Copy to Clipboard Toggle word wrap
    certmap rhcs <certificate issuer DN>
    		rhcs:CmapLdapAttr seeAlso
    		rhcs:verifyCert on

    以下に例を示します。

    Copy to Clipboard Toggle word wrap
    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 つ削除します。

Copy to Clipboard Toggle word wrap
internaldb.ldapauth.bindDN
		internaldb.ldapauth.bindPWPrompt

以下に例を示します。

Copy to Clipboard Toggle word wrap
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. アクセスバナーの有効化

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

7.5.9. Watchdog サービスの有効化

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

7.5.10. CMC 登録および失効の設定 (CA)

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

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

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

注記

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

7.5.12. ロールユーザーの作成

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

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

7.5.13. Bootstrap ユーザーの削除

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

7.5.14. マルチロールサポートの無効化

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

7.5.15. KRA の設定

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

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

7.5.15.2. KRA 暗号化設定の設定

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

7.5.16. ユーザーインターフェイスを使用するようにユーザーを設定する

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

7.5.17. 署名付き監査ログの有効化

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

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

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

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

  1. pki-server ユーティリティーを使用して、--logSigning オプションを true に設定します。

    Copy to Clipboard Toggle word wrap
    # pki-server subsystem-audit-config-mod --logSigning True
      ...
      Log Signing: True
      ...
  2. インスタンスを再起動します。

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

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

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

7.5.18. 暗号リストの更新

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.18.1. サーバーとして機能する CS インスタンスの暗号の設定

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

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

重要

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

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

    Copy to Clipboard Toggle word wrap
    <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.18.2. クライアントとして機能する CS インスタンスの暗号の設定

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

重要

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

  • CS インスタンスが内部 LDAP データベースのクライアントとして機能している場合。

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

    Copy to Clipboard Toggle word wrap
    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 ファイルに追加します。

    Copy to Clipboard Toggle word wrap
    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 ファイルに追加します。

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

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

Copy to Clipboard Toggle word wrap
# 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 ウォッチドッグを使用している場合は以下を使用します。

Copy to Clipboard Toggle word wrap
# 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.18.3. DS インスタンスの暗号の設定

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

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

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

      Copy to Clipboard Toggle word wrap
      # dsconf -D "cn=Directory Manager" ldap://rhds11.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"
    2. DS インスタンスを再起動します。

      Copy to Clipboard Toggle word wrap
      # dsctl slapd-CC-RSA-SubCA-LDAP stop
      Copy to Clipboard Toggle word wrap
      # dsctl slapd-CC-RSA-SubCA-LDAP start
    3. 有効な暗号を一覧表示して確認します。

      Copy to Clipboard Toggle word wrap
      # dsconf -D "cn=Directory Manager" ldap://rhds11.example.com:7389 security ciphers list --enabled
      
      Enter password for cn=Directory Manager on ldap://rhds11.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.19. 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.19.1. KRA

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

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

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

  1. KRA を停止します。

    Copy to Clipboard Toggle word wrap
    pki-server stop <subsystem instance name>
  2. /var/lib/pki/<subsystem instance name>/CS.cfg 設定ファイルを編集し、次の 3 行を追加します。

    Copy to Clipboard Toggle word wrap
    keyWrap.useOAEP=true
    kra.legacyPKCS12=false
    kra.nonLegacyAlg=AES/None/PKCS5Padding/Kwp/256

    上記の最初の行は OAEP に関連し、最後の 2 つの設定は OAEP シナリオでの適切な KRA 操作を可能にするための補足的な設定です。上記の状況では、AES ベースの “KWP” アルゴリズムが使用されます。

  3. KRA を起動します。

    Copy to Clipboard Toggle word wrap
    pki-server start <subsystem instance name>

7.5.19.2. TKS

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

  1. TKS を停止します。

    Copy to Clipboard Toggle word wrap
    pki-server stop <subsystem instance name>
  2. /var/lib/pki/<subsystem instance name>/CS.cfg 設定ファイルを編集し、次のエントリーを追加します。

    Copy to Clipboard Toggle word wrap
    keyWrap.useOAEP=true
  3. TKS を起動します。

    Copy to Clipboard Toggle word wrap
    pki-server start <subsystem instance name>

7.5.19.3. TPS

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

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

  1. TKS を停止します。

    Copy to Clipboard Toggle word wrap
    pki-server stop <subsystem instance name>
  2. /var/lib/pki/<subsystem instance name>/CS.cfg 設定ファイルを編集し、次のエントリーを追加します。

    Copy to Clipboard Toggle word wrap
    keyWrap.useOAEP=true
  3. TKS を起動します。

    Copy to Clipboard Toggle word wrap
    pki-server start <subsystem instance name>
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.