7.10. インストール後のタスク
pkispawn
ユーティリティーを使用したインストールが完了したら、サイトの設定に応じて、さらに設定をカスタマイズすることができます。詳細は、パートIII「Certificate System の設定」で説明してください。
このセクションでは、デプロイメントのセキュリティーを強化するために、パートIII「Certificate System の設定」 からの操作のリストを紹介します。
7.10.1. RHCS の日付/時刻の設定
RHCS を実行するための時間を正しく設定しておくことが重要です。『Red Hat Certificate System 管理ガイド』 の 『日時の設定』 セクションを参照してください。
7.10.2. 一時的な証明書の置き換え
注記
このセクションでは、ルート CA をインストールして実行する必要があります。以下の手順は、インストールの完了後に実行します。
以下の手順では、一時的な自己署名 Directory Server 証明書を新しくインストールした CA によって発行された永続的な Directory Server 証明書に置き換えるプロセス、または古い Directory Server 証明書を新しいものに置き換えるプロセスを説明します。
- 新しい Directory Server サーバー証明書を取得します。CA が署名した新規証明書の要求を送信します。CMC メソッドを使用して新しい Directory Server 証明書を取得するには、『Red Hat Certificate System 管理ガイド』 の 『システム証明書およびサーバー証明書の取得』 を参照してください。上記のセクションで、TLS サーバー証明書の作成に関するガイダンスに従ってください。証明書を作成したら、Directory Server 証明書データベースにインポートし直す必要があります。
- NSS データベースにアクセスする前に、Directory Server インスタンスを停止します。
# systemctl stop dirsrv@instance_name
- 古い Directory Server 証明書を削除します。
# certutil -F -d /etc/dirsrv/slapd-instance_name -f /etc/dirsrv/slapd-instance_name/password.txt -n "DS Certificate"
- 先ほどダウンロードした CA 証明書をインポートします。
# PKICertImport -d /etc/dirsrv/slapd-instance_name -f /etc/dirsrv/slapd-instance_name/password.txt -n "CA Certificate" -t "CT,C,C" -a -i ca.crt -u L
- 先にダウンロードした新しい Directory Server 証明書をインポートします。
# PKICertImport -d /etc/dirsrv/slapd-instance_name -f /etc/dirsrv/slapd-instance_name/password.txt -n "DS Certificate" -t ",," -a -i ds.crt -u V
「HSM への証明書のインポート」 も併せて参照してください。 - Directory Server インスタンスを開始します。
# systemctl start dirsrv@instance_name
- PKI CA から古い Directory Server 証明書を削除します。
- Certificate System インスタンスを停止します。
# systemctl stop pki-tomcatd@instance_name.service
- 証明書を削除します。
# certutil -D -d /var/lib/pki/instance_name/alias/ -n "DS Certificate"
- Certificate System インスタンスを起動します。
# systemctl start pki-tomcatd@instance_name.service
- 新しい Directory Server 証明書が、NSS データベースにインストールされている CA で署名されていることを確認します。
- Directory Server 証明書の表示
$ certutil -L -d /etc/dirsrv/slapd-instance_name -n "DS Certificate" Issuer: "CN=CA Signing Certificate,O=EXAMPLE" Subject: "CN=server.example.com"
- 古い Directory Server 証明書が PKI NSS データベースに存在しなくなったことを確認します。
$ certutil -L -d /var/lib/pki/instance_name/alias
- Certificate System が、新しい証明書を使用して Directory Server に接続できることを確認します。
$ pki cert-find
7.10.3. TLS クライアント認証の有効化
注記
このセクションでは、ルート CA をインストールして実行する必要があります。一時的な LDAP サーバー証明書を使用している場合は、最初に 「一時的な証明書の置き換え」 で置き換えます。以下の手順は、インストールの完了後に実行します。
TLS クライアント認証を有効にすることを選択した場合は、CS サブシステムのインストール時に基本的な TLS サーバー認証を設定して実行すると、逆戻りして、特定のサブシステムから LDAP サーバーへのクライアント認証の有効化を試みることができます。
クライアント認証の設定には 2 つの部分があります。最初の部分は、TLS の相互認証を必要とする LDAP ディレクトリーを設定します。この手順は、『Red Hat Directory Server 管理ガイド』 の 証明書ベースのクライアント認証の使用 を参照してください。
以下の点に注意してください。
pkispawn
は、すでに内部ディレクトリーサーバー上に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.10.4. セッションタイムアウトの設定
さまざまなタイムアウト設定がシステムに存在し、終了前に TLS セッションがアイドル状態の意地する時間に影響を与える可能性があります。詳細は、「セッションのタイムアウト」 を参照してください。
7.10.5. CRL または証明書の発行
CRL 公開は、OCSP サービスを提供する際に重要です。証明書の公開は任意になりますが、多くの場合、サイトで必要になります。詳細は、『Red Hat Certificate System 管理ガイド』 の 『証明書および CRL の公開』 セクションを参照してください。
7.10.6. 証明書登録プロファイル (CA) の設定
RHCS には、証明書登録プロファイルのカスタマイズを可能にするリッチプロファイルフレームワークがあります。システムで使用できるデフォルトのプロファイルを有効またはにしたり、既存のプロファイルを変更したり、独自のプロファイルを作成することが非常に一般的です。詳細は、16章証明書プロファイルの設定 を参照してください。
7.10.7. アクセスバナーの有効化
ユーザーインターフェイスバナーを有効にするには、「アクセスバナーの有効化」を参照してください。
7.10.8. Watchdog サービスの有効化
ウォッチドッグ (nuxwdog) サービスは、セキュアなシステムパスワード管理を提供します。詳細は、「Watchdog サービスの有効化」 を参照してください。
7.10.9. CMC 登録および失効 (CA) の設定
証明書の登録と失効は CMC で行うことができます。
- CMC Shared Token Feature の有効化に関する詳細は、「CMC 共有シークレット機能の有効化」 を参照してください。
PopLinkWittness
機能を有効にする方法は、「PopLinkWittnessV2
機能の有効化」 を参照してください。- Web ユーザーインターフェイスの
CMCRevoke
を有効にする方法は、「Web ユーザーインターフェイスの CMCRevoke の有効化」 を参照してください。
7.10.10. Java コンソールの TLS クライアント認証
Certificate System 管理者が Java コンソールにログインするときにユーザー TLS クライアント証明書を提示するように要求するには、「TLS クライアント証明書認証を使用するための
pkiconsole
要件の設定」 を参照してください。
注記
pkiconsole
は非推奨になりました。
7.10.11. ロールユーザーの作成
ブートストラップユーザーを削除できるように、実際のロールユーザーを作成します。
ユーザーを作成して異なる特権ロールに割り当てて、Certificate System を管理するには、19章ロールユーザーの作成 を参照してください。
7.10.12. Bootstrap ユーザーの削除
実際のロールユーザーが作成されると、インストール時に自動的に作成されたブートストラップユーザーは不要になりました。このアカウントを削除するには、個人個人に割り当てられている新しい管理者アカウントを作成したことを確認してから、20章Bootstrap ユーザーの削除 を参照してください。
7.10.13. マルチロールサポートの無効化
ブートストラップユーザーが削除された後にマルチロールサポートを無効にするには、「マルチロールサポートの無効化」 を参照してください。
7.10.14. KRA の設定
7.10.14.1. KRA (Key Recovery Authority) に複数のエージェント承認の要件の追加
複数の KRA エージェントがキーリカバリーを承認するための要件を設定するには、『Red Hat Certificate System 管理ガイド』の『コマンドラインでのエージェント承認キーリカバリーの設定』 を参照してください。
7.10.14.2. KRA 暗号化設定の設定
キーの暗号化/ラップアルゴリズムを設定する場合は、「KRA 操作の暗号化」 を参照してください。
7.10.15. ユーザーインターフェイスを使用するようにユーザーを設定
ユーザーが承認されたユーザーインターフェイスを使用する前に、初期化を行う必要があります。ユーザー (管理ロールなど) は、ユーザーインターフェイスにアクセスするためにクライアントを設定するために必要です。『Red Hat Certificate System 管理ガイド』 の 『クライアント NSS データベースの初期化』 セクションを参照してください。