7.13. インストール後の設定


この章では、サブシステムをインストールしてから実行されるインストール後のタスクを説明します。

pkispawn ユーティリティーを使用してインストールを完了すると、特定のアクションが必須になるか、強く推奨されます。サイトの設定によっては、いくつかのオプションのアクションも役立ちます。

オプションの手順は、パートIII「パート III: Red Hat Certificate System の設定」 を参照してください。有用なインストール後の手順には、次のものがあります。

必須または強く推奨される手順として、以下に説明するアクションを実行してください。

重要

インスタンスを起動または再起動するまで、設定の変更は有効になりません。一般的に、すべての OS ファイルシステムレベルのインストール後の設定を実行する前に、すべての CS インスタンスが停止していることを確認する必要があります。完了したら、インスタンスを再起動できます。

7.13.1. RHCS の日付と時刻の設定

RHCS を実行するには、正しい時刻を設定することが重要です。システム時間は常に 協定世界時 (UTC) で維持され、必要に応じてアプリケーション内でローカル時間に変換されます。ローカルタイム は、夏時間 (DST) を考慮に入れた現行タイムゾーンの実際の時刻です。

timedatectl ユーティリティーは、systemd システムおよびサービスマネージャーの一部として配布されており、システムクロック設定を確認および変更できます。

  • 現在の時刻を変更するには、以下を実行します。

    Copy to Clipboard Toggle word wrap
    # timedatectl set-time HH:MM:SS

    HH は時間、MM は分、SS は秒 (すべて 2 桁) の数字に置き換えます。

  • 現在の日付を変更するには、以下を実行します。

    Copy to Clipboard Toggle word wrap
    # timedatectl set-time YYYY-MM-DD

    YYYY は 4 桁の年に、MMDD は 2 桁の月と日に置き換えます。

  • タイムゾーンを設定するには、以下を実行します。

    1. まず、利用可能なタイムゾーンのリストを表示します。

      Copy to Clipboard Toggle word wrap
      # timedatectl list-timezones
    2. 上記のリストに基づき、次のコマンドを実行してタイムゾーンを設定します。

      Copy to Clipboard Toggle word wrap
      # timedatectl set-timezone <your_preferred_timezone>

この時間の変更はオペレーティングシステムによって監査されます。詳細は、「時間変更イベントの監査」 を参照してください。

7.13.2. セッションタイムアウトの設定

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

7.13.3. 証明書の SubjectKeyIdentifier 拡張に非 SHA1 メッセージダイジェストアルゴリズムを設定する

登録プロファイルで設定されている場合、SubjectKeyIdentifier 拡張はデフォルトで SHA-1 を使用して計算されます。別のアルゴリズムに設定するには、登録プロファイルを編集する必要があります。以下に例を示します。

  1. 証明書の登録プロファイルを開きます。

    Copy to Clipboard Toggle word wrap
    # vi /var/lib/pki/rhcs10-RSA-SubCA/ca/profiles/ca/caCMCcaCert.cfg
  2. 次のパラメーターを追加します。

    Copy to Clipboard Toggle word wrap
    policyset.caCertSet.8.default.params.messageDigest=SHA-256
  3. ファイルを保存し、CA を再起動します。
注記

SubjectKeyIdentifierExtensionAuthorityKeyIdentifierExtension の前に配置してください。そうでない場合は、list パラメーター内の位置を調整します。たとえば、8SubjectKeyIdentifierExtension で、4AuthorityKeyIdentifierExtension の場合、以下のようにリスト内で 84 の前に配置されます。

Copy to Clipboard Toggle word wrap
policyset.caCertSet.list=1,2,3,8,4,5,6,9,10

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

CMC 経由で証明書の登録と取り消しを実行できます。この設定は、「CMC の設定」 で説明しています。具体的には以下を実行します。

7.13.5. Nuxwdog (ウォッチドッグサービス) の有効化

ウォッチドッグ (nuxwdog) サービスは、セキュアなシステムパスワード管理を提供します。詳細は、「Watchdog サービスの有効化」 を参照してください。このセクションでは、インスタンスごとに Nuxwdog ウォッチドッグを有効にする方法を説明します。

7.13.5.1. RootCA の Nuxwdog の有効化

次の手順は、RootCA インスタンスで Nuxwdog を有効にするために必要なステップを説明しています。

前提条件

  • root として rhcs10.example.com にログインしている。
  • インスタンスが停止していることを確認する。そうでない場合は、systemctl stop pki-tomcatd@rhcs10-RSA-RootCA.service コマンドを使用して停止します。

手順

  1. 以下の例のように、cms.tokenList = <HSM_TOKEN_NAME> パラメーターを CS.cfg に追加します。

    Copy to Clipboard Toggle word wrap
    # cat /var/lib/pki/rhcs10-RSA-RootCA/ca/conf/CS.cfg | grep cms.tokenList
    
    cms.tokenList=NHSM-CONN-XC
  2. パスワードファイルを別のディレクトリーに移動します。

    Copy to Clipboard Toggle word wrap
    # mv /var/lib/pki/rhcs10-RSA-RootCA/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
  3. Nuxwdog サービスを有効にします。

    Copy to Clipboard Toggle word wrap
    # pki-server instance-nuxwdog-enable rhcs10-RSA-RootCA
    ---------------------------
    Nuxwdog enabled for instance rhcs10-RSA-RootCA.
    ---------------------------
  4. Nuxwdog サービスを使用してインスタンスを起動します。パスワードの入力が求められます。パスワードは、前の手順で保存するように指示された password.conf ファイル ( 〜/<YOUR_PREFERRED_DIR>/) にあります。Nuxwdog を正常に有効にすると、CS インスタンスの開始/停止/再起動/ステータスコマンドが異なることに注意してください。

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-RootCA.service
    
    [rhcs10-RSA-RootCA] Please provide the password for internal: *****
    [rhcs10-RSA-RootCA] Please provide the password for hardware-NHSM-CONN-XC: *****

検証手順:

  • Nuxwdog を使用して RootCA インスタンスのステータスを確認します。

    Copy to Clipboard Toggle word wrap
    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-RootCA.service
    
    ● pki-tomcatd-nuxwdog@rhcs10-RSA-RootCA.service - PKI Tomcat Server rhcs10-RSA-RootCA
    Started by Nuxwdog
      Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
      Active: active (running) since …

7.13.5.2. SubCA の Nuxwdog の有効化

次の手順は、SubCA インスタンスで Nuxwdog を有効にするために必要な手順を示しています。

前提条件

  • root として rhcs10.example.com にログインしている。
  • インスタンスが停止していることを確認する。そうでない場合は、systemctl stop pki-tomcatd@rhcs10-RSA-SubCA.service コマンドを使用して停止します。

手順

  1. 以下の例のように、cms.tokenList = <HSM_TOKEN_NAME> パラメーターを CS.cfg に追加します。

    Copy to Clipboard Toggle word wrap
    # cat /var/lib/pki/rhcs10-RSA-SubCA/ca/conf/CS.cfg | grep cms.tokenList
    
    cms.tokenList=NHSM-CONN-XC
  2. パスワードファイルを別のディレクトリーに移動します。

    Copy to Clipboard Toggle word wrap
    # mv /var/lib/pki/rhcs10-RSA-SubCA/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
  3. Nuxwdog サービスを有効にします。

    Copy to Clipboard Toggle word wrap
    # pki-server instance-nuxwdog-enable rhcs10-RSA-SubCA
    ---------------------------
    Nuxwdog enabled for instance rhcs10-RSA-SubCA.
    ---------------------------
  4. Nuxwdog サービスを使用してインスタンスを起動します。Nuxwdog を正常に有効にすると、CS インスタンスの開始/停止/再起動/ステータスコマンドが異なることに注意してください。

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service
    
    [rhcs10-RSA-SubCA] Please provide the password for internal: *****
    [rhcs10-RSA-SubCA] Please provide the password for hardware-NHSM-CONN-XC: *****
    [rhcs10-RSA-SubCA] Please provide the password for Rule SharedToken: ******

検証手順:

  • Nuxwdog を使用して SubCA インスタンスのステータスを確認します。

    Copy to Clipboard Toggle word wrap
    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service
    
    ● pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service - PKI Tomcat Server rhcs10-RSA-SubCA
    Started by Nuxwdog
      Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
      Active: active (running) since …

7.13.5.3. OCSP の Nuxwdog の有効化

次の手順は、OCSP インスタンスで Nuxwdog を有効にするために必要な手順を示しています。

前提条件

  • root として rhcs10.example.com にログインしている。
  • インスタンスが停止していることを確認する。そうでない場合は、関連するインスタンスに対して systemctl stop pki-tomcatd@rhcs10-RSA-OCSP-rootca.servicesystemctl stop pki-tomcatd@rhcs10-RSA-OCSP-subca.service などを使用して停止します。

手順

たとえば RootCA の OCSP の場合は以下を実行します。

  1. 以下の例のように、cms.tokenList = <TOKEN_NAME> パラメーターを CS.cfg に追加します。

    Copy to Clipboard Toggle word wrap
    # cat /var/lib/pki/rhcs10-RSA-OCSP-rootca/ocsp/conf/CS.cfg | grep cms.tokenList
    
    cms.tokenList=NHSM-CONN-XC
  2. パスワードファイルを別のディレクトリーに移動します。

    Copy to Clipboard Toggle word wrap
    # mv /var/lib/pki/rhcs10-RSA-OCSP-rootca/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
  3. Nuxwdog サービスを有効にします。

    Copy to Clipboard Toggle word wrap
    # pki-server instance-nuxwdog-enable rhcs10-RSA-OCSP-rootca/
    ---------------------------
    Nuxwdog enabled for instance rhcs10-RSA-OCSP-rootca/.
    ---------------------------
  4. Nuxwdog サービスを使用してインスタンスを起動します。

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service
    
    [rhcs10-RSA-OCSP-rootca/] Please provide the password for internal: *****
    [rhcs10-RSA-OCSP-rootca/] Please provide the password for hardware-NHSM-CONN-XC: *****
  5. インスタンスの名前を適宜変更し (例: rhcs10-RSA-OCSP-subca)、SubCA の OCSP に対して上記の手順を繰り返します。

検証

  • Nuxwdog を使用して OCSP インスタンスのステータスを確認します。

    Copy to Clipboard Toggle word wrap
    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service
    
    ● pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service - PKI Tomcat Server rhcs10-RSA-OCSP-rootca/
    Started by Nuxwdog
      Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
      Active: active (running) since …
    Copy to Clipboard Toggle word wrap
    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca.service
    
    ● pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca/.service - PKI Tomcat Server rhcs10-RSA-OCSP-subca/
    Started by Nuxwdog
      Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
      Active: active (running) since …

7.13.5.4. KRA の Nuxwdog の有効化

次の手順は、KRA インスタンスで Nuxwdog を有効にするために必要な手順を示しています。

前提条件

  • root として rhcs10.example.com にログインしている。
  • インスタンスが停止していることを確認する。そうでない場合は、systemctl stop pki-tomcatd@rhcs10-RSA-KRA.service コマンドを使用して停止します。

手順

  1. 以下の例のように、cms.tokenList =<TOKEN_NAME> パラメーターを CS.cfg ファイルに追加します。

    Copy to Clipboard Toggle word wrap
    # cat /var/lib/pki/rhcs10-RSA-KRA/kra/conf/CS.cfg | grep cms.tokenList
    
    cms.tokenList=NHSM-CONN-XC
  2. パスワードファイルを別のディレクトリーに移動します。

    Copy to Clipboard Toggle word wrap
    # mv /var/lib/pki/rhcs10-RSA-KRA/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
  3. Nuxwdog サービスを有効にします。

    Copy to Clipboard Toggle word wrap
    # pki-server instance-nuxwdog-enable rhcs10-RSA-KRA
    ---------------------------
    Nuxwdog enabled for instance rhcs10-RSA-KRA.
    ---------------------------
  4. Nuxwdog サービスを使用してインスタンスを起動します。

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service
    
    [rhcs10-RSA-KRA] Please provide the password for internal: *****
    [rhcs10-RSA-KRA] Please provide the password for hardware-NHSM-CONN-XC: *****

検証手順:

  • Nuxwdog を使用して KRA インスタンスのステータスを確認します。

    Copy to Clipboard Toggle word wrap
    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service
    
    ● pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service - PKI Tomcat Server rhcs10-RSA-KRA
    Started by Nuxwdog
      Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
      Active: active (running) since …

7.13.5.5. TKS の Nuxwdog の有効化

次の手順は、TKS インスタンスで Nuxwdog を有効にするために必要な手順を示しています。

前提条件

  • root として rhcs10.example.com にログインしている。
  • インスタンスが停止していることを確認する。そうでない場合は、systemctl stop pki-tomcatd@rhcs10-RSA-TKS.service コマンドを使用して停止します。

手順

  1. 以下の例のように、cms.tokenList =<TOKEN_NAME> パラメーターを CS.cfg ファイルに追加します。

    Copy to Clipboard Toggle word wrap
    # cat /var/lib/pki/rhcs10-RSA-TKS/TKS/conf/CS.cfg | grep cms.tokenList
    
    cms.tokenList=NHSM-CONN-XC
  2. パスワードファイルを別のディレクトリーに移動します。

    Copy to Clipboard Toggle word wrap
    # mv /var/lib/pki/rhcs10-RSA-TKS/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
  3. Nuxwdog サービスを有効にします。

    Copy to Clipboard Toggle word wrap
    # pki-server instance-nuxwdog-enable rhcs10-RSA-TKS
    ---------------------------
    Nuxwdog enabled for instance rhcs10-RSA-TKS.
    ---------------------------
  4. Nuxwdog サービスを使用してインスタンスを起動します。

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-TKS.service
    
    [rhcs10-RSA-TKS] Please provide the password for internal: *****
    [rhcs10-RSA-TKS] Please provide the password for hardware-NHSM-CONN-XC: *****

検証手順:

  • Nuxwdog を使用して TKS インスタンスのステータスを確認します。

    Copy to Clipboard Toggle word wrap
    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-TKS.service
    
    ● pki-tomcatd-nuxwdog@rhcs10-RSA-TKS.service - PKI Tomcat Server rhcs10-RSA-TKS
    Started by Nuxwdog
      Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
      Active: active (running) since …

7.13.5.6. TPS の Nuxwdog の有効化

次の手順は、TPS インスタンスで Nuxwdog を有効にするために必要な手順を示しています。

前提条件

  • root として rhcs10.example.com にログインしている。
  • インスタンスが停止していることを確認する。そうでない場合は、systemctl stop pki-tomcatd@rhcs10-RSA-TPS.service コマンドを使用して停止します。

手順

  1. 以下の例のように、cms.tokenList =<TOKEN_NAME> パラメーターを CS.cfg ファイルに追加します。

    Copy to Clipboard Toggle word wrap
    # cat /var/lib/pki/rhcs10-RSA-TPS/TPS/conf/CS.cfg | grep cms.tokenList
    
    cms.tokenList=NHSM-CONN-XC
  2. パスワードファイルを別のディレクトリーに移動します。

    Copy to Clipboard Toggle word wrap
    # mv /var/lib/pki/rhcs10-RSA-TPS/conf/password.conf ~/<YOUR_PREFERRED_DIR>/
  3. Nuxwdog サービスを有効にします。

    Copy to Clipboard Toggle word wrap
    # pki-server instance-nuxwdog-enable rhcs10-RSA-TPS
    ---------------------------
    Nuxwdog enabled for instance rhcs10-RSA-TPS.
    ---------------------------
  4. Nuxwdog サービスを使用してインスタンスを起動します。

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-TPS.service
    
    [rhcs10-RSA-TPS] Please provide the password for internal: *****
    [rhcs10-RSA-TPS] Please provide the password for hardware-NHSM-CONN-XC: *****

検証手順:

  • Nuxwdog を使用して TPS インスタンスのステータスを確認します。

    Copy to Clipboard Toggle word wrap
    # systemctl status pki-tomcatd-nuxwdog@rhcs10-RSA-TPS.service
    
    ● pki-tomcatd-nuxwdog@rhcs10-RSA-TPS.service - PKI Tomcat Server rhcs10-RSA-TPS
    Started by Nuxwdog
      Loaded: loaded (/lib/systemd/system/pki-tomcatd-nuxwdog@.service; enabled; vendor preset: disabled)
      Active: active (running) since …

7.13.6. クライアント認証を使用した pkiconsole ログイン設定

このセクションでは、クライアント認証を使用した pkiconsole ログインの設定を説明します。次の設定では、インスタンスは CA、OCSP、KRA、または TKS のいずれかになります。

必要な設定

pkiconsole TLS 接続を許可するように各 CS インスタンスを設定する必要があります。

  1. rhcs10.example.com に root としてログインします。
  2. クライアント認証でのコンソールログインが必要なサーバーを停止します。

    Copy to Clipboard Toggle word wrap
    # pki-server stop rhcs10-<INSTANCE>

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

    Copy to Clipboard Toggle word wrap
    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service
  3. /var/lib/pki/<instance name>/<subsystem>/conf でディレクトリーを変更します。たとえば、RootCA conf ディレクトリーに変更する場合、以下を実行します。

    Copy to Clipboard Toggle word wrap
    # cd /var/lib/pki/rhcs10-RSA-RootCA/ca/conf
  4. 以下の例のように、CS.cfg ファイルを変更して、authTypepwd から sslclientauth に変更します。

    Copy to Clipboard Toggle word wrap
    authType=sslclientauth
    注記

    または、config-set コマンドを使用して、CS.cfgauthType=sslclientauth という行を追加することもできます。たとえば、ca-config-set を使用して RootCA に追加します。

    Copy to Clipboard Toggle word wrap
    # pki-server ca-config-set -i rhcs10-RSA-RootCA authType sslclientauth
  5. サーバーを起動します。

    Copy to Clipboard Toggle word wrap
    # pki-server start rhcs10-<INSTANCE>

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

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service

手順

各 RHCS 管理者は、TLS 接続で pkiconsole を使用する前に、いくつか設定を実行する必要があります。

  1. root 以外の管理者ユーザー (例: jgenie) として rhcs10.example.com にログインします。
  2. ブートストラップ管理ユーザーは、SubCA および RootCA 署名証明書を jgenie に渡す必要があります。rhcs10.example.com 上の /opt/pki_rsa/subCA.pem/opt/pki_rsa/rootCA.pem の内容を受け取った後、jgenie はその内容をそれぞれ /home/jgenie/certs_db/rsa_subCA.pem/home/jgenie/certs_db/rsa_rootCA.pem にコピーする必要があります。
  3. nssdb がまだ存在しない場合は、作成します。

    Copy to Clipboard Toggle word wrap
    $ pki -d /home/jgenie/.redhat-idm-console -c SECret.123 client-init
  4. ロールユーザー証明書をインポートします (例: /home/jgenie/certs_db/rsa_SubCA_AdminV.p12)。

    Copy to Clipboard Toggle word wrap
    $ pki -d /home/jgenie/.redhat-idm-console -c SECret.123 client-cert-import --pkcs12 /home/jgenie/certs_db/rsa_SubCA_AdminV.p12 --pkcs12-password SECret.123
  5. CA 証明書をインポートします。

    Copy to Clipboard Toggle word wrap
    $ pki -d /home/jgenie/.redhat-idm-console -c SECret.123 client-cert-import "CA Signing Cert - rhcs10-RSA-SubCA" --ca-cert /home/jgenie/certs_db/rsa_subCA.pem
    -------------------------------------
    Imported certificate "CA Signing Cert - rhcs10-RSA-SubCA"
    -------------------------------------
    Copy to Clipboard Toggle word wrap
    $ pki -d /home/jgenie/.redhat-idm-console -c SECret.123 client-cert-import "CA Signing Cert - rhcs10-RSA-RootCA" --ca-cert /home/jgenie/certs_db/rsa_rootCA.pem
    -------------------------------------
    Imported certificate "CA Signing Cert - rhcs10-RSA-RootCA"
    -------------------------------------

検証:

  • このサーバーへの認証用の管理者ユーザー証明書を確認します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    $ pki -U https://rhcs10.example.com:31443 -d /home/jgenie/.redhat-idm-console -c SECret.123 -n rsa_SubCA_AdminV ca-user-find
    1. クライアント認証を使用して pkiconsole が ca に接続できることを確認します。

      1. pki 管理者ユーザー (jgenie など) としてログインします。例:

        Copy to Clipboard Toggle word wrap
        $ ssh -X jgenie@rhcs10.example.com
      2. pkiconsole を実行します。以下に例を示します。

        Copy to Clipboard Toggle word wrap
        $ pkiconsole -d /home/jgenie/.redhat-idm-console -n rsa_SubCA_AdminV https://rhcs10.example.com:31443/ca
注記

pkiconsole の起動時に No X11 DISPLAY variable was set, but this program performed an operation which requires it エラーが表示される場合は、次の手順を試してください。

  1. root ユーザーとして xauthrhcs10.example.com にインストールします。

    Copy to Clipboard Toggle word wrap
    # dnf install xauth
  2. pkiconsole を実行するには、RHCS 管理者ユーザーとして再度ログインします。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # ssh -X jgenie@rhcs10.example.com
    Copy to Clipboard Toggle word wrap
    # pkiconsole -d /home/jgenie/.redhat-idm-console -n rsa_SubCA_AdminV https://rhcs10.example.com:31443/ca

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

前提条件

  • root ユーザーとして rhcs10.example.com にログインしている。

手順

  1. インスタンスを停止します。たとえば KRA の場合は以下を実行します。

    Copy to Clipboard Toggle word wrap
    # pki-server stop rhcs10-RSA-KRA

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

    Copy to Clipboard Toggle word wrap
    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-KRA.service
  2. CS.cfg ファイルで log.instance.SignedAudit.logSigning 属性を true に設定します (デフォルトでは false)。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # vi /var/lib/pki/rhcs10-RSA-KRA/kra/conf/CS.cfg
    Copy to Clipboard Toggle word wrap
    log.instance.SignedAudit.logSigning=true
  3. インスタンスを起動します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # pki-server start rhcs10-RSA-KRA

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

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-KRA.service
注記

CLI 経由で監査ログの署名を行うこともできます。インストールガイドの「署名付き監査ログの有効化」を参照してください。

7.13.8. 監査ログファイルの取得 (監査者)

Auditor (例: rsa_SubCA_AuditV) は、次の手順を使用して署名済みの監査ログにアクセスできます。

手順

  1. rhcs10.example.comAuditor (非 root ユーザー、例: aguru) としてログインします。

    Copy to Clipboard Toggle word wrap
    $ certutil -d /home/aguru/certs_db -L
    
    Certificate Nickname                      Trust Attributes
                                              SSL,S/MIME,JAR/XPI
    
    . . . Output omitted . . .
    
    rsa_SubCA_AuditV                          u,u,u
    CA Signing Cert - rhcs10-RSA-RootCA       CT,C,C
  2. 利用可能な監査ログファイルをリスト表示します。

    Copy to Clipboard Toggle word wrap
    $ pki -d /home/aguru/certs_db -n "rsa_SubCA_AuditV" -c SECret.123 -p 31443 -h `hostname` ca-audit-file-find
    -----------------
    1 entries matched
    -----------------
      File name: ca_audit
      Size: 1184345
    ----------------------------
    Number of entries returned 1
    ----------------------------

    この例では、ca_audit というファイルが 1 つしかありませんが、複数の監査ログファイルを使用できます。

  3. Auditor として、監査ログファイルを取得し、ローカルに保存します。

    Copy to Clipboard Toggle word wrap
    $ pki -d /home/aguru/certs_db -n "rsa_SubCA_AuditV" -c SECret.123 -p 31443 -h `hostname` ca-audit-file-retrieve ca_audit --output /home/aguru/certs_db/ca_audit

    複数のログファイルがある場合は、それらを 1 つずつ取得します。

  4. AuditVerify ツールを使用して署名された監査ログを確認します。

    1. SubCA 監査署名証明書を nssdb にインポートします。

      Copy to Clipboard Toggle word wrap
      $ pki -p 31443 -h `hostname` ca-cert-find --name "CA Audit Signing Certificate"
      ---------------
      1 entries found
      ---------------
        Serial Number: 0xe8e47bf
      
      . . . Output omitted . . .
      Copy to Clipboard Toggle word wrap
      $ pki -d /home/aguru/certs_db -c SECret.123 -p 31443 -h hostname client-cert-import "SubCA Audit Signing Certificate" --serial 0xe8e47bf --trust ",,P"
      ---------------------------------------------------
      Imported certificate "SubCA Audit Signing Certificate"
      ---------------------------------------------------
    2. 監査ログファイルのリストを含むファイルを時系列で作成します。

      Copy to Clipboard Toggle word wrap
      $ cat > /home/aguru/certs_db/audit.txt << EOF
      ca_audit
      EOF
    3. AuditVerify ツールを実行します。

      Copy to Clipboard Toggle word wrap
      $ cd /home/aguru/certs_db/
      Copy to Clipboard Toggle word wrap
      $ AuditVerify -d /home/aguru/certs_db -n "SubCA Audit Signing Certificate" -a audit.txt

7.13.9. OS レベル (実稼働環境) の監査ログの有効化

auditd ロギングフレームワークは、多くの監査機能を追加で提供します。これらの OS レベル (実稼働環境) の監査ログは、Certificate System によって直接提供される機能を補完します。

前提条件

  • このセクションの手順を実行する前に、audit パッケージがインストールされていることを確認してください。

    Copy to Clipboard Toggle word wrap
    # dnf install audit
重要

次の内容の /etc/audit/rules.d/audit.rules ファイルがシステムに存在していることを確認してください。

Copy to Clipboard Toggle word wrap
# cat /etc/audit/rules.d/audit.rules
## First rule - delete all
-D
## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192
## This determine how long to wait in burst of events
--backlog_wait_time 60000
## Set failure mode to syslog
-f 1

Certificate System の監査ログ削除の監査

監査ログが削除されたときの監査イベントを受信するには、ターゲットが Certificate System ログであるシステムコールを監査する必要があります。

  1. 以下の内容で /etc/audit/rules.d/rhcs-audit-log-deletion.rules ファイルを作成します。

    Copy to Clipboard Toggle word wrap
    -a always,exit -F arch=b32 -S unlink -F dir=/var/log/pki -F key=rhcs_audit_deletion
    -a always,exit -F arch=b32 -S rename -F dir=/var/log/pki -F key=rhcs_audit_deletion
    -a always,exit -F arch=b32 -S rmdir -F dir=/var/log/pki -F key=rhcs_audit_deletion
    -a always,exit -F arch=b32 -S unlinkat -F dir=/var/log/pki -F key=rhcs_audit_deletion
    -a always,exit -F arch=b32 -S renameat -F dir=/var/log/pki -F key=rhcs_audit_deletion
    -a always,exit -F arch=b64 -S unlink -F dir=/var/log/pki -F key=rhcs_audit_deletion
    -a always,exit -F arch=b64 -S rename -F dir=/var/log/pki -F key=rhcs_audit_deletion
    -a always,exit -F arch=b64 -S rmdir -F dir=/var/log/pki -F key=rhcs_audit_deletion
    -a always,exit -F arch=b64 -S unlinkat -F dir=/var/log/pki -F key=rhcs_audit_deletion
    -a always,exit -F arch=b64 -S renameat -F dir=/var/log/pki -F key=rhcs_audit_deletion
  2. 次に、auditd サービスを再起動します。

    Copy to Clipboard Toggle word wrap
    # service auditd restart

秘密鍵の使用が承認されていない Certificate System の監査

Certificate System の秘密または秘密鍵へのすべてのアクセスに対する監査イベントを受け取るには、nssdb へのファイルシステムアクセスを監査する必要があります。

  1. 次の内容の /etc/audit/rules.d/rhcs-audit-nssdb-access.rules ファイルを作成します。<instance name> は、現在のインスタンスに置き換えます。

    Copy to Clipboard Toggle word wrap
    -w /etc/pki/<instance name>/alias -p warx -k rhcs_audit_nssdb
  2. /etc/pki/<instance name>/alias の各ファイル (<file>) の /etc/audit/rules.d/rhcs-audit-nssdb-access.rules に、以下の行を追加します。

    Copy to Clipboard Toggle word wrap
    -w /etc/pki/<instance name>/alias/<file> -p warx -k rhcs_audit_nssdb

    たとえば、rhcs10-RSA-SubCA インスタンス上のファイルが cert8.dbkey3.dbNHSM-CONN-XCcert8.dbNHSM-CONN-XCkey3.db、および secmod.db の場合は、設定ファイルに以下が含まれます。

    Copy to Clipboard Toggle word wrap
    -w /etc/pki/rhcs10-RSA-SubCA/alias/ -p warx -k rhcs_audit_nssdb
    -w /etc/pki/rhcs10-RSA-SubCA/alias/ca.crt -p warx -k rhcs_audit_nssdb
    -w /etc/pki/rhcs10-RSA-SubCA/alias/cert9.db -p warx -k rhcs_audit_nssdb
    -w /etc/pki/rhcs10-RSA-SubCA/alias/key4.db -p warx -k rhcs_audit_nssdb
    -w /etc/pki/rhcs10-RSA-SubCA/alias/NHSM-CONN-XCcert9.db -p warx -k rhcs_audit_nssdb
    -w /etc/pki/rhcs10-RSA-SubCA/alias/NHSM-CONN-XCkey4.db -p warx -k rhcs_audit_nssdb
    -w /etc/pki/rhcs10-RSA-SubCA/alias/pkcs11.txt -p warx -k rhcs_audit_nssdb
  3. 次に auditd を再起動します。

    Copy to Clipboard Toggle word wrap
    # service auditd restart
注記

新しいインスタンスを同じシステムに追加するときは常に、/etc/audit/rules.d/rhcs-audit-nssdb-access.rules をデプロイメントして、同じ方法で新しいインスタンスファイルを含めます。

時間変更イベントの監査

時間変更の監査イベントを受信するには、システム時間を変更する可能性のあるシステムコールアクセスを監査する必要があります。

  1. 以下の内容で /etc/audit/rules.d/rhcs-audit-rhcs_audit_time_change.rules ファイルを作成します。

    Copy to Clipboard Toggle word wrap
    -a always,exit -F arch=b32 -S adjtimex,settimeofday,stime -F key=rhcs_audit_time_change
    -a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=rhcs_audit_time_change
    -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=rhcs_audit_time_change
    -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=rhcs_audit_time_change
    -a always,exit -F arch=b32 -S clock_adjtime -F key=rhcs_audit_time_change
    -a always,exit -F arch=b64 -S clock_adjtime -F key=rhcs_audit_time_change
    -w /etc/localtime -p wa -k rhcs_audit_time_change
  2. 次に auditd を再起動します。

    Copy to Clipboard Toggle word wrap
    # service auditd restart

Certificate System 設定へのアクセスの監査

Certificate System インスタンス構成ファイルへのすべての変更に関する監査イベントを受け取るには、これらのファイルのファイルシステムアクセスを監査します。

  1. 以下の内容で /etc/audit/rules.d/rhcs-audit-config-access.rules ファイルを作成します。

    Copy to Clipboard Toggle word wrap
    -w /etc/pki/instance_name/server.xml -p wax -k rhcs_audit_config
  2. また、/etc/pki/instance_name/ ディレクトリーの各サブシステムに次の内容を追加します。

    Copy to Clipboard Toggle word wrap
    -w /etc/pki/instance name/subsystem/CS.cfg -p wax -k rhcs_audit_config

    たとえば CA のみが rhcs10-RSA-SubCA インスタンスにインストールされている場合、/etc/audit/rules.d/rhcs-audit-config-access.rules ファイルには以下が含まれます。

    Copy to Clipboard Toggle word wrap
    -w /etc/pki/rhcs10-RSA-SubCA/server.xml -p wax -k rhcs_audit_config
    -w /etc/pki/rhcs10-RSA-SubCA/ca/CS.cfg -p wax -k rhcs_audit_config

    RHCS NSS データベースへのアクセスは rhcs_audit_nssdb 配下で監査されていることに注意してください。

注記

新しいインスタンスを同じシステムに追加するときは常に、/etc/audit/rules.d/rhcs-audit-nssdb-access.rules をデプロイメントして、同じ方法で新しいインスタンスファイルを含めます。

監査ルールの検証

  1. 各監査ルールを追加して auditd サービスを再起動したら、新しいルールが追加されたことを確認します。

    Copy to Clipboard Toggle word wrap
    # auditctl -l

    新しいルールの内容が出力に表示されるはずです。

監査の検証

rhcs_audit_nssdb のルールが、次のような簡単なテストで機能することを確認できます。

  1. SubCA エイリアスディレクトリーにアクセスします。

    Copy to Clipboard Toggle word wrap
    # cd /etc/pki/rhcs10-RSA-SubCA/alias/
  2. 監査イベントがないかを確認します。

    Copy to Clipboard Toggle word wrap
    # ausearch -k rhcs_audit_nssdb

7.13.10. RHCS サブシステムのピア証明書の検証

RHCS 10.4 は、TLS セッション確立時にクライアントとして動作しているかサーバーとして動作しているかにかかわらず、RHCS サブシステムがピア証明書を検証するためのさまざまなメカニズムを提供します。使用されるメカニズムは OCSP または CRL のいずれかです。

以下に、RHCS サブシステムの各タイプでこれらを有効にする方法の詳細を示します。

7.13.10.1. OCSP のピア証明書ステータスチェックを有効にする

重要

このセクションでは、OCSP サブシステムで失効チェックを有効にする別の方法を説明します。推奨される方法は、「CA/KRA/TKS/TPS の OCSP を有効にする」 セクションを参照してください。

OCSP システム自体に対して OCSP を有効にすると、鶏が先か卵が先かという現象 (ピア AIA が、完全に起動する前に OCSP システム自体を指す) が発生します。幸い OCSP サブシステムは、頻繁に更新される CRL を利用して、別の OCSP システムにアクセスすることなくピアの証明書を検証できます。このような特別な機能を有効にするには、OCSP の CS.cfg で次の 2 つのパラメーターを設定します。

Copy to Clipboard Toggle word wrap
ocsp.store.ldapStore.validateConnCertWithCRL=true
auths.revocationChecking.enabled=true

CS.cfg で 2 つのパラメーターを有効にするだけでなく、その server.xml ファイル (この例では /var/lib/pki/rhcs10-RSA-OCSP-rootca/conf/server.xml および /var/lib/pki/rhcs10-RSA-OCSP-subca/conf/server.xml) で enableOCSP パラメーターを “false” のままにしておく必要があります。

Copy to Clipboard Toggle word wrap
enableOCSP=”false”

7.13.10.2. CA/KRA/TKS/TPS の OCSP を有効にする

注記

このセクションで説明する手順は、OCSP システムの起動時にピア証明書の AIA が同じ OCSP サブシステムを指していなければ、OCSP サブシステムにも適用されます。

たとえば、この章の前半のインストール手順 (7.4.1 および 7.7.1) では、OCSP サーバーの内部ディレクトリーサーバーの server-certs が、再発行され、その AIA は対応する CA の内部 OCSP サービスを指していました。

ここでは、ピア証明書の以下の拡張に従って、ピア証明書の失効ステータスを確認するように CA、OCSP、KRA、TKS、および TPS インスタンスを設定するための手順を示します。

前提条件

  • root ユーザーとして rhcs10.example.com にログインしている。

手順

この手順では、KRA を例として使用します。同様の手順が CA、OCSP、TKS、TPS インスタンスにも適用されます。適切なインスタンスに合わせてコマンドを調整してください。

  1. KRA を停止します。

    Copy to Clipboard Toggle word wrap
    # pki-server stop rhcs10-RSA-KRA

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

    Copy to Clipboard Toggle word wrap
    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-KRA.service
  2. /var/lib/pki/rhcs10-RSA-KRA/conf/server.xml ファイルを編集して、Connector name="Secure" セクションを設定します。

    1. enableRevocationCheck パラメーターを true に設定します。enableRevocationCheckenableOCSP とも呼ばれます。両方ではなく、どちらか一方のみを設定してください。
    2. 次の 2 つのパラメーターとそれらに割り当てられた値を必ず 削除 してください。

      • ocspResponderURL
      • ocspResponderCertNickname

      以下に例を示します。

    Copy to Clipboard Toggle word wrap
    <Connector name="Secure"
         enableRevocationCheck="true"
         ocspCacheSize="1000"
         ocspMinCacheEntryDuration="60"
         ocspMaxCacheEntryDuration="120"
         ocspTimeout="10"
         ...
    />
  3. KRA を起動します。

    Copy to Clipboard Toggle word wrap
    # pki-server start rhcs10-RSA-KRA

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

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-KRA.service
注記

デフォルトでは、インストール中に作成されたすべての RHCS システム証明書は、発行元 CA の内部 OCSP サービス (http://rhcs10.example.com:31080/ca/ocsp など) を指す AIA (Authority Information Access) 拡張機能を使用して生成されます。
KRA をインストールする前に、この OCSP を指すようにデフォルトの AIA 拡張機能を設定する の手順に従って、外部 OCSP を指すようにした場合に、すべての KRA システム証明書 (およびその CA によって発行された他のすべての証明書) は、代わりに外部の OCSP を参照する正しい AIA が使用されるはずです。

重要

OCSP に依存している環境 (上記の server.xmlenableRevocationCheck または enableOCSP パラメーターを設定することで有効化) では、インストール例の KRA、TKS、TPS など、OCSP に依存するインスタンスを起動する前に OCSP インスタンスを起動して実行しておく必要があります。
同様に、外部 OCSP を開始する前に CA が起動して実行されている必要があります。

7.13.10.3. CA で OCSP を使用せずにピア証明書ステータスチェックを有効にする

起動時に CRL 配布ポイントを使用するために必要な証明書 (たとえば、CA の LDAP サーバー証明書) を CA に設定して、起動時の鶏と卵の問題を回避することができます (詳細は 「CA での自動失効チェックの有効化」 の「CRL 配布ポイントのサポートを設定する」を参照してください)。

起動すると、CA は他の CS サブシステムと同様に、OCSP を使用して失効チェックをサポートできます。

注記

証明書失効の検証順序と想定

CRL 配布ポイントと OCSP-aia 拡張は、CS サブシステム上のピア証明書の失効検証中に次のように処理されます。

  • 証明書に CRL 配布ポイントのみが存在する場合:

    • CRL 配布ポイントから取得/関連付けられた CRL ごとに検証されます。

      • CRL に証明書がある場合: 失敗/失効
      • CRL に証明書がない場合: 正常
    • CRL 配布ポイントの URL に到達できない場合、異常ありとみなされます。

      • 失敗/失効 (他のオプションが選択されなかった場合: 無視/不明)
        ocsp-aia が到達不能な場合とは少し異なることに注意してください。
  • 証明書に OCSP-aia のみが存在する場合:

    • OCSP-aia が指す OCSP からの OCSP 応答ごとに検証されます。

      • OCSP レスポンダーが CRL で証明書を見つけた場合: 失敗/失効
      • OCSP レスポンダーが CRL で証明書を見つけられない場合: 正常
    • OCSP-aia の URL が到達不能な場合は異常ありとみなされます。

      • 不正な証明書
        CRL 配布ポイントが到達不能な場合とは少し異なることに注意してください。
  • 証明書に OCSP-aia と CRL 配布ポイントの両方が存在する場合:

    • OCSP-aia が優先されます。正常または異常があります。
    • OCSP-aia の URL が到達不能な場合は、CRL 配布が引き継ぎます。

      • CRL 配布ポイントの URL が到達不能な場合、失敗/失効とみなされます。

7.13.11. 暗号リストの更新

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.13.11.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.13.11.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
Copy to Clipboard Toggle word wrap
# pki-server restart rhcs10-RSA-SubCA
Copy to Clipboard Toggle word wrap
# pki-server restart rhcs10-RSA-OCSP-rootca
Copy to Clipboard Toggle word wrap
# pki-server restart rhcs10-RSA-OCSP-subca
Copy to Clipboard Toggle word wrap
# pki-server restart rhcs10-RSA-KRA

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

Copy to Clipboard Toggle word wrap
# systemctl restart rhcs10-RSA-RootCA
Copy to Clipboard Toggle word wrap
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service
Copy to Clipboard Toggle word wrap
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service
Copy to Clipboard Toggle word wrap
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca.service
Copy to Clipboard Toggle word wrap
# systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service

…​

7.13.11.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.13.12. CS への接続に TLS 相互認証を要求する

デフォルトでは、Red Hat Certificate System は、RHCS 認証プラグインでクライアント証明書の検証を実行することにより、ロールのユーザー操作が TLS 相互認証を通過することをすでに要求していますが、同時に、ロール以外の操作の一部を TLS サーバー認証経由のみで処理できるようにしています。TLS 相互認証は、サーバーコネクターに対してより強力な認証を提供します。次の手順により、サイトは、TLS ハンドシェイク用の証明書を提示できないクライアントが Certificate System インスタンスにアクセスできないようにすることができます。

重要

必要な Certificate System インスタンスをすべてインストールするまで、このセクションの手順を実行しないでください。このセクションの手順を実行したら、後でさらに Certificate System インスタンスをインストールする場合に備えて、変更を元に戻す必要があります。

手順

TLS 相互認証を有効にするには、server.xml 設定ファイルを変更します。

重要

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

  1. server.xml ファイルを編集し、certificateVerification= パラメーターを検索します。
  2. パラメーター値を optional から required に変更します。

    Copy to Clipboard Toggle word wrap
    certificateVerification=required
  3. 変更を有効にするには、各サーバーインスタンスを保存して再起動します。

CS インスタンスを強化したら、通常は TLS 相互認証を必要としない操作で、TLS ハンドシェイク時に有効なクライアント証明書を提示する必要があることに注意してください。これによって影響を受ける操作の例は、CMCSharedToken を使用した登録と、通常は TLS 相互認証を必要としない一部の pki コマンドです。

  • CMCSharedToken を機能させるには、証明書をユーザーに事前に発行し、HttpClient 呼び出し時に HttpClient 設定ファイルを編集して、以下が含まれるようにする必要があります。

    Copy to Clipboard Toggle word wrap
    clientmode=true
    nickname=<client cert that was issued and imported>
  • pki コマンドを機能させるには、有効なクライアント証明書を提示する必要があります。

    • たとえば、元々、ca-cert-find コマンドは相互認証を必要としません。

      Copy to Clipboard Toggle word wrap
      # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 31443 ca-cert-find
    • 現在、新しい制限により、次のことを行う必要があります。

      Copy to Clipboard Toggle word wrap
      # pki -d /root/.dogtag/pki_rsa_bootstrap/certs_db/ -c SECret.123 -p 31443 -n 'SubCA_AdminV' ca-cert-find

      次のリストは、このカテゴリーに分類される pki コマンドを示しています。

      • pki client-cert-request
      • pki ca-authority-find
      • pki ca-authority-show
      • pki ca-cert-find
      • pki ca-cert-show
      • pki ca-cert-export
      • pki ca-cert-status
      • pki ca-cert-request-show
      • pki ca-cert-request-submit
      • pki ca-cert-request-profile-find
      • pki ca-cert-request-profile-show
      • pki ca-cert-signing-show
      • pki ca-cert-signing-export
      • pki ca-cert-transport-show
      • pki ca-cert-transport-export
      • pki ca-feature-find
      • pki ca-feature-show

同じカテゴリーに分類され、同様の処理が必要な他のコマンドが存在する場合があります。

7.13.13. CS から DS への TLS 相互認証を有効にする

CS サブシステムのインストール時に基本的な TLS サーバー認証を設定した後、特定のサブシステムから LDAP サーバーへの TLS 相互認証 (クライアント認証とも呼ばれる) を有効にすることを選択する必要があります。

注記

このセクションは、CS インスタンスがインストールされ、実行されていることが必須となります。一時的な LDAP サーバー証明書 (CA の場合) を使用した場合は、まず以下を実行して証明書を置き換えます。

以下の手順は、インストールの完了後に実行します。

相互認証のセットアップは 2 つのパートで構成されており、まず DS 側で設定し、次に CS 側で設定します。

DS での設定

最初に、TLS 相互認証を要求するように LDAP ディレクトリーを設定する必要があります。

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

  • 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 を再起動します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # dsctl slapd-CC-RSA-SubCA-LDAP restart

CS での設定

次に、正しい認証タイプ (BasicAuth ではなく SslClientAuth) を使用するように 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 です。

  1. 設定する CS インスタンスを停止します。

    Copy to Clipboard Toggle word wrap
    # pki-server stop rhcs10-<INSTANCE>

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

    Copy to Clipboard Toggle word wrap
    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service
  2. 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
  1. CS インスタンスを再起動します。

    Copy to Clipboard Toggle word wrap
    # pki-server start rhcs10-<INSTANCE>

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

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service
注記

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

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

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

7.13.14. supported_groups TLS 拡張機能を更新する

証明機関バージョン 2.1 のプロテクションプロファイル は、TLS 鍵交換用の新しい (より安全な) 名前付きグループを許可しません。この要件を満たすために、次の手順でこれらのグループを無効にする方法を説明します。

  1. 最初に、必要な変更を加えた既存のポリシー (/usr/share/crypto-policies/FIPS.pol) に基づいて一連のポリシーを作成します。これにより、それに応じて別の設定ファイル (/etc/crypto-policies/back-ends/nss.config) が更新されます。
  2. 必要な結果を得るために、変更された設定ファイル (/etc/crypto-policies/back-ends/nss.config) をさらに調整する方法を説明します。
重要

必要なすべての CS インスタンスをインストールするまで、このセクションの手順を実行しないでください。このセクションの手順を実行したら、後でさらに CS インスタンスをインストールする場合は、続行する前に変更を元に戻す必要があります。

Copy to Clipboard Toggle word wrap
# update-crypto-policies --set FIPS

手順

  1. Certificate System サーバーをすべてシャットダウンします。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # pki-server stop rhcs10-<INSTANCE>

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

    Copy to Clipboard Toggle word wrap
    # systemctl stop pki-tomcatd-nuxwdog@rhcs10-<INSTANCE>.service
  2. システムがそのポリシーに基づいているファイルを見つけます。

    Copy to Clipboard Toggle word wrap
    # update-crypto-policies --show

    インストール手順に従った場合、コマンド出力として "FIPS"が表示されます。

  3. 変更のために、現在のポリシーを新しいカスタムポリシーファイルにコピーします。

    Copy to Clipboard Toggle word wrap
    # cp /usr/share/crypto-policies/policies/FIPS.pol /etc/crypto-policies/policies/CC-FIPS.pol
  4. カスタムポリシーファイルを編集します。次に例を示します。

    Copy to Clipboard Toggle word wrap
    # vi /etc/crypto-policies/policies/CC-FIPS.pol

    次の変更を行い、ファイルを保存します。

    1. groups パラメーターの割り当てを次のように変更します。

      Copy to Clipboard Toggle word wrap
      group = SECP256R1 SECP384R1 SECP521R1 \ FFDHE-2048 FFDHE-3072 FFDHE-4096 FFDHE-6144 FFDHE-8192

      to

      Copy to Clipboard Toggle word wrap
      group = SECP256R1 SECP384R1 SECP521R1
    2. key_exchange パラメーターの割り当てを次のように変更します。

      Copy to Clipboard Toggle word wrap
      key_exchange = ECDHE DHE DHE-RSA PSK DHE-PSK ECDHE-PSK

      to

      Copy to Clipboard Toggle word wrap
      key_exchange = ECDHE DHE PSK DHE-PSK ECDHE-PSK
    3. min_dh_size パラメーターの割り当てを次のように変更します。

      Copy to Clipboard Toggle word wrap
      min_dh_size = 2048

      to

      Copy to Clipboard Toggle word wrap
      min_dh_size = 176384
  5. カスタムサイトポリシーを登録します。

    Copy to Clipboard Toggle word wrap
    # update-crypto-policies --set CC-FIPS

    カスタムポリシーファイルへの update_crypto-policies -set 呼び出しの後に、nss.config ファイルに変更が反映されます。
    この手順の 2 番目の部分では、nss.config ファイルにさらに必要な変更を加えます。

  6. nss.config ファイルを編集します。次に例を示します。

    Copy to Clipboard Toggle word wrap
    # vi /etc/crypto-policies/back-ends/nss.config

    config パラメーターの割り当ての下の allow= 文字列で、dtls-version-min=dtls1.2 設定の直後に次の文字列を挿入します。

    Copy to Clipboard Toggle word wrap
    tls-version-max=tls1.2:dtls-version-max=dtls1.2

    結果の config 行は次のようになります。

    Copy to Clipboard Toggle word wrap
    config="disallow=ALL allow=HMAC-SHA256:HMAC-SHA1:HMAC-SHA384:HMAC-SHA512:SECP256R1:SECP384R1:SECP521R1:aes256-gcm:aes256-cbc:aes128-gcm:aes128-cbc:SHA256:SHA384:SHA512:SHA224:ECDHE-RSA:ECDHE-ECDSA:tls-version-min=tls1.2:dtls-version-min=dtls1.2:tls-version-max=tls1.2:dtls-version-max=dtls1.2:DH-MIN=176384:DSA-MIN=2048:RSA-MIN=2048"
  7. nss ベースのアプリケーション/サーバー/クライアントを開始または再起動して、変更が適用されていることを確認します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # pki-server start rhcs10-RSA-RootCA
    Copy to Clipboard Toggle word wrap
    # pki-server restart rhcs10-RSA-SubCA

    …​

    Nuxwdog ウォッチドッグを使用している場合は以下のようになります。

    Copy to Clipboard Toggle word wrap
    # systemctl start pki-tomcatd-nuxwdog@rhcs10-RSA-RootCA.service
    Copy to Clipboard Toggle word wrap
    # systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-SubCA.service
    Copy to Clipboard Toggle word wrap
    # systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-rootca.service
    Copy to Clipboard Toggle word wrap
    # systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-OCSP-subca.service
    Copy to Clipboard Toggle word wrap
    # systemctl restart pki-tomcatd-nuxwdog@rhcs10-RSA-KRA.service

    …​

7.13.15. アクセスバナーの有効化

rhcs10.example.com でアクセスバナーを有効または無効にするには、以下を行います。

  • /etc/pki/instance_name/banner.txt ファイルを作成し、表示するテキストを入力して、バナーを有効にします。バナーテキストは UTF-8 形式を使用する必要があります。
  • 既存のアクセスバナーを無効にする必要がある場合は、/etc/pki/instance_name/banner.txt ファイルを削除するか名前を変更します。以下に例を示します。

    Copy to Clipboard Toggle word wrap
    # mv /etc/pki/instance_name/banner.txt /etc/pki/instance_name/banner.txt.UNUSED

検証:

  1. バナーに無効な文字が含まれていないことを確認します。

    Copy to Clipboard Toggle word wrap
    # pki-server banner-validate -i instance_name
    ---------------
    Banner is valid
    ---------------
  2. 現在設定されているバナーを表示するには、次のコマンドを実行します。

    Copy to Clipboard Toggle word wrap
    # pki-server banner-show -i instance_name

7.13.16. 製品バージョンの確認

Red Hat Certificate System の製品バージョンは、/usr/share/pki/CS_SERVER_VERSION ファイルに保存されます。

インストールされている Red Hat Certificate System サーバーのバージョンを表示するには、以下を実行します。

Copy to Clipboard Toggle word wrap
# cat /usr/share/pki/CS_SERVER_VERSION

Red Hat Certificate System 10.4.3

サーバーをインストールして実行すると、ブラウザーから次の URL にアクセスして、各インスタンスの製品バージョンを確認できます。

  • http://host_name:port_number/ca/admin/ca/getStatus
  • http://host_name:port_number/kra/admin/kra/getStatus
  • http://host_name:port_number/ocsp/admin/ocsp/getStatus
  • http://host_name:port_number/tks/admin/tks/getStatus
  • http://host_name:port_number/tps/admin/tps/getStatus
注記

各コンポーネントは個別のパッケージであるため、バージョン番号は異なります。上記は、現在実行中の各コンポーネントのバージョン番号を示しています。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.