9.4. Tomcat Engine および Web サービスの設定ファイル
サブシステムのユーザーおよび管理 (管理者、エージェント、および監査者) サービスはすべて、Web プロトコルを介してアクセスされます。
本セクションでは、すべての Red Hat Certificate System サブシステム (CA、KRA、OCSP、TKS、および TPS) に適用される設定ファイルの 2 つの主要なセットを説明します。
/var/lib/pki/instance_name/conf/server.xml
は、Tomcat エンジンの設定を提供します。/usr/share/pki/subsystem_type/webapps/WEB-INF/web.xml
は、このインスタンスが提供する Web サービスの設定を提供します。
9.4.1. Tomcatjss
注記
以降のサブセクションには、パラメーター値で必要な変更に関する重要な設定情報が含まれます。必ず厳密なコンプライアンスを確保してください。
サンプル
pki-tomcat/conf
ディレクトリーにある server.xml
ファイルの以下の設定は、Tomcat js が Certificate System エコシステム全体にどのように適合するかを説明するために使用できます。シークレットポートの Connector エントリーの一部を以下に示します。
<Connector name="Secure" # Info about the socket itself port="8443" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true" sslProtocol="SSL" scheme="https" secure="true" connectionTimeout="80000" maxHttpHeaderSize="8192" acceptCount="100" maxThreads="150" minSpareThreads="25" enableLookups="false" disableUploadTimeout="true" # Points to our tomcat jss implementation sslImplementationName="org.apache.tomcat.util.net.jss.JSSImplementation" # OCSP responder configuration can be enabled here enableOCSP="true" ocspCacheSize="1000" ocspMinCacheEntryDuration="60" ocspMaxCacheEntryDuration="120" ocspTimeout="10" # A collection of cipher related settings that make sure connections are secure. strictCiphers="true" # The "clientAuth" parameter configures the client authentication scheme # for this server socket. If you set "clientAuth" to "want", the client # authentication certificate is optional. Alternatively, set the # parameter to "required" to configure that the certificate is is mandatory. clientAuth="want" sslVersionRangeStream="tls1_1:tls1_2" sslVersionRangeDatagram="tls1_1:tls1_2" sslRangeCiphers="+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 serverCertNickFile="/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" />
<Connector name="Secure"
# Info about the socket itself
port="8443"
protocol="org.apache.coyote.http11.Http11Protocol"
SSLEnabled="true"
sslProtocol="SSL"
scheme="https"
secure="true"
connectionTimeout="80000"
maxHttpHeaderSize="8192"
acceptCount="100" maxThreads="150" minSpareThreads="25"
enableLookups="false" disableUploadTimeout="true"
# Points to our tomcat jss implementation
sslImplementationName="org.apache.tomcat.util.net.jss.JSSImplementation"
# OCSP responder configuration can be enabled here
enableOCSP="true"
ocspCacheSize="1000"
ocspMinCacheEntryDuration="60"
ocspMaxCacheEntryDuration="120"
ocspTimeout="10"
# A collection of cipher related settings that make sure connections are secure.
strictCiphers="true"
# The "clientAuth" parameter configures the client authentication scheme
# for this server socket. If you set "clientAuth" to "want", the client
# authentication certificate is optional. Alternatively, set the
# parameter to "required" to configure that the certificate is is mandatory.
clientAuth="want"
sslVersionRangeStream="tls1_1:tls1_2"
sslVersionRangeDatagram="tls1_1:tls1_2"
sslRangeCiphers="+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
serverCertNickFile="/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"
/>
Tomcat エンジンの
server.xml
設定ファイルに、この Connector 設定要素には、この Connector オブジェクトの sslImplementation
プロパティーにプラグインできる tomcatjss 実装へのポインターが含まれるこの Connector 設定要素があります。
各キーパラメーター要素は、以下のサブセクションで説明します。
9.4.1.1. TLS 暗号の設定
server.xml
ファイルで設定された TLS 暗号は、Red Hat Certificate システムがクライアントおよびサーバーとして機能する際にシステム全体のデフォルトを提供します。これには、サーバーとして機能する場合 (たとえば、Tomcat から HTTPS 接続を提供する場合) およびクライアントとして機能する場合 (たとえば、LDAP サーバーと通信する場合または別の Certificate System インスタンスと通信する場合) が含まれます。
サーバー TLS 暗号の設定は、Red Hat Certificate System インスタンス固有の
/var/lib/pki/instance_name/conf/server.xml
ファイルにあります。以下のパラメーターは、提供される暗号を制御します。
strictCiphers
を true に設定すると、sslRangeCiphers
に + 記号が付いた暗号のみが有効になります。Copy to Clipboard Copied! Toggle word wrap Toggle overflow strictCiphers="true"
strictCiphers="true"
デフォルト値を変更しないでください(true)。sslVersionRangeStream
およびsslVersionRangeDatagram
は、サーバーがサポートする TLS バージョンを設定します。パラメーターのデフォルト値は以下のとおりです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow sslVersionRangeStream="tls1_1:tls1_2" sslVersionRangeDatagram="tls1_1:tls1_2"
sslVersionRangeStream="tls1_1:tls1_2" sslVersionRangeDatagram="tls1_1:tls1_2"
パラメーターのデフォルト値は変更しないでください。sslRangeCiphers
は、有効または無効にする暗号を設定します。+ 記号のある暗号は有効になり、- 記号を持つ暗号は有効になります。RSA 暗号を以下のように設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow sslRangeCiphers="+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
sslRangeCiphers="+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,+TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
EC 暗号を以下のように設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow sslRangeCiphers="+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,+TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
sslRangeCiphers="+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,+TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
許可される暗号の一覧は、「許可された TLS 暗号スイート」を参照してください。- RSA で FIPS モードが有効になっているシステムに LunaSA または nCipher の Hardware Security Module (HSM) のいずれかを使用した Certificate System をインストールする場合は、FIPS モードの HSM ではサポートされていないため、以下の暗号を無効にします。
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
9.4.1.2. サブシステムの証明書失効チェックの有効化
Certificate System サブシステムでは、デフォルトで OCSP チェックが有効になっていません。
server.xml
ファイルを編集して、すべてのサブシステムに対して OCSP チェックを有効にできます。
OCSP チェックを設定するために許可されている方法が 1 つあります。
- 許可されている方法: 証明書システムサブシステムが、ピア証明書の機関情報アクセス (AIA) 拡張で指定された OCSP レスポンダー URL を使用できるようにする: この方法により、ピア証明書が複数の CA によって発行される、より動的な環境が可能になります。たとえば、LDAP サーバーの証明書が他の証明書とは異なる CA によって発行されている場合です。詳細は、「Certificate System サブシステムが、ピア証明書の機関情報アクセス (AIA) 拡張で指定された OCSP レスポンダー URL を使用できるようにする」 を参照してください。
以下のセクションでは、
server.xml
ファイルのさまざまな OCSP パラメーターが使用される、許可される OCSP チェック方法の設定について説明します。
以下の表は、
server.xml
ファイルの OCSP に関連する各パラメーターに関する情報を提供します。
パラメーター | 説明 |
---|---|
enableOCSP | サブシステムの OCSP チェックを有効 (または無効) にします。 |
ocspResponderURL | 該当なし |
ocspResponderCertNickname | 該当なし |
ocspCacheSize |
ネットワークセキュリティーサービス (NSS) によって保持される OCSP 応答キャッシュエントリーの最大数を設定します。
2 つの特別な値があります。
|
ocspMinCacheEntryDuration | 別のフェッチを試行するまでの最小秒数を設定します。たとえば、これが 120 に設定された場合は、最後の有効期間をチェックから 2 分以上経たないと証明書の有効性を再度確認することができません。 |
ocspMaxCacheEntryDuration | 次のフェッチを試みる前に待機する最大秒数を設定します。これにより、有効期間チェック間でウィンドウが大きくなり過ぎないようにできます。 |
ocspTimeout | OCSP 要求のタイムアウト期間を秒単位で設定します。 |
注記
OCSP 応答で nextUpdate フィールドが送信されると、以下のように
ocspMinCacheEntryDuration
および ocspMaxCacheEntryDuration
で次のフェッチ時間に影響を与える可能性があります。
ocspMinCacheEntryDuration
に設定された値の前に nextUpdate の値に達すると、ocspMinCacheEntryDuration
に設定された値に達するまでフェッチは開始されません。ocspMinCacheEntryDuration
に達すると、サーバーは nextUpdate の値に達したかどうかを確認します。値に達すると、フェッチが発生します。- nextUpdate の値に関係なく、
ocspMaxCacheEntryDuration
の設定に達すると、フェッチが発生します。
9.4.1.2.1. OCSP 署名証明書の信頼の設定
各 OCSP 署名証明書は、Certificate System の NSS データベース内の信頼されたルートまで連鎖する必要があります。
OCSP 署名証明書がインポートされ、サブシステムの NSS データベースで信頼されると、次の考慮事項が必要になります。使用されている OCSP レスポンダーが、各 OCSP 応答で OCSP 署名証明書の証明書チェーン全体を提供するように設定されている場合、それ以上のアクションは必要ありません。NSS は、リクエスト情報からこのチェーンを検証する方法を知っています。一方、OCSP が完全なチェーンを返さないことがわかっている場合は、チェーンを手動でインポートできます。詳細は、「OCSP レスポンダーのインポート」 を参照してください。Certificate System OCSP レスポンダには、すべてのレスポンスにチェーンがすでに含まれています。これには、証明書システムの外部 OCSP レスポンダーと、各 CA に付属する内部 OCSP サービスが含まれます。
この動作はデフォルトであり、変更できません。
9.4.1.2.2. Certificate System サブシステムが、ピア証明書の機関情報アクセス (AIA) 拡張で指定された OCSP レスポンダー URL を使用できるようにする
Certificate System がピア証明書の Authority Information Access (AIA)拡張で指定された OCSP レスポンダー URL を使用するように設定するには、
server.xml
ファイルを編集し、
enableOCSP
を true に設定します。ocspResponderURL
パラメーターを削除します。ocspResponderCertNickname
パラメーターを削除します。
設定可能なパラメーターの完全リストは、表9.10「server.xml の OCSP パラメーター」 を参照してください。
重要
これらの設定に加えて、目的の結果がその特定の証明書の OCSP 検証である場合は、すべてのピア証明書に AIA 拡張が含まれている必要があります。それ以外の場合、拡張機能が欠落している場合、検証手順はスキップされます。
また、含まれているすべての AIA 拡張 URL が正しく、到達可能であることを確認してください。これは、システムが到達不能な OCSP サーバーに接続しようとすると、問題の証明書が無効な証明書として拒否されたことをシステムが報告するためです。
例9.4 server.xml
<Connector name="Secure" enableOCSP="true" ocspCacheSize="1000" ocspMinCacheEntryDuration="60" ocspMaxCacheEntryDuration="120" ocspTimeout="10" ... />
<Connector name="Secure"
enableOCSP="true"
ocspCacheSize="1000"
ocspMinCacheEntryDuration="60"
ocspMaxCacheEntryDuration="120"
ocspTimeout="10"
...
/>
さらに、OCSP 署名証明書の信頼を設定します。詳細は、「OCSP 署名証明書の信頼の設定」 を参照してください。
9.4.1.2.3. AIA 拡張機能の登録プロファイルへの追加
外部 OCSP を使用する際にプロファイルに AIA URL を設定するには、証明書プロファイルに正しい URL を追加します。以下に例を示します。
policyset.cmcUserCertSet.5.default.params.authInfoAccessADLocation_0=http://example.com:8080/ocsp/ee/ocsp
policyset.cmcUserCertSet.5.default.params.authInfoAccessADLocation_0=http://example.com:8080/ocsp/ee/ocsp
9.4.1.3. セッションのタイムアウト
ユーザーがクライアントアプリケーションを介して PKI サーバーに接続すると、サーバーはユーザーを追跡するセッションを作成します。ユーザーがアクティブな状態である限り、ユーザーは再認証せずに同じセッションで複数の操作を実行できます。
セッションタイムアウトは、アクティブでないためにセッションを終了するまで最後の操作からサーバーが待機する期間を決定します。セッションが終了すると、ユーザーはサーバーへのアクセスを継続するためにユーザーを再認証し、サーバーが新しいセッションを作成します。
タイムアウトには、2 つのタイプがあります。
- TLS セッションのタイムアウト
- HTTP セッションのタイムアウト
クライアントの仕組みが異なるため、クライアントはこれらのタイムアウトによって影響を及ぼします。
注記
特定のクライアントには独自のタイムアウト設定があります。たとえば、Firefox には keep-alive タイムアウト設定があります。詳細は、http://kb.mozillazine.org/Network.http.keep-alive.timeout を参照してください。値が TLS セッションタイムアウトまたは HTTP セッションタイムアウトのサーバーの設定と異なる場合は、異なる動作を確認できます。
9.4.1.3.1. TLS セッションのタイムアウト
TLS セッションは、TLS ハンドシェイクプロトコルを介して確立された TLS 接続におけるセキュアな通信チャネルです。
PKI サーバーは、TLS セッションアクティビティーの監査イベントを生成します。接続の作成時に、サーバーは Outcome=Success の ACCESS_SESSION_ESTABLISH 監査イベントを生成します。接続の作成に失敗すると、サーバーは Outcome=Failure の ACCESS_SESSION_ESTABLISH 監査イベントを生成します。接続が閉じられると、サーバーは ACCESS_SESSION_TERMINATED 監査イベントを生成します。
TLS セッションタイムアウト(TLS 接続タイムアウト)は、
/etc/pki/<instance>/server.xml ファイルの Secure <Connector> 要素の keepAliveTimeout パラメーターで設定されます。
... <Server> <Service> <Connector name="Secure" ... keepAliveTimeout="300000" ... /> </Service> </Server> ...
...
<Server>
<Service>
<Connector name="Secure"
...
keepAliveTimeout="300000"
...
/>
</Service>
</Server>
...
デフォルトではタイムアウト値は 300000 ミリ秒 (5 分) に設定されます。この値を変更するには、
/etc/pki/<instance>/server.xml
ファイルを編集し、サーバーを再起動します。
注記
この値は、サーバーへのすべての TLS 接続に影響することに注意してください。期限切れでない既存の接続を再利用できるため、クライアントの効率が大きくなる可能性があります。ただし、放棄された接続の有効期限が切れるまでに時間がかかるため、サーバーが同時にサポートする必要のある接続の数も増える可能性があります。
9.4.1.3.2. HTTP セッションのタイムアウト
HTTP セッションは、HTTP クッキーを使用して複数の HTTP リクエストでユーザーを追跡するメカニズムです。PKI サーバーは、HTTP セッションの監査イベントを生成しません。
注記
一貫性を監査するには、このセクションの < ;session-timeout > 値を 「TLS セッションのタイムアウト」 の keepAliveTimeout 値と一致するように設定します。たとえば、keepAliveTimeout が 300000 (5 分)に設定された場合は、< session-timeout> を 30 に 設定します。
HTTP セッションタイムアウトは、
/etc/pki/<instance>/web.xml ファイルの <session -timeout > 要素で設定できます。
... <web-app> <session-config> <session-timeout>30</session-timeout> </session-config> </web-app> ...
...
<web-app>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
</web-app>
...
デフォルトでは、タイムアウト値は 30 分に設定されています。値を変更するには、
/etc/pki/<instance>/web.xml
ファイルを編集し、サーバーを再起動します。
注記
この値は、サーバー上のすべての Web アプリケーションにあるすべてのセッションに影響することに注意してください。アクセスバナーを再度認証したり、表示したりする必要がないため、大きな値がユーザーのエクスペリエンスが向上します。ただし、破棄された HTTP セッションが期限切れになるまでの時間があるため、セキュリティーリスクも高まります。
9.4.1.3.3. PKI Web UI のセッションタイムアウト
PKI Web UI は、ブラウザーで実行されるインタラクティブな Web ベースのクライアントです。現在、クライアント証明書認証のみをサポートしています。
Web UI が開くと、ブラウザーはサーバーに複数の TLS 接続を作成できます。これらの接続は単一の HTTP セッションに関連付けられます。
Web UI のタイムアウトを設定するには、「HTTP セッションのタイムアウト」を参照してください。ブラウザーがクライアント証明書をキャッシュし、TLS セッションを自動的に再作成できるようにするため、TLS セッションのタイムアウトは通常無関係です。
HTTP セッションの期限が切れると、Web UI は即座に表示されません。ただし、Web UI は、ユーザーが操作を実行する前にアクセスバナー (有効な場合) を表示します。
9.4.1.3.4. PKI コンソールのセッションタイムアウト
PKI コンソールは、インタラクティブなスタンドアロングラフィカル UI クライアントです。ユーザー名/パスワードおよびクライアント証明書認証をサポートします。
コンソールの起動時に、サーバーへの 1 つの TLS 接続が作成されます。コンソールは、グラフィカルインターフェイスを開く前に、アクセスバナー (有効な場合) を表示します。Web UI とは異なり、コンソールはサーバーで HTTP セッションを維持しません。
コンソールのタイムアウトを設定するには、「TLS セッションのタイムアウト」を参照してください。コンソールは HTTP セッションを使用しないため、HTTP セッションタイムアウトは無関係です。
TLS セッションの期限が切れると、TLS 接続が閉じられ、コンソールがシステムにすぐに終了します。ユーザーが続行する場合は、コンソールを再起動する必要があります。
9.4.1.3.5. PKI CLI のセッションタイムアウト
PKI CLI は、一連の操作を実行するコマンドラインクライアントです。ユーザー名/パスワードおよびクライアント証明書認証をサポートします。
CLI の起動時に、サーバーと HTTP セッションへの単一の TLS 接続を作成します。CLI は、操作を実行する前にアクセスバナー (有効な場合) を表示します。
通常、操作は遅延なく順次実行され、CLI が完了するとすぐに CLI を終了するため、両方のタイムアウトは PKI CLI とは無関係です。ただし、CLI がユーザー入力を待機するか、速度が低下するか、応答しなくなると、TLS セッションまたは HTTP セッションが期限切れになり、残りの操作が失敗する場合があります。このような遅延が予想される場合は、「TLS セッションのタイムアウト」 と 「HTTP セッションのタイムアウト」 を参照して、想定される遅延に対応します。
9.4.2. web.xml
9.4.2.1. web.xml からの未使用インターフェイスの削除 (CA のみ)
(一括発行やポリシーフレームワークなどの機能用の)レガシーインターフェイスは、CA の
web.xml
ファイルに含まれます。ただし、これらの機能は非推奨となり、使用されなくなりました。したがって、CA 設定から削除してセキュリティーを強化することができます。
- CA を停止します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl stop pki-tomcatd@instance_name.service
systemctl stop pki-tomcatd@instance_name.service
またはCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl stop pki-tomcatd-nuxwdog@instance_name.service (if using nuxwdog watchdog)
systemctl stop pki-tomcatd-nuxwdog@instance_name.service (if using nuxwdog watchdog)
- CA の Web ファイルディレクトリーを開きます。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cd /var/lib/pki/pki-tomcat/ca/webapps/ca/WEB-INF
cd /var/lib/pki/pki-tomcat/ca/webapps/ca/WEB-INF
- 現在の
web.xml
ファイルをバックアップします。Copy to Clipboard Copied! Toggle word wrap Toggle overflow cp web.xml web.xml.servlets
cp web.xml web.xml.servlets
web.xml
ファイルを編集し、非推奨となった以下の各サーブレットの <servlet > エントリー全体を削除します。- caadminEnroll
- cabulkissuance
- cacertbasedenrollment
- caenrollment
- caProxyBulkIssuance
たとえば、caadminEnroll サーブレットエントリーを削除します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow <servlet> <servlet-name> caadminEnroll </servlet-name> <servlet-class> com.netscape.cms.servlet.cert.EnrollServlet </servlet-class> <init-param><param-name> GetClientCert </param-name> <param-value> false </param-value> </init-param> <init-param><param-name> successTemplate </param-name> <param-value> /admin/ca/EnrollSuccess.template </param-value> </init-param> <init-param><param-name> AuthzMgr </param-name> <param-value> BasicAclAuthz </param-value> </init-param> <init-param><param-name> authority </param-name> <param-value> ca </param-value> </init-param> <init-param><param-name> interface </param-name> <param-value> admin </param-value> </init-param> <init-param><param-name> ID </param-name> <param-value> caadminEnroll </param-value> </init-param> <init-param><param-name> resourceID </param-name> <param-value> certServer.admin.request.enrollment </param-value> </init-param> <init-param><param-name> AuthMgr </param-name> <param-value> passwdUserDBAuthMgr </param-value> </init-param> </servlet>
<servlet> <servlet-name> caadminEnroll </servlet-name> <servlet-class> com.netscape.cms.servlet.cert.EnrollServlet </servlet-class> <init-param><param-name> GetClientCert </param-name> <param-value> false </param-value> </init-param> <init-param><param-name> successTemplate </param-name> <param-value> /admin/ca/EnrollSuccess.template </param-value> </init-param> <init-param><param-name> AuthzMgr </param-name> <param-value> BasicAclAuthz </param-value> </init-param> <init-param><param-name> authority </param-name> <param-value> ca </param-value> </init-param> <init-param><param-name> interface </param-name> <param-value> admin </param-value> </init-param> <init-param><param-name> ID </param-name> <param-value> caadminEnroll </param-value> </init-param> <init-param><param-name> resourceID </param-name> <param-value> certServer.admin.request.enrollment </param-value> </init-param> <init-param><param-name> AuthMgr </param-name> <param-value> passwdUserDBAuthMgr </param-value> </init-param> </servlet>
- サーブレットエントリーを削除したら、対応する < servlet-mapping> エントリーを削除 します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <servlet-mapping> <servlet-name> caadminEnroll </servlet-name> <url-pattern> /admin/ca/adminEnroll </url-pattern> </servlet-mapping>
<servlet-mapping> <servlet-name> caadminEnroll </servlet-name> <url-pattern> /admin/ca/adminEnroll </url-pattern> </servlet-mapping>
- エンドエンティティー要求インターフェイスの < filter-mapping > エントリーを 3 つ削除します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <filter-mapping> <filter-name> EERequestFilter </filter-name> <url-pattern> /certbasedenrollment </url-pattern> </filter-mapping> <filter-mapping> <filter-name> EERequestFilter </filter-name> <url-pattern> /enrollment </url-pattern> </filter-mapping> <filter-mapping> <filter-name> EERequestFilter </filter-name> <url-pattern> /profileSubmit </url-pattern> </filter-mapping>
<filter-mapping> <filter-name> EERequestFilter </filter-name> <url-pattern> /certbasedenrollment </url-pattern> </filter-mapping> <filter-mapping> <filter-name> EERequestFilter </filter-name> <url-pattern> /enrollment </url-pattern> </filter-mapping> <filter-mapping> <filter-name> EERequestFilter </filter-name> <url-pattern> /profileSubmit </url-pattern> </filter-mapping>
- CA を再度起動します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl start pki-tomcatd@instance_name.service
systemctl start pki-tomcatd@instance_name.service
またはCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl start pki-tomcatd-nuxwdog@instance_name.service (if using nuxwdog watchdog)
systemctl start pki-tomcatd-nuxwdog@instance_name.service (if using nuxwdog watchdog)
9.4.3. Web サービスのカスタマイズ
すべてのサブシステム (TKS を除く) には、エージェント用の Web ベースのサービスページや、その他のロール (管理者やエンドエンティティーなど) 用の Web ベースのサービスページがあります。これらの Web ベースのサービスページは基本的な HTML や JavaScript を使用しており、既存のサイトやイントラネットに合わせて、さまざまな色、ロゴ、その他のデザイン要素を使用するようにカスタマイズできます。
9.4.3.1. サブシステム Web アプリケーションのカスタマイズ
各 PKI サブシステムには以下が含まれる対応する web アプリケーションがあります。
- テキスト、JavaScript コード、ページレイアウト、CSS フォーマットなどを含む HTML ページ
- サーブレット、パス、セキュリティー制約などを定義する
web.xml
ファイル - PKI ライブラリーへのリンク。
サブシステムの Web アプリケーションは、
/var/lib/pki/pki-tomcat/conf/Catalina/localhost/
ディレクトリーにあるコンテキストファイル( ca.xml
ファイルなど)を使用してデプロイされます。
<Context docBase="/usr/share/pki/ca/webapps/ca" crossContext="true" allowLinking="true"> ... </Context>
<Context docBase="/usr/share/pki/ca/webapps/ca" crossContext="true" allowLinking="true">
...
</Context>
docBase
は、デフォルトの Web アプリケーションディレクトリー /usr/share/pki/
の場所を参照します。
Web アプリケーションをカスタマイズするには、Web アプリケーションディレクトリーをインスタンスの
webapps
ディレクトリーにコピーします。
cp -r /usr/share/pki/ca/webapps/ca /var/lib/pki/pki-tomcat/webapps
$ cp -r /usr/share/pki/ca/webapps/ca /var/lib/pki/pki-tomcat/webapps
次に、
webapps
ディレクトリーから相対的なカスタム Web アプリケーションディレクトリーを参照するように、docBase
を変更します。
<Context docBase="ca" crossContext="true" allowLinking="true"> ... </Context>
<Context docBase="ca" crossContext="true" allowLinking="true">
...
</Context>
変更は、サーバーを再起動しなくてもすぐに有効になります。
カスタム Web アプリケーションを削除するには、
docBase
を元に戻して、カスタム Web アプリケーションディレクトリーを削除します。
rm -rf /var/lib/pki/pki-tomcat/webapps/ca
$ rm -rf /var/lib/pki/pki-tomcat/webapps/ca
9.4.3.2. Web UI テーマのカスタマイズ
同じインスタンスのサブシステムの web アプリケーションは、同じテーマを共有します。これには以下が含まれます。
- CSS ファイル (グローバルの外観を決定する)
- ロゴ、アイコン、およびその他のイメージファイル
- ページタイトル、ロゴリンク、タイトルの色などを判断するブランディングプロパティー。
Web UI テーマは、
/var/lib/pki/pki-tomcat/conf/Catalina/localhost/
ディレクトリーの pki.xml
コンテキストファイルを使用してデプロイされます。
<Context docBase="/usr/share/pki/common-ui" crossContext="true" allowLinking="true"> ... </Context>
<Context docBase="/usr/share/pki/common-ui" crossContext="true" allowLinking="true">
...
</Context>
docBase は、デフォルトのテーマディレクトリー
/usr/share/pki/
の場所を参照します。
テーマをカスタマイズするには、デフォルトのテーマディレクトリーをインスタンスの
webapps
ディレクトリーの pki
ディレクトリーにコピーします。
cp -r /usr/share/pki/common-ui /var/lib/pki/pki-tomcat/webapps/pki
$ cp -r /usr/share/pki/common-ui /var/lib/pki/pki-tomcat/webapps/pki
次に、
webapps
ディレクトリーから相対的なカスタムテーマのディレクトリーを参照するように、docBase
を変更します。
<Context docBase="pki" crossContext="true" allowLinking="true"> ... </Context>
<Context docBase="pki" crossContext="true" allowLinking="true">
...
</Context>
変更は、サーバーを再起動しなくてもすぐに有効になります。
カスタムテーマを削除するには、
docBase
を元に戻して、カスタムテーマのディレクトリーを削除します。
rm -rf /var/lib/pki/pki-tomcat/webapps/pki
$ rm -rf /var/lib/pki/pki-tomcat/webapps/pki
9.4.3.3. TPS トークンの状態ラベルのカスタマイズ
デフォルトのトークン状態ラベルは
/usr/share/pki/tps/conf/token-states.properties
ファイルに保存され、「トークンの状態および遷移ラベル」 で説明されています。
ラベルをカスタマイズするには、ファイルをインスタンスディレクトリーにコピーします。
cp /usr/share/pki/tps/conf/token-states.properties /var/lib/pki/pki-tomcat/tps/conf
$ cp /usr/share/pki/tps/conf/token-states.properties /var/lib/pki/pki-tomcat/tps/conf
変更は、サーバーを再起動しなくてもすぐに有効になります。
カスタマイズされたラベルを削除するには、カスタマイズされたファイルを削除するだけです。
rm /var/lib/pki/pki-tomcat/tps/conf/token-states.properties
$ rm /var/lib/pki/pki-tomcat/tps/conf/token-states.properties