第23章 認証および相互運用性
yum が、ipa-clientのインストール後にパッケージの競合を報告しなくなりました。
ユーザーが ipa-client パッケージをインストールすると、
yum ユーティリティーが、ipa パッケージと freeipa パッケージ間のパッケージの競合を予期せず報告しました。このエラーは、トランザクションの失敗後、または yum check コマンドの使用後に発生しました。今回の更新で、RPM でこのような競合が発生するため、yum は自己競合パッケージに関するエラーを報告しなくなりました。その結果、yum は、ipa-client のインストール後に上記のエラーを表示しなくなりました。(BZ#1370134)
FIPS モードでは、slapd_pk11_getInternalKeySlot （） 関数を使用して、トークンのキースロットを取得するようになりました。
Red Hat Directory Server は、セキュリティーデータベースで FIPS モードが有効になっているときに、固定トークン名からキースロットを取得しようとしました。ただし、トークン名は変更できます。キースロットが見つからないと、Directory Server がレプリケーションマネージャーのパスワードをデコードできず、レプリケーションセッションが失敗します。この問題を修正するために、slapd_pk11_getInternalKeySlot （） 関数は FIPS モードを使用して現在のキースロットを取得するようになりました。その結果、上記の状況では、
SSL または STTARTTLS を使用したレプリケーションセッションが失敗しなくなりました。(BZ#1378209)
Certificate System は、FIPS モードのシステムで Thales HSM でインストールに失敗しなくなりました。
Thales ハードウェアセキュリティーモジュール (HSM) で Certificate System (CS) を使用してインストールした後、HSM ですべてのシステムキーを生成した場合、SSL プロトコルが正しく機能しませんでした。そのため、CS は FIPS モードが有効になっているシステムにインストールできず、
server.xml ファイルの sslRangeCiphers パラメーターを手動で変更する必要がありました。このバグが修正され、Thales HSM を使用したインストールの FIPS 対応システムが期待どおりに機能するようになりました。(BZ#1382066)
pkispawn の依存関係一覧に、openssl が正しく含まれるようになる
以前は、openssl パッケージがインストールされていない場合、
pkispawn ユーティリティーの使用が以下のエラーで失敗していました。
Installation failed: [Errno 2] No such file or directory
この問題は、opensslパッケージが、pki-core パッケージに含まれる pki-server パッケージのランタイム依存関係として含まれていなかったために発生しました。このバグは、不足している依存関係を追加することで修正され、openssl がないため
pkispawn のインストールに失敗しなくなりました。(BZ#1376488)
PKI サーバープロファイルフレームワークからのエラーメッセージがクライアントに渡されるようになる
以前は、PKI サーバーは、証明書要求のプロファイルフレームワークにより生成された特定のエラーメッセージをクライアントに渡していませんでした。そのため、Web UI または pki コマンドの出力に表示されるエラーメッセージで、要求が失敗した理由が説明されませんでした。コードが修正され、エラーメッセージが渡されるようになりました。ユーザーは、登録に失敗した理由や、登録が拒否された理由を確認できるようになりました。(BZ#1249400)
インストール時に、Certificate System が Lightweight CA 鍵のレプリケーションを開始しない
Certificate System は、2 段階のインストールで、Lightweight CA 鍵のレプリケーションを間違って開始していました。その結果、インストールに失敗し、エラーが表示されました。この更新では、2 段階のインストールで Lightweight CA キーの複製は開始されず、インストールは正常に完了します。(BZ#1378275)
PKI サーバーが、起動時にサブジェクト DN を正しく比較するようになりました。
プライマリー CA に Lightweight CA エントリーを追加するルーチンのバグにより、PKI サーバーは、UTF8String 以外のエンコーディングを使用する属性が含まれている場合に、サブジェクト識別名(DN)の比較に失敗していました。その結果、プライマリー CA が起動するたびに、Lightweight CA エントリーが追加されました。PKI サーバーは、サブジェクト DN を正規の形式で比較するようになりました。その結果、PKI サーバーは、前述のシナリオで Lightweight CA エントリーを追加しなくなりました。(BZ#1378277)
不完全な証明書チェーンを持つ中間 CA に接続したときに、KRA のインストールが失敗しなくなりました。
以前は、信頼できる CA 証明書があるがルート CA 証明書がない中間 CA への接続を試みると、KRA (Key Recovery Authority)サブシステムのインストールが
UNKNOWN_ISSUER エラーで失敗していました。この更新により、KRA のインストールはエラーを無視し、正常に完了します。(BZ#1381084)
証明書プロファイルの startTime フィールドが長い整数形式を使用するようになりました。
以前は、Certificate System は、証明書プロファイルの
startTime フィールドに 整数 として値を保存していました。これより大きな数字を入力すると、Certificate System により、この値が負の数として解釈されます。その結果、認証局は、過去の開始日を含む証明書を発行しました。今回の更新で、startTime フィールドの入力形式が長い整数に変更されました。これにより、発行した証明書の開始日が正しくなりました。(BZ#1385208)
PKCS#11 トークンがログインしてい ないため、下位 CA のインストールに失敗しなくなりました。
以前は、Network Security Services (NSS)ライブラリーのバグが原因で、下位認証局(sub-CA)のインストールに失敗していました。これにより、SEC_ERROR_TOKEN_NOT_LOGGED_IN エラーが生成されていました。今回の更新で、インストーラーに回避策が追加され、インストールを続行できるようになりました。それでもエラーが表示される場合は、無視できるようになりました。(BZ#1395817)
pkispawn スクリプトが ECC 鍵サイズを正しく設定するようになりました。
以前は、ユーザーが Elliptic Curve Cryptography (ECC)キーサイズパラメーターをデフォルト値( nistp256 )とは異なる値に設定して pkispawn スクリプトを実行すると、設定は無視されていました。そのため、作成された PKI サーバーインスタンスがシステム証明書を発行しました。これは、デフォルトの ECC 鍵曲線を誤って使用していました。今回の更新で、PKI サーバーは、ECC 鍵曲線名に pkispawn 設定に設定された値を使用するようになりました。その結果、PKI サーバーインスタンスは、インスタンスの設定時に設定された ECC 鍵サイズを使用するようになりました。(BZ#1397200)
FIPS モードでの CA クローンのインストールに失敗しなくなりました。
以前は、CA クローンまたは Key Recovery Authority (KRA) のインストールは、内部 NSS トークン名の処理に一貫性がないため、FIPS モードで失敗していました。今回の更新で、トークン名を処理するコードが統合され、すべてのトークン名が一貫して処理されるようになりました。T を使用すると、FIPS モードで KRA および CA クローンのインストールが適切に完了します。(BZ#1411428)
entryUSN 属性に 32 ビットより大きい値が含まれている場合に、PKI サーバーの起動に失敗しなくなりました。
以前は、*LDAP プロファイルモニターと Lightweight CA Monitor は、entryUSN 属性の値を 32 ビット整数として解析していました。その結果、属性にそれより大きい値が含まれる場合、
NumberFormatException エラーがログに記録され、サーバーが起動しませんでした。この問題は修正され、前述のシナリオでサーバーの起動に失敗することはなくなりました。(BZ#1412681)
Tomcat はデフォルトで IPv6 で動作する
IPv4固有の 127.0.0.1 ループバックアドレスは、以前はデフォルトのサーバー設定ファイルでデフォルトの AJP ホスト名として使用されていました。これにより、IPv6のみの環境で実行されるサーバーで接続が失敗しました。今回の更新で、デフォルト値は localhost に変更され、IPv4 プロトコルと IPv6 プロトコルの両方で機能します。さらに、既存のサーバーインスタンスの AJP ホスト名を自動的に変更するためのアップグレードスクリプトを使用できます。(BZ#1413136)
pkispawn が無効な NSS データベースパスワードを生成しなくなりました。
今回の更新以前は、pkispawn は
NSS データベース用に無作為のパスワードを生成していましたが、場合によってはバックスラッシュ(\)文字が含まれていました。これにより、NSS が SSL 接続を確立したときに問題が発生し、ACCESS_SESSION_ESTABLISH_FAILURE エラーでインストールが失敗しました。
この更新により、ランダムに生成されたパスワードにバックスラッシュ文字を含めることができなくなり、接続を常に確立できるため、インストールを正常に完了することができます。(BZ#1447762)
--serial オプションを使用してユーザー証明書を追加するときに、証明書の取得が失敗しなくなりました。
--serial パラメーターを指定して pki user-cert-add コマンドを使用すると、認証局(CA)への
SSL 接続が正しく設定されていなかったため、証明書の取得に失敗していました。この更新では、コマンドは CA への適切に設定された SSL 接続を使用し、操作は正常に完了します。(BZ#1246635)
エントリーが 1 つだけの場合、CA Web インターフェイスに空の証明書要求ページが表示されなくなりました。
以前は、CA Web ユーザーインターフェイスの証明書要求ページにエントリーが 1 つしか含まれていなかった場合、単一のエントリーではなく空のページが表示されていました。今回の更新で Web ユーザーインターフェイスが修正され、証明書の要求ページがすべての状況で正しくエントリーを表示できるようになりました。(BZ#1372052)
コンテナー環境に PKI サーバーをインストールしても警告が表示されなくなる
以前は、コンテナー環境に pki-server RPM パッケージをインストールすると、
systemd デーモンが再読み込みされていました。その結果、警告が表示されました。RPM アップグレード時のみデーモンを再ロードするパッチが適用されました。その結果、上記のシナリオで警告が表示されなくなります。(BZ#1282504)
G&D スマートカードを使用したトークンの再登録が失敗しなくなる
以前は、Giesecke & Devrient (G&D) スマートカードを使用してトークンを再登録すると、特定の状況でトークンの登録が失敗する可能性がありました。問題が修正され、トークンの再登録が想定どおりに機能するようになりました。(BZ#1404881)
PKI サーバーは、起動時の証明書検証エラーの詳細を提供します。
以前は、サーバーの起動時に証明書の検証エラーが発生した場合、PKI サーバーが十分な情報を提供していませんでした。その結果、問題のトラブルシューティングは困難でした。PKI サーバーは、新しい Java セキュリティーサービス (JSS) API を使用するようになりました。これにより、前述のシナリオでのエラーの原因に関するより詳細な情報が提供されます。(BZ#1330800)
PKI サーバーが LDAPProfileSubsystem プロファイルの再初期化に失敗しなくなる
LDAPProfileSubsystem プロファイルの再初期化中の競合状態が原因で、PKI サーバーは以前に要求されたプロファイルが存在しないと誤って報告する可能性がありました。その結果、プロファイルを使用する要求が失敗する可能性がありました。問題が修正され、プロファイルを使用する要求が失敗しなくなりました。(BZ#1376226)
HSM で生成された秘密鍵の抽出に失敗しなくなりました。
以前は、鍵回復エージェント (KRA) で新しい Asymmetric Key Generation REST サービスを使用して、Lunasa または Thales ハードウェアセキュリティーモジュール (HSM) で非対称鍵を生成すると、PKI サーバーが間違ったフラグを設定していました。その結果、生成された秘密鍵をユーザーが取得できませんでした。このコードは、この HSM で生成された鍵に正しいフラグを設定するように更新されました。これにより、前述のシナリオでユーザーが秘密鍵を取得できるようになりました。(BZ#1386303)
pkispawn が数字のみで設定されるパスワードを生成しなくなりました
以前は、pkispawn は数字のみで設定される NSS データベースの無作為なパスワードを生成する可能性がありました。このようなパスワードは FIPS に準拠していません。今回の更新で、インストーラーが、数字、小文字、大文字、および特定の句読点を混在させた FIPS 準拠のランダムパスワードを生成するように変更されました。(BZ#1400149)
CA 証明書が正しい信頼フラグでインポートされる
以前のリリースでは、pki client-cert-import コマンドは、
CT,c, 信頼フラグを使用して CA 証明書をインポートしていましたが、これは不十分で、他の PKI ツールと一貫性がありませんでした。今回の更新で、コマンドが修正され、CA 証明書の信頼フラグが CT,C,C に設定されるようになりました。(BZ#1458429)
--usage verify オプションの使用時に対称鍵の生成に失敗しなくなりました。
pki ユーティリティーは、生成される対称鍵の有効な使用法のリストをチェックします。以前は、このリストに verify の使用がありませんでした。これにより、key-generate --usage verify オプションを使用するとエラーメッセージが返されました。コードが修正され、verify オプションが期待どおりに機能するようになりました。(BZ#1238684)
後続の PKI インストールが失敗しなくなる
以前は、複数の公開鍵インフラストラクチャー (PKI) インスタンスをバッチモードでインストールする場合、インストールスクリプトは CA インスタンスが再起動されるまで待機しませんでした。その結果、後続の PKI インスタンスのインストールが失敗する可能性がありました。スクリプトが更新され、新しいサブシステムが要求を処理できるようになるまで待機してから続行します。(BZ#1446364)
FIPS モードでの 2 段階の subordinate CA インストールに失敗しなくなる
以前は、FIPS モードでの subordinate CA インストールのバグにより、2 つ目の手順でインスタンスが存在しないことをインストーラーが要求するため、2 段階のインストールが失敗していました。今回の更新で、最初の手順 (インストール) ではインスタンスが存在しないことが要求され、2 番目の手順 (設定) ではインスタンスが存在することが要求されるようにワークフローが変更されました。
以前の
pki_skip_configuration および pki_skip_installation デプロイメントパラメーターを置き換えるために、pkispawn コマンドに 2 つの新しいオプション--skip-configuration および --skip-installation が追加されました。これにより、変更を加えずに、両方の手順で同じデプロイメント設定ファイルを使用できます。(BZ#1454450)
監査ログは、証明書の要求が拒否またはキャンセルされたときに成功を記録しなくなりました。
以前は、証明書要求が拒否またはキャンセルされた場合、サーバーは
Outcome=Success で CERT_REQUEST_PROCESSED 監査ログエントリーを生成していました。要求に対して証明書が発行されていないため、これは間違っていました。このバグは修正され、拒否またはキャンセルされたリクエストの CERT_REQUEST_PROCESSED 監査ログエントリーが Outcome=Failure を読み取るようになりました。(BZ#1452250)
セルフテストに失敗した PKI サブシステムが、システムの起動時に自動的に再度有効になるようになりました。
以前は、セルフテストの失敗が原因で PKI サブシステムを開始できなかった場合に、一貫性のない状態で実行されないように、PKI サブシステムは自動的に無効にされていました。管理者は、問題を修正した後、pki-server サブシステムを有効にして手動でサブシステムを再度有効 にすることが想定されました。しかし、これは明確に伝達されておらず、この要件を常に認識しているとは限らない管理者の間で混乱を引き起こす可能性がありました。
この問題を軽減するため、すべての PKI サブシステムが、デフォルトでシステムの起動時に自動的に再度有効になりました。セルフテストが失敗すると、サブシステムは以前と同様に無効になりますが、手動で再度有効にする必要はありません。
CERT_REQUEST_PROCESSED 監査ログエントリーに、エンコードされたデータではなく証明書のシリアル番号が含まれるようになりました。
以前は、
CERT_REQUEST_PROCESSED 監査ログエントリーに Base64 でエンコードされた証明書データが含まれていました。以下に例を示します。
[AuditEvent=CERT_REQUEST_PROCESSED]...[InfoName=certificate][InfoValue=MIIDBD...]
証明書データは個別にデコードする必要があるため、この情報はあまり役に立ちませんでした。以下の例のように、コードが変更され、証明書のシリアル番号がログエントリーに直接含まれるようになりました。
[AuditEvent=CERT_REQUEST_PROCESSED]...[CertSerialNum=7]
(BZ#1452344)
LDAPProfileSubsystem プロファイルの更新で属性の削除に対応
以前は、PKI サーバーで
LDAPProfileSubsystem プロファイルを更新すると、属性を削除できませんでした。そのため、特定の状況でプロファイルを更新した後、PKI サーバーがプロファイルを読み込んだり、証明書を発行したりできませんでした。パッチが適用され、PKI サーバーが新しい設定を読み込む前に、既存のプロファイル設定を消去するようになりました。その結果、LDAPProfileSubsystem プロファイルの更新で、設定属性を削除できるようになりました。(BZ#1445088)
