8.4. 既知の問題
これらは、Red Hat Certificate System 9.0 リリースの既知の問題です。利用可能な場合は、回避策も含まれます。
- BZ#1041414
- バグのため、TPS をインストールするときに証明書システムは間違った CA プロファイル ID を設定します。この問題を回避するには、手動で設定します。
op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId
/var/lib/pki/instance_name/tps/conf/CS.cfg
ファイル内のパラメーターを caTokenUserDelegateAuthKeyEnrollment に追加します。op.enroll.delegateISEtoken.keyGen.encryption.ca.profileId=caTokenUserDelegateAuthKeyEnrollment
- BZ#1256901
TLS_ECDHE_RSA_*
暗号が有効になっているときに特定の HSM が使用されると、サブシステムで通信の問題が発生します。この問題は、以下のシナリオで発生します。- CA がインストールされた後、2 番目のサブシステムをインストールする際に、セキュリティードメインとして CA にコンタクトしようとするため、正常にインストールすることができません。
- CA で証明書登録を実行している最中にアーカイブが必要になると、CA が KRA と同じ通信問題に遭遇します。このシナリオは、問題のある暗号がインストールで一時的に無効になっている場合に限り発生します。
この問題を回避するには、可能であればTLS_ECDHE_RSA_*
暗号をオフにしておきます。Perfect Forward Secrecy はTLS_ECDHE_RSA_*
暗号を使用してセキュリティーを強化しますが、各 SSL セッションの確立には約 3 倍の時間がかかることに注意してください。また、デフォルトのTLS_RSA_*
暗号は、Certificate System の操作に適しています。- 上流で追跡された問題
- Red Hat Certificate System 9 は、RSA トランスポート証明書のみを使用した SCEP 登録を提供します。SCEP を使用して ECC 証明書を発行する必要がある場合、管理者は、CA 署名証明書の代わりに、転送目的で使用される RSA システム証明書を設定する必要があります。
- BZ#1202527
- クライアントから提供された CUID の形式が適切に変換されていない場合、
tokenType
およびkeySet
マッピングリゾルバーフレームワークは、CUID 範囲 (tokenCUID.start/tokenCUID.end
) のマッピングフィルターを適切に評価できないことがあります。 - BZ#1256984
- 現在、外部登録リカバリーは、個別にリカバリーする各キーのサイズを計算せず、デフォルトでは 1024 ビットキーに対してのみ適切に機能します。たとえば、2048 ビットの秘密キーを使用して証明書を回復しようとすると失敗します。この問題を回避するには、
CS.cfg
ファイルのexternalRegAddToToken
プロファイルに次の設定を追加します。op.enroll.externalRegAddToToken.keyGen.encryption.keySize=2048
この設定は、追加する必要なすべての証明書に同じサイズのキーがある場合に機能します。 - BZ#1255963
scp01
スマートカードをサポートする最新の TPS アプレットバージョンを使用すると、SafeNet 330 Java (330J) スマートカードでのフォーマット操作が失敗します。TPS サーバーは現在テクノロジープレビューとして提供されており、サブスクリプション契約ではまだ完全にはサポートされていないことに注意してください。- BZ#1202526
- トークンを終了すると、トークン上のすべての証明書が強制的に失効するため、以前はそのプロセスをカスタマイズする機能がほとんどありませんでした。Red Hat Certificate System は、証明書に対して実行される操作に対するきめ細かい制御を追加します。ただし、この機能が適切に動作するには、すべてのトークンタイプに対して次のパラメーターのリストを TPS
CS.cfg
ファイルに追加する必要があります。op.enroll.tokenType.keyGen.keyType.recovery.terminated.revokeCert op.enroll.tokenType.keyGen.keyType.recovery.terminated.revokeCert.reason op.enroll.tokenType.keyGen.keyType.recovery.terminated.scheme
上記のパラメーターにより、terminated
状態とkeyCompromise
状態に異なる取り消し理由を設定できることが保証されます。op.enroll.tokenType.keyGen.keyType.recovery.endState.holdRevocationUntilLastCredential = true/false
上記の各トークンの新しいパラメーターのセットにより、証明書が複数のトークンで共有されている場合、その証明書を含む最後のトークンが終了するか失われるまでその証明書が取り消されないように動作を設定できます。最後のトークンで証明書が最終的に取り消されると、他のすべてのトークンのステータスも同様に取り消し
に設定されます。op.enroll.tokenType.keyGen.keyType.recovery.state.revokeExpiredCerts = true/false
トークンタイプごとに上記の新しいパラメーターのセットを使用すると、期限切れの証明書が取り消されないように動作を設定できます。 - BZ#1255192
- 証明書マネージャー - 証明書プロファイル で、無効になっているプロファイルインスタンスを選択し、編集/表示 をクリックして 証明書プロファイルルールエディター ウィンドウを表示すると、入力への変更が正常に適用されません。
- BZ#1253502
caDirUserCert
証明書が発行されるとき、発行された証明書のジョブ通知が有効になっていると、ジョブ通知電子メールは送信されません。- BZ#1252952
- 現在テクノロジープレビューとして提供されている
gp211
Coolkey アプレットで SCP02 トークンを使用する場合、再登録操作を試行するとプロセスの終わり近くで失敗します。この問題を回避するには、再登録する前にフォーマット操作を実行します。 - BZ#1254804
- CRMF キー生成リクエストタイプは、Firefox 33、35 以降ではサポートされなくなりました。その結果、特に主要なアーカイブ機能において、ブラウザーベースの登録を実行できなくなりました。キーのアーカイブを実行しないプロファイルに対しては、単純な keygen ベースの登録の限定的なサポートが存在することに注意してください。この問題を回避するには、
pki
CLI ユーティリティーを通じて登録を実行します。Red Hat Certificate System 9 では、client-cert-request コマンドは PKCS #10 と CRMF の両方の証明書リクエストをサポートします。キーのアーカイブを含む CRMF 証明書リクエストを生成して送信するには、まずトランスポート証明書をダウンロードします。# pki cert-find --name "<KRA Transport certificate's subject common name>" # pki cert-show serial_number --output transport.pem
次に、証明書リクエストを送信します。# pki -c password client-init # pki -c password client-cert-request subject_DN --profile caDualCert --type crmf --transport transport.pem
- BZ#1257670
- KRA を備えた CA がインストールされており、アーカイブが有効な CA プロファイルを介してアーカイブが試行される場合、サブシステムユーザーではなくユーザー
pkidbuser
を使用して CA と KRA 間の接続が試行されると、アーカイブの試行は失敗します。この問題を回避するには、pkidbuser
ユーザーを Trusted Managers グループに追加します。 - BZ#1244965
- 同期キー回復メカニズムは Red Hat Certificate System 9 では非推奨になりました。Red Hat では、代わりに非同期キーリカバリーを使用することを推奨します。
- BZ#1250741
- CA と、
serialCloneTransferNumber=0
が設定されているマスター CA のクローンを作成する場合、現在、pkispawn
ユーティリティーは適切なエラーメッセージを返しません。 - BZ#1255431
- 認証プラグインインターフェイスプロトコルとの非互換性により、
UdnPwdDirAuth
プラグインが Red Hat Certificate System 9.0 で適切に動作しなくなるため、現時点ではこのプラグインをどのプロファイルにも配置できません。 - BZ#1250734
- CA のクローンを作成するときに、シリアル番号の範囲が
SerialCloneTransferNumber
の値より小さい場合、pkispawn
ユーティリティーは適切なエラーメッセージを返さずに例外で終了します。 - BZ#1252621
pkispawn
ユーティリティーは、/etc/pki/default.cfg
で定義されている次のデフォルトポートを使用します。pki_https_port=8443 pki_http_port=8080
pkispawn
では非常に柔軟なカスタマイズが可能ですが、他の用途に事前に割り当てられたポートを使用してデフォルトのポート値をオーバーライドしようとすると、インストールまたは設定が失敗し、次のようなエラーメッセージが表示される場合があります。pkispawn : DEBUG ....... Error Type: Exception pkispawn : DEBUG ....... Error Message: port 9180 has invalid selinux context pki_ca_port_t
特定のポートが利用可能かどうかは、次のコマンドを実行して確認できます。# semanage port -l | grep 9180 pki_ca_port_t tcp 829, 9180, 9701, 9443-9447 # semanage port -l | grep 18443 (if the port is unused, nothing will be displayed)
注記Red Hat Certificate System 9 は、デフォルトの HTTP ポート 8080 がhttp_cache_port_t
を使用する場合でも、主にhttp_port_t
SELinux コンテキストを使用します。以下のポートとその SELinux コンテキストは、以前のバージョンの Red Hat Certificate System のシステムポリシーに追加されたため、Red Hat Certificate System 9 では使用できません。# semanage port -l | grep pki pki_ca_port_t tcp 829, 9180, 9701, 9443-9447 pki_kra_port_t tcp 10180, 10701, 10443-10446 pki_ocsp_port_t tcp 11180, 11701, 11443-11446 pki_ra_port_t tcp 12888-12889 pki_tks_port_t tcp 13180, 13701, 13443-13446 pki_tps_port_t tcp 7888-7889
- BZ#1246635
- pki user-cert-add コマンドには、CA からユーザー証明書を直接インポートするオプションが用意されています。ただし、クライアントライブラリーの初期化が正しくないためにコマンドが SSL ポート経由で実行される場合、このオプションは正しく機能しません。その結果、コマンドは失敗し、次のエラーメッセージが表示されます。
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated.
この問題を回避するには、pki cert-show コマンドを使用して CA から証明書をファイルにダウンロードし、次に pki user-cert-add コマンドを使用してファイルから証明書をアップロードします。 - BZ#1247410
- 現在、
ocspResponderURL
設定パラメーターは、HTTPS セキュアポートを使用する場合には機能しません。その結果、CA のセキュアポートを使用して KRA (Key Recovery Authority) サブシステムから OCSP チェックを有効にしようとすると、KRA の再起動中に自己テストが失敗します。この問題を回避するには、応答には署名とタイムスタンプが付いているため、安全でない HTTP ポートを安全に使用できます。 - BZ#1251581
- エンドエンティティーページで
手動ユーザー署名および暗号化証明書登録
プロファイルを使用して登録要求が送信されると、CA は暗号化証明書と署名証明書の両方を生成します。ただし、CRMFPopClient
またはpki
ユーティリティーを使用して要求が送信された場合、CA は暗号化証明書のみを生成します。この問題を回避するには、署名証明書を個別に要求します。 - BZ#1231261
pkispawn
ユーティリティーには対話型モードがあり、主にユーザーが最も簡単な設定をデプロイし、Red Hat Certificate System に慣れるのに役立ちます。したがって、pkispawn は
現在、HSM、クローン作成サブシステム、サブ CA、および外部署名された CA の対話型セッションを提供しません。一時的な救済策として、対話型のpkispawn
セッション中に、どの機能がまだサポートされていないのかがユーザーに適切に通知され、他の関連するエラーメッセージによる混乱が防止されます。- BZ#753311
- CA を再起動すると、SELinux は AVC 拒否エラーメッセージを返します。最終的に CA は適切に再起動されるため、これらのエラーは無視できます。
- BZ#699456
- 管理者がカスタムログタイプを作成した場合、ファイルまたはログファイル設定に加えられた変更は監査ログに記録されません。これは、ログファイルが安全ではないことを意味します。
- BZ#693412
- KRA エージェントのページを使用して保留中の回復リクエストを検索しても、保留中のリクエストのリストは返されません。回復リクエストの送信時に指定された参照番号を使用して、特定の回復リクエストを検索します。参照番号で検索すると、回復要求レコードが返されます。そこから、ボタンをクリックすることでリクエストを承認できます。
- BZ#678320
- アプレットのアップグレード操作でトークンのパスワードをリセットすると、正しく機能しません。パスワードのリセット操作とアプレットのアップグレード操作は両方とも失敗します。この問題を回避するには、PIN リセットプロファイルでアプレットのアップグレードを無効にします。
- BZ#673182
- ECC キーは監査ログの署名ではサポートされていません。サーバーも AuditVerify ユーティリティーも、署名付き監査ログファイルの ECC キーをサポートしません。この問題を回避するには、監査ログの署名に RSA キーを使用します。
- BZ#664594
- キー回復リクエストが承認されて完了すると、回復リクエストページにどの KRA エージェントが回復を承認したかのリストが表示されます。代わりに、回復承認エージェント フィールドは空白のままになります。エージェントがリクエストを承認するために使用する回復ページは、承認するエージェントのリストで更新されます。そのページは参照できます。
- BZ#616532
- キーを回復しようとするときに、キー識別子に基づいて保留中のリクエストを検索し、ボタンをクリックすると、リクエストの処理に問題があったというエラーが返されます。検索リクエストの送信に使用されたフォームが不正な形式のリクエストを送信し、その結果、無効な X.509 証明書エラーが発生します。この問題を回避するには、検索条件フォームに完全な証明書 BLOB を貼り付けて回復証明書を検索します。
- BZ#512029
- 同じ HSM パーティションが複数の Red Hat Certificate System サブシステムインスタンスに使用されている場合、インスタンスが異なるホスト上にある場合でも、インスタンス名を複数回使用することはできません。ユーザーが既存のインスタンスと同じ名前 (デフォルトのオプションを含む) で新しいインスタンスを設定しようとすると、証明書のサブジェクト名がすでに存在するというエラーが表示され、設定プロセスが鍵生成ステップで停止します。この問題を回避するには、HSM を使用するときに、常に個別の
pki_ XYZ _subject_dn
を個別に指定します。 - BZ#226823
server.xml
ファイルの <Connector> エントリーにエラーがあると、サーバーが起動してそのコネクターポートをリッスンしますが、サービスは提供されません。この問題は、システムが内部トークンではなく HSM を使用するように設定されている場合に発生し、Tomcat サーバーから返される次の JSS 設定エラーによって認識できます。Failed to create jss service: java.lang.SecurityException: Unable to initialize security library
- BZ#454559
wget
ユーティリティーまたは HTTP POST を使用して Online Certificate Status Manager に接続して OCSP 要求を送信しようとすると、タイムアウトになります。この問題を回避するには、OCSPClient
ユーティリティーを使用してステータス要求を送信します。