Menu Close

リリースノート

Red Hat Certificate System 10

Red Hat Certificate System 10 に関連する主な機能および更新

概要

本リリースノートには、システム要件、インストールノート、重要な変更、現在の問題など、Red Hat Certificate System 10 に関連する重要な情報が含まれています。Red Hat Certificate System 10 をデプロイする前に、このリリースノートを完全に読み取る必要があります。

第1章 Red Hat Certificate System 10

本セクションでは、サポートされるプラットフォームやシステム要件、インストールノート、および非推奨など、Red Hat Certificate System 10 に関する一般的な情報を説明します。

重要

Red Hat Certificate System 10 パッケージとその依存関係は、redhat-pki モジュールから Red Hat Enterprise Linux 8 で提供されます。

1.1. 前提条件

Red Hat Certificate System 10 をインストールするには、Red Hat Enterprise Linux 8 が必要です。Red Hat Enterprise Linux 8 のインストール方法は『 標準的な RHEL インストールの実行』を 参照してください。

1.2. ハードウェア要件

本セクションでは、Red Hat Certificate System 10 の最小および推奨されるハードウェアを説明します。環境によっては、より多くのリソースが必要になる可能性があることに注意してください。

1.2.1. 最低要件

  • CPU: 2 スレッド
  • RAM: 2 GB
  • ディスク容量: 20 GB

最小要件は、Red Hat Enterprise Linux 8 の最小要件に基づいています。詳細は、「Red Hat Enterprise Linux テクノロジーの機能と制限」を参照してください。

1.3. サポートされるプラットフォーム

本セクションでは、Red Hat Certificate System 10 でサポートされているさまざまなサーバープラットフォーム、ハードウェア、トークン、およびソフトウェアを説明します。

1.3.1. サーバーサポート

{RHCS }10 の認証局(CA)、Key Recovery Authority(KRA)、オンライン証明書ステータスプロトコル(OCSP)、トークンキーサービス(TKS)、およびトークン処理システム(TPS)サブシステムの実行は、Red Hat Enterprise Linux 8 以降でサポートされています。サポートされる Red Hat Directory Server バージョンは 11 以降です。

注記

Red Hat Certificate System 10 は、認定済みのハイパーバイザーの Red Hat Enterprise Linux 8 仮想ゲストでの実行に対応します。詳細は、ナレッジベースアーティクル「 RHEL の実行が認定されているハイパーバイザー 」を参照してください。

1.3.2. クライアントサポート

Enterprise Security Client (ESC) は以下でサポートされます。

  • Red Hat Enterprise Linux 8.
  • Red Hat Enterprise Linux 6 および 7 の最新版

    これらのプラットフォームは Red Hat Certificate System 10 をサポートしませんが、このクライアントは Red Hat Certificate System 10 の Token Management System (TMS) システムで使用できます。

1.3.3. サポートされる Web ブラウザー

Red Hat Certificate System 10 は、以下のブラウザーをサポートします。

表1.1 プラットフォームでサポートされる Web ブラウザー

プラットフォームエージェントサービスエンドユーザーページ

Red Hat Enterprise Linux

Firefox 60 以降[a]

Firefox 60 以降

Windows 7

Firefox 60 以降

Firefox 60 以降

Internet Explorer 10 [b]

[a] この Firefox バージョンは、ブラウザーからキーの生成およびアーカイブに使用される crypto Web オブジェクトに対応しなくなりました。そのため、このエリアでは機能が限定されるはずです。
[b] 現在、Internet Explorer 11 は Red Hat Certificate System 10 ではサポートされていません。この Web ブラウザーの登録コードは、Internet Explorer 11 で非推奨となった Visual Basic スクリプト に依存するためです。
注記

HTML ベースのインスタンス設定に完全に対応するブラウザーは Mozilla Firefox のみです。

1.3.4. 対応するスマートカード

Enterprise Security Client (ESC) は、Global Platform 2.01 準拠のスマートカードおよび JavaCard 2.1 以降をサポートします。

Certificate System サブシステムは、以下のトークンを使用してテスト済みです。

  • Gemalto TOP IM FIPS CY2 64K トークン (SCP01)
  • Giesecke & Devrient (G&D) SmartCafe Expert 7.0 (SCP03)
  • SafeNet Assured Technologies SC-650 (SCP01)

Certificate System でサポートされている唯一のカードマネージャーアプレットは、Red Hat Certificate System の pki-tps パッケージに含まれる CoolKey アプレットです。

1.3.5. サポート対象のハードウェアセキュリティーモジュール

以下の表は、Red Hat Certificate System がサポートする Hardware Security Modules(HSM)を示しています。

HSMファームウェアアプライアンスソフトウェアクライアントソフトウェア

nCipher nShield Connect 6000

2.61.2

CipherTools-linux64-dev-12.30.00

CipherTools-linux64-dev-12.30.00

Gemalto SafeNet Luna SA 1700 / 7000 (制限)

(サポートは限定されます): 詳細は以下を参照してください。

6.24.0

6.2.0-15

libcryptoki-6.2.x86_64

1.3.5.1. Gemalto SafeNet Luna SA 1700 / 7000 (制限)

本セクションでは、Gemalto SafeNet Luna SA 1700 / 7000 HSM を使用する場合にサポートされる機能を説明します。

Gemalto SafeNet Luna SA は、CKE - Key Export モデルでの PKI 秘密鍵抽出のみおよび 非 FIPS モードでのみサポートされます。FIPS モードの Luna SA Cloning モデルおよび CKE モデルは、PKI 秘密鍵の抽出をサポートしません。その後、Luna SA CKE - Key Export Model が FIPS モードにあり、PKI 秘密鍵を抽出できません。

CL - クローンモデル
  • 対称キーおよびオブジェクトのクローン: 他の Luna SAs/G5 または Luna バックアップ HSM が可能
  • 非対称 (プライベート) キーおよびオブジェクトのクローン作成: 他の Luna SAs/G5 または Luna バックアップ HSM が可能
  • 対称キーおよびオブジェクトのレプリケーション: HA グループに設定されている場合、対称キーおよびオブジェクトはすべてレプリケートされます。
  • 非対称キーおよびオブジェクトのレプリケーション: HA グループに設定されている場合、非対称キーおよびオブジェクトはすべてレプリケートされます。
  • HSM からプライベート (非対称) キーをラップ: 実行できません。

図1.1 クローンモデルの例

LunaSA クローン作成
CKE - Key Export モデル
  • 対称キーおよびオブジェクトのクローン: 他の Luna SAs/G5 または Luna バックアップ HSM が可能
  • 非対称 (プライベート) キーおよびオブジェクトのクローン作成ができない
  • 対称キーおよびオブジェクトのレプリケーション: HA グループに設定されている場合、対称キーおよびオブジェクトはすべてレプリケートされます。
  • 非対称キーおよびオブジェクトのレプリケーション: 不可能
  • HSM からプライベート (非対称) キーをラップ: 可能

図1.2 キーエクスポートモデルの例

LunaSA CKE

1.4. RHCS サブシステムをインストールするためのクイックスタート

The following procedure describes the prerequisites and the basic installation process for {RHCS} 10.

前提条件

  • 最新の Red Hat Enterprise Linux 8 バージョンが、アクティブなネットワーク connexion でインストールされます。最新の iso イメージについては、「 Red Hat Enterprise Linux のダウンロード 」を参照してください。

手順

  1. Red Hat Subscription Manager(RHSM)を使用してシステムをカスタマーポータルアカウントに登録し、登録したシステム用にこのアカウントで利用可能なサブスクリプションを一覧表示します。

    $ subscription-manager register
    $ subscription-manager list --available --all
  2. 前の手順で取得した対応するプール ID を使用して、Red Hat Enterprise Linux Server および Red Hat Certificate System に必要なサブスクリプションを割り当てます。

    $ subscription-manager attach --pool=POOL_ID_RHEL_SERVER
    $ subscription-manager attach --pool=POOL_ID_CERT_SYSTEM
  3. Red Hat Enterprise Linux に最新の更新があることを確認します。

    $ dnf update
  4. Directory Server モジュールをインストールします。

    & dnf module enable 389-ds:1.4 && dnf install 389-ds-base
  5. 実際のドメイン名が /etc/resolv.conf で指定されていることを確認します。ホスト名は /etc/hosts 内に設定されます。
  6. Directory Server インタラクティブインストーラーを実行し、必要に応じてカスタマイズします。

    $ dscreate interactive

    詳細またはその他のインストール方法は、『Red Hat Directory Server インストールガイド』を参照してください。

  7. Certificate System パッケージおよび依存関係をインストールします。

    $ dnf module enable redhat-pki:10 && dnf install redhat-pki
  8. pkispawn スクリプトを実行して、サブシステムインスタンスを作成および構成します。他のタイプのサブシステムを構成する前に、少なくとも 1 つの CA サブシステムをインストールして完全に構成する必要があります。詳細は、man ページの pkispawn を参照してください。オプションがない場合、pkispawnはインタラクティブモードで実行され、インストールに必要な基本情報の入力をユーザーに求めます。

    $ pkispawn
  9. 適切に構成されたローカルまたはリモートの Mozilla Firefox Web ブラウザーを使用して、さまざまな Red Hat Certificate System サブシステムのエージェントインターフェースにアクセスします。

Red Hat Certificate System サブシステムのインストールと設定の詳細は、『 プランニング、インストール、およびデプロイメントのガイド』 を参照してください。

1.5. 非推奨の機能

本セクションでは、Red Hat Certificate System 10 で非推奨になった機能を説明します。

Certificate System の SCP01 サポートが非推奨に

Secure Channel Protocol 01 (SCP01) のサポートは Certificate System 10 で非推奨になり、削除される可能性があります。Red Hat は、SCP03 をサポートするスマートカードの使用を推奨します。

pkiconsole ツールが非推奨に

Certificate System 10 では、pkiconsole ツールが非推奨になりました。

第2章 Red Hat Certificate System 10.4

本セクションでは、強調表示された更新や新機能、重要なバグ修正、現在の既知の問題など、Red Hat Certificate System 10.4 における重要な変更を説明します。

注記

Red Hat Certificate System を以前のマイナーバージョンにダウングレードすることはサポートされていません。

2.1. CS 10.4 の更新および新機能

本セクションでは、Red Hat Certificate System 10.4 の新機能および重要な更新を説明します。

pki-core パッケージ内の機能を更新し、新機能を加えます。

証明書システムパッケージがバージョン 10.13.0 にリベースされました。

pki-core パッケージ、redhat-pki パッケージ、redhat-pki-theme パッケージ、および pki-console パッケージがアップストリームバージョン 10.13.0 にアップグレードされ、以前のバージョンに対するバグ修正や機能強化が数多く追加されました。

2.2. CS 10.4 のバグ修正

本パートでは、ユーザーに大きな影響を及ぼしていた Red Hat Certificate System 10.4 で修正されたバグを説明します。

TPS が、tps-cert-findのトークンプロファイルの分離を適切に実施するようになりました。

今回の修正により、tps-cert-find コマンドが、tps-token-find コマンドと同様の方法で、ユーザープロファイルに応じてトークン ID、ユーザー ID、ステータス、日付などのエントリーを適切に制限するようになりました。

TPS Web UI でトークンが適切に表示されるようになりました。

以前のバージョンでは、tpsclient ツールを使用してトークンをフォーマットおよび登録したり、Web UI でトークンを追加すると、TPS Web UI でトークンが表示されませんでしたが、デバッグログには正常に記録されたエントリーが表示されませんでした。今回の修正により、Web UI がすべてのトークンを適切に一覧表示するようになりました。

pki-core パッケージのバグ修正:

ファイルへの書き込み時に pki-server ca-cert-request-show が失敗しなくなりました。

以前は、pki-server ca-cert-request-show < request_id > -i < instance > --output-file < output_file > コマンドは、以下のエラーで失敗していました。ERROR: a bytes-like object is required, not 'str'.今回の修正により、ファイルに書き込む前に証明書要求がバイトとしてエンコードされるようになりました。その結果、コマンドは証明書を正常にエクスポートするようになりました。

2.3. CS 10.4 の既知の問題

ここでは、Red Hat Certificate System 10.4 でユーザーが認識すべき既知の問題を説明し、必要に応じて回避策を説明します。

TPS では、匿名バインド ACI アクセスの追加が必要

以前のバージョンでは、匿名バインド ACI はデフォルトで許可されていましたが、LDAP では無効になっています。これにより、TPS スマートカードの登録またはフォーマットができなくなります。

修正までこの問題を回避するには、Directory Server に匿名バインド ACI を手動で追加する必要があります。

$ ldapmodify -D "cn=Directory Manager" -W -x -p 3389 -h hostname -x <<EOF
dn: dc=example,dc=org
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
EOF

pki-core パッケージで既知の問題

auditSigningCertに属性がないため、HSM で KRA のクローン作成に失敗する

HSM で KRA のクローンを作成する場合は、auditSigningCert 信頼属性 u,u,Pu は、マスターとクローンの間でエイリアス DB で暗黙的に同期する必要があります。ただし、クローンのエイリアス DB でのレプリケーションに失敗するようになりました。したがって、HSM で KRA のクローン作成に失敗すると、audit SigningCert cert-topology-02-KRA KRA is invalid: Invalid certificate:(-8101)Certificate type not approved for application というエラーが出て失敗します。

この問題を回避するには、クローン KRA の alias DB に auditSigningCertu,u,Pu trust 属性を明示的に追加し、インスタンスを再起動する必要があります。以下は例になります。

  • 回避策を行う前に、以下を行います。

    # certutil -vv -V -d /var/lib/pki/clone-KRA/alias/ -h nfast -n 'token:auditSigningCert cert-topology-02-KRA KRA' -u J
      Enter Password or Pin for "token":
      certutil: certificate is invalid: Certificate type not approved for application.
  • 回避策の後には、以下の点に注意してください。

    # certutil -M -d /var/lib/pki/clone-KRA/alias/ -n 'token:auditSigningCert cert-topology-02-KRA KRA' -t u,u,Pu
    # certutil -vv -V -d /var/lib/pki/clone-KRA/alias/ -h nfast -n 'token:auditSigningCert cert-topology-02-KRA KRA' -u J
      Enter Password or Pin for "token":
      certutil: certificate is valid

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムが破損します。

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムの LDAP 設定が破損します。そのため、証明書システムが不安定になり、システムの復旧に手動の手順が必要になる可能性があります。

第3章 Red Hat Certificate System 10.3

本セクションでは、強調表示された更新や新機能、重要なバグ修正、最新の既知の問題など、Red Hat Certificate System 10.3 の重要な変更点を説明します。

注記

Red Hat Certificate System を以前のマイナーバージョンにダウングレードすることはサポートされていません。

3.1. CS 10.3 の更新および新機能

本セクションでは、Red Hat Certificate System 10.3 の新機能および重要な更新を説明します。

pki-core パッケージ内の機能を更新し、新機能を加えます。

証明書システムパッケージがバージョン 10.12.4 にリベースされました。

pki-core パッケージ、redhat-pkiredhat-pki-theme パッケージ、および pki-console パッケージがアップストリームバージョン 10.12.4 にアップグレードされ、以前のバージョンに対するバグ修正および機能拡張が数多く追加されました。

3.2. CS 10.3 のバグ修正

本パートでは、ユーザーに大きな影響を及ぼしていた Red Hat Certificate System 10.3 で修正されたバグを説明します。

pki-core パッケージのバグ修正:

pcsc-litepcsc-lite-ccid、および escが原因で、特定の SCP03 および SCP01 トークンでセキュアなチャネルを完了できなくなりました。

Red Hat Certificate System 10.2 のリリース時点では、pcsc-lite、pcsc -lite- ccid、および esc パッケージに関する問題が原因で、特定の SCP03 および SCP01 トークンを持つセキュアなチャネルが完了しました。これは、後続のバッチ更新によって修正されました。

サブ CA 署名証明書の検証中にサブ CA の 2 ステップインストールが失敗しなくなりました。

以前は、FIPS が有効な HSM 環境で SubCA をインストールすると、RSA または ECC のいずれかのオプションを使用し、SubCA 署名証明書を検証しようとするとエラーが返されていました。今回の修正により、pki cli コマンドが nss-import-cert から client-import-cert および --cert '--ca-cert に 変更されました。これにより、CA 署名証明書は信頼のある nssdb に適切にインポートされます。さらに、pkispawn が pki-server subsystem-cert-validate 呼び出しに失敗すると、このパッチにより、pkispawn の完了を許可する間に、障害の詳細を さらに 提供できます。これにより、管理者は CA 署名証明書を手動で追加できますが、前述の修正により問題が発生するのを防ぐことができます。

3.3. CS 10.3 の既知の問題

本パートでは、ユーザーが Red Hat Certificate System 10.3 で認識する必要がある既知の問題と、該当する場合は回避策を説明します。

TPS では、匿名バインド ACI アクセスの追加が必要

以前のバージョンでは、匿名バインド ACI はデフォルトで許可されていましたが、LDAP では無効になっています。これにより、TPS スマートカードの登録またはフォーマットができなくなります。

修正までこの問題を回避するには、Directory Server に匿名バインド ACI を手動で追加する必要があります。

$ ldapmodify -D "cn=Directory Manager" -W -x -p 3389 -h hostname -x <<EOF
dn: dc=example,dc=org
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
EOF

トークンは TPS Web UI で表示されない

tpsclient ツールからトークンのフォーマットおよび登録を行う場合、または Web UI でトークンを追加すると、TPS Web UI にはトークンが正常に記録されたエントリーは表示されません。

修正までこの問題を回避するには、以下のように tps-token-find コマンドを使用してトークンを一覧表示します。

# pki -d /opt/pki/certdb/ -c SECret.123 -p 25443 -n 'PKI TPS Administrator for Example.Org' tps-token-find

pki-core パッケージで既知の問題

auditSigningCertに属性がないため、HSM で KRA のクローン作成に失敗する

HSM で KRA のクローンを作成する場合は、auditSigningCert 信頼属性 u,u,Pu は、マスターとクローンの間でエイリアス DB で暗黙的に同期する必要があります。ただし、クローンのエイリアス DB でのレプリケーションに失敗するようになりました。したがって、HSM で KRA のクローン作成に失敗すると、audit SigningCert cert-topology-02-KRA KRA is invalid: Invalid certificate:(-8101)Certificate type not approved for application というエラーが出て失敗します。

この問題を回避するには、クローン KRA の alias DB に auditSigningCertu,u,Pu trust 属性を明示的に追加し、インスタンスを再起動する必要があります。以下は例になります。

  • 回避策を行う前に、以下を行います。

    # certutil -vv -V -d /var/lib/pki/clone-KRA/alias/ -h nfast -n 'token:auditSigningCert cert-topology-02-KRA KRA' -u J
      Enter Password or Pin for "token":
      certutil: certificate is invalid: Certificate type not approved for application.
  • 回避策の後には、以下の点に注意してください。

    # certutil -M -d /var/lib/pki/clone-KRA/alias/ -n 'token:auditSigningCert cert-topology-02-KRA KRA' -t u,u,Pu
    # certutil -vv -V -d /var/lib/pki/clone-KRA/alias/ -h nfast -n 'token:auditSigningCert cert-topology-02-KRA KRA' -u J
      Enter Password or Pin for "token":
      certutil: certificate is valid

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムが破損します。

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムの LDAP 設定が破損します。そのため、証明書システムが不安定になり、システムの復旧に手動の手順が必要になる可能性があります。

第4章 Red Hat Certificate System 10.2

本セクションでは、強調表示された更新や新機能、重要なバグ修正、最新の既知の問題など、Red Hat Certificate System 10.2 における主な変更点を説明します。

注記

Red Hat Certificate System を以前のマイナーバージョンにダウングレードすることはサポートされていません。

4.1. CS 10.2 の更新および新機能

本セクションでは、Red Hat Certificate System 10.2 の新機能および重要な更新を説明します。

pki-core パッケージ内の機能を更新し、新機能を加えます。

Certificate System パッケージがバージョン 10.10.5 にリベース

pki-core パッケージ、redhat-pkiredhat-pki-theme パッケージ、および pki-console パッケージがアップストリームバージョン 10.10.5 にアップグレードされ、以前のバージョンに対するバグ修正および機能拡張が数多く追加されました。

4.2. CS 10.2 のバグ修正

本パートでは、ユーザーに大きな影響を及ぼしていた Red Hat Certificate System 10.2 で修正されたバグを説明します。

pki-core パッケージのバグ修正:

PKI CA に接続された PKI ACME Responder が発行した証明書で OCSP 検証に失敗しなくなる

以前のバージョンでは、PKI CA が提供するデフォルトの ACME 証明書プロファイルには、実際の OCSP サービスを参照していないサンプル OCSP URL が含まれていました。これにより、PKI ACME Responder が PKI CA 発行者を使用するように設定されている場合、レスポンダーが発行する証明書は OCSP 検証に失敗する可能性があります。今回の更新で、ACME 証明書プロファイルのハードコーディングされた URL が削除され、カスタマイズしない場合にプロファイル設定ファイルを修正するアップグレードスクリプトが追加されました。

pki-tools ファイルが単一のフォルダーに

pki-tools パッケージの以下のファイルは、java-tools および native-tools の別々のファイルにありました。

  • /usr/share/pki/java-tools/DRMTool.cfg
  • /usr/share/pki/java-tools/KRATool.cfg
  • /usr/share/pki/native-tools/setpin.conf

一貫性を保つために、以下は 1 つのフォルダーにマージされます。

  • /usr/share/pki/tools/DRMTool.cfg
  • /usr/share/pki/tools/KRATool.cfg
  • /usr/share/pki/tools/setpin.conf

4.3. CS 10.2 の既知の問題

ここでは、ユーザーが Red Hat Certificate System 10.2 で認識する必要がある既知の問題と、該当する場合は回避策を説明します。

pcsc-litepcsc-lite-ccid、および escの既知の問題

Red Hat Certificate System 10.2 のリリース日時点で、pcsc-lite、pcsc -lite- ccid、および esc パッケージの既知の問題により、特定の SCP03 および SCP01 トークンで安全なチャンネルを完了できない場合があります。RHEL 8.4 の今後のバッチ更新では、これらのパッケージの修正バージョンが提供されます。

HSM を使用した KRA のクローン作成が失敗する

HSM を使用した KRA のクローン作成は、audit SigningCert cert-topology-02-KRA KRA というエラーで失敗します。Invalid certificate:(-8101)Certificate type not approved for application in the clone.

SubCA 署名証明書の検証中に SubCA の 2 ステップインストールに失敗する

2 段階の方法を使用した SubCA のインストールは、FIPS が有効になっている HSM 環境では失敗します。RSA オプションまたは ECC オプションのいずれかを使用すると、SubCA 署名証明書がエラーを返します。

TPS では、匿名バインド ACI アクセスの追加が必要

以前のバージョンでは、匿名バインド ACI はデフォルトで許可されていましたが、LDAP では無効になっています。これにより、TPS スマートカードの登録またはフォーマットができなくなります。

修正までこの問題を回避するには、Directory Server に匿名バインド ACI を手動で追加する必要があります。

$ ldapmodify -D "cn=Directory Manager" -W -x -p 3389 -h hostname -x <<EOF
dn: dc=example,dc=org
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
EOF

pki-core パッケージで既知の問題

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムが破損します。

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムの LDAP 設定が破損します。そのため、証明書システムが不安定になり、システムの復旧に手動の手順が必要になる可能性があります。

第5章 Red Hat Certificate System 10.1

本セクションでは、強調表示された更新や新機能、重要なバグ修正、最新の既知の問題ユーザーなど、Red Hat Certificate System 10.1 における重要な変更を説明します。

注記

Red Hat Certificate System を以前のマイナーバージョンにダウングレードすることはサポートされていません。

5.1. CS 10.1 の更新および新機能

本セクションでは、Red Hat Certificate System 10.1 の新機能および重要な更新を説明します。

Certificate System パッケージがバージョン 10.9.0 にリベース

pki-core パッケージ、redhat-pkiredhat-pki-theme パッケージ、および pki-console パッケージがアップストリームバージョン 10.9.0 にアップグレードされ、以前のバージョンに対するバグ修正および機能拡張が数多く追加されました。

RHCS での ACME サポート

Automated Certificate Management Environment(ACME)レスポンダーを介したサーバー証明書の発行は、Red Hat Certificate System(RHCS)で利用できます。ACME レスポンダーは ACME v2 プロトコル (RFC 8555) をサポートします。

以前は、ユーザーは認証局 (CA) の独自の証明書署名要求 (CSR) 送信ルーチンを使用する必要がありました。ルーチンでは、要求を手動で確認して証明書を発行するために、認証局 (CA) エージェントが必要になる場合がありました。

RHCS ACME レスポンダーは、CA エージェントを使用せずに、サーバー証明書の自動発行とライフサイクル管理のための標準メカニズムを提供するようになりました。この機能により、RHCS CA を既存の証明書発行インフラストラクチャーと統合して、デプロイメント用のパブリック CA と開発用の内部 CA をターゲットにすることができます。

将来の RHEL アップデートにより、ACME のインストールが中断される可能性があることに注意してください。

詳細は、「 IETF definition of ACME 」を参照してください。

JSS が FIPS 準拠の SSLContext を提供

以前では、Tomcat は Java Cryptography Architecture (JCA) SSLContext クラスの SSLEngine ディレクティブを使用していました。デフォルトの SunJSSE 実装は連邦情報処理標準 (FIPS) に準拠していないため、PKI は JSS 経由で FIPS 準拠の実装を提供するようになりました。

サーバー側の Keygen 登録

多くの新しいバージョンのブラウザーでは、PKI キーを生成する機能と、キーアーカイブ用の CRMF のサポートが削除されています。この効率性を解決するために、Red Hat Certificate System 10.1 では、サーバー側の Keygen 登録メカニズムが導入されました。キーは KRA サーバーで生成され、PKCS#12 のクライアントに安全に転送されます。

注記

暗号化証明書にのみサーバー側 Keygen メカニズムを使用することが強く推奨されます。

主な機能

  • 証明書要求キーは KRA で生成されます (注: CA と連携するには、KRA をインストールする必要があります)。
  • プロファイルのデフォルトプラグイン serverKeygenUserKeyDefaultImpl は、キーのアーカイブを有効または無効にする(つまり enableArchival)の選択を提供します。
  • RSA 鍵と EC 鍵の両方のサポート
  • 手動 (エージェント) 承認と自動承認 (ディレクトリパスワードベースなど) の両方のサポート

CA 証明書の埋め込み署名証明書タイムスタンプを使用した CA 証明書送信

Red Hat Certificate System は、証明書透過性(CT)V1 サポートの基本バージョン(rfc 6962)を提供するようになりました。各デプロイメントサイトがルート CA 証明書を含めることを選択した信頼できるログから、Signed Certificate Time スタンプ (SCT) が埋め込まれた証明書を発行する機能があります。複数の CT ログに対応するようにシステムを設定することもできます。この機能を使用するには、少なくとも 1 つの信頼できる CT ログが必要です。

重要

デプロイメントサイトが、信頼できる CT ログサーバーとの信頼関係を確立します。

pki-core パッケージ内の機能を更新し、新機能を加えます。

公開鍵インフラストラクチャーの全体的な正常性を確認できるようになる

pki-healthcheck ツールは、公開鍵インフラストラクチャー(PKI)環境の健全性に影響を与える可能性があるエラー状態を見つけて報告するのに役立ついくつかのチェックを提供します。

PKI が、RSA PSS (Probabilistic Signature Scheme) 署名アルゴリズムに対応するようになる

今回の機能強化により、PKI は RSA PSS (Probabilistic Signature Scheme) 署名アルゴリズムに対応するようになりました。この機能を有効にするには、特定のサブシステムの pkispawn スクリプトファイルに、以下の行を pki_use_pss_rsa_signing_algorithm=Trueに設定します。

5.2. CS 10.1 のバグ修正

本パートでは、ユーザーに大きな影響を及ぼしていた Red Hat Certificate System 10.1 のバグで修正されたものを説明します。

pki-core パッケージのバグ修正:

TPS インストールで auditors グループが利用できるようになりました。

以前のバージョンでは、LDAP は TPS 固有の Auditor のグループエントリーを表示していました。新規インストールで、デフォルトの TPS Auditors グループが提供されるようになりました。既存のインスタンスには、このグループを使用するには、手動の LDAP 手順が必要です。

  1. これを修正するには、ldapmodify ユーティリティーを実行して問題の LDAP サーバーに接続し、不足しているオブジェクトを追加します。

    $ ldapmodify -x -D "cn=Directory Manager" -w $PASSWORD << EOF
    dn: cn=Auditors,ou=Groups,{rootSuffix}
    changeType: add
    objectClass: top
    objectClass: groupOfUniqueNames
    cn: Auditors
    description: People who can read the signed audit logs for TPS
    EOF

    {rootSuffix} を、TPS 設定ファイルのベース DN (pki_ds_base_dn) に置き換えます。たとえば、dc =tks,dc=pki,dc={DOMAIN…​},dc={TLD} です。

これにより、既存の TPS インストールでは、新しい TPS インストールと共に Auditors グループを使用できます。

5.3. CS 10.1 の既知の問題

ここでは、ユーザーが Red Hat Certificate System 10.1 で認識する必要がある既知の問題と、該当する場合は回避策を説明します。

TPS では、匿名バインド ACI アクセスの追加が必要

以前のバージョンでは、匿名バインド ACI はデフォルトで許可されていましたが、LDAP では無効になっています。これにより、TPS スマートカードの登録またはフォーマットができなくなります。

修正までこの問題を回避するには、Directory Server に匿名バインド ACI を手動で追加する必要があります。

$ ldapmodify -D "cn=Directory Manager" -W -x -p 3389 -h hostname -x <<EOF
dn: dc=example,dc=org
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
EOF

pki-core パッケージで既知の問題

PKI CA に接続する PKI ACME Responder が発行する証明書により、OCSP の検証が失敗する可能性がある

PKI CA が提供するデフォルトの ACME 証明書プロファイルには、実際の OCSP サービスを参照しないサンプル OCSP URL が含まれています。これにより、PKI ACME Responder が PKI CA 発行者を使用するように設定されていると、レスポンダーが発行する証明書に OCSP 検証が失敗することがあります。

この問題を回避するには、policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0 プロパティーを /usr/share/pki/ca/profiles/ca/acmeServerCert.cfg 設定ファイルの空の値に設定する必要があります。

  1. ACME Responder 設定ファイルで policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ocsp.example.com の行を policyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=に変更します。
  2. サービスを再起動して、証明書を再生成します。

これにより、PKI CA は、実際の OCSP サービスを参照する自動生成 OCSP URL で ACME 証明書を生成します。

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムが破損します。

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムの LDAP 設定が破損します。そのため、証明書システムが不安定になり、システムの復旧に手動の手順が必要になる可能性があります。

第6章 Red Hat Certificate System 10.0

本セクションでは、強調表示された更新や新機能、重要なバグ修正、最新の既知の問題ユーザーなど、Red Hat Certificate System 10.0 における重要な変更を説明します。

6.1. CS 10.0 の更新および新機能

本セクションでは、Red Hat Certificate System 10.0 の新機能および重要な更新を説明します。

Certificate System パッケージがバージョン 10.8.3 にリベース

pki-core パッケージ、redhat-pkiredhat-pki-theme パッケージ、および pki-console パッケージがアップストリームバージョン 10.8.3 にアップグレードされ、以前のバージョンに対するバグ修正および機能拡張が数多く追加されました。

RHCS での ACME サポートがテクノロジープレビューとして利用可能に

Automated Certificate Management Environment(ACME)レスポンダーを介したサーバー証明書の発行は、Red Hat Certificate System(RHCS)で利用できます。ACME レスポンダーは ACME v2 プロトコル (RFC 8555) をサポートします。

以前は、ユーザーは認証局 (CA) の独自の証明書署名要求 (CSR) 送信ルーチンを使用する必要がありました。ルーチンでは、要求を手動で確認して証明書を発行するために、認証局 (CA) エージェントが必要になる場合がありました。

RHCS ACME レスポンダーは、CA エージェントを使用せずに、サーバー証明書の自動発行とライフサイクル管理のための標準メカニズムを提供するようになりました。この機能により、RHCS CA を既存の証明書発行インフラストラクチャーと統合して、デプロイメント用のパブリック CA と開発用の内部 CA をターゲットにすることができます。

このテクノロジープレビューには、ACME サーバーのサポートのみが含まれていることに注意してください。このリリースの一部として ACME クライアントは出荷されていません。さらに、この ACME プレビューは、発行データを保持したり、ユーザー登録を処理したりしません。

今後の Red Hat Enterprise Linux の更新により、ACME のインストールが破損する可能性があることに注意してください。

詳細は、「 IETF definition of ACME 」を参照してください。

注記

この機能はテクノロジープレビューとして提供され、今後の製品機能への早期アクセスを提供し、サブスクリプション契約ではまだ完全にはサポートされていないことに注意してください。

pki-core パッケージ内の機能を更新し、新機能を加えます。

テクノロジープレビューとして、公開鍵インフラストラクチャーの全体的な正常性を確認できるようになる

pki-healthcheck ツールは、公開鍵インフラストラクチャー(PKI)環境の健全性に影響を与える可能性があるエラー状態を見つけて報告するのに役立ついくつかのチェックを提供します。

注記

この機能はテクノロジープレビューとして提供され、今後の製品機能への早期アクセスを提供し、サブスクリプション契約ではまだ完全にはサポートされていないことに注意してください。

pki subsystem-cert-find コマンドおよび pki subsystem-cert-show コマンドが証明書のシリアル番号を表示

今回の機能拡張により、Certificate System の pki subsystem-cert-find コマンドおよび pki subsystem-cert-show コマンドは、出力内の証明書のシリアル番号を表示するようになりました。シリアル番号は重要な情報であり、他の複数のコマンドで必要になることがよくあります。その結果、証明書のシリアル番号を識別するのが容易になりました。

証明書システムで pki user コマンドおよび pki group コマンドが非推奨に

今回の更新で、証明書システムの新しい pki <subsystem>-user コマンドおよび pki <subsystem>-group コマンドが、pki user コマンドおよび pki group コマンドに代わるようになりました。置き換えられたコマンドは引き続き機能しますが、コマンドが非推奨であるというメッセージが表示され、新しいコマンドを参照します。

Certificate System がシステム証明書のオフライン更新をサポートするようになる

今回の機能強化により、管理者はオフライン更新機能を使用して、Certificate System で設定されたシステム証明書を更新できるようになりました。システム証明書の期限が切れると、証明書システムが起動できません。この機能強化により、管理者は期限切れのシステム証明書を置き換える必要がなくなりました。

Certificate System は、外部 CA 署名用の SKI 拡張機能を備えた CSR を作成できるようになる

今回の機能強化により、証明書システムは、外部認証局(CA)署名用の SKI(Subject Key Identifier)拡張を持つ証明書署名要求(CSR)の作成をサポートするようになりました。特定の CA は、特定の値で、または CA 公開鍵から派生したこの拡張を必要とします。これにより、管理者は pkispawn ユーティリティーに渡される設定ファイルの pki_req_ski パラメーターを使用して、SKI 拡張で CSR を作成できるようになりました。

6.2. CS 10.0 のバグ修正

本パートでは、ユーザーに大きな影響を及ぼしていた Red Hat Certificate System 10.0 で修正されたバグを説明します。

pki-core パッケージのバグ修正:

pkidestroy ユーティリティーが正しいインスタンスを選択するようになりました。

以前のリリースでは、半分削除されたインスタンスで pkidestroy --force コマンドを実行すると、- i instanceオプションで指定したインスタンス名に関係なく、デフォルトで pki-tomcat インスタンスが選択されていました。したがって、これにより、目的のインスタンスの代わりに pki-tomcat インスタンスが削除され、--remove-logs オプションにより、目的のインスタンスのログが削除されませんでした。pkidestroy が正しいインスタンス名を適用し、目的のインスタンスの左側のみを削除します。

Nuxwdog サービスは、HSM 環境で PKI サーバーの起動に失敗しなくなる

以前では、バグにより、keyutils パッケージが pki-core パッケージの依存関係としてインストールされませんでした。さらに、Nuxwdog ウォッチドッグサービスでは、ハードウェアセキュリティーモジュール (HSM) を使用する環境で公開鍵インフラストラクチャー (PKI) サーバーを起動できませんでした。これらの問題は修正されています。その結果、必要な keyutils パッケージが依存関係として自動的にインストールされ、Nuxwdog が、HSM を使用する環境で想定通りに PKI サーバーを起動するようになりました。

証明書システムが、サービスの起動時に SetAllPropertiesRule 操作の警告をログに記録しなくなる

以前は、Certificate System は、サービスの起動時に /var/log/messages ログファイルの SetAllPropertiesRule 操作で警告をログに記録していました。この問題は修正され、上記の警告はログに記録されなくなりました。

証明書システムが、デバッグログのローテートに対応

以前のバージョンでは、証明書システムは、ログローテーションに対応しないカスタムロギングフレームワークを使用していました。これにより、/var/log/pki/instance_name/ca/debug などのデバッグログが無限に拡張されました。今回の更新で、Certificate System は、ログローテーションに対応する java.logging.util フレームワークを使用するようになりました。これにより、/var/lib/pki/instance_name/conf/logging.properties ファイルでログローテーションを設定できます。

Certificate System KRA クライアントは、鍵要求 の 応答を 正しく解析する

Certificate System は、新しい JSON ライブラリーに切り替えられます。その結果、特定のオブジェクトのシリアライズが異なり、Python の 鍵回復機関 (KRA) クライアントが、鍵要求 の応答を解析できませんでした。クライアントは、古い JSON ライブラリーと新しい JSON ライブラリーの両方を使用した応答に対応するように修正されました。これにより、Python KRA クライアントは キー要求 応答を正しく解析します。

6.3. CS 10.0 の既知の問題

ここでは、ユーザーが Red Hat Certificate System 10.0 で認識する必要がある既知の問題と、該当する場合は回避策を説明します。

TPS では、匿名バインド ACI アクセスの追加が必要

以前のバージョンでは、匿名バインド ACI はデフォルトで許可されていましたが、LDAP では無効になっています。これにより、TPS スマートカードの登録またはフォーマットができなくなります。

修正までこの問題を回避するには、Directory Server に匿名バインド ACI を手動で追加する必要があります。

$ ldapmodify -D "cn=Directory Manager" -W -x -p 3389 -h hostname -x <<EOF
dn: dc=example,dc=org
changetype: modify
add: aci
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
EOF

pki-core パッケージで既知の問題

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムが破損します。

--agent-uid pkidbuser オプションを指定して cert-fix ユーティリティーを使用すると、証明書システムの LDAP 設定が破損します。そのため、証明書システムが不安定になり、システムの復旧に手動の手順が必要になる可能性があります。