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 署名証明書のエクスポート
pki-server cert-export ca_signing --cert-file ca_signing.crt
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
$ 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
$ pki ca-cert-request-submit --profile caServerCert --csr-file ds_server.csr
7.5.2.2.3. 証明書要求の承認:
PKI エージェントとして、以下を実行します。
pki -n caadmin ca-cert-request-review <request ID> --action approve
$ pki -n caadmin ca-cert-request-review <request ID> --action approve
7.5.2.3. 証明書の取得
DS 管理者ユーザーとして証明書を取得します。
pki ca-cert-export <certificate ID> --output-file ds_server.crt
$ pki ca-cert-export <certificate ID> --output-file ds_server.crt
7.5.2.4. DS インスタンスの停止
NSS データベースを変更する前に、DS インスタンスを停止します。
dsctl localhost stop
$ 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"
# 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 -F -d /etc/dirsrv/slapd-localhost \ -f /etc/dirsrv/slapd-localhost/pwdfile.txt \ -n Self-Signed-CA
$ 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 サーバー証明書のインポート:
pki \ -d /etc/dirsrv/slapd-localhost \ -C /etc/dirsrv/slapd-localhost/pwdfile.txt \ nss-cert-import \ --cert ds_server.crt \ Server-Cert
$ 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
$ 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 接続を有効にするには、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dsconf localhost config replace nsslapd-security=on
$ dsconf localhost config replace nsslapd-security=on
DS インスタンスを起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dsctl localhost start
$ dsctl localhost start
SSL 接続を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow LDAPTLS_REQCERT=never ldapsearch \ -H ldaps://$HOSTNAME:636 \ -x \ -D "cn=Directory Manager" \ -w Secret.123 \ -b "" \ -s base
$ 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
$ 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 署名証明書の作成
次のコマンドで DS 署名 CSR を生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ 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 署名証明書を発行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ 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 署名証明書をインポートします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ 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 署名証明書を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow certutil -L -d /etc/dirsrv/slapd-localhost -n Self-Signed-CA
$ 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 を生成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ 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 サーバー証明書を発行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
$ 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 サーバー証明書のインポート:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pki \ -d /etc/dirsrv/slapd-localhost \ -C /etc/dirsrv/slapd-localhost/pwdfile.txt \ nss-cert-import \ --cert ds_server.crt \ Server-Cert
$ 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 Copied! Toggle word wrap Toggle overflow certutil -L -d /etc/dirsrv/slapd-localhost -n Server-Cert
$ 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 接続を有効にするには、以下を実行します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dsconf localhost config replace nsslapd-security=on
$ dsconf localhost config replace nsslapd-security=on
DS インスタンスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dsctl localhost restart
$ dsctl localhost restart
SSL 接続を確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow LDAPTLS_REQCERT=never ldapsearch \ -H ldaps://$HOSTNAME:636 \ -x \ -D "cn=Directory Manager" \ -w Secret.123 \ -b "" \ -s base
$ 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 Copied! Toggle word wrap Toggle overflow certmap rhcs <certificate issuer DN> rhcs:CmapLdapAttr seeAlso rhcs:verifyCert on
certmap rhcs <certificate issuer DN> rhcs:CmapLdapAttr seeAlso rhcs:verifyCert on
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow certmap rhcs CN=CA Signing Certificate,OU=pki-tomcat-ca,O=pki-tomcat-ca-SD 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.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
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 で行うことができます。
- CMC Shared Token Feature の有効化に関する詳細は、「CMC 共有シークレット機能の有効化」 を参照してください。
-
PopLinkWittness
機能を有効にする方法は、「PopLinkWittnessV2
機能の有効化」 を参照してください。 -
Web ユーザーインターフェイスの
CMCRevoke
を有効にする方法は、「Web ユーザーインターフェイスの CMCRevoke の有効化」 を参照してください。
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. 署名付き監査ログの有効化
デフォルトでは、監査ロギングはインストール時に有効になります。ただし、インストール後に、ログ署名を手動で有効にする必要があります。
現在の監査ロギング設定を表示するには、以下を実行します。
pki-server subsystem-audit-config-show
# 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
に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow pki-server subsystem-audit-config-mod --logSigning True
# pki-server subsystem-audit-config-mod --logSigning True ... Log Signing: True ...
インスタンスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl restart pki-tomcatd@instance_name.service
# systemctl restart pki-tomcatd@instance_name.service
または (
nuxwdog watchdog
を使用している場合)Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl start pki-tomcatd-nuxwdog@instance_name.service
# 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
などにバックアップします。
-
server.xml
ファイルを編集し、メイン SSL ポートの Connector 宣言に移動して、SSLHostConfig 要素を見つけます。 次の設定で SSLHostConfig 要素を変更します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <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">
<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 Copied! Toggle word wrap Toggle overflow 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
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 Copied! Toggle word wrap Toggle overflow 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
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 Copied! Toggle word wrap Toggle overflow 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
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
# 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
# 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 で以下を実行します。
目的の暗号を有効にします (DS インスタンスの SSL 以外のポートを使用します)。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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"
# 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"
DS インスタンスを再起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dsctl slapd-CC-RSA-SubCA-LDAP stop
# dsctl slapd-CC-RSA-SubCA-LDAP stop
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dsctl slapd-CC-RSA-SubCA-LDAP start
# dsctl slapd-CC-RSA-SubCA-LDAP start
有効な暗号を一覧表示して確認します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow dsconf -D "cn=Directory Manager" ldap://rhds11.example.com:7389 security ciphers list --enabled
# 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
注記: OAEP でのコマンドラインインターフェイスの使用例については、管理ガイドを参照してください。
7.5.19.1. KRA
KRA は、OAEP を利用する主要な Certificate System サブシステムの 1 つです。これは、KRA トランスポート証明書が、クライアントプログラムによってキーをラップするために頻繁に使用され、その後 KRA 自体によってアンラップされるためです。
このセクションには、ファームウェア v12.72.1 を搭載した Entrust nShield Connect XC ユニットなど、AES キーのラッピング/アンラッピング操作をサポートする HSM デバイスに対応するための OAEP 以外の設定が含まれています。
サブシステムが含まれるホスト上で、次の操作を (root として) 実行します。
KRA を停止します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pki-server stop <subsystem instance name>
pki-server stop <subsystem instance name>
/var/lib/pki/<subsystem instance name>/CS.cfg
設定ファイルを編集し、次の 3 行を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow keyWrap.useOAEP=true kra.legacyPKCS12=false kra.nonLegacyAlg=AES/None/PKCS5Padding/Kwp/256
keyWrap.useOAEP=true kra.legacyPKCS12=false kra.nonLegacyAlg=AES/None/PKCS5Padding/Kwp/256
上記の最初の行は OAEP に関連し、最後の 2 つの設定は OAEP シナリオでの適切な KRA 操作を可能にするための補足的な設定です。上記の状況では、AES ベースの “KWP” アルゴリズムが使用されます。
KRA を起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pki-server start <subsystem instance name>
pki-server start <subsystem instance name>
7.5.19.2. TKS
サブシステムが含まれるホスト上で、次の操作を (root として) 実行します。
TKS を停止します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pki-server stop <subsystem instance name>
pki-server stop <subsystem instance name>
/var/lib/pki/<subsystem instance name>/CS.cfg
設定ファイルを編集し、次のエントリーを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow keyWrap.useOAEP=true
keyWrap.useOAEP=true
TKS を起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pki-server start <subsystem instance name>
pki-server start <subsystem instance name>
7.5.19.3. TPS
トークン管理システムを使用する場合、TPS と TKS は連携して動作します。正常に動作するには、両方のサブシステムで OAEP を有効にする必要があります。TKS と TPS の通常のインストール順序では、最初に TKS がインストールされ、次に TPS がインストールされます。次の手順は、TKS が OAEP 用に設定されていることが明らかな場合に適用されます。
サブシステムが含まれるホスト上で、次の操作を (root として) 実行します。
TKS を停止します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pki-server stop <subsystem instance name>
pki-server stop <subsystem instance name>
/var/lib/pki/<subsystem instance name>/CS.cfg 設定ファイルを編集し、次のエントリーを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow keyWrap.useOAEP=true
keyWrap.useOAEP=true
TKS を起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow pki-server start <subsystem instance name>
pki-server start <subsystem instance name>