14.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 サービスの設定を指定します。

14.4.1. Tomcatjss

注記
以降のサブセクションには、パラメーター値で必要な変更に関する重要な設定情報が含まれます。必ず厳密なコンプライアンスを確保してください。
サンプルの pki-tomcat/conf ディレクトリーにある server.xml ファイルの以下の設定は、Tomcatjss が 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"

/>
Tomcat エンジンの server.xml 設定ファイルに、この Connector 設定要素として、この Connector オブジェクトの sslImplementation プロパティーにプラグインできる tomcatjss 実装へのポインターが含まれるこの Connector 設定要素があります。
各キーパラメーター要素は、以下のサブセクションで説明します。

14.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 ファイルにあります。以下のパラメーターは、提供される暗号を制御します。
  • strictCipherstrue に設定すると、sslRangeCiphers+ 記号が付いた暗号のみが有効になります。
    strictCiphers="true"
    デフォルト値 (true) を変更しないでください。
  • sslVersionRangeStream および sslVersionRangeDatagram は、サーバーがサポートする TLS バージョンを設定します。パラメーターのデフォルト値は以下のとおりです。
    sslVersionRangeStream="tls1_1:tls1_2"
    sslVersionRangeDatagram="tls1_1:tls1_2"
    パラメーターのデフォルト値は変更しないでください。
  • sslRangeCiphers は、有効または無効にする暗号を設定します。+ 記号の付いた暗号は有効になり、- 記号の付いた暗号は無効になります。
    RSA 暗号を以下のように設定します。
    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 暗号を以下のように設定します。
    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、ECC、および RSA」 を参照してください。
  • 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
14.4.1.1.1. クライアント TLS 暗号の設定
Red Hat Certificate System は、別の CS システムへのクライアントとして動作している場合にシステムでの暗号化設定を可能にします。
リストの暗号はコンマで区切ります。
CA で (KRA と CA の通信用)、以下を行います。
ca.connector.KRA.clientCiphers=your selected cipher list
以下に例を示します。
ca.connector.KRA.clientCiphers=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
TPS の場合 (CA、KRA、および TKS との通信用):
tps.connector.ca id.clientCiphers=your selected cipher list
tps.connector.kra id.clientCiphers=your selected cipher list
tps.connector.tks id.clientCiphers=your selected cipher list
以下に例を示します。
tps.connector.ca1.clientCiphers=TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA

14.4.1.2. CA での自動失効チェックの有効化

CA は、SSL/TLS クライアントの認証中にサーバーが受信する証明書 (エージェント、管理者、登録を含む) の失効ステータスを確認するように設定できます。つまり、CA がクライアント認証要求を受け取ると、OCSP が自動的にチェックされます。OCSP レスポンダーの設定に関する詳細は、『Red Hat Certificate システム管理ガイド』 の OCSP (Online Certificate Status Protocol) レスポンダーの使用 を参照してください。
CA は、失効チェックの一環としてクライアント認証をキャッシュし、検証された証明書のリストを保持するようにします。これにより、CA は内部データベースまたは OCSP をチェックする前にキャッシュされた結果をチェックできるようになり、全体的な操作パフォーマンスが向上します。revocationChecking.enabled パラメーターで、自動失効チェックが有効になります。
失効ステータスの結果は、指定された期間 (revocationChecking.validityInterval) のみ有効になります。CA がキャッシュにある証明書の状態を再検証する方法がない場合は、有効期間外であっても、以前キャッシュされていた状態が有効とみなされる猶予間隔 (revocationChecking.unknownStateInterval) があります。
注記
キャッシュされた証明書はバッファー (revocationChecking.bufferSize) に保持されます。バッファー設定がない場合やゼロに設定されている場合は、バッファーは保持されません。つまり、失効チェックの結果はキャッシュされません。この場合、失効チェックはすべて CA 内部データベースに対して直接実行されます。
注記
サブシステム CS.cfg 設定ファイルにはパラメーター jss.ocspcheck.enable が含まれています。このパラメーターは、Certificate Manager が OCSP を使用して、SSL/TLS クライアントまたはサーバー認証の一部として受信する証明書の失効状態を検証するかどうかを設定します。このパラメーターの値を true に変更すると、Certificate Manager は証明書の Authority Information Access 拡張を読み取り、拡張に指定された OCSP レスポンダーから証明書の失効状態を検証します。
  1. サブシステムインスタンスを停止します。
    # pki-server stop instance_name
  2. CS.cfg ファイルを開きます。
    # vim /var/lib/pki/instance-name/ca/conf/CS.cfg
  3. 失効関連のパラメーターを編集します。
    auths.revocationChecking.bufferSize=50
    auths.revocationChecking.ca=ca
    auths.revocationChecking.enabled=true
    auths.revocationChecking.unknownStateInterval=0
    auths.revocationChecking.validityInterval=120
    
    • revocationChecking.ca。OCSP 応答、CA または OCSP レスポンダーを提供するサービスを設定します。
    • revocationChecking.enabled。失効チェックを設定します。true は、チェックを有効にします。false はチェックを無効にします。デフォルトでは、この機能は有効になっています。
    • revocationChecking.bufferSize。サーバーがキャッシュで維持する必要のある、最後に確認された証明書の合計数を設定します。たとえば、バッファーサイズが 2 の場合、サーバーはキャッシュでチェックされた最後の 2 つの証明書を保持します。デフォルトでは、サーバーは最後の 50 個の証明書をキャッシュします。
    • revocationChecking.unknownStateInterval。サーバーが失効ステータスを確認する頻度を設定します。デフォルトの間隔は 0 秒です。unknownStateInterval は、CA に証明書のステータスを確認する手段がない (情報へのアクセスが許可されていない) 場合に、キャッシュ結果が true であると見なされる猶予期間です。
    • revocationChecking.validityInterval。キャッシュされた証明書が有効とみなされる期間を設定します。間隔を選択するときは慎重に行ってください。たとえば、有効期間が 60 秒の場合、サーバーは 1 分ごとにキャッシュ内の証明書を破棄し、ソースから証明書を取得しようとします。Certificate Manager は内部データベースを使用して、証明書の失効ステータスを取得して確認します。デフォルトの有効期間は 120 秒 (2 分) です。
  4. Certificate System インスタンスを起動します。
    # pki-server start instance_name

14.4.1.3. サブシステムの証明書失効チェックの有効化

Certificate System サブシステムには、デフォルトで OCSP チェックを有効にしてサブシステム証明書を検証します。つまり、失効した証明書を使用して管理インターフェイスまたはエージェントインターフェイスにログインすることができます。
server.xml ファイルを編集して、すべてのサブシステムに対して OCSP チェックを有効にできます。エージェントインターフェイスと管理インターフェイスは別々に設定されるため、この設定で両方のセクションを編集する必要があります。
注記
サブシステムが内部データベースで SSL/TLS 接続を使用するように設定されている場合は、LDAP 内部データベースの SSL/TLS サーバー証明書が OCSP レスポンダーによって認識される必要があります。OCSP レスポンダーが LDAP サーバー証明書を認識しない場合は、サブシステムが適切に起動しません。この設定は、サブシステムの SSL/TLS サーバー接続がサブシステム設定の一部として設定されているため、Red Hat Certificate System 10 のプランニング、インストール、およびデプロイメントガイドで説明されています。
  1. 証明書ステータスの確認に使用される OCSP または CA の OCSP 署名証明書の名前を取得します。以下に例を示します。
    # certutil -L -d /etc/pki/instance-name/alias
    Certificate Nickname                                         Trust Attributes
    															 SSL,S/MIME,JAR/XPI
    Certificate Authority - Example Domain                       CT,c,
    ocspSigningCert cert-pki-ocsp CTu,Cu,Cu
    subsystemCert cert-pki-ocsp                                  u,u,u
    Server-Cert cert-pki-ocsp                                    u,u,u
    auditSigningCert cert-pki-ocsp                               u,u,Pu
    
  2. サブシステムの server.xml ファイルを開きます。以下に例を示します。
    # vim /etc/pki/instance-name/server.xml
  3. OCSP 署名証明書がインスタンスのセキュリティーデータベースにない場合は、インポートします。
    # certutil -d /etc/pki/instance-name/alias -A -n "ocspSigningCert cert-pki-ca" -t "C,," -a -i ocspCert.b64
  4. OCSP チェックを有効にするには、以下の 3 つの重要なパラメーターがあります。
    • enableOCSP: OCSP チェックを有効にするには、true に設定する必要があります。
      これはグローバル設定です。単一のインターフェイスに設定されている場合には、インスタンスのすべてのインターフェイスに適用されます。ただし、通常は、server.xml ファイルに記載されている最初のインターフェイスで設定する必要があります。別のインターフェイスの設定は無視されます。
    • ocspResponderURL: OCSP レスポンダーの URL に OCSP リクエストを送信します。
      OCSP Manager の場合は、別の OCSP または CA の別の OCSP サービスになります。その他のサブシステムでは、これは常に OCSP または CA の外部 OCSP サービスを参照します。
    • ocspResponderCertNickname: レスポンスの署名に使用する署名証明書を提供します。CA OCSP サービスの場合、これは CA の OCSP 署名証明書であり、OCSP レスポンダーについては OCSP 署名証明書になります。
    その他のパラメーターを使用して OCSP 通信を定義できます。OCSP チェックパラメーターはすべて 表14.10「server.xml の OCSP パラメーター」 に記載されています。
    エージェントインターフェイスと管理者インターフェイス用に、ファイルには 2 つの異なるセクションがあります。OCSP チェックを有効にして設定するには、両方のセクションに OCSP パラメーターを追加する必要があります。以下に例を示します。

    例14.3 エージェントインターフェイスの OCSP 設定

    <Connector name="Agent" port="8443" maxHttpHeaderSize="8192"
    					maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
    					enableLookups="false" disableUploadTimeout="true"
    					acceptCount="100" scheme="https" secure="true"
    					clientAuth="true" sslProtocol="SSL"
    					sslOptions="ssl2=true,ssl3=true,tls=true"
    
    		ssl3Ciphers="-SSL3_FORTEZZA_DMS_WITH_NULL_SHA, ..."
    
    		tls3Ciphers="-SSL3_FORTEZZA_DMS_WITH_NULL_SHA, ..."
    					SSLImplementation="org.apache.tomcat.util.net.jss.JSSImplementation"
    					enableOCSP="true"  
    					ocspResponderURL="http://server.example.com:8443/ca/ocsp"  
    					ocspResponderCertNickname="ocspSigningCert cert-pki-ca 102409a"  
    					ocspCacheSize="1000"  
    					ocspMinCacheEntryDuration="60"  
    					ocspMaxCacheEntryDuration="120"  
    					ocspTimeout="10"  
    					debug="true"
    					serverCertNickFile="/etc/pki/instance-name/serverCertNick.conf"
    					passwordFile="/etc/pki/instance-name/password.conf"
    					passwordClass="org.apache.tomcat.util.net.jss.PlainPasswordFile"
    					certdbDir="/etc/pki/instance-name/alias"/>
  5. 指定の OCSP サービスが CA ではない場合は、OCSP サービスの署名証明書がサブシステムの NSS データベースにインポートする必要があります。これは、コンソールまたは certutil を使用して行うことができます。いずれのオプションも、『Red Hat Certificate System 管理ガイド』 の Certificate System データベースへの Certificates のインストール で説明されています。
  6. サブシステムを再起動します。
    # pki-server restart instance_name
表14.10 server.xml の OCSP パラメーター
パラメーター 説明
enableOCSP サブシステムの OCSP チェックを有効 (または無効) にします。
ocspResponderURL OCSP リクエストが送信される URL を設定します。
OCSP Manager の場合は、別の OCSP または CA の別の OCSP サービスになります。TKS または KRA の場合、これは常に OCSP または CA の外部 OCSP サービスを指します。
ocspResponderCertNickname レスポンダーの署名証明書のニックネームを設定します。OCSP 署名証明書または CA の OCSP 署名証明書のいずれかです。証明書はサブシステムの NSS データベースにインポートされ、適切な信頼設定が設定されている必要があります。
ocspCacheSize キャッシュエントリーの最大数を設定します。
ocspMinCacheEntryDuration 別のフェッチを試行するまでの最小秒数を設定します。たとえば、これが 120 に設定された場合は、最後の有効期間をチェックから 2 分以上経たないと証明書の有効性を再度確認することができません。
ocspMaxCacheEntryDuration 次のフェッチを試みる前に待機する最大秒数を設定します。これにより、有効期間チェック間でウィンドウが大きくなり過ぎないようにできます。
ocspTimeout OCSP 要求のタイムアウト期間を秒単位で設定します。

14.4.1.4. AIA 拡張機能の登録プロファイルへの追加

外部 OCSP を使用する際にプロファイルに AIA URL を設定するには、証明書プロファイルに正しい URL を追加します。以下に例を示します。
policyset.cmcUserCertSet.5.default.params.authInfoAccessADLocation_0=http://example.com:8080/ocsp/ee/ocsp

14.4.2. セッションのタイムアウト

ユーザーがクライアントアプリケーションを介して PKI サーバーに接続すると、サーバーはユーザーを追跡するセッションを作成します。ユーザーがアクティブな状態である限り、ユーザーは再認証せずに同じセッションで複数の操作を実行できます。
セッションタイムアウトは、アクティブでないためにセッションを終了するまで最後の操作からサーバーが待機する期間を決定します。セッションが終了すると、ユーザーはサーバーへのアクセスを継続するためにユーザーを再認証し、サーバーが新しいセッションを作成します。
タイムアウトには、2 つのタイプがあります。
  • TLS セッションのタイムアウト
  • HTTP セッションのタイムアウト
クライアントの仕組みが異なるため、クライアントはこれらのタイムアウトによって影響を及ぼします。
注記
特定のクライアントには独自のタイムアウト設定があります。たとえば、Firefox には keep-alive タイムアウト設定があります。詳細は、http://kb.mozillazine.org/Network.http.keep-alive.timeout を参照してください。値が TLS セッションタイムアウトまたは HTTP セッションタイムアウトのサーバーの設定と異なる場合は、異なる動作を確認できます。

14.4.2.1. TLS セッションのタイムアウト

TLS セッションは、TLS ハンドシェイクプロトコルを介して確立された TLS 接続におけるセキュアな通信チャネルです。
PKI サーバーは、TLS セッションアクティビティーの監査イベントを生成します。サーバーは、接続の作成時に、Outcome=SuccessACCESS_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>
...
デフォルトではタイムアウト値は 300000 ミリ秒 (5 分) に設定されます。この値を変更するには、/etc/pki/<instance>/server.xml ファイルを編集し、サーバーを再起動します。
注記
この値は、サーバーへのすべての TLS 接続に影響することに注意してください。期限切れでない既存の接続を再利用できるため、クライアントの効率が大きくなる可能性があります。ただし、放棄された接続の有効期限が切れるまでに時間がかかるため、サーバーが同時にサポートする必要のある接続の数も増える可能性があります。

14.4.2.2. HTTP セッションのタイムアウト

HTTP セッションは、HTTP クッキーを使用して複数の HTTP リクエストでユーザーを追跡するメカニズムです。PKI サーバーは、HTTP セッションの監査イベントを生成しません。
注記
一貫性を監査するために、このセクションの <session-timeout> 値を、「TLS セッションのタイムアウト」keepAliveTimeout 値と一致するように設定します。たとえば、keepAliveTimeout300000 (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>
...
デフォルトでは、タイムアウト値は 30 分に設定されています。値を変更するには、/etc/pki/<instance>/web.xml ファイルを編集し、サーバーを再起動します。
注記
この値は、サーバー上のすべての Web アプリケーションにあるすべてのセッションに影響することに注意してください。アクセスバナーを再度認証したり、表示したりする必要がないため、大きな値がユーザーのエクスペリエンスが向上します。ただし、破棄された HTTP セッションが期限切れになるまでの時間があるため、セキュリティーリスクも高まります。

14.4.2.3. PKI Web UI のセッションタイムアウト

PKI Web UI は、ブラウザーで実行されるインタラクティブな Web ベースのクライアントです。現在、クライアント証明書認証のみをサポートしています。
Web UI が開くと、ブラウザーはサーバーに複数の TLS 接続を作成できます。これらの接続は単一の HTTP セッションに関連付けられます。
Web UI のタイムアウトを設定するには、「HTTP セッションのタイムアウト」 を参照してください。ブラウザーがクライアント証明書をキャッシュし、TLS セッションを自動的に再作成できるようにするため、TLS セッションのタイムアウトは通常無関係です。
HTTP セッションの期限が切れると、Web UI は即座に表示されません。ただし、Web UI は、ユーザーが操作を実行する前にアクセスバナー (有効な場合) を表示します。

14.4.2.4. PKI コンソールのセッションタイムアウト

PKI コンソールは、インタラクティブなスタンドアロングラフィカル UI クライアントです。ユーザー名/パスワードおよびクライアント証明書認証をサポートします。
コンソールの起動時に、サーバーへの 1 つの TLS 接続が作成されます。コンソールは、グラフィカルインターフェイスを開く前に、アクセスバナー (有効な場合) を表示します。Web UI とは異なり、コンソールはサーバーで HTTP セッションを維持しません。
コンソールのタイムアウトを設定するには、「TLS セッションのタイムアウト」 を参照してください。コンソールは HTTP セッションを使用しないため、HTTP セッションタイムアウトは無関係です。
TLS セッションの期限が切れると、TLS 接続が閉じられ、コンソールがシステムにすぐに終了します。ユーザーが続行する場合は、コンソールを再起動する必要があります。

14.4.2.5. PKI CLI のセッションタイムアウト

PKI CLI は、一連の操作を実行するコマンドラインクライアントです。ユーザー名/パスワードおよびクライアント証明書認証をサポートします。
CLI の起動時に、サーバーと HTTP セッションへの単一の TLS 接続を作成します。CLI は、操作を実行する前にアクセスバナー (有効な場合) を表示します。
通常、操作は遅延なく順次実行され、CLI が完了するとすぐに CLI を終了するため、両方のタイムアウトは PKI CLI とは無関係です。ただし、CLI がユーザー入力を待機するか、速度が低下するか、応答しなくなると、TLS セッションまたは HTTP セッションが期限切れになり、残りの操作が失敗する場合があります。このような遅延が予想される場合は、「TLS セッションのタイムアウト」「HTTP セッションのタイムアウト」 を参照して、想定される遅延に対応します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.