13.3. サブシステムのコンソールおよびサービスを開く
各サブシステムには、ユーザータイプごとに異なるインターフェイスがあります。すべてのサブシステムには、TKS を除くエージェント、管理者、またはエンドユーザー (すべて 3 つ) の Web サービスページがあります。さらに、CA、KRA、OCSP、および TKS はすべて、サーバーにインストールされ、サブシステム自体を管理する管理タスクを実行する Java ベースのコンソールがあります。
外観と、サブシステムの Web ベースのサービスページの機能をカスタマイズして、組織の既存の Web サイトとの統合を改善できます。『Red Hat Certificate System 計画、インストール、およびデプロイメントのガイド』を参照してください。
13.3.1. サブシステムの Web サービスページの検索
CA、KRA、OCSP、TKS、および TPS サブシステムには、エージェント、通常のユーザー、および管理者向けの Web サービスページがあります。これらの Web サービスのメニューには、サブシステムのセキュアなユーザーのポート上でサブシステムホストに URL を開くとアクセスできます。CA の場合の例を以下に示します。
https://server.example.com:8443/ca/services
各サブシステムの主な Web サービスページには、利用可能なサービスページの一覧があります。これらは 表13.1「デフォルトの Web サービスページ」 で要約されています。特定のサービスにアクセスするには、適切なポートにアクセスし、適切なディレクトリーを URL に追加します。たとえば、CA のエンドエンティティー (通常のユーザー) の Web サービスにアクセスするには、以下を実行します。
https://server.example.com:8443/ca/ee/ca
DNS が適切に設定されていると、IPv4 アドレスまたは IPv6 アドレスを使用して、サービスページに接続できます。以下に例を示します。
https://1.2.3.4:8443/ca/services https://[00:00:00:00:123:456:789:00:]:8443/ca/services
一部のサブシステムインターフェイスは、それらにアクセスするためにクライアント認証を必要とします。通常、インターフェイスはエージェントまたは管理者のロールに関連付けられています。他のインターフェイスは、セキュア (SSL 接続) で実行されるインターフェイスであっても、クライアント認証を必要としません。これらのインターフェイス (エンドエンティティーサービスなど) の一部は、クライアント認証を必要とするように設定できますが、クライアント認証をサポートするように設定することはできません。これらの相違点は、表13.1「デフォルトの Web サービスページ」 に記載されています。
注記
サブシステムのエンドユーザーページには誰でもアクセスできますが、エージェントまたは管理者の Web サービスページにアクセスするには、エージェントまたは管理者の証明書を発行して Web ブラウザーにインストールする必要があります。そうしないと、Web サービスへの認証が失敗します。
| SSL に使用 | クライアント認証に使用[a] | Web サービス | Web サービスの場所 |
|---|---|---|---|
| Certificate Manager | |||
| No | エンドエンティティー | ca/ee/ca/ | |
| はい | いいえ | エンドエンティティー | ca/ee/ca |
| はい | はい | エージェント | ca/agent/ca |
| はい | いいえ | サービス | ca/services |
| はい | いいえ | コンソール | pkiconsole https://host:port/ca |
| キーリカバリー認証局 | |||
| はい | はい | エージェント | kra/agent/kra |
| はい | いいえ | サービス | kra/services |
| はい | いいえ | コンソール | pkiconsole https://host:port/kra |
| オンライン証明書ステータスマネージャー | |||
| はい | はい | エージェント | ocsp/agent/ocsp |
| はい | いいえ | サービス | ocsp/services |
| はい | いいえ | コンソール | pkiconsole https://host:port/ocsp |
| トークンキーサービス | |||
| はい | いいえ | サービス | tks/services |
| はい | いいえ | コンソール | pkiconsole https://host:port/tks |
| トークン処理システム | |||
| はい | サービス | index.cgi | |
[a]
クライアント認証値が No のサービスは、クライアント認証を要求するように再設定できます。Yes または No のいずれかの値を持たないサービスは、クライアント認証を使用するように設定することはできません。
| |||
13.3.2. 証明書システム管理コンソールの起動
pkiconsole コマンドを使用して SSL ポート経由でサブシステムインスタンスに接続すると、コンソールが開きます。このコマンドの形式は以下のとおりです。
pkiconsole https://server.example.com:admin_port/subsystem_type
subsystem_type は ca、kra、ocsp、または tks にすることができます。たとえば、これにより KRA コンソールが開きます。
pkiconsole https://server.example.com:8443/kra
DNS が設定されていない場合は、IPv4 アドレスまたは IPv6 アドレスを使用してコンソールに接続できます。以下に例を示します。
pkiconsole https://1.2.3.4:8443/ca pkiconsole https://[00:00:00:00:123:456:789:00:]:8443/ca
13.3.3. Java 管理コンソールの SSL の有効化
Certificate System Console への証明書ベースの認証を有効にして、管理者が Certificate System Console にログインする前にクライアント証明書を使用して認証する必要があります。証明書ベースの認証を有効にする前に、管理者の証明書を保存します。
コンソールで SSL を有効にするには、クライアントとサーバーの両方を設定します。
重要
CA が管理ポートを介したクライアント認証用に設定されていて、その CA がセキュリティードメインマネージャーである場合、その CA をセキュリティードメインに使用する新しい PKI サブシステムを設定することはできません。新しい PKI インスタンスは、クライアント認証を使用せずに、管理ポートを介してセキュリティードメイン CA に登録します。CA でクライアント認証が必要な場合、登録は失敗します。
まず、SSL クライアント認証を使用するように Certificate System サーバーを設定します。
- このシステムを使用して管理者の証明書を保存します。証明書は、CA 自体からのものか、サブシステムの証明書に署名した CA からのものである必要があります。
- サブシステムコンソールを開きます。
- 左側の ユーザーとグループ オプションを選択します。
- ユーザー タブで管理ユーザーを選択し、 をクリックします。
- をクリックします。
- Web ブラウザーに保存されている管理者証明書などの base-64 でエンコードされた SSL クライアント証明書を貼り付けます。
クライアント証明書が SSL クライアント認証に適していることを確認してください。それ以外の場合、サーバーはクライアント証明書を受け入れず、/var/log/instanceID/systemのエラーログにエラーメッセージを投稿します。failure (14290): Error receiving connection SEC_ERROR_INADEQUATE_CERT_TYPE - Certificate type not approved for application.)
- サブシステムを停止します。
systemctl stop pki-tomcatd@instance_name.service
- インスタンス設定ディレクトリー
/var/lib/pki/instance_name/subsystem_type/confを開きます。 CS.cfgファイルを開きます。- authType パラメーターの値を pwd から sslclientauth に変更します。
authType=sslclientauth
- ファイルを保存します。
server.xmlファイルを開きます。- admin インターフェイスコネクターセクションで clientAuth="false" 属性を clientAuth="want" に変更します。
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true"clientAuth="want"sslProtocol="SSL" ..... serverCertFile="/var/lib/pki/pki-tomcat/conf/serverCertNick.conf" passwordFile="/var/lib/pki/pki-tomcat/conf/password.conf" passwordClass="org.apache.tomcat.util.net.jss.PlainPasswordFile" certdbDir="/var/lib/pki/pki-tomcat/alias"/>この want 値は、クライアント認証が優先されますが、必須ではありません。これにより、(コンソールなど) 簡単に使用できるインターフェイスを介したクライアント認証が可能になりますが、クライアント認証を簡単にサポートしないクライアント (セキュリティードメイン内の他のサブシステム) は通常の接続を使用して接続できます。 - サブシステムを起動します。
systemctl start pki-tomcatd@instance_name.service
サーバーの設定後、クライアントが SSL クライアント認証を使用するように設定します。
コンソールは、サーバーへの SSL クライアント認証に使用される管理者証明書およびキーにアクセスできる必要があります。コンソールのデフォルト証明書およびキーデータベースは、
.redhat-idm-console ディレクトリーに保存されます。
管理者証明書およびキーへのアクセスを提供するには、管理者のブラウザーから
.p12 ファイルにエクスポートして pk12util を使用してインポートして、ブラウザーの証明書およびキーデータベースを .redhat-idm-console ディレクトリーにコピーします。(この手順では、証明書がブラウザーから .p12 ファイルにエクスポートされていることを前提とします)。
- ブラウザーから
admin.p12などのファイルに管理者ユーザー証明書および鍵をエクスポートします。 - ユーザーのコンソールディレクトリーを開きます。
/user-directory/.redhat-idm-console
- 必要な場合は、新規セキュリティーデータベースを作成します。
certutil -N -d .
- Certificate System インスタンスを停止します。
systemctl stop pki-tomcatd@instance_name.service
- pk12util を使用して証明書をインポートします。
# pk12util -i /tmp/admin.p12 -d /user-directory/.redhat-idm-console -W [p12filepassword]
手順に成功すると、コマンドは以下を出力します。pk12util: PKCS12 IMPORT SUCCESSFUL
- ブラウザーから発行される CA 証明書の 64 ビットブロブをエクスポートし、これを
ca.crtファイルなどに保存します。 - 管理者ユーザー証明書に関連するベース 64-blob から CA 証明書をインポートします。
certutil -A -d . -n ca -t CT,C,C -i ./ca.crt
- Certificate System インスタンスを起動します。
systemctl start pki-tomcatd@instance_name.service
- コンソールを起動します。これで、証明書の入力を求められます。
