Menu Close

IdM での証明書の管理

Red Hat Enterprise Linux 9

Red Hat Enterprise Linux 9 の Identity Management での証明書の発行、証明書ベースの認証の設定、および証明書の有効性の制御

概要

このドキュメントでは、IdM 認証局によって発行された証明書の管理、認証に証明書を使用するためのユーザーアカウントの設定、および Red Hat Enterprise Linux 9 の Identity Management での証明書のメンテナンスについて説明します。

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社の CTO、Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバックの提供

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。

  • 特定の部分についての簡単なコメントをお寄せいただく場合は、以下をご確認ください。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上隅に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • Bugzilla を介してフィードバックを送信するには、新しいチケットを作成します。

    1. Bugzilla の Web サイトに移動します。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 Identity Management の公開鍵証明書

この章では、Identity Management (IdM) で、ユーザー、ホスト、およびサービスの認証に使用する X.509 公開鍵証明書を紹介します。X.509 証明書は、認証のほかに、デジタル署名と暗号化も可能にし、プライバシー、完全性、否認不可を実現します。

証明書には、以下の情報が含まれます。

  • 証明書が認証する発行先
  • 証明書を署名した CA の発行元
  • 証明書の有効性の開始日と終了日
  • 証明書の有効な用途
  • 発行先の公開鍵

公開鍵により暗号化したメッセージは、対応した秘密鍵により複号できます。証明書および、勝目所に含まれる公開鍵は、公開できますが、ユーザー、ホスト、またはサービスは、対応の秘密鍵を秘密にしておく必要があります。

1.1. IdM の認証局

認証局は信頼の階層で機能します。内部認証局 (CA) がある IdM 環境では、CA が署名している正しい証明書を、すべての IdM ホスト、ユーザー、およびサービスが信頼します。このルート CA とは別に、IdM は、ルート CA から証明書に署名する権限を付与されたサブ CA にも対応します。多くの場合、このようなサブ CA が署名できる証明書は、VPN 証明書 など、特定の種類の証明書です。最後に、IdM は外部 CA の使用に対応します。以下 の表は、IdM の各種 CA の用途に関する詳細を紹介します。

表1.1 IdM での統合および外部 CA の用途の比較

CA の名前説明用途関連リンク

ipa CA

Dogtag アップストリームプロジェクトをベースとする統合 CA

統合 CA は、ユーザー、ホスト、およびサービスの証明書の作成、取り消し、および発行が可能です。

ipa CA を使用した新規ユーザー証明書の要求およびクライアントへのエクスポート

IdM サブ CA

ipa CA の下位となる統合 CA

IdM サブ CA は、ipa CA が証明書の署名を許可した CA です。多くの場合に、これらの証明書は、VPN 証明書など、特定の種類の証明書です。

証明書のサブセットだけに信頼するアプリケーションを制限する手順

外部 CA

外部 CA は、統合 IdM CA またはそのサブ CA 以外の CA です。

IdM ツールを使用して、これらの CA が発行する証明書をユーザー、サービス、またはホストに対して追加し、削除します。

IdM ユーザー、ホスト、およびサービスの外部署名証明書の管理

証明書の観点からは、自己署名 IdM CA と、外部署名の間に違いがありません。

CA のロールの目的は以下のとおりです。

  • デジタル証明書を発行する。
  • 証明書を署名して、証明書に名前のある発行先が公開鍵を所有することを認定する。発行先は、ユーザー、ホスト、またはサービスのいずれかです。
  • 証明書をキャンセルして、証明書失効リスト (CRL) および Online Certificate Status Protocol (OCSP) で失効ステータスを提供できる。

関連情報

1.2. 証明書および Kerberos の比較

証明書は、Kerberos チケットが実行したのと同様の機能を実行します。Kerberos は、セキュアでないネットワーク上で通信するノードが、安全な方法で互いに ID を証明できるように、チケットベースで機能するコンピューターネットワーク認証プロトコルです。以下の表では、Kerberos および X.509 の証明書を比較します。

表1.2 証明書および Kerberos の比較

特徴

Kerberos

X.509

認証

はい

はい

プライバシー

任意

はい

インテグリティー

任意

はい

関係する暗号の種類

対称

非対称

デフォルトの有効性

短い (1 日)

長い (2 年)

デフォルトでは、Identity Management の Kerberos は、通信相手の ID のみを保証します。

1.3. IdM でユーザーを認証する証明書を使用する利点と問題点

IdM でユーザーを認証する証明書を使用する利点は次のとおりです。

  • 通常、スマートカードの秘密鍵を保護する PIN は、通常のパスワードよりも簡単で覚えやすいものになります。
  • デバイスによっては、スマートカードに保存されている秘密鍵をエクスポートできません。これによりセキュリティーが強化されます。
  • スマートカードはログアウトを自動化できます。IdM は、ユーザーがリーダーからスマートカードを取り外すと、ユーザーをログアウトするように設定できます。
  • 秘密鍵を盗むには、スマートカードへの物理的なアクセスが必要で、スマートカードはハッキング攻撃に対して安全になります。
  • スマートカード認証は 2 要素認証の一例です。つまり、所有しているもの (カード) と、知っているもの (PIN) の両方が必要です。
  • スマートカードは、電子メールの暗号化など、他の目的に使用できる鍵を提供するため、パスワードよりも柔軟性があります。
  • IdM クライアントである共有マシンでスマートカードを使用しても、通常、システム管理者に対して追加で発生する問題はありません。実際、スマートカード認証は共有マシンにとって理想的な選択肢です。

IdM のユーザーを認証する証明書を使用する問題点は次のとおりです。

  • スマートカードまたは証明書を紛失したり忘れたりすることで、実質的にロックアウトされる可能性があります。
  • PIN を複数回誤入力すると、カードがロックされる可能性があります。
  • 一般に、セキュリティー担当者や承認者などによる要求と承認の間には中間ステップがあります。セキュリティー担当者または管理者が、IdM で ipa cert-request コマンドを実行する必要があります。
  • スマートカードとリーダーは、ベンダーとドライバーに固有である傾向があります。多くのリーダーはさまざまなカードに使用できますが、一部のベンダーのスマートカードは、別のベンダーのリーダーや、その目的で設計されていないリーダーでは機能しない場合があります。
  • 証明書とスマートカードの場合は、管理者が短期間で習得しなければならない内容が多くなります。

第2章 統合 IdM CA を使用したユーザー、ホスト、およびサービスの証明書の管理

本章では、統合 CA、ipa CA、およびそのサブ CA を使用して、Identity Management (IdM) で証明書を管理する方法を説明します。

本章は以下のセクションで構成されます。

certmonger ユーティリティーを使用して、IdM CA からサービスの新しい証明書を要求することもできます。詳細については、certmonger を使用した IdM CA からのサービスの新しい証明書の要求 を参照してください。

前提条件

2.1. IdM Web UI でのユーザー、ホスト、またはサービスの新規証明書の要求

本セクションでは、Identity Management (IdM) の Web UI を使用して、統合 IdM 認証局 (CA) から IdM エンティティー (ipa CA またはそのサブ CA) の新しい証明書を要求する方法を説明します。

IdM エンティティーには、以下が含まれます。

  • ユーザー
  • ホスト
  • サービス
重要

サービスは通常、秘密鍵の保存先となる専用のサービスノードで実行されます。サービスの秘密鍵を IdM サーバーにコピーすることは、安全ではないとみなされます。したがって、サービスの証明書を要求する場合には、サービスノードで証明書署名要求 (CSR) を作成します。

前提条件

  • IdM デプロイメントに統合 CA が含まれている。
  • IdM 管理者として IdM Web UI にログインしている。

手順

  1. Identity タブで、 UsersHosts、または Services のサブタブを選択します。
  2. ユーザー、ホスト、またはサービス名をクリックして、設定ページを開きます。

    図2.1 ホストの一覧

    「ホスト」ページのスクリーンショット。ホストと属性 ("Host name" - "Description" - "Enrolled") の表が表示されています。 最初のエントリーのホスト名が強調表示されています。
  3. ActionsNew Certificate をクリックします。
  4. 必要に応じて、発行元の CA およびプロファイル ID を選択します。
  5. 画面の certutil コマンドライン (CLI) ユーティリティーの使用手順に従います。
  6. Issue をクリックします。

2.2. certutil を使用した IdM CA からのユーザー、ホスト、またはサービスの新規証明書の要求

標準の IdM 状況で Identity Management (IdM) ユーザー、ホスト、またはサービスの証明書を要求するには、certutil ユーティリティーを使用できます。ホストまたはサービスの Kerberos エイリアスが証明書を使用できるようにするには、代わりに openssl ユーティリティーを使用して証明書を要求 します。

本セクションでは、certutil を使用して、ipa (IdM 認証局 (CA)) から IdM ユーザー、ホスト、またはサービスの証明書を要求する方法を説明します。

重要

サービスは通常、秘密鍵の保存先となる専用のサービスノードで実行されます。サービスの秘密鍵を IdM サーバーにコピーすることは、安全ではないとみなされます。したがって、サービスの証明書を要求する場合には、サービスノードで証明書署名要求 (CSR) を作成します。

前提条件

  • IdM デプロイメントに統合 CA が含まれている。
  • IdM 管理者として IdM コマンドラインインターフェース (CLI) にログインしている。

手順

  1. 証明書データベースの一時ディレクトリーを作成します。

    # mkdir ~/certdb/
  2. 以下のように、新しい一時証明書データベースを作成します。

    # certutil -N -d ~/certdb/
  3. CSR を作成し、出力をファイルにリダイレクトします。たとえば、4096 ビット証明書の CSR を作成し、発行先を CN=server.example.com,O=EXAMPLE.COM に設定するには、以下を実行します。

    # certutil -R -d ~/certdb/ -a -g 4096 -s "CN=server.example.com,O=EXAMPLE.COM" -8 server.example.com > certificate_request.csr
  4. IdM サーバーで実行している CA に証明書要求ファイルを送信します。新しく発行した証明書に関連付ける Kerberos プリンシパルを指定します。

    # ipa cert-request certificate_request.csr --principal=host/server.example.com

    IdM の ipa cert-request コマンドは、次のデフォルトを使用します。

    • caIPAserviceCert 証明書プロファイル

      カスタムプロファイルを選択するには、--profile-id オプションを使用します。

    • 統合 IdM のルート CA (ipa)

      サブ CA を選択するには、--ca オプションを使用します。

関連情報

2.3. openssl を使用した IdM CA からのユーザー、ホスト、またはサービスの新規証明書の要求

ホストまたはサービスの Kerberos エイリアスが証明書を使用できるようにするには、openssl ユーティリティーを使用して、Identity Management (IdM) ホストまたはサービスの証明書を要求してください。標準の状況では、代わりに certutil ユーティリティーを使用して新しい証明書を要求することを 検討してください。

本セクションでは、openssl を使用して、ipa (IdM 認証局) から IdM ホストまたはサービスの証明書を要求する方法を説明します。

重要

サービスは通常、秘密鍵の保存先となる専用のサービスノードで実行されます。サービスの秘密鍵を IdM サーバーにコピーすることは、安全ではないとみなされます。したがって、サービスの証明書を要求する場合には、サービスノードで証明書署名要求 (CSR) を作成します。

前提条件

  • IdM デプロイメントに統合 CA が含まれている。
  • IdM 管理者として IdM コマンドラインインターフェース (CLI) にログインしている。

手順

  1. Kerberos プリンシパル test/server.example.com のエイリアスを 1 つ以上作成します。例: test1/server.example.com および test2/server.example.com
  2. CSR で dnsName (server.example.com) と otherName (test2/server.example.com) の subjectAltName を追加します。これには、UPN otherName および subjectAltName を指定する以下の行を追加するように、openssl.conf ファイルを 設定します。

    otherName=1.3.6.1.4.1.311.20.2.3;UTF8:test2/server.example.com@EXAMPLE.COM
    DNS.1 = server.example.com
  3. openssl を使用して証明書要求を作成します。

    openssl req -new -newkey rsa:2048 -keyout test2service.key -sha256 -nodes -out certificate_request.csr -config openssl.conf
  4. IdM サーバーで実行している CA に証明書要求ファイルを送信します。新しく発行した証明書に関連付ける Kerberos プリンシパルを指定します。

    # ipa cert-request certificate_request.csr --principal=host/server.example.com

    IdM の ipa cert-request コマンドは、次のデフォルトを使用します。

    • caIPAserviceCert 証明書プロファイル

      カスタムプロファイルを選択するには、--profile-id オプションを使用します。

    • 統合 IdM のルート CA (ipa)

      サブ CA を選択するには、--ca オプションを使用します。

関連情報

2.4. 関連情報

第3章 IdM ユーザー、ホスト、およびサービスの外部署名証明書の管理

この章では、Identity Management (IdM) コマンドラインインターフェイス (CLI) および IdM Web UI を使用して、外部認証局 (CA) によって発行されたユーザー、ホスト、またはサービスの証明書を追加または削除する方法について説明します。

3.1. IdM CLI を使用して、外部 CA によって発行された証明書を IdM ユーザー、ホスト、またはサービスに追加する

Identity Management (IdM) 管理者は、Identity Management (IdM)CLI を使用して、外部で署名された証明書を IdM ユーザー、ホスト、またはサービスのアカウントに追加できます。

前提条件

  • 管理者ユーザーのチケット付与チケットを取得しました。

手順

  • IdM ユーザーに証明書を追加するには、次のように入力します。

    $ ipa user-add-cert user --certificate=MIQTPrajQAwg...

    このコマンドでは、次の情報を指定する必要があります。

    • ユーザーの名前
    • Base64 でエンコードされた DER 証明書
注記

証明書の内容をコピーしてコマンドラインに貼り付ける代わりに、証明書を DER 形式に変換してから、Base64 に再エンコードすることができます。たとえば、user_cert.pem 証明書を user に追加するには、次のように入力します。

$ ipa user-add-cert user --certificate="$(openssl x509 -outform der -in user_cert.pem | base64 -w 0)"

オプションを追加せずに実行することにより、ipauser-add-cert コマンドをインタラクティブに実行できます。

IdM ホストに証明書を追加するには、次のように入力します。

  • ipa host-add-cert

IdM サービスに証明書を追加するには、次のように入力します。

  • ipa service-add-cert

3.2. IdM Web UI を使用して、外部 CA によって発行された証明書を IdM ユーザー、ホスト、またはサービスに追加する

Identity Management (IdM) 管理者は、Identity Management (IdM)Web UI を使用して、外部で署名された証明書を IdM ユーザー、ホスト、またはサービスのアカウントに追加できます。

前提条件

  • 管理ユーザーとして IdentityManagement (IdM)WebUI にログインしています。

手順

  1. ID タブを開き、ユーザーホスト、または サービス サブタブを選択します。
  2. ユーザー、ホスト、またはサービス名をクリックして、設定ページを開きます。
  3. 証明書 エントリーの横にある 追加 をクリックします。

    図3.1 ユーザーアカウントへの証明書の追加

    ユーザーが証明書を追加
  4. Base64 または PEM でエンコードされた形式で証明書をテキストフィールドに貼り付け、Add をクリックします。
  5. Save をクリックして変更を保存します。

3.3. IdM CLI を使用して、外部 CA によって発行された証明書を IdM ユーザー、ホスト、またはサービスアカウントから削除する

Identity Management (IdM) 管理者は、Identity Management (IdM)CLI を使用して、IdM ユーザー、ホスト、またはサービスのアカウントから外部署名された証明書を削除できます。

前提条件

  • 管理者ユーザーのチケット付与チケットを取得しました。

手順

  • IdM ユーザーから証明書を削除するには、次のように入力します。

    $ ipa user-remove-cert user --certificate=MIQTPrajQAwg...

    このコマンドでは、次の情報を指定する必要があります。

    • ユーザーの名前
    • Base64 でエンコードされた DER 証明書
注記

証明書の内容をコピーしてコマンドラインに貼り付ける代わりに、証明書を DER 形式に変換してから、Base64 に再エンコードすることができます。たとえば、user_cert.pem 証明書を ユーザー から削除するには、次のように入力します。

$ ipa user-remove-cert user --certificate="$(openssl x509 -outform der -in user_cert.pem | base64 -w 0)"

オプションを追加せずに実行することにより、ipauser-remove-cert コマンドをインタラクティブに実行できます。

IdM ホストから証明書を削除するには、次のように入力します。

  • ipa host-remove-cert

IdM サービスから証明書を削除するには、次のように入力します。

  • ipa service-remove-cert

3.4. IdM Web UI を使用して、外部 CA によって発行された証明書を IdM ユーザー、ホスト、またはサービスアカウントから削除する

Identity Management (IdM) 管理者は、Identity Management (IdM)Web UI を使用して、IdM ユーザー、ホスト、またはサービスのアカウントから外部署名された証明書を削除できます。

前提条件

  • 管理ユーザーとして IdentityManagement (IdM)WebUI にログインしています。

手順

  1. ID タブを開き、ユーザーホスト、または サービス サブタブを選択します。
  2. ユーザー、ホスト、またはサービス名をクリックして、設定ページを開きます。
  3. 削除する証明書の横にある Actions をクリックし、Delete を選択します。
  4. Save をクリックして変更を保存します。

3.5. 関連情報

第4章 IdM と機能する証明書形式への変換

このユーザーストーリーでは、IdM システム管理者が、特定の IdM コマンドで証明書の正しい形式を使用するようにする方法を説明します。これは、たとえば以下の状況で役に立ちます。

4.1. IdM での証明書の形式およびエンコード

IdM におけるスマートカード認証を含む証明書認証は、ユーザーが提示する証明書と、ユーザーの IdM プロファイルに保存されている証明書または証明書データを比較することによって進められます。

システムの設定

IdM プロファイルに格納されるものは証明書のみで、対応する秘密鍵ではありません。また、認証中に、ユーザーが、対応する秘密鍵の所有していることを表示する必要があります。ユーザーは、証明書と秘密鍵の両方が含まれる PKCS #12 ファイル、またはこれら 2 つのファイル (証明書が含まれるファイルと、秘密鍵が含まれているファイル) のいずれかを提示して行います。

したがって、ユーザープロファイルに証明書を読み込むなどのプロセスでは、秘密鍵を含まない証明書ファイルのみが使用できます。

同様に、システム管理者が外部の CA 証明書を提供している場合は、パブリックデータ (秘密鍵がない証明書) のみを提供します。スマートカード認証用の IdM サーバーまたは IdM クライアントを設定する ipa-advise ユーティリティーでは、外部 CA の証明書が含まれる入力ファイルが必要ですが、秘密鍵は必要ありません。

証明書のエンコーディング

2 つの一般的な証明書エンコーディング PEM (Privacy-enhanced Electronic Mail) および DER (Distinguished Encoding Rules) があります。base64 形式は PEM 形式とほぼ同じですが、ヘッダーおよびフッター (-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) は含まれません。

DER を使用してエンコードされた証明書は、バイナリーファイルの X509 デジタル証明書です。証明書はバイナリーファイルで、人間は判読できません。DER ファイルは、ファイル名の拡張子 .der を使用することもありますが、ファイル名の拡張子 .crt および .cerDER 証明書が含まれることもあります。鍵を含む DER ファイルの名前は .key です。

PEM Base64 を使用してエンコードされた証明書は、人間が判読できるファイルです。このファイルには、「-----BEGIN …」の行頭に付けられた ASCII (Base64) のデータが含まれます。PEM ファイルは、.pem ファイル拡張子を使用することもありますが、ファイル名の拡張子 .crt および .cerPEM 証明書が含まれる場合もあります。鍵を含む PEM ファイルの名前は .key です。

ipa コマンドには、許可される証明書の種類に、さまざまな制限があります。たとえば、ipa user-add-cert コマンドでは、base64 形式でエンコードされた証明書のみが使用できますが、ipa-server-certinstall は、PEM、DER、PKCS #7、PKCS #8 および PKCS #12 の証明書が使用できます。

表4.1 証明書のエンコーディング

エンコーディング形式人間が判別可能一般的なファイル名の拡張子エンコーディング形式を使用できる IdM コマンドの例

PEM/base64

はい

.pem、.crt、.cer

ipa user-add-cert、ipa-server-certinstall など

DER

いいえ

.der、.crt、.cer

ipa-server-certinstall など

IdM の証明書関連のコマンドおよび形式 は、コマンドが受け入れる証明書形式を含むその他の ipa コマンドを一覧表示します。

ユーザー認証

ブラウザーのデータベースに秘密鍵と証明書の両方を保存することで、Web UI を使用して IdM にアクセスすると、証明書に対応する秘密鍵をユーザーが所有していることを証明します。

CLI を使用して IdM にアクセスすると、以下のいずれかの方法で、証明書に対応する秘密鍵をユーザーが所有していることを証明します。

  • ユーザーは、kinit -X コマンドの X509_user_identity パラメーターの値として、証明書と鍵の両方が含まれるスマートカードに接続するスマートカードモジュールへのパスを追加します。

    $ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' idm_user
  • ユーザーは、kinit -X コマンドの X509_user_identity パラメーターの値として、証明書が含まれるファイルと、秘密鍵が含まれるファイルの 2 つを追加します。

    $ kinit -X X509_user_identity='FILE:`/path/to/cert.pem,/path/to/cert.key`' idm_user

便利な証明書コマンド

証明書データ (発行先や発行者など) を表示するには、次のコマンドを実行します。

$ openssl x509 -noout -text -in ca.pem

2 つの証明書で、異なる行を比較するには、次のコマンドを実行します。

$ diff cert1.crt cert2.crt

2 つの証明書の出力を 2 列で表示して、2 つの証明書で異なる行を比較するには、次のコマンドを実行します。

$ diff cert1.crt cert2.crt -y

4.2. IdM ユーザーアカウントに読み込む外部証明書の変換

このセクションでは、外部証明書がユーザーエントリーに追加される前に、適切にエンコードされおよび形式が正しいことを確認する方法を説明します。

4.2.1. 前提条件

  • 証明書が Active Directory 認証局によって発行され、PEM エンコーディングを使用する場合は、PEM ファイルが UNIX 形式に変換されていることを確認します。ファイルを変換するには、dos2unix パッケージが提供する dos2unix ユーティリティーを使用します。

4.2.2. IdM CLI での外部証明書の変換および IdM ユーザーアカウントへの読み込み

IdM CLI では、最初の行および最後の行 (-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) が削除された PEM 証明書のみが使用できます。

以下の手順に従って、外部証明書を PEM 形式に変換し、IdM CLI を使用して IdM ユーザーアカウントに追加します。

手順

  1. 証明書を PEM 形式に変換します。

    • 証明書が DER 形式の場合は、次のようになります。

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • ファイルが PKCS #12 形式で、共通のファイル名の拡張子が .pfx および .p12 で、証明書、秘密鍵、およびその他のデータが含まれている場合は、openssl pkcs12 ユーティリティーを使用して証明書を展開します。プロンプトが表示されたら、そのファイルに保存されている秘密鍵をパスワードで保護します。

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. 管理者の認証情報を取得します。

    $ kinit admin
  3. 以下のいずれかの方法で、IdM CLI を使用して証明書をユーザーアカウントに追加します。

    • 文字列を ipa user-add-cert コマンドに追加する前に、sed ユーティリティーを使用して PEM ファイルの最初の行および最後の行 (-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) を削除します。

      $ ipa user-add-cert some_user --certificate="$(sed -e '/BEGIN CERTIFICATE/d;/END CERTIFICATE/d' cert.pem)"
    • 最初の行と最後の行(-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) がない証明書ファイルのコンテンツを、ipa user-add-cert コマンドにコピーして貼り付けます。

      $ ipa user-add-cert some_user --certificate=MIIDlzCCAn+gAwIBAgIBATANBgkqhki...
      注記

      最初の行および最後の行 (-----BEGIN CERTIFICATE----- および -----END CERTIFICATE-----) を削除せずに、直接証明書を含む PEM ファイルを、ipa user-add-cert コマンドへの入力として直接渡すことはできません。

      $ ipa user-add-cert some_user --cert=some_user_cert.pem

      このコマンドの結果、「ipa: ERROR: Base64 decoding failed: Incorrect padding」エラーメッセージが表示されます。

  4. 必要に応じて、システムで証明書が許可されているかどうかを確認するには、次のコマンドを実行します。

    [idm_user@r8server]$ ipa user-show some_user

4.2.3. IdM ユーザーアカウントに読み込むための IdM Web UI での外部証明書の変換

以下の手順に従って、外部証明書を PEM 形式に変換し、これを IdM Web UI の IdM ユーザーアカウントに追加します。

手順

  1. CLI を使用して、証明書を PEM 形式に変換します。

    • 証明書が DER 形式の場合は、次のようになります。

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • ファイルが PKCS #12 形式で、共通のファイル名の拡張子が .pfx および .p12 で、証明書、秘密鍵、およびその他のデータが含まれている場合は、openssl pkcs12 ユーティリティーを使用して証明書を展開します。プロンプトが表示されたら、そのファイルに保存されている秘密鍵をパスワードで保護します。

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. エディターで証明書を開き、コンテンツをコピーします。IdM Web UI には PEM 形式および base64 形式が使用できるため、ヘッダー行「-----BEGIN CERTIFICATE-----」およびフッター行「-----END CERTIFICATE-----」を含めることができます。
  3. IdM Web UI で、セキュリティー担当者としてログインします。
  4. IdentityUserssome_user の順に選択します。
  5. 証明書 の横にある 追加 をクリックします。
  6. 表示されるウインドウに、PEM 形式のコンテンツを貼り付けます。
  7. Add をクリックします。

証明書がシステムに受け入れられる場合は、ユーザープロファイルの 証明書 間で一覧に表示されるのを確認できます。

4.3. 証明書をブラウザーに読み込むための準備

ユーザー証明書をブラウザーにインポートする前に、証明書と対応する秘密鍵が PKCS #12 形式にあることを確認してください。その他の準備作業が必要な一般的な状況は、次の 2 つです。

その後、PEM 形式の CA 証明書と、PKCS #12 形式のユーザー証明書をブラウザーにインポートするには、証明書認証を有効にするためのブラウザーの設定 および Identity Management ユーザーとして証明書を使用した Identity Management Web UI の認証 の手順に従います。

4.3.1. NSS データベースから PKCS #12 ファイルへの証明書と秘密鍵のエクスポート

手順

  1. 証明書を、NSS データベースから PKCS12 形式にエクスポートするには、pk12util コマンドを使用します。たとえば、~/certdb ディレクトリーに保存されている NSS データベースから、~/some_user.p12 ファイルに、some_user ニックネームを持つ証明書をエクスポートする場合は、次のコマンドを実行します。

    $ pk12util -d ~/certdb -o ~/some_user.p12 -n some_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  2. .p12 ファイルに適切なパーミッションを設定します。

    # chmod 600 ~/some_user.p12

    PKCS #12 ファイルには秘密鍵も含まれるため、その他のユーザーがファイルを使用できないように保護する必要があります。それ以外の場合は、ユーザー権限になりすますことができます。

4.3.2. 証明書と秘密鍵の PEM ファイルを PKCS #12 ファイルに統合

このセクションでは、個別の PEM ファイルに保存されている証明書、および対応する鍵を、PKCS #12 ファイルに統合する方法を説明します。

手順

  • certfile.cer に保存されている証明書と、certfile.key に保存されている鍵を、証明書および鍵の両方が含まれる certfile.p12 ファイルに追加します。

    $ openssl pkcs12 -export -in certfile.cer -inkey certfile.key -out certfile.p12

4.4. IdM における証明書関連のコマンドおよび形式

IdM 証明書コマンドおよび形式 の表は、IdM の証明書関連のコマンドを、使用可能な形式で表示しています。

表4.2 IdM 証明書コマンドおよび形式

コマンド使用できる形式備考

ipa user-add-cert some_user --certificate

base64 PEM 証明書

 

ipa-server-certinstall

PEM および DER 証明書、PKCS#7 証明書チェーン、PKCS#8 および生の秘密鍵、PKCS#12 証明書および秘密鍵

 

ipa-cacert-manage install

DER、PEM、PKCS#7

 

ipa-cacert-manage renew --external-cert-file

PEM および DER 証明書、PKCS#7 証明書チェーン

 

ipa-ca-install --external-cert-file

PEM および DER 証明書、PKCS#7 証明書チェーン

 

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

該当なし

<cert_serial> シリアル番号がある証明書で、PEM でエンコードされた file.pem ファイルを作成します。

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

該当なし

<cert_serial> シリアル番号がある証明書で、PEM でエンコードされた file.pem ファイルを作成します。--chain オプションを使用すると、PEM ファイルに、証明書チェーンを含む証明書が含まれます。

ipa cert-request --certificate-out=FILE /path/to/req.csr

該当なし

新しい証明書で、PEM 形式の req.csr ファイルを作成します。

ipa cert-request --certificate-out=FILE /path/to/req.csr

該当なし

新しい証明書で、PEM 形式の req.csr ファイルを作成します。--chain オプションを使用すると、PEM ファイルに、証明書チェーンを含む証明書が含まれます。

第5章 Identity Management での証明書プロファイルの作成および管理

証明書プロファイルは、証明書署名要求 (CSR) が受け入れ可能であるかどうかを判断するために、証明書の署名時に認証局 (CA) により使用されます。そのため、証明書プロファイルは、証明書に存在する機能と拡張機能があるかどうかを判断します。証明書プロファイルは、特定のタイプの証明書を発行するのに関連付けられています。証明書プロファイルと CA アクセス制御リスト (ACL) を組み合わせることで、カスタム証明書プロファイルへのアクセスを定義し、制御できます。

証明書プロファイルの作成方法の説明では、例として S/MIME 証明書を使用します。一部の電子メールプログラムは、Secure Multipurpose Internet Mail Extension (S/MIME) プロトコルを使用して、デジタル署名および暗号化された電子メールをサポートします。S/MIME を使用して電子メールメッセージに署名または暗号化するには、メッセージの送信者に S/MIME 証明書が必要です。

5.1. 証明書プロファイルの概要

証明書プロファイルを使用すると、証明書の内容や、以下のような証明書を発行するための制約を決定できます。

  • 証明書署名要求をエンコードするために使用する署名アルゴリズム。
  • 証明書のデフォルトの有効性。
  • 証明書を取り消しするために使用できる失効理由。
  • プリンシパルの共通名が subject alternative name フィールドにコピーされる場合。
  • 証明書に存在する必要がある機能およびエクステンション。

単一の証明書プロファイルは、特定のタイプの証明書を発行するのに関連付けられます。IdM のユーザー、サービス、およびホストに、さまざまな証明書プロファイルを定義できます。IdM には、デフォルトで次の証明書プロファイルが含まれています。

  • caIPAserviceCert
  • IECUserRoles
  • kdcs_PKINIT_Certs (内部で使用)

さらに、特定の目的で証明書を発行できるカスタムプロファイルを作成およびインポートできます。たとえば、特定のプロファイルの使用を 1 つのユーザーまたはグループに制限し、他のユーザーやグループがそのプロファイルを使用して認証用の証明書を発行しないようにすることができます。カスタム証明書プロファイルを作成するには、ipa certprofile コマンドを使用します。

関連情報

  • ipa help certprofile コマンドを参照してください。

5.2. 証明書プロファイルの作成

この手順では、S/MIME 証明書を要求するプロファイル設定ファイルを作成して、コマンドラインを使用して証明書プロファイルを作成する方法を説明します。

手順

  1. 既存のデフォルトプロファイルをコピーしてカスタムプロファイルを作成します。

    $ ipa certprofile-show --out smime.cfg caIPAserviceCert
    ------------------------------------------------
    Profile configuration stored in file 'smime.cfg'
    ------------------------------------------------
      Profile ID: caIPAserviceCert
      Profile description: Standard profile for network services
      Store issued certificates: TRUE
  2. テキストエディターで新たに作成されたプロファイル設定ファイルを開きます。

    $ vi  smime.cfg
  3. プロファイル ID をsmime など、プロファイルの使用を反映する名前に変更します。

    注記

    新規に作成されたプロファイルをインポートする場合は、profileId フィールドがあれば、コマンドラインで指定された ID と一致する必要があります。

  4. Extended Key Usage 設定を更新します。TLS サーバーおよびクライアント認証用のデフォルトの Extended Key Usage 拡張設定はです。たとえば、S/MIME の場合、電子メール保護のために Extended Key Usage を設定する必要があります。

    policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.4
  5. 新しいプロファイルをインポートします。

    $ ipa certprofile-import smime --file smime.cfg \
      --desc "S/MIME certificates" --store TRUE
    
    ------------------------
    Imported profile "smime"
    ------------------------
      Profile ID: smime
      Profile description: S/MIME certificates
      Store issued certificates: TRUE

検証手順

  • 新しい証明書プロファイルがインポートされたことを確認します。

    $ ipa certprofile-find
    
    ------------------
    4 profiles matched
    ------------------
      Profile ID: caIPAserviceCert
      Profile description: Standard profile for network services
      Store issued certificates: TRUE
    
      Profile ID: IECUserRoles
      Profile description: User profile that includes IECUserRoles extension from request
      Store issued certificates: TRUE
    
      Profile ID: KDCs_PKINIT_Certs
      Profile description: Profile for PKINIT support by KDCs
      Store issued certificates: TRUE
    
      Profile ID: smime
      Profile description: S/MIME certificates
      Store issued certificates: TRUE
    ----------------------------
    Number of entries returned 4
    ----------------------------

関連情報

5.3. CA アクセス制御リストの概要

認証局のアクセス制御リスト (CA ACL) ルールは、どのプリンシパルにプロファイルを使用して証明書を発行するかを定義します。CA ACL を使用してこれを実行できます。以下に例を示します。

  • 特定のプロファイルで証明書を発行できるユーザー、ホスト、またはサービスを決定します。
  • 証明書を発行できる IdM 認証局またはサブ CA の特定

たとえば、CA ACL を使用して、ロンドンのオフィスから作業する社員向けのプロファイルの使用を、そのオフィスに関連する ldM ユーザーグループのメンバーであるユーザーに限定することができます。

CA ACL ルールを管理する ipa caacl ユーティリティーを使用すると、特権ユーザーは、指定した CA ACL を追加、表示、変更、または削除できます。

関連情報

  • ipa help caacl を参照してください。

5.4. 証明書プロファイルへのアクセスを制御する CA ACL の定義

この手順では、caacl ユーティリティーを使用して CA アクセス制御リスト (ACL) ルールを定義し、グループ内のユーザーがカスタム証明書プロファイルにアクセスできるようにする方法を説明します。この場合は、S/MIME ユーザーのグループと CA ACL を作成し、そのグループのユーザーが smime 証明書プロファイルにアクセスできるようにする方法を説明します。

前提条件

  • IdM 管理者の認証情報を取得していることを確認している。

手順

  1. 証明書プロファイルのユーザーに新しいグループを作成します。

    $ ipa group-add smime_users_group
    ---------------------------------
    Added group "smime users group"
    ---------------------------------
      Group name: smime_users_group
      GID: 75400001
  2. smime_user_group グループに追加する新規ユーザー を作成します。

    $ ipa user-add smime_user
    First name: smime
    Last name: user
    ----------------------
    Added user "smime_user"
    ----------------------
      User login: smime_user
      First name: smime
      Last name: user
      Full name: smime user
      Display name: smime user
      Initials: TU
      Home directory: /home/smime_user
      GECOS: smime user
      Login shell: /bin/sh
      Principal name: smime_user@IDM.EXAMPLE.COM
      Principal alias: smime_user@IDM.EXAMPLE.COM
      Email address: smime_user@idm.example.com
      UID: 1505000004
      GID: 1505000004
      Password: False
      Member of groups: ipausers
      Kerberos keys available: False
  3. smime_usersmime_users_group に追加します。

    $ ipa group-add-member smime_users_group --users=smime_user
      Group name: smime_users_group
      GID: 1505000003
      Member users: smime_user
    -------------------------
    Number of members added 1
    -------------------------
  4. CA ACL を作成し、グループのユーザーが証明書プロファイルにアクセスできるようにします。

    $ ipa caacl-add smime_acl
    ------------------------
    Added CA ACL "smime_acl"
    ------------------------
      ACL name: smime_acl
      Enabled: TRUE
  5. CA ACL にユーザーグループを追加します。

    $ ipa caacl-add-user smime_acl --group smime_users_group
      ACL name: smime_acl
      Enabled: TRUE
      User Groups: smime_users_group
    -------------------------
    Number of members added 1
    -------------------------
  6. CA ACL に証明書プロファイルを追加します。

    $ ipa caacl-add-profile smime_acl --certprofile smime
      ACL name: smime_acl
      Enabled: TRUE
      Profiles: smime
      User Groups: smime_users_group
    -------------------------
    Number of members added 1
    -------------------------

検証手順

  • 作成した CA ACL の詳細を表示します。

    $ ipa caacl-show smime_acl
      ACL name: smime_acl
      Enabled: TRUE
      Profiles: smime
      User Groups: smime_users_group
    ...

関連情報

  • ipa のman ページを参照してください。
  • ipa help caacl を参照してください。

5.5. 証明書プロファイルおよび CA ACL を使用した証明書発行

認証局のアクセス制御リスト (CA ACL) が許可する場合は、証明書プロファイルを使用して証明書を要求できます。この手順では、CA ACL 経由でアクセスが付与されたカスタム証明書プロファイルを使用して、ユーザーの S/MIME 証明書を要求する方法を説明します。

前提条件

  • 証明書プロファイルが作成されている。
  • ユーザーが必要な証明書プロファイルを使用して証明書を要求することができる CA ACL が作成されました。
注記

ユーザーが cert-request コマンドを実行すると、CA ACL チェックをバイパスできます。

  • admin ユーザーです。
  • Request Certificate ignoring CA ACLs パーミッションがある。

手順

  1. ユーザーの証明書要求を生成します。例: OpenSSL の使用:

    $ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=smime_user'
  2. IdM CA からユーザーの新しい証明書を要求します。

    $ ipa cert-request cert.csr --principal=smime_user --profile-id=smime

    必要に応じて、--ca sub-CA_name オプションをコマンドに渡して、ルート CA ではなくサブ CA から証明書を要求します。

検証手順

  • 新たに発行した証明書がユーザーに割り当てられていることを確認します。

    $ ipa user-show user
      User login: user
      ...
      Certificate: MIICfzCCAWcCAQA...
      ...

関連情報

  • ipa(a) の man ページを参照してください。
  • ipa help user-show コマンドを参照してください。
  • ipa help cert-request コマンドを参照してください。
  • openssl(lssl) の man ページを参照してください。

5.6. 証明書プロファイルの変更

この手順では、ipa certprofile-mod コマンドを使用して、コマンドラインを使用して証明書プロファイルを直接変更する方法を説明します。

手順

  1. 変更する証明書プロファイルの証明書プロファイル ID を確認します。IdM に現在保存されている証明書プロファイルをすべて表示するには、次のコマンドを実行します。

    # ipa certprofile-find
    
    ------------------
    4 profiles matched
    ------------------
      Profile ID: caIPAserviceCert
      Profile description: Standard profile for network services
      Store issued certificates: TRUE
    
      Profile ID: IECUserRoles
      ...
    
      Profile ID: smime
      Profile description: S/MIME certificates
      Store issued certificates: TRUE
    --------------------------
    Number of entries returned
    --------------------------
  2. 証明書プロファイルの説明を変更します。たとえば、既存のプロファイルを使用して S/MIME 証明書のカスタム証明書プロファイルを作成した場合は、説明を新しい使用方法に合わせて変更します。

    # ipa certprofile-mod smime --desc "New certificate profile description"
    ------------------------------------
    Modified Certificate Profile "smime"
    ------------------------------------
        Profile ID: smime
        Profile description: New certificate profile description
        Store issued certificates: TRUE
  3. テキストエディターでカスタマー証明書プロファイルファイルを開き、要件に合わせてを変更します。

    # vi smime.cfg

    証明書プロファイル設定ファイルで設定できるオプションの詳細は、「証明書プロファイル設定パラメーター」を参照してください。

  4. 既存の証明書プロファイル設定ファイルを更新します。

    # ipa certprofile-mod _profile_ID_ --file=smime.cfg

検証手順

  • 証明書プロファイルが更新されたことを確認します。

    $ ipa certprofile-show smime
      Profile ID: smime
      Profile description: New certificate profile description
      Store issued certificates: TRUE

関連情報

  • ipa(a) の man ページを参照してください。
  • ipa help certprofile-mod を参照してください。

5.7. 証明書プロファイル設定パラメーター

証明書プロファイル設定パラメーターは、CA プロファイルディレクトリー /var/lib/pki/pki-tomcat/ca/profiles/caprofile_name ファイルに保存されます。プロファイルのパラメーター (デフォルト、入力、出力、および制約) はすべて、単一のポリシーセット内で設定されます。証明書プロファイルのポリシーセットにはpolicyset.policyName.policyNumber という名前があります。たとえば、ポリシーセット serverCertSet の場合、以下を実行します。

policyset.list=serverCertSet
policyset.serverCertSet.list=1,2,3,4,5,6,7,8
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=pki-ipa, O=IPA
policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl
policyset.serverCertSet.2.constraint.name=Validity Constraint
policyset.serverCertSet.2.constraint.params.range=740
policyset.serverCertSet.2.constraint.params.notBeforeCheck=false
policyset.serverCertSet.2.constraint.params.notAfterCheck=false
policyset.serverCertSet.2.default.class_id=validityDefaultImpl
policyset.serverCertSet.2.default.name=Validity Default
policyset.serverCertSet.2.default.params.range=731
policyset.serverCertSet.2.default.params.startTime=0

各ポリシーセットには、評価順で証明書プロファイルに設定されたポリシーの一覧 (ポリシー ID 番号) が含まれます。サーバーは、受信するリクエストごとに各ポリシーセットを評価します。単一の証明書要求を受信すると、1 つのセットが評価され、その他のプロファイルセットは無視されます。デュアルキーペアが発行されると、最初の証明書要求に対して最初のポリシーセットが評価され、2 番目の証明書要求に対して 2 番目のセットが評価されます。デュアルキーペアを発行するときに、単一の証明書を発行する場合や 2 つ以上のセットを発行する場合は、複数のポリシーセットは必要ありません。

表5.1 証明書プロファイル設定ファイルパラメーター

パラメーター説明

desc

end-entities ページに表示される証明書プロファイルのフリーテキストの説明。たとえば、desc= this certificate プロファイルは、エージェント認証でサーバー証明書を登録するためのものです

enable

プロファイルを有効にし、エンドエンティティーページからアクセスできるようにします。例: enable=true

auth.instance_id

証明書要求の認証に使用する認証マネージャープラグインを設定します。自動登録では、認証に成功すると、CA は証明書をすぐに発行します。認証に失敗したり、認証プラグインが指定されていない場合、要求はエージェントにより手動で承認されるようにキューに置かれます。例: auth.instance_id=AgentCertAuth

authz.acl

承認の制約を指定します。これは、グループ評価アクセス制御リスト (ACL) を設定するために事前に使用されます。たとえば、caCMCUserCert パラメーターでは、CMC リクエストの署名者が Certificate Manager Agents グループに属する必要があります。

authz.acl=group="Certificate Manager Agents

ディレクトリーベースのユーザー証明書の更新では、このオプションを使用して、元の要求元と現在認証されているユーザーが同じであることを確認できます。承認を評価する前に、エンティティーは認証 (バインドまたは基本的にシステムにログインします) を認証する必要があります。

name

証明書プロファイルの名前。たとえば、name=Agent-Authenticated Server Certificate Enrollment 等。この名前は、エンドユーザーの登録または更新ページに表示されます。

input.list

証明書プロファイルの許可される入力を名前で表示します。たとえば、input.list=i1,i2 のようになります。

input.input_id.class_id

入力 ID (input.list に一覧表示される入力の名前) で入力の java クラス名を示します。たとえば、input.i1.class_id=certReqInputImpl

output.list

証明書プロファイルの出力形式を名前で表示します。たとえば、output.list=o1 となります。

output.output_id.class_id

output.list に名前が付けられた出力形式の Java クラス名を指定します。たとえば、output.o1.class_id=certOutputImpl

policyset.list

設定した証明書プロファイルルールを一覧表示します。デュアル証明書の場合、署名キーともう 1 つのルールセットが暗号鍵に適用されます。単一の証明書は、証明書プロファイルルールのセットを 1 つだけ使用します。例: policyset.list=serverCertSet

policyset.policyset_id.list

評価順でポリシー ID 番号で証明書プロファイルに設定されたポリシーセット内のポリシーを一覧表示します。例: policyset.serverCertSet.list=1,2,3,4,5,6,7,8

policyset.policyset_id.policy_number.constraint.class_id

プロファイルルールに設定されたデフォルトに設定された制約プラグインの java クラス名を示します。例: policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl.

policyset.policyset_id.policy_number.constraint.name

制約のユーザー定義の名前を指定します。例: policyset.serverCertSet.1.constraint.name=Subject Name Constraint

policyset.policyset_id.policy_number.constraint.params.attribute

制約に許可される属性値を指定します。設定可能な属性は、制約のタイプによって異なります。例: policyset.serverCertSet.1.constraint.params.pattern=CN=.*

policyset.policyset_id.policy_number.default.class_id

プロファイルルールのデフォルトセットの java クラス名を指定します。例: policyset.serverCertSet.1.default.class_id=userSubjectNameDefaultImpl

policyset.policyset_id.policy_number.default.name

デフォルトのユーザー定義の名前を指定します。例: policyset.serverCertSet.1.default.name=Subject Name Default

policyset.policyset_id.policy_number.default.params.attribute

デフォルトに許可される属性の値を指定します。設定可能な属性は、デフォルトのタイプによって異なります。例: policyset.serverCertSet.1.default.params.name=CN=(Name)$request.requestor_name$

第6章 IdM での証明書の有効性の管理

Identity Management (IdM) では、既存の証明書と将来発行する証明書の両方の有効性を管理できますが、その方法は異なります。

6.1. IdM CA が発行した既存の証明書の効力の管理

IdM では、証明書の有効期限を表示する次の方法を使用できます。

IdM CA により発行した既存の証明書の効力を次の方法で管理できます。

6.2. IdM CA が発行する将来の証明書の効力の管理

IdM CA が発行する将来の証明書の効力を管理するには、証明書プロファイルを変更、インポート、または作成します。詳細は「Identity Management での証明書プロファイルの作成および管理」を参照してください。

6.3. IdM WebUI での証明書の有効期限の表示

IdM WebUI を使用して、IdM CA が発行したすべての証明書の有効期限を表示できます。

前提条件

  • 管理者の資格情報を取得していることを確認している。

手順

  1. Authentication メニューで、Certificates > Certificates をクリックします。
  2. 証明書のシリアル番号をクリックして、証明書情報ページを開きます。

    図6.1 証明書の一覧

    IdM Web UI の「証明書」ページのスクリーンショット。証明書の表が表示されています。証明書は、シリアル番号とその発行先別に整理されています。シリアル番号「3」(表の 3 番目の証明書) が強調表示されています。
  3. 証明書の情報ページで、失効日 情報を見つけます。

6.4. CLI での証明書の有効期限の表示

コマンドラインインターフェース (CLI) を使用して、証明書の有効期限を表示できます。

手順

  • openssl ユーティリティーを使用して、人間が読める形式でファイルを開きます。

    $ openssl x509 -noout -text -in ca.pem
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 1 (0x1)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O = IDM.EXAMPLE.COM, CN = Certificate Authority
            Validity
                Not Before: Oct 30 19:39:14 2017 GMT
                Not After : Oct 30 19:39:14 2037 GMT

6.5. 統合 IdM CA を使用した証明書の失効

6.5.1. 証明書失効の理由

失効した証明書は無効であり、認証に使用できません。理由 6 の 証明書の保留 を除き、すべての失効は永続的です。

デフォルトの失効理由は 0 (未指定) です。

表6.1 証明書の失効理由

ID理由説明

0

指定なし

 

1

鍵が侵害された

証明書を発行した鍵が信頼されなくなりました。

考えられる原因 - トークンの消失、ファイルへの不適切なアクセス。

2

CA が侵害された

証明書を発行した CA は信頼されなくなりました。

3

所属が変更した

考えられる原因:

* 人が退職したか、または別の部門に移動した。

* ホストまたはサービスが廃止された。

4

置き換え

現在の証明書から新しい証明書に置き換えられた。

5

運用停止

ホストまたはサービスが廃止されている。

6

証明書が保留になっている

証明書は一時的に取り消されている。証明書は後で復元できます。

8

CRL から削除された

証明書は、証明書失効リスト (CRL) に含まれていません。

9

特権が撤回された

ユーザー、ホスト、またはサービスは、証明書の使用を許可されなくなった。

10

侵害された属性機関 (Attribute Authority)

属性機関証明書は信頼されなくなった。

6.5.2. IdM WebUI を使用して統合 IdM CA で証明書の失効

証明書の秘密鍵を紛失した場合は、証明書を無効にして不正使用を防ぐ必要があります。IdM CA が発行した証明書を IdM WebUI を使用して取り消すには、この手順を完了します。

手順

  1. Authentication > Certificates > Certificates をクリックします。
  2. 証明書のシリアル番号をクリックして、証明書情報ページを開きます。

    図6.2 証明書の一覧

    IdM Web UI の「証明書」ページのスクリーンショット。証明書の表が表示されています。証明書は、シリアル番号とその発行先別に整理されています。シリアル番号「3」(表の 3 番目の証明書) が強調表示されています。
  3. 証明書情報ページで、ActionsRevoke Certificate をクリックします。
  4. 取り消しの理由を選択し、Revoke をクリックします。詳細は 証明書失効の理由 を参照してください。

6.5.3. IdM CLI を使用した統合 IdM CA での証明書の失効

証明書の秘密鍵を紛失した場合は、証明書を無効にして不正使用を防ぐ必要があります。IdM CLI で、IdM CA が発行した証明書を取り消すには、以下の手順を行います。

手順

  • ipa cert-revoke コマンドを使用して、次を指定します。

    • 証明書のシリアル番号
    • 失効理由の ID 番号。詳細は 証明書失効の理由 を参照してください。

たとえば、理由 1 (侵害された鍵) のためにシリアル番号 1032 の証明書を失効させるには、次のコマンドを実行します。

$ ipa cert-revoke 1032 --revocation-reason=1

新しい証明書の要求の詳細は、次のドキュメントを参照してください。

6.6. 統合 IdM CA を使用した証明書の復元

理由6 (証明書の保留) のために証明書が失効し、証明書の秘密鍵が侵害されていない場合は、証明書を再度復元できます。証明書を復元するには、次のいずれかの手順を使用します。

6.6.1. IdM WebUI を使用して統合 IdM CA で証明書の復元

IdM WebUI を使用して、理由 6 (証明書の保留) のために取り消された IdM 証明書を復元するには、この手順を完了します。

手順

  1. Authentication メニューで、Certificates > Certificates をクリックします。
  2. 証明書のシリアル番号をクリックして、証明書情報ページを開きます。

    図6.3 証明書の一覧

    IdM Web UI の「証明書」ページのスクリーンショット。証明書の表が表示されています。証明書は、シリアル番号とその発行先別に整理されています。シリアル番号「3」(表の 3 番目の証明書) が強調表示されています。
  3. 証明書情報ページで、ActionsRestore Certificate をクリックします。

6.6.2. IdM CA を使用して、統合 IdM CA で証明書の失効

IdM CLI を使用して、理由6 (証明書の保留) のために取り消された IdM 証明書を復元するには、この手順を完了します。

手順

  • ipa cert-remove-hold コマンドを使用して、証明書のシリアル番号を指定します。以下に例を示します。

    $ ipa cert-remove-hold 1032

第7章 スマートカード認証用の Identity Management の設定

スマートカードに基づいた認証は、パスワードの代替手段です。ユーザー認証情報は、秘密鍵と証明書の形式でスマートカードに格納され、特別なソフトウェアやハードウェアを使用してその鍵にアクセスします。スマートカードをリーダーまたは USB ポートに挿入して、パスワードを入力する代わりに、スマートカードの PIN コードを入力します。

Identity Management (IdM) では、以下によるスマートカード認証に対応しています。

  • IdM 認証局が発行するユーザー証明書
  • 外部認証局が発行するユーザー証明書

このユーザーストーリーでは、両方のタイプの証明書に対して、IdM でスマートカード認証を設定する方法を説明します。ユーザーストーリーでは、smartcard_ca.pem CA 証明書は、信頼された外部の認証局の証明書を含むファイルです。

ユーザーストーリーには次のようなモジュールが含まれています。

7.1. スマートカード認証用の IdM サーバーの設定

LDAP 識別名 (DN) が、CN=Certificate Authority,DC=EXAMPLE,DC=ORG である EXAMPLE.ORG ドメインの認証局により証明書が発行されたユーザーに対してスマートカード認証を有効にする場合は、IdM サーバーが設定するスクリプトで実行できるように、認証局の証明書を取得する必要があります。たとえば、認証局により発行された証明書が含まれる Web ページから、その証明書をダウンロードできます。詳細については、証明書認証を有効にするためのブラウザーの設定の 手順 1〜4a を参照してください。

IdM 認証局が証明書を発行している IdM ユーザーに対してスマートカード認証を有効にするには、IdM CA が実行している IdM サーバーの /etc/ipa/ca.crt ファイルから CA 証明書を取得します。

本セクションでは、スマートカード認証に IdM サーバーを設定する方法を説明します。まず、PEM 形式の CA 証明書でファイルを取得してから、組み込みの ipa-advise スクリプトを実行します。最後に、システム設定を再読み込みます。

前提条件

  • IdM サーバーへの root アクセス権限がある。
  • ルート CA 証明書とサブ CA 証明書がある。

手順

  1. 設定を行うディレクトリーを作成します。

    [root@server]# mkdir ~/SmartCard/
  2. そのディレクトリーに移動します。

    [root@server]# cd ~/SmartCard/
  3. PEM 形式のファイルに保存されている関連する CA 証明書を取得します。CA 証明書が DER などの異なる形式のファイルに保存されている場合は、これを PEM 形式に変換します。IdM 認証局の証明書は、/etc/ipa/ca.crt ファイルにあります。

    DER ファイルを PEM ファイルに変換します。

    # openssl x509 -in <filename>.der -inform DER -out <filename>.pem -outform PEM
  4. 便宜上、設定を行うディレクトリーに証明書をコピーします。

    [root@server SmartCard]# cp /etc/ipa/ca.crt ~/SmartCard/
    [root@server SmartCard]# cp /tmp/smartcard_ca.pem ~/SmartCard/
  5. 必要に応じて、外部の認証局の証明書を使用する場合は、openssl x509 ユーティリティーを使用して PEM 形式のファイルの内容を表示し、Issuer および Subject の値が正しいことを確認します。

    [root@server SmartCard]# openssl x509 -noout -text -in smartcard_ca.pem | more
  6. 管理者の権限を使用して、組み込みの ipa-advise ユーティリティーで設定スクリプトを生成します。

    [root@server SmartCard]# kinit admin
    [root@server SmartCard]# ipa-advise config-server-for-smart-card-auth > config-server-for-smart-card-auth.sh

    config-server-for-smart-card-auth.sh スクリプトは、以下の操作を実行します。

    • IdM Apache HTTP サーバーを設定します。
    • キー配布センター (KDC) の Kerberos (PKINIT) で、初回認証用の公開鍵暗号化機能を有効にします。
    • スマートカード認可要求を受け入れるように IdM Web UI を設定します。
  7. スクリプトを実行し、root CA と サブ CA 証明書が含まれる PEM ファイルを引数として追加します。

    [root@server SmartCard]# chmod +x config-server-for-smart-card-auth.sh
    [root@server SmartCard]# ./config-server-for-smart-card-auth.sh smartcard_ca.pem ca.crt
    Ticket cache:KEYRING:persistent:0:0
    Default principal: admin@IDM.EXAMPLE.COM
    [...]
    Systemwide CA database updated.
    The ipa-certupdate command was successful
    注記

    ルート CA 証明書を、サブ CA 証明書の前に引数として追加します。また、CA またはサブ CA 証明書の有効期限が切れていないことを確認します。

  8. 必要に応じて、ユーザー証明書を発行した認証局が Online Certificate Status Protocol (OCSP) レスポンダーを提供しない場合は、IdM Web UI への認証に対する OCSP チェックを無効にすることが必要になる場合があります。

    1. /etc/httpd/conf.d/ssl.conf ファイルで SSLOCSPEnable パラメーターを off に設定します。

      SSLOCSPEnable off
    2. 変更をすぐに有効にするには、Apache デーモン (httpd) を再起動します。

      [root@server SmartCard]# systemctl restart httpd
    警告

    IdM CA が発行したユーザー証明書のみを使用する場合は、OCSP チェックを無効にしないでください。OCSP レスポンダーは IdM に含まれます。

    ユーザー証明書を発行した CA が、OCSP サービスリクエストをリッスンする場所に関する情報がユーザー証明書に含まれていない場合に、OCSP チェックを有効にしたまま、ユーザー証明書が IdM サーバーにより拒否されないようにする方法は、Apache mod_ssl 設定オプションSSLOCSPDefaultResponder ディレクティブを参照してください。

これで、スマートカード認証にサーバーが設定されました。

注記

トポロジー全体でスマートカード認証を有効にするには、各 IdM サーバーで手順を実行します。

7.2. スマートカード認証用の IdM クライアントの設定

本セクションでは、スマートカード認証に IdM クライアントを設定する方法を説明します。この手順は、認証にスマートカードを使用しているときに接続する各 IdM システム、クライアント、またはサーバーで実行する必要があります。たとえば、ホスト A からホスト B への ssh 接続を有効にするには、スクリプトをホスト B で実行する必要があります。

管理者として、以下を使用して、この手順でスマートカード認証を有効にします。

この手順は、IdM Web UI に対する認証には必要ありません。IdM Web UI の認証には 2 つのホストが関係しますが、どちらも IdM クライアントである必要はありません。

  • マシン - 場合によっては IdM ドメイン外にあります (ブラウザーが実行されている場合)
  • httpd が実行している IdM サーバー

以下の手順は、IdM サーバーではなく、IdM クライアントでスマートカード認証を設定していることを前提としています。このため、2 台のコンピューターが必要です。設定スクリプトを生成する IdM サーバーと、スクリプトを実行する IdM クライアントが必要になります。

前提条件

  • スマートカード認証 用の IdM サーバーの設定で説明されているように、IdM サーバーがスマートカード認証用 に設定されています。
  • IdM サーバーと IdM クライアントに root アクセス権限がある。
  • root CA証明書とサブ CA 証明書にアクセスできる。
  • --mkhomedir オプションを使用して IdM クライアントをインストールし、リモートユーザーが正常にログインできるようにしている。ホームディレクトリーを作成しない場合、デフォルトのログイン場所はルートになります。

手順

  1. IdM サーバーで、管理者権限を使用して、ipa-advise で設定スクリプトを生成します。

    [root@server SmartCard]# kinit admin
    [root@server SmartCard]# ipa-advise config-client-for-smart-card-auth > config-client-for-smart-card-auth.sh

    config-client-for-smart-card-auth.sh スクリプトは、以下の操作を実行します。

    • スマートカードデーモンを設定する。
    • システム全体のトラストストアを設定する。
    • System Security Services Daemon (SSSD) を設定して、スマートカードのログインをデスクトップに許可する。
  2. IdM サーバーから、IdM クライアントマシンの任意のディレクトリーに、スクリプトをコピーします。

    [root@server SmartCard]# scp config-client-for-smart-card-auth.sh root@client.idm.example.com:/root/SmartCard/
    Password:
    config-client-for-smart-card-auth.sh        100%   2419       3.5MB/s   00:00
  3. 便宜上、IdM サーバーから、上の手順で使用した IdM クライアントマシンのディレクトリーに、PEM 形式の CA 証明書ファイルをコピーします。

    [root@server SmartCard]# scp {smartcard_ca.pem,ca.crt} root@client.idm.example.com:/root/SmartCard/
    Password:
    smartcard_ca.pem                    100%   1237     9.6KB/s   00:00
    ca.crt                              100%   2514    19.6KB/s   00:00
  4. クライアントマシンで、スクリプトを実行し、CA 証明書を含む PEM ファイルを引数として追加します。

    [root@client SmartCard]# kinit admin
    [root@client SmartCard]# chmod +x config-client-for-smart-card-auth.sh
    [root@client SmartCard]# ./config-client-for-smart-card-auth.sh smartcard_ca.pem ca.crt
    Ticket cache:KEYRING:persistent:0:0
    Default principal: admin@IDM.EXAMPLE.COM
    [...]
    Systemwide CA database updated.
    The ipa-certupdate command was successful
    注記

    ルート CA 証明書を、サブ CA 証明書の前に引数として追加します。また、CA またはサブ CA 証明書の有効期限が切れていないことを確認します。

これで、クライアントがスマートカード認証に対して設定されました。

7.3. IdM Web UI のユーザーエントリーへの証明書の追加

この手順では、IdM Web UIのユーザーエントリーに外部証明書を追加する方法を説明します。

証明書全体をアップロードする代わりに、IdM のユーザーエントリーに証明書マッピングデータをアップロードすることもできます。システム管理者向けのスマートカード認証の設定を容易にするために、完全な証明書または証明書マッピングデータのいずれかが含まれるユーザーエントリーを、対応する証明書マッピングルールと併用できます。詳細については、スマートカードで認証を設定するための証明書マッピングルールを 参照してください。

注記

ユーザーの証明書が IdM 認証局により発行された場合、証明書はユーザーエントリーにすでに保存されているため、本セクションを省略できます。

前提条件

  • ユーザーエントリーに追加できる証明書がある。

手順

  1. 別のユーザーに証明書を追加する場合は、管理者として IdM Web UI にログインします。独自のプロファイルに証明書を追加する場合は、管理者の認証情報が必要ありません。
  2. UsersActive userssc_user の順に移動します。
  3. Certificate オプションを探して、Add をクリックします。
  4. コマンドラインインターフェース で、cat ユーティリティーまたはテキストエディターで、PEM の証明書を表示します。

    [user@client SmartCard]$ cat testuser.crt
  5. CLI で、証明書をコピーし、Web UI で開いたウィンドウにこれを貼り付けます。
  6. Add をクリックします。

    図7.1 IdM Web UI で新しい証明書の追加

    「新規証明書」のポップアップウィンドウのスクリーンショット。そのウィンドウには、大きめのサイズの base64 PEM 形式の証明書のフィールドが表示されています。右下の「追加」ボタンが強調表示されています。

sc_user エントリーに外部証明書が含まれるようになりました。

7.4. IdM CLI でユーザーエントリーへの証明書の追加

この手順では、IdM CLIのユーザーエントリーに外部証明書を追加する方法を説明します。

証明書全体をアップロードする代わりに、IdM のユーザーエントリーに証明書マッピングデータをアップロードすることもできます。システム管理者向けのスマートカード認証の設定を容易にするために、完全な証明書または証明書マッピングデータのいずれかが含まれるユーザーエントリーを、対応する証明書マッピングルールと併用できます。詳細は、スマートカードにおける認証を設定するための証明書マッピングルール を参照してください。

注記

ユーザーの証明書が IdM 認証局により発行された場合、証明書はユーザーエントリーにすでに保存されているため、本セクションを省略できます。

前提条件

  • ユーザーエントリーに追加できる証明書がある。

手順

  1. 別のユーザーに証明書を追加する場合は、管理者として IdM Web CLI にログインします。

    [user@client SmartCard]$ kinit admin

    独自のプロファイルに証明書を追加する場合は、管理者の認証情報は必要ありません。

    [user@client SmartCard]$ kinit sc_user
  2. ヘッダーとフッターのある証明書を含む環境変数を作成し、1 行に連結します。これは、ipa user-add-cert コマンドで必要な形式です。

    [user@client SmartCard]$ export CERT=`openssl x509 -outform der -in testuser.crt | base64 -w0 -`

    testuser.crt ファイルの証明書は、PEM 形式である必要があることに注意してください。

  3. ipa user-add-cert コマンドを使用して、sc_user のプロファイルに証明書を追加します。

    [user@client SmartCard]$ ipa user-add-cert sc_user --certificate=$CERT

sc_user エントリーに外部証明書が含まれるようになりました。

7.5. スマートカードを管理および使用するツールのインストール

スマートカードを設定するには、証明書を生成し、スマートカードに保存するツールが必要になります。

以下を行う必要があります。

  • 証明書管理に役立つ gnutls-utils パッケージをインストールする。
  • スマートカードと連携するライブラリーおよびユーティリティーのセットを提供する opensc パッケージをインストールします。
  • スマートカードリーダーと通信する pcscd サービスを開始する。

手順

  1. opensc パッケージおよび gnutls-utils パッケージをインストールします。

    # dnf -y install opensc gnutls-utils
  2. pcscd サービスを開始します。

    # systemctl start pcscd

pcscd サービスが稼働していることを確認します。

7.6. スマートカードでの証明書の保存

本セクションでは、設定に役立つ pkcs15-init によるスマートカードの設定を説明します。

  • スマートカードの消去
  • 新しい PIN およびオプションの PIN ブロック解除キー (PUK) の設定
  • スマートカードでの新規スロットの作成
  • スロットへの証明書、秘密鍵、および公開鍵の保存
  • スマートカード設定のロック (一部のスマートカードではこのタイプのファイナライズが必要になります)

前提条件

  • pkcs15-init ツールを含む opensc パッケージがインストールされている。

    詳細は「スマートカードを管理および使用するツールのインストール」を参照してください。

  • カードがリーダーに挿入され、コンピューターに接続されている。
  • スマートカードに保存する秘密鍵、公開鍵、および証明書がある。この手順では、testuser.keytestuserpublic.key、および testuser.crt は、秘密鍵、公開鍵、および証明書に使用される名前です。
  • 現在のスマートカードユーザー PIN およびセキュリティーオフィス PIN (SO-PIN)

手順

  1. スマートカードを消去して PIN で自身を認証します。

    $ pkcs15-init --erase-card --use-default-transport-keys
    Using reader with a card: Reader name
    PIN [Security Officer PIN] required.
    Please enter PIN [Security Officer PIN]:

    カードが削除されました。

  2. スマートカードを初期化し、ユーザー PIN と PUK を設定します。また、セキュリティーオフィス PIN と PUK を設定します。

    $ pkcs15-init --create-pkcs15 --use-default-transport-keys \
        --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123
    Using reader with a card: Reader name

    pcks15-init ツールは、スマートカードに新しいスロットを作成します。

  3. スロットのラベルと認証 ID を設定します。

    $ pkcs15-init --store-pin --label testuser \
        --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478
    Using reader with a card: Reader name

    ラベルは人間が判読できる値に設定されます (この場合は testuser)。auth-id は 16 進数の値である必要があります。この場合、01 に設定されます。

  4. スマートカードの新しいスロットに秘密鍵を保存し、ラベルを付けます。

    $ pkcs15-init --store-private-key testuser.key --label testuser_key \
        --auth-id 01 --id 01 --pin 963214
    Using reader with a card: Reader name
    注記

    --id に指定する値は、秘密鍵と証明書を保存する際に同じである必要があります。--id の値を指定しないと、ツールによりより複雑な値が計算されるため、独自の値の定義が容易になります。

  5. スマートカードの新しいスロットに証明書を保存し、ラベル付けします。

    $ pkcs15-init --store-certificate testuser.crt --label testuser_crt \
        --auth-id 01 --id 01 --format pem --pin 963214
    Using reader with a card: Reader name
  6. (オプション) スマートカードの新しいスロットに公開鍵を保存し、ラベルを付けます。

    $ pkcs15-init --store-public-key testuserpublic.key
        --label testuserpublic_key --auth-id 01 --id 01 --pin 963214
    Using reader with a card: Reader name
    注記

    公開鍵が秘密鍵または証明書に対応している場合は、その秘密鍵または証明書と同じ ID を指定する必要があります。

  7. (オプション) スマートカードの中には、設定をロックしてカードを最終処理する必要があるものもあります。

    $ pkcs15-init -F

    この段階では、スマートカードには、新たに作成されたスロットに証明書、秘密鍵、および公開鍵が含まれます。ユーザーの PIN と PUK、およびセキュリティー担当者の PIN と PUK も作成しました。

7.7. スマートカードを使用して IdM へのログイン

本セクションでは、IdM Web UI へのログインにスマートカードを使用する方法を説明します。

前提条件

  • Web ブラウザーが、スマートカード認証を使用できるように設定されている。
  • IdM サーバーが、スマートカード認証用に設定されている。
  • IdM サーバーが、スマートカードにインストールした証明書を認識している。
  • スマートカードのロックを解除するには PIN が必要です。
  • スマートカードがリーダーにプラグインされている。

手順

  1. ブラウザーで IdM Web UI を開きます。
  2. Log In Using Certificate をクリックします。

    A screenshot of the IdM Web UI displaying an empty "Username" field and an empty "Password" field. Below those two fields the "Log in using a Certificate" option has been highlighted.

  3. Password Required ダイアログボックスが開いたら、スマートカードのロックを解除する PIN を追加して、OK ボタンをクリックします。

    User Identification Request ダイアログボックスが開きます。

    スマートカードに複数の証明書が含まれている場合は、Choose a certificate to present as identification の下にあるドロップダウンリストで、認証に使用する証明書を選択します。

  4. OK ボタンをクリックします。

これで、IdM Web UI に正常にログインできるようになりました。

A screenshot of the first screen visible after logging in to the IdM Web UI. There are 5 tabs listed along the top of the screen: Identity - Policy - Authentication - Network Services - IPA Server. The Identity tab has been selected and it is displaying the Users page which is the first menu item among 6 choices just below the tabs: Users - Hosts - Services - Groups - ID Views - Automember. The Active users page displays a table of user logins and their information: First name - Last name - Status - UID - Email address - Telephone number - Job Title.

7.8. スマートカード認証を使用した GDM アクセスの設定

Gnome Desktop Manager(GDM)には認証が必要です。パスワードは使用できますが、認証にスマートカードを使用することもできます。

本セクションでは、GDM にアクセスするスマートカード認証を説明します。

スマートカード認証を使用する利点は、ユーザーアカウントが Identity Management ドメインの 一 部である場合に、TGT (Ticket-Granting Ticket) を取得することです。

前提条件

手順

  1. スマートカードをリーダーに挿入します。
  2. スマートカード PIN を入力します。
  3. Sign In をクリックします。

RHEL システムにログインし、IdM サーバーが提供する TGT がある。

検証手順

  • 端末 ウィンドウで klist を入力し、結果を確認します。

    $ klist
    Ticket cache: KEYRING:persistent:1358900015:krb_cache_TObtNMd
    Default principal: example.user@REDHAT.COM
    
    Valid starting       Expires              Service principal
    04/20/2020 13:58:24  04/20/2020 23:58:24  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    	renew until 04/27/2020 08:58:15

7.9. スマートカード認証を使用した su アクセスの設定

別のユーザーへの変更には認証が必要です。パスワードまたは証明書を使用できます。本セクションでは、su コマンドでスマートカードを使用する方法を説明します。これは、su コマンドを入力すると、スマートカード PIN の入力が求められます。

前提条件

  • スマートカードに、証明書と秘密鍵が含まれている。
  • カードがリーダーに挿入され、コンピューターに接続されている。

手順

  • 端末で、su コマンドで別のユーザーに移動します。

    $ su - example.user
    PIN for smart_card

    設定に成功すると、スマートカードの PIN を入力するように求められます。

第8章 IdM でスマートカード認証用に ADCS が発行した証明書の設定

このシナリオでは、次の状況を説明します。

  • デプロイメントは、Identity Management (IdM) と Active Directory (AD) と間のフォレスト間の信頼に基づいている場合
  • AD にアカウントが保存されているユーザーに対してスマートカード認証を許可したい場合
  • 証明書が作成され、Active Directory Certificate Services (ADCS) に保存される場合

設定は、次の手順で行われます。

前提条件

  • Identity Management (IdM) および Active Directory (AD) 信頼がインストールされている。

    詳細については、IdM と AD 間の信頼のインストールを 参照してください。

  • Active Directory 証明書サービス (ADCS) がインストールされ、ユーザーの証明書が生成されている。

8.1. スマートカード認証

スマートカードは、カードに保存されている証明書を使用して個人認証を提供できる物理デバイスです。個人認証とは、ユーザーパスワードと同じ方法でスマートカードを使用できることを意味します。

ユーザー認証情報は、秘密鍵と証明書の形式でスマートカードに格納され、特別なソフトウェアやハードウェアを使用してその鍵にアクセスします。スマートカードをリーダーまたは USB ソケットに挿入して、パスワードを入力する代わりに、スマートカードの PIN コードを入力します。

特定の IdM クライアントでスマートカード認証を機能させる方法を設定できます。

  • ユーザーは、ユーザー名とパスワードまたはスマートカードで認証できます。
  • ユーザーは、自分のスマートカードで認証でき、パスワードは使用できません。
  • ユーザーは、スマートカードを使用して、削除時に機能ロックを設定してログアウトできます。パスワードは使用できません。

Identity Management (IdM) では、以下によるスマートカード認証に対応しています。

注記

スマートカード認証の使用を開始する場合は、ハードウェア要件: RHEL9 でのスマートカードのサポートを 参照してください。

8.2. 信頼の構成と証明書の使用に必要な Windows Server 設定

本セクションでは、Windows Server で設定する必要があるものを要約します。

  • Active Directory 証明書サービス (ADCS) がインストールされる
  • 認証局が作成される
  • 必要に応じて、認証機関の Web 登録を使用している場合は、IIS (Internet Information Services) を設定する必要がある。

証明書をエクスポートします。

  • 鍵には 2048 ビット以上が必要
  • 秘密鍵を含める
  • Personal Information Exchange (PKCS #12(.PFX)) の形式の証明書が必要

    • 証明書のプライバシーを有効にする

8.3. sftp を使用して Active Directory から証明書のコピー

スマートカード認証を使用できるようにするには、次の証明書ファイルをコピーする必要があります。

  • IdM サーバーにある CER 形式のルート CA 証明書 (adcs-winserver-ca.cer)
  • IdM クライアントの PFX 形式の秘密鍵を持つユーザー証明書 (aduser1.pfx)
注記

この手順では、SSH アクセスが許可されていることを想定しています。SSH が使用できない場合、ユーザーは AD サーバーから IdM サーバーおよびクライアントにファイルをコピーする必要があります。

手順

  1. IdM サーバー から接続し、adcs-winserver-ca.cer ルート証明書を IdM サーバーにコピーします。

    root@idmserver ~]# sftp Administrator@winserver.ad.example.com
    Administrator@winserver.ad.example.com's password:
    Connected to Administrator@winserver.ad.example.com.
    sftp> cd <Path to certificates>
    sftp> ls
    adcs-winserver-ca.cer    aduser1.pfx
    sftp>
    sftp> get adcs-winserver-ca.cer
    Fetching <Path to certificates>/adcs-winserver-ca.cer to adcs-winserver-ca.cer
    <Path to certificates>/adcs-winserver-ca.cer                 100%  1254    15KB/s 00:00
    sftp quit
  2. IdM クライアント から接続し、aduser1.pfx ユーザー証明書をクライアントにコピーします。

    [root@client1 ~]# sftp Administrator@winserver.ad.example.com
    Administrator@winserver.ad.example.com's password:
    Connected to Administrator@winserver.ad.example.com.
    sftp> cd /<Path to certificates>
    sftp> get aduser1.pfx
    Fetching <Path to certificates>/aduser1.pfx to aduser1.pfx
    <Path to certificates>/aduser1.pfx                 100%  1254    15KB/s 00:00
    sftp quit

これで、CA 証明書は IdM サーバーに保存され、ユーザー証明書はクライアントマシンに保存されます。

8.4. ADCS 証明書を使用したスマートカード認証用の IdM サーバーおよびクライアントの構成

IdM 環境でスマートカード認証を使用できるように、IdM (Identity Management) サーバーおよびクライアントを設定する必要があります。IdM には、必要なすべての変更を行う ipa-advise スクリプトが含まれています。

  • 必要なパッケージをインストールする
  • IdM サーバーとクライアントを構成して設定する
  • CA 証明書を予想される場所にコピーする

IdM サーバーで ipa-advise を実行できるようになります。

この手順では以下を説明します。

  • IdM サーバー - ipa-advise スクリプトを準備して、スマートカード認証用に IdM サーバーを設定します。
  • IdM サーバー - ipa-advise スクリプトを準備して、スマートカード認証用に IdM クライアントを設定します。
  • IdMサーバー - AD 証明書を使用して IdM サーバーに ipa-advise サーバースクリプトを適用します。
  • クライアントスクリプトを IdM クライアントマシンに移動します。
  • IdMサーバー - AD 証明書を使用して IdM クライアントに ipa-advise クライアントスクリプトを適用します。

前提条件

  • 証明書が IdM サーバーにコピーされている。
  • Kerberos チケットを取得している。
  • 管理者権限を持つユーザーとしてログインしている。

手順

  1. IdM サーバーで、クライアントを設定する ipa-advise スクリプトを使用します。

    [root@idmserver ~]# ipa-advise config-client-for-smart-card-auth > sc_client.sh
  2. IdM サーバーで、サーバーを設定する ipa-advise スクリプトを使用します。

    [root@idmserver ~]# ipa-advise config-server-for-smart-card-auth > sc_server.sh
  3. IdM サーバーで、スクリプトを実行します。

    [root@idmserver ~]# sh -x sc_server.sh adcs-winserver-ca.cer
    • IdM Apache HTTP サーバーを設定します。
    • キー配布センター (KDC) の Kerberos (PKINIT) で、初回認証用の公開鍵暗号化機能を有効にします。
    • スマートカード認可要求を受け入れるように IdM Web UI を設定します。
  4. sc_client.sh スクリプトをクライアントシステムにコピーします。

    [root@idmserver ~]# scp sc_client.sh root@client1.idm.example.com:/root
    Password:
    sc_client.sh                  100%  2857   1.6MB/s   00:00
  5. Windows 証明書をクライアントシステムにコピーします。

    [root@idmserver ~]# scp adcs-winserver-ca.cer root@client1.idm.example.com:/root
    Password:
    adcs-winserver-ca.cer                 100%  1254   952.0KB/s   00:00
  6. クライアントシステムで、クライアントスクリプトを実行します。

    [root@idmclient1 ~]# sh -x sc_client.sh adcs-winserver-ca.cer

CA 証明書が IdM サーバーとクライアントシステムに正しい形式でインストールされました。次の手順は、ユーザー証明書をスマートカード自体にコピーすることです。

8.5. PFX ファイルの変換

PFX (PKCS#12) ファイルをスマートカードに保存する前に、以下を行う必要があります。

  • ファイルを PEM 形式に変換する。
  • 秘密鍵と証明書を 2 つの異なるファイルに抽出する。

前提条件

  • PFX ファイルが IdM クライアントマシンにコピーされます。

手順

  1. IdM クライアントで、PEM 形式に変換します。

    [root@idmclient1 ~]# openssl pkcs12 -in aduser1.pfx -out aduser1_cert_only.pem -clcerts -nodes
    Enter Import Password:
  2. 鍵を別のファイルに展開します。

    [root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -nocerts -out adduser1.pem > aduser1.key
  3. パブリック証明書を別のファイルに展開します。

    [root@idmclient1 ~]# openssl pkcs12 -in adduser1.pfx -clcerts -nokeys -out aduser1_cert_only.pem > aduser1.crt

この時点で、aduser1.key および aduser1.crt をスマートカードに保存できます。

8.6. スマートカードを管理および使用するツールのインストール

スマートカードを設定するには、証明書を生成し、スマートカードに保存するツールが必要になります。

以下を行う必要があります。

  • 証明書管理に役立つ gnutls-utils パッケージをインストールする。
  • スマートカードと連携するライブラリーおよびユーティリティーのセットを提供する opensc パッケージをインストールします。
  • スマートカードリーダーと通信する pcscd サービスを開始する。

手順

  1. opensc パッケージおよび gnutls-utils パッケージをインストールします。

    # dnf -y install opensc gnutls-utils
  2. pcscd サービスを開始します。

    # systemctl start pcscd

pcscd サービスが稼働していることを確認します。

8.7. スマートカードでの証明書の保存

本セクションでは、設定に役立つ pkcs15-init によるスマートカードの設定を説明します。

  • スマートカードの消去
  • 新しい PIN およびオプションの PIN ブロック解除キー (PUK) の設定
  • スマートカードでの新規スロットの作成
  • スロットへの証明書、秘密鍵、および公開鍵の保存
  • スマートカード設定のロック (一部のスマートカードではこのタイプのファイナライズが必要になります)

前提条件

  • pkcs15-init ツールを含む opensc パッケージがインストールされている。

    詳細は「スマートカードを管理および使用するツールのインストール」を参照してください。

  • カードがリーダーに挿入され、コンピューターに接続されている。
  • スマートカードに保存する秘密鍵、公開鍵、および証明書がある。この手順では、testuser.keytestuserpublic.key、および testuser.crt は、秘密鍵、公開鍵、および証明書に使用される名前です。
  • 現在のスマートカードユーザー PIN およびセキュリティーオフィス PIN (SO-PIN)

手順

  1. スマートカードを消去して PIN で自身を認証します。

    $ pkcs15-init --erase-card --use-default-transport-keys
    Using reader with a card: Reader name
    PIN [Security Officer PIN] required.
    Please enter PIN [Security Officer PIN]:

    カードが削除されました。

  2. スマートカードを初期化し、ユーザー PIN と PUK を設定します。また、セキュリティーオフィス PIN と PUK を設定します。

    $ pkcs15-init --create-pkcs15 --use-default-transport-keys \
        --pin 963214 --puk 321478 --so-pin 65498714 --so-puk 784123
    Using reader with a card: Reader name

    pcks15-init ツールは、スマートカードに新しいスロットを作成します。

  3. スロットのラベルと認証 ID を設定します。

    $ pkcs15-init --store-pin --label testuser \
        --auth-id 01 --so-pin 65498714 --pin 963214 --puk 321478
    Using reader with a card: Reader name

    ラベルは人間が判読できる値に設定されます (この場合は testuser)。auth-id は 16 進数の値である必要があります。この場合、01 に設定されます。

  4. スマートカードの新しいスロットに秘密鍵を保存し、ラベルを付けます。

    $ pkcs15-init --store-private-key testuser.key --label testuser_key \
        --auth-id 01 --id 01 --pin 963214
    Using reader with a card: Reader name
    注記

    --id に指定する値は、秘密鍵と証明書を保存する際に同じである必要があります。--id の値を指定しないと、ツールによりより複雑な値が計算されるため、独自の値の定義が容易になります。

  5. スマートカードの新しいスロットに証明書を保存し、ラベル付けします。

    $ pkcs15-init --store-certificate testuser.crt --label testuser_crt \
        --auth-id 01 --id 01 --format pem --pin 963214
    Using reader with a card: Reader name
  6. (オプション) スマートカードの新しいスロットに公開鍵を保存し、ラベルを付けます。

    $ pkcs15-init --store-public-key testuserpublic.key
        --label testuserpublic_key --auth-id 01 --id 01 --pin 963214
    Using reader with a card: Reader name
    注記

    公開鍵が秘密鍵または証明書に対応している場合は、その秘密鍵または証明書と同じ ID を指定する必要があります。

  7. (オプション) スマートカードの中には、設定をロックしてカードを最終処理する必要があるものもあります。

    $ pkcs15-init -F

    この段階では、スマートカードには、新たに作成されたスロットに証明書、秘密鍵、および公開鍵が含まれます。ユーザーの PIN と PUK、およびセキュリティー担当者の PIN と PUK も作成しました。

8.8. sssd.conf でタイムアウトの設定

スマートカード証明書による認証は、SSSD で使用されるデフォルトのタイムアウトよりも時間がかかる場合があります。タイムアウトの期限切れは次の原因で発生する可能性があります。

  • 読み込みが遅い
  • 物理デバイスから仮想環境への転送
  • スマートカードに保存されている証明書が多すぎる
  • OCSP (Online Certificate Status Protocol) を使用して証明書を検証する場合は、OCSP レスポンダーからの応答が遅い

この場合は、sssd.conf ファイルにある次のタイムアウトを、たとえば 60 秒まで延長できます。

  • p11_child_timeout
  • krb5_auth_timeout

前提条件

  • root としてログインしている。

手順

  1. sssd.conf ファイルを開きます。

    [root@idmclient1 ~]# vim /etc/sssd/sssd.conf
  2. p11_child_timeout の値を変更します。

    [pam]
    p11_child_timeout = 60
  3. krb5_auth_timeout の値を変更します。

    [domain/IDM.EXAMPLE.COM]
    krb5_auth_timeout = 60
  4. 設定を保存します。

現在、スマートカードとの相互作用は 1 分間 (60 秒) 実行でき、その後、認証はタイムアウトで失敗します。

8.9. スマートカード認証用の証明書マッピングルールの作成

AD (Active Directory) および IdM (Identity Management) にアカウントを持つユーザーに対して証明書を 1 つ使用する場合は、IdM サーバーで証明書マッピングルールを作成できます。

このようなルールを作成すると、ユーザーは両方のドメインのスマートカードで認証できます。

証明書マッピングルールの詳細については、スマートカードで認証を設定するための証明 書マッピングルールを参照してください。

第9章 Identity Management での証明書マッピングルールの設定

9.1. スマートカードにおける認証を設定するための証明書マッピングルール

証明書マッピングルールは、Identity Management (IdM) 管理者が特定のユーザーの証明書にアクセスしない場合に、シナリオで証明書を使用して認証できるため便利な方法です。通常、このようなアクセスがない理由は、証明書が外部認証局によって発行されたためです。特別なユースケースは、IdM ドメインが信頼関係にある Active Directory (AD) の証明書システムが発行した証明書によって表されます。

証明書マッピングルールは、スマートカードを使用するユーザーが多く、IdM 環境が大きい場合にも便利です。このような場合、完全な証明書を追加すると複雑になります。ほとんどの場合、発行先と発行者は予測可能であるため、完全な証明書よりも簡単に追加できます。システム管理者は、証明書マッピングルールを作成し、特定のユーザーに証明書を発行する前に、ユーザーエントリーに証明書マッピングデータを追加できます。証明書を発行すると、完全な証明書がまだユーザーエントリーにアップロードされていなくても、ユーザーは証明書を使用してログインできます。

さらに、証明書は一定間隔で更新する必要があるため、証明書マッピングルールは管理のオーバーヘッドを軽減します。ユーザーの証明書を更新する際に、管理者がユーザーエントリーを更新する必要がありません。たとえば、マッピングが SubjectIssuer の値に基づいている場合、および新しい証明書の Subject と Issuer が以前と同じ場合は、マッピングは引き続き適用されます。一方で、完全な証明書を使用した場合、管理者は古い証明書に置き換わる新しい証明書をユーザーエントリーにアップロードする必要があります。

証明書マッピングを設定するには、以下を実行します。

  1. 管理者は、証明書マッピングデータ (通常は発行者と題名)、または完全な証明書をユーザーアカウントに読み込む必要があります。
  2. ユーザーが IdM へのログインを問題なく行えるようにするために、管理者が証明書マッピングルールを作成する必要があります。

    1. アカウントに、証明書マッピングデータエントリーが含まれる
    2. 証明書マッピングデータエントリーが、証明書の情報と一致する

    マッピングルールを設定する個々のコンポーネントとそれらを取得および使用する方法の詳細については、IdM の ID マッピングルールのコンポーネント および 一致ルールで使用するための証明書からの発行者の取得 を参照してください。

その後、エンドユーザーが ファイルシステム または スマートカード のいずれかに保存されている証明書を提示すると、認証は成功します。

9.1.1. Active Directory ドメインとの信頼に対する証明書マッピングルール

本セクションでは、IdM デプロイメントが Active Directory (AD) ドメインと信頼関係にある場合に可能な、別の証明書マッピングのユースケースを簡単に説明します。

証明書マッピングルールは、信頼された AD 証明書システムが発行したスマートカード証明書を持つユーザーに対して、IdM リソースにアクセスするのに便利な方法です。AD 設定によっては、以下の状況が考えられます。

9.1.2. IdM における ID マッピングルールのコンポーネント

本セクションでは、IdM の ID マッピングルール のコンポーネントと、その設定方法を説明します。各コンポーネントには、オーバーライドできるデフォルト値があります。コンポーネントは、Web UI または CLI のいずれかで定義できます。CLI では、ipa certmaprule-add コマンドを使用して、ID マッピングルールが作成されます。

マッピングルール

マッピングルールコンポーネントでは、証明書を 1 人または複数のユーザーアカウントに関連付けます (または マップ します)。ルールは、証明書を目的のユーザーアカウントに関連付ける LDAP 検索フィルターを定義します。

さまざまな認証局 (CA) が発行する証明書にはさまざまなプロパティーがあり、さまざまなドメインで使用される可能性があります。そのため、IdM はマッピングルールを無条件に適用せず、適切な証明書にのみ適用されます。適切な証明書は、マッチングルール を使用して定義されます。

マッピングルールのオプションを空のままにすると、証明書は、DER でエンコードされたバイナリーファイルとして、userCertificate 属性で検索されることに注意してください。

--maprule オプションを使用して、CLI でマッピングルールを定義します。

マッチングルール

マッチングルールコンポーネントは、マッピングルールを適用する証明書を選択します。デフォルトのマッチングルールは、digitalSignature 鍵 の使用と、clientAuth 拡張鍵 の使用で、証明書と一致します。

--matchrule オプションを使用して、CLI にマッチングルールを定義します。

ドメインリスト

ドメイン一覧は、ID マッピングルールの処理時に IdM がユーザーを検索する ID ドメインを指定します。このオプションを指定しないと、IdM は、IdM クライアントが所属しているローカルドメイン内でのみユーザーを検索します。

--domain オプションを使用して CLI にドメインを定義します。

優先度

複数のルールが証明書に適用される場合は、最も優先度が高いルールが優先されます。その他のルールはすべて無視されます。

  • 数値が低いほど、ID マッピングルールの優先度が高くなります。たとえば、優先度 1 のルールは、優先度 2 のルールよりも高く設定されています。
  • ルールに優先度の値が定義されていないと、優先度が最も低くなります。

--priority オプションを使用して、CLI にマッピングルールの優先度を定義します。

証明書マッピングルールの例 1

CLI を使用して、その証明書の Subject が IdM のユーザーアカウントの certmapdata エントリーと一致している場合に限り、EXAMPLE.ORG 組織の スマートカード CA が発行する証明書を認証局が認証できるようにする証明書マッピングルール simple_rule を定義するには、次のコマンドを実行します。

# ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

9.1.3. マッチングルールで使用する証明書から発行者の取得

この手順では、証明書から発行者情報を取得して、証明書マッピングルールのマッチングルールにコピーする方法を説明します。マッチングルールで必要な発行者の形式を取得するには、openssl x509 ユーティリティーを使用します。

前提条件

  • .pem 形式または .crt 形式のユーザー証明書がある。

手順

  1. 証明書からユーザー情報を取得します。以下のように、openssl x509 証明書の表示および署名ユーティリティーを使用します。

    • リクエストのエンコードされたバージョンの出力を防ぐ -noout オプション
    • 発行者名を出力する -issuer オプション
    • 証明書を読み込む入力ファイル名を指定する -in オプション
    • RFC2253 値と共に -nameopt オプションを指定して、最初に最も具体的な相対識別名 (RDN) で出力を表示します。

      入力ファイルに Identity Management 証明書が含まれる場合は、コマンドの出力で、組織 情報を使用して発行者が定義されていることを示しています。

      # openssl x509 -noout -issuer -in idm_user.crt -nameopt RFC2253
      issuer=CN=Certificate Authority,O=REALM.EXAMPLE.COM

      入力ファイルに Active Directory 証明書が含まれる場合は、コマンドの出力で、ドメインコンポーネント の情報を使用して発行者が定義されていることを示しています。

      # openssl x509 -noout -issuer -in ad_user.crt -nameopt RFC2253
      issuer=CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM
  2. 必要に応じて、証明書発行者が、ad.example.com ドメインから展開した AD-WIN2012R2-CA であることを指定するマッチングルールに基づいて、CLI で新しいマッピングルールを作成する場合は、証明書の発行先が、IdM のユーザーアカウントにある certmapdata エントリーと一致する必要があります。

    # ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

9.1.4. 関連情報

  • sss-certmap(5) のman ページを参照してください。

9.2. IdM に保存されたユーザーの証明書マッピングの設定

このユーザーストーリーでは、証明書認証が設定されているユーザーが IdM に保存されている場合に、システム管理者が IdM での証明書マッピングを有効にする必要がある手順を説明します。このセクションでは、以下について説明します。

  • マッピングルールおよび証明書マッピングデータエントリーで指定された条件に一致する証明書を持つ IdM ユーザーが IdM に認証できるように、証明書マッピングルールを設定する方法。
  • 証明書マッピングデータエントリーに指定された値がすべて含まれている場合に限り、ユーザーが複数の証明書を使用して認証できるように、IdM ユーザーエントリーに証明書マッピングデータを入力する方法。

前提条件

  • IdM にユーザーがアカウントがある。
  • 管理者が、ユーザーエントリーに追加する証明書全体または証明書マッピングデータのいずれかを所有している。

9.2.1. IdM Web UI で証明書マッピングルールの追加

  1. 管理者として IdM Web UI にログインします。
  2. AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules の順に移動します。
  3. Add をクリックします。

    図9.1 IdM Web UI で新しい証明書マッピングルールの追加

    IdM Web UI のスクリーンショット。Authentication タブの「Certificate Identity Mapping Rules」サブタブが表示されています。ページの右側にある「Add」ボタンが強調表示されています。
  4. ルール名を入力します。
  5. マッピングルールを入力します。たとえば、IdM に提示された証明書の Issuer およびSubject エントリーを Idm で検索し、提示された証明書に含まれるこの 2 つのエントリーで見つかった情報に基づいて認証するかどうかを決定するには、次のコマンドを実行します。

    (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
  6. マッチングルールを入力します。たとえば、EXAMPLE.ORG 組織の スマートカード CA が発行する証明書のみが IdM に対して認証できるようにするには、次のコマンドを実行します。

    <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG

    図9.2 IdM Web UI への証明書マッピングルールの詳細の入力

    Rule name (必須) - Mapping rule - Matching rule のフィールドに入力済みの「Add Certificate Identity Mapping Rule」ポップアップウィンドウのスクリーンショット。Priority のフィールドは空白で、ドメイン名のラベルの横に「Add」ボタンがあります。
  7. ダイアログボックスの下部にある Add をクリックして、ルールを追加し、ダイアログボックスを閉じます。
  8. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

これで、証明書マッピングルールセットが設定され、スマートカードの証明書で検出されたマッピングルールで指定されたデータの種類と、IdM ユーザーエントリーの証明書マッピングデータを比較します。一致するファイルが見つかると、一致するユーザーが認証されます。

9.2.2. IdM CLI での証明書マッピングルールの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. マッピングルールを入力し、マッピングルールの基となっているマッチングルールを入力します。たとえば、提示する証明書内の Issuer および Subject のエントリーを IdM で検索し、提示された証明書に含まれるこの 2 つのエントリーで見つかった情報に基づいて認証するかどうかを決定し、EXAMPLE.ORG 組織の Smart Card CA が発行する証明書のみを認識するには、次のコマンドを実行します。

    # ipa certmaprule-add rule_name --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "rule_name"
    -------------------------------------------------------
      Rule name: rule_name
      Mapping rule: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
      Matching rule: <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG
      Enabled: TRUE
  3. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

これで、証明書マッピングルールセットが設定され、スマートカードの証明書で検出されたマッピングルールで指定されたデータの種類と、IdM ユーザーエントリーの証明書マッピングデータを比較します。一致するファイルが見つかると、一致するユーザーが認証されます。

9.2.3. IdM Web UI のユーザーエントリーへの証明書マッピングデータの追加

  1. 管理者として IdM Web UI にログインします。
  2. UsersActive usersidm_user に移動します。
  3. Certificate mapping data オプションを見つけ、Add をクリックします。
  4. 利用できる idm_user の証明書がある場合は、次のコマンドを実行します。

    1. コマンドラインインターフェースで、cat ユーティリティーまたはテキストエディターで証明書を表示します。

      [root@server ~]# cat idm_user_certificate.pem
      -----BEGIN CERTIFICATE-----
      MIIFFTCCA/2gAwIBAgIBEjANBgkqhkiG9w0BAQsFADA6MRgwFgYDVQQKDA9JRE0u
      RVhBTVBMRS5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0x
      ODA5MDIxODE1MzlaFw0yMDA5MDIxODE1MzlaMCwxGDAWBgNVBAoMD0lETS5FWEFN
      [...output truncated...]
    2. 証明書をコピーします。
    3. IdM Web UI で、Certificate の横にある Add をクリックして、開いたウィンドウに証明書を貼り付けます。

      図9.3 ユーザーの証明書マッピングデータの追加 - 証明書

      ユーザー「demouser」の設定が表示されているページのスクリーンショット。左側の「Identity Setting」コラムで Job Title - First name - Last name - Full name - Display name などの項目が入力されています。「Account Settings」コラムが右側にあり、User login - Password - UID - GID などの項目が入力されています。「証明書」エントリーの「追加」ボタンが強調表示されています。

      または、利用できる idm_user の証明書がなくても、証明書の 発行者 および 発行先 を知っている場合は、Issuer and subject のラジオボタンをオンにして、該当するボックスに値を入力します。

      図9.4 ユーザーの証明書マッピングデータの追加 - 発行者および発行先

      「Add Certificate Mapping Data」ポップアップウィンドウのスクリーンショット。「Certificate mapping data」と「Issuer and subject」のラジオボタンオプションが 2 つあり、「Issuer and subject」が選択されています。その 2 つのフィールド (Issuer and Subject) に入力済みです。
  5. Add をクリックします。
  6. 必要に応じて、.pem 形式の証明書全体へのアクセスがある場合は、ユーザーと証明書がリンクされていることを確認します。

    1. sss_cache ユーティリティーを使用して、SSSD キャッシュで idm_user の記録を無効にし、idm_user 情報を再読み込みします。

      # sss_cache -u idm_user
    2. ipa certmap-match コマンドに、IdM ユーザーの証明書が含まれるファイルの名前を付けて実行します。

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      この出力では、証明書マッピングデータが idm_user に追加され、対応するマッピングルールが存在することを確認します。これは、定義した証明書マッピングデータに一致する証明書を使用して、idm_user として認証できることを意味します。

9.2.4. IdM CLI のユーザーエントリーへの証明書マッピングデータの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. 利用できる idm_user の証明書がある場合は、ipa user-add-cert コマンドを使用して、証明書をユーザーアカウントに追加します。

    # CERT=`cat idm_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
    # ipa user-add-certmapdata idm_user --certificate $CERT

    または、利用できる idm_user の証明書がなく、idm_user の証明書の 発行者 および 発行先 が分かっている場合は、次のコマンドを実行します。

    # ipa user-add-certmapdata idm_user --subject "O=EXAMPLE.ORG,CN=test" --issuer "CN=Smart Card CA,O=EXAMPLE.ORG"
    --------------------------------------------
    Added certificate mappings to user "idm_user"
    --------------------------------------------
      User login: idm_user
      Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG
  3. 必要に応じて、.pem 形式の証明書全体へのアクセスがある場合は、ユーザーと証明書がリンクされていることを確認します。

    1. sss_cache ユーティリティーを使用して、SSSD キャッシュで idm_user の記録を無効にし、idm_user 情報を再読み込みします。

      # sss_cache -u idm_user
    2. ipa certmap-match コマンドに、IdM ユーザーの証明書が含まれるファイルの名前を付けて実行します。

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      この出力では、証明書マッピングデータが idm_user に追加され、対応するマッピングルールが存在することを確認します。これは、定義した証明書マッピングデータに一致する証明書を使用して、idm_user として認証できることを意味します。

/include::modules/identity-management/proc_add-certmapdata-to-user.adoc[leveloffset=+1]

9.3. AD ユーザーエントリーに証明書全体が含まれるユーザーに証明書マッピングを設定

このユーザーストーリーでは、IdM デプロイメントが Active Directory (AD) を信頼し、そのユーザーが AD に保存され、AD のユーザーエントリーに証明書全体が含まれる場合に、IdM で証明書マッピングを有効にするのに必要な手順を説明します。

前提条件

  • IdM にユーザーアカウントがない。
  • ユーザーに、証明書を含む AD のアカウントがある。
  • IdM 管理者が、IdM 証明書マッピングルールが基になっているデータにアクセスできる。

9.3.1. IdM Web UI で証明書マッピングルールの追加

  1. 管理者として IdM Web UI にログインします。
  2. AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules の順に移動します。
  3. Add をクリックします。

    図9.5 IdM Web UI で新しい証明書マッピングルールの追加

    IdM Web UI のスクリーンショット。Authentication タブの「Certificate Identity Mapping Rules」サブページが表示されています。右側にある「追加」ボタンが強調表示されています。
  4. ルール名を入力します。
  5. マッピングルールを入力します。認証のために IdM に提示された証明書全体を、AD で利用可能な証明書全体と比較するには、次のコマンドを実行します。

    (userCertificate;binary={cert!bin})
  6. マッチングルールを入力します。たとえば、AD.EXAMPLE.COM ドメインの AD-ROOT-CA が発行する証明書のみを認証できるようにするには、次のコマンドを実行します。

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com

    図9.6 AD に保存されている証明書があるユーザーの証明書マッピングルール

    Rule name (必須) - Mapping rule - Matching rule のフィールドに入力済みの「Add Certificate Identity Mapping Rule」ポップアップウィンドウのスクリーンショット。Priority のフィールドは空白で、ドメイン名のラベルの横に「Add」ボタンがあります。
  7. Add をクリックします。
  8. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにするには、CLI で SSSD を再起動します。

    # systemctl restart sssd

9.3.2. IdM CLI での証明書マッピングルールの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. マッピングルールを入力し、マッピングルールの基となっているマッチングルールを入力します。AD で利用可能な証明書と比較する、認証用に提示される証明書全体を取得して、AD.EXAMPLE.COM ドメインの AD-ROOT-CA により発行された証明書のみの認証を許可するには、次のコマンドを実行します。

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

9.4. ユーザー証明書をユーザーアカウントにマッピングするように AD が設定されている場合に、証明書マッピングの設定

このユーザーストーリーでは、IdM デプロイメントが Active Directory (AD) を信頼し、そのユーザーが AD に保存され、AD のユーザーエントリーに証明書マッピングデータが含まれる場合に、IdM で証明書マッピングを有効にするのに必要な手順を説明します。

前提条件

  • IdM にユーザーアカウントがない。
  • このユーザーに、altSecurityIdentities 属性を含む AD にアカウントがある。AD は、IdM の certmapdata 属性に相当します。
  • IdM 管理者が、IdM 証明書マッピングルールが基になっているデータにアクセスできる。

9.4.1. IdM Web UI で証明書マッピングルールの追加

  1. 管理者として IdM Web UI にログインします。
  2. AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules の順に移動します。
  3. Add をクリックします。

    図9.7 IdM Web UI で新しい証明書マッピングルールの追加

    IdM Web UI のスクリーンショット。Authentication タブの「Certificate Identity Mapping Rules」サブタブが表示されています。ページの右側にある「Add」ボタンが強調表示されています。
  4. ルール名を入力します。
  5. マッピングルールを入力します。たとえば、提示された証明書で Issuer エントリーおよび Subject エントリーを AD DC で検索し、提示された証明書に含まれるこの 2 つのエントリーで見つかった情報に基づいて認証するかどうかを決定するには、次のコマンドを実行します。

    (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
  6. マッチングルールを入力します。たとえば、AD.EXAMPLE.COM ドメインの AD-ROOT-CA が発行する証明書のみを許可し、IdM に対してユーザーを認証するには、次のコマンドを実行します。

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. ドメインを入力します。

    ad.example.com

    図9.8 AD がマッピング用に設定されている場合の証明書マッピングルール

    Rule name (必須) - Mapping rule - Matching rule のフィールドに入力済みの「Add Certificate Identity Mapping Rule」ポップアップウィンドウのスクリーンショット。Priority のフィールドは空白で、ドメイン名のラベルの横に「Add」ボタンがあります。
  8. Add をクリックします。
  9. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにするには、CLI で SSSD を再起動します。

    # systemctl restart sssd

9.4.2. IdM CLI での証明書マッピングルールの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. マッピングルールを入力し、マッピングルールの基となっているマッチングルールを入力します。たとえば、提示する証明書の Issuer エントリーおよび Subject エントリーを AD で検索し、AD.EXAMPLE.COM ドメインの AD-ROOT-CA により発行された証明書のみを許可するには、次のコマンドを実行します。

    # ipa certmaprule-add ad_configured_for_mapping_rule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})' --domain=ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "ad_configured_for_mapping_rule"
    -------------------------------------------------------
      Rule name: ad_configured_for_mapping_rule
      Mapping rule: (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

9.4.3. AD で証明書マッピングデータの確認

altSecurityIdentities 属性は、IdM の certmapdata ユーザー属性と同等の Active Directory (AD) です。信頼されている AD ドメインが、ユーザーアカウントにユーザー証明書をマッピングするように設定されている時に IdM で証明書マッピングを設定する場合は、IdM システム管理者が、AD のユーザーエントリーに altSecurityIdentities 属性が正しく設定されていることを確認する必要があります。

AD に保存されているユーザーに対して、AD が正しい情報が含まれていることを確認する場合は、ldapsearch コマンドを使用します。

  • たとえば、以下のコマンドを入力して、以下の条件が適用される adserver.ad.example.com サーバーでチェックします。

    • altSecurityIdentities 属性は、ad_user のユーザーエントリーに設定されます。
    • matchrule は、以下の条件が適用されるように指定します。

      • ad_user が AD への認証に使用する証明書は、ad.example.com ドメインの AD-ROOT-CA により発行されました。
      • 発行者は <S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user です。
    $ ldapsearch -o ldif-wrap=no -LLL -h adserver.ad.example.com \
    -p 389 -D cn=Administrator,cn=users,dc=ad,dc=example,dc=com \
    -W -b cn=users,dc=ad,dc=example,dc=com "(cn=ad_user)" \
    altSecurityIdentities
    Enter LDAP Password:
    dn: CN=ad_user,CN=Users,DC=ad,DC=example,DC=com
    altSecurityIdentities: X509:<I>DC=com,DC=example,DC=ad,CN=AD-ROOT-CA<S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user

9.5. AD ユーザーエントリーに証明書やマッピングデータが含まれていない場合に、証明書マッピングの設定

このユーザーストーリーでは、IdM デプロイメントが Active Directory (AD) を信頼し、そのユーザーが AD に保存され、AD のユーザーエントリーに証明書全体または証明書マッピングデータが含まれる場合に、IdM で証明書マッピングを有効にするのに必要な手順を説明します。

前提条件

  • IdM にユーザーアカウントがない。
  • ユーザーのアカウントがある AD に、証明書全体、または altSecurityIdentities 属性、IdM certmapdata 属性で AD に相当するものがない。
  • IdM 管理者が、IdM に、AD ユーザーの ユーザー ID オーバーライド に追加する AD ユーザー証明書全体を所有している。

9.5.1. IdM Web UI で証明書マッピングルールの追加

  1. 管理者として IdM Web UI にログインします。
  2. AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules の順に移動します。
  3. Add をクリックします。

    図9.9 IdM Web UI で新しい証明書マッピングルールの追加

    IdM Web UI のスクリーンショット。Authentication タブの「Certificate Identity Mapping Rules」サブページが表示されています。右側にある「追加」ボタンが強調表示されています。
  4. ルール名を入力します。
  5. マッピングルールを入力します。認証するために IdM に提示された証明書全体を、IdM の AD ユーザーエントリーのユーザー ID オーバーライドエントリーに保存されている証明書と比較できるようにするには、次のコマンドを実行します。

    (userCertificate;binary={cert!bin})
  6. マッチングルールを入力します。たとえば、AD.EXAMPLE.COM ドメインの AD-ROOT-CA が発行する証明書のみを認証できるようにするには、次のコマンドを実行します。

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. ドメイン名を入力します。たとえば、ad.example.com ドメインでユーザーを検索するには、以下を実行します。

    図9.10 AD に証明書やマッピングデータが保存されていないユーザーに対する証明書マッピングルール

    Rule name (必須) - Mapping rule - Matching rule のフィールドに入力済みの「Add Certificate Identity Mapping Rule」ポップアップウィンドウのスクリーンショット。Priority のフィールドは空白で、ドメイン名のラベルの横に「Add」ボタンがあります。
  8. Add をクリックします。
  9. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにするには、CLI で SSSD を再起動します。

    # systemctl restart sssd

9.5.2. IdM CLI での証明書マッピングルールの追加

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. マッピングルールを入力し、マッピングルールの基となっているマッチングルールを入力します。IdM の AD ユーザーエントリーのユーザー ID オーバーライドエントリーに保存されている証明書と比較する、認証用に提示される証明書全体を取得して、AD.EXAMPLE.COM ドメインの AD-ROOT-CA により発行された証明書のみを認証できるようにするには、以下のコマンドを実行します。

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. System Security Services Daemon (SSSD) は、証明書マッピングルールを定期的に再読み込みします。新たに作成したルールがすぐに読み込まれるようにする場合は、次のコマンドを実行して SSSD を再起動します。

    # systemctl restart sssd

9.5.3. IdM Web UI で、AD ユーザーの ID オーバーライドに証明書を追加

  1. IdentityID ViewsDefault Trust View の順に選択します。
  2. Add をクリックします。

    図9.11 IdM Web UI で新規ユーザー ID オーバーライドの追加

    IdM Web UI のスクリーンショット。Identity タブの「ID Views」ページが表示されています。右側の追加ボタンが強調表示されています。
  3. User to override フィールドに、ad_user@ad.example.com と入力します。
  4. ad_user の証明書を、Certificate フィールドにコピーアンドペーストします。

    図9.12 AD ユーザーにユーザー ID オーバーライドの設定

    「Add User ID override」ポップアップウィンドウと、User to override (必須) - User login - GECOS - UID - GID - Certificate (プレーンテキスト形式の証明書が入力されている) のフィールドが表示されているスクリーンショット。
  5. Add をクリックします。

検証手順

  • ユーザーと証明書がリンクしていることを確認します。

    • sss_cache ユーティリティーを使用して、SSSD キャッシュで ad_user@ad.example.com のレコードを無効にし、ad_user@ad.example.com 情報の再読み込みを強制します。

      # sss_cache -u ad_user@ad.example.com
    • AD ユーザーの証明書が含まれるファイルの名前で、ipa certmap-match コマンドを実行します。

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

この出力では、ad_user@ad.example.com に追加した証明書マッピングデータがあり、Adding a certificate mapping rule if the AD user entry contains no certificate or mapping data で定義した対応するマッピングルールが存在することを確認します。これは、定義した証明書マッピングデータに一致する証明書を使用して、ad_user@ad.example.com として認証できることを意味します。

9.5.4. IdM CLI で、AD ユーザーの ID オーバーライドに証明書を追加する

関連情報

  1. 管理者の認証情報を取得します。

    # kinit admin
  2. 証明書 blob を CERT という新しい変数に格納します。

    # CERT=`cat ad_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
  3. ipa idoverrideuser-add-cert コマンドを使用して、ad_user@ad.example.com の証明書をユーザーアカウントに追加します。

    # ipa idoverrideuser-add-cert ad_user@ad.example.com --certificate $CERT

検証手順

  • ユーザーと証明書がリンクしていることを確認します。

    • sss_cache ユーティリティーを使用して、SSSD キャッシュで ad_user@ad.example.com のレコードを無効にし、ad_user@ad.example.com 情報の再読み込みを強制します。

      # sss_cache -u ad_user@ad.example.com
    • AD ユーザーの証明書が含まれるファイルの名前で、ipa certmap-match コマンドを実行します。

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

この出力では、ad_user@ad.example.com に追加した証明書マッピングデータがあり、Adding a certificate mapping rule if the AD user entry contains no certificate or mapping data で定義した対応するマッピングルールが存在することを確認します。これは、定義した証明書マッピングデータに一致する証明書を使用して、ad_user@ad.example.com として認証できることを意味します。

9.6. 複数のアイデンティティーマッピングルールを 1 つに結合

関連情報

複数の ID マッピングルールを 1 つのルールに結合するには、個々のマッピングルールの前に | (or) 文字を追加し、括弧 () で区切ります。以下に例を示します。

証明書マッピングフィルターの例 1

$ ipa certmaprule-add ad_cert_for_ipa_and_ad_users \ --maprule='(|(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \ --matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \ --domain=ad.example.com

上記の例では、--maprule オプションのフィルター定義には、以下の基準が含まれます。

--maprule オプションのフィルターの定義では、論理演算子 | (or) が使用できるため、複数の基準を指定できます。この場合、ルールは、1 つ以上の基準を満たすユーザーアカウントをすべてマップします。

証明書マッピングフィルターの例 2

$ ipa certmaprule-add ipa_cert_for_ad_users \
  --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
  --matchrule='<ISSUER>CN=Certificate Authority,O=REALM.EXAMPLE.COM' \
  --domain=idm.example.com --domain=ad.example.com

上記の例では、--maprule オプションのフィルター定義には、以下の基準が含まれます。

--maprule オプションのフィルターの定義では、論理演算子 | (or) が使用できるため、複数の基準を指定できます。この場合、ルールは、1 つ以上の基準を満たすユーザーアカウントをすべてマップします。

第10章 IdM クライアントのデスクトップに保存されている証明書を使用した認証の設定

Identity Management (IdM) を設定すると、IdM システム管理者は、認証局 (CA) がユーザーに発行した証明書を使用して、IdM Web UI とコマンドラインインターフェース (CLI) に対してユーザーを認証できます。

Web ブラウザーは、IdM ドメイン外のシステムで実行できます。

このユーザーストーリーの手順では、IdM クライアントのデスクトップに保存された証明書を使用して、Identitiy Management の Web UI と CLI へのログインを効果的に設定およびテストする方法を説明します。このユーザーストーリーでは、以下の点に注意してください。

注記

Identity Management ユーザーのみが、証明書を使用して Web UI にログインできます。Active Directory ユーザーは、ユーザー名とパスワードを使用してログインできます。

10.1. Web UI での証明書認証用の Identity Management Server の設定

Identity Management (IdM) 管理者は、ユーザーが、証明書を使用して IdM 環境で認証できるように設定できます。

手順

Identity Management 管理者が、以下を行います。

  1. Identity Management サーバーで管理者権限を取得し、サーバーを設定するシェルスクリプトを作成します。

    1. ipa-advise config-server-for-smart-card-auth コマンドを実行し、その出力をファイル (例: server_certificate_script.sh) に保存します。

      # kinit admin
      # ipa-advise config-server-for-smart-card-auth > server_certificate_script.sh
    2. chmod ユーティリティーを使用して、実行パーミッションをファイルに追加します。

      # chmod +x server_certificate_script.sh
  2. Identity Management ドメインの全サーバーで、server_certificate_script.sh スクリプトを実行します。

    1. 証明書認証を有効にするユーザーの証明書を発行した唯一の認証局が IdM CA である場合は、IdM Certificate Authority 証明書へのパス (/etc/ipa/ca.crt) を使用します。

      # ./server_certificate_script.sh /etc/ipa/ca.crt
    2. 証明書認証を有効にするユーザーの証明書を外部の複数の CA が署名した場合は、関連する CA 証明書へのパスを使用します。

      # ./server_certificate_script.sh /tmp/ca1.pem /tmp/ca2.pem
注記

トポロジー全体でユーザーの証明書認証を有効にする場合は、今後新たにシステムに追加する各レプリカに対して、必ずスクリプトを実行してください。

10.2. 新しいユーザー証明書を要求し、クライアントにエクスポート

Identity Management (IdM) 管理者は、IdM 環境でユーザーの証明書を作成し、作成した証明書を、ユーザーの証明書認証を有効にする IdM クライアントにエクスポートできます。

注記

証明書を使用して認証するユーザーがすでに証明書を持っている場合は、本セクションを飛ばして次に進みます。

手順

  1. 必要に応じて、新しいディレクトリー (例: ~/certdb/) を作成し、証明書の一時データベースを作成します。要求されたら、NSS 証明書の DB パスワードを作成し、後続の手順で生成される証明書への鍵を暗号化します。

    # mkdir ~/certdb/
    # certutil -N -d ~/certdb/
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
  2. 証明書署名要求 (CSR) を作成し、その出力をファイルにリダイレクトします。たとえば、IDM.EXAMPLE.COM レルムの idm_user ユーザーの 4096 ビット証明書に対して、certificate_request.csr という名前の CSR を作成する場合は、判別を簡単にするために、証明書の秘密鍵のニックネームを idm_user に設定し、発行先を CN=idm_user,O=IDM.EXAMPLE.COM に設定します。

    # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr
  3. プロンプトが表示されたら、certutil を使用して一時データベースを作成したときに入力したパスワードを入力します。その後、止めるように言われるまで、ランダムにタイピングし続けます。

    Enter Password or Pin for "NSS Certificate DB":
    
    A random seed must be generated that will be used in the
    creation of your key.  One of the easiest ways to create a
    random seed is to use the timing of keystrokes on a keyboard.
    
    To begin, type keys on the keyboard until this progress meter
    is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
    
    
    Continue typing until the progress meter is full:
  4. 証明書要求ファイルをサーバーに送信します。新しく発行した証明書に関連付ける Kerberos プリンシパルと、証明書を保存する出力ファイルを指定し、必要に応じて証明書のプロファイルを指定します。たとえば、IECUserRoles プロファイル (idm_user@IDM.EXAMPLE.COM プリンシパルに追加したユーザーロール拡張を持つプロファイル) の証明書を取得して、それを ~/idm_user.pem ファイルに保存する場合は、次のコマンドを実行します。

    # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --certificate-out=~/idm_user.pem
  5. 証明書を NSS データベースに追加します。証明書が NSS データベースの秘密鍵に一致するように、CSR を作成する際に使用したニックネームを設定するには、-n オプションを使用します。-t オプションは信頼レベルを設定します。詳細は、man ページの certutil(1) を参照してください。-i オプションは、入力証明書ファイルを指定します。たとえば、idm_user ニックネームを持つ証明書を NSS データベースに追加するには、次のコマンドを実行します。証明書は、~/certdb/ データベースの ~/idm_user.pem ファイルに保存されます。

    # certutil -A -d ~/certdb/ -n idm_user -t "P,," -i ~/idm_user.pem
  6. NSS データベースの鍵で、ニックネームが (orphan) と表示されていないことを確認します。たとえば、~/certdb/ データベースに保存されている証明書で、対応する鍵が存在することを確認するには、以下のコマンドを実行します。

    # certutil -K -d ~/certdb/
    < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user
  7. 証明書を、NSS データベースから PKCS12 形式にエクスポートするには、pk12util コマンドを使用します。たとえば、NSS データベース /root/certdb から ~/idm_user.p12 ファイルへ、idm_user ニックネームを持つ証明書をエクスポートする場合は、次のコマンドを実行します。

    # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  8. idm_user の証明書認証を有効にするホストに、証明書を転送します。

    # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/
  9. セキュリティー上の理由から、証明書が転送されたホストの、.pkcs12 ファイルが格納されているディレクトリーに、「other」グループがアクセスできないようにします。

    # chmod o-rwx /home/idm_user/
  10. セキュリティー上の理由から、一時 NSS データベースおよび .pkcs12 ファイルを、サーバーから削除します。

    # rm ~/certdb/
    # rm ~/idm_user.p12

10.3. 証明書とユーザーが互いにリンクしていることの確認

注記

ユーザーの証明書が IdM CA により発行されている場合は、本セクションを飛ばして先に進みます。

証明書が機能するには、証明書が、それを使用して Identity Management (IdM) に認証を受けるユーザーにリンクされていることを確認する必要があります。

10.4. 証明書認証を有効にするためのブラウザーの設定

WebUI を使用して Identity Management (IdM) にログインする際に証明書で認証できるようにするには、ユーザーおよび関連の認証局 (CA) 証明書を Mozilla Firefox または Google Chrome ブラウザーにインポートする必要があります。ブラウザーが実行しているホスト自体は、IdM ドメインの一部である必要はありません。

IdM は、以下のブラウザーで WebUI への接続に対応します。

  • Mozilla Firefox 38 以降
  • Google Chrome 46 以降

次の手順は、Mozilla Firefox 57.0.1 ブラウザーを設定する方法を説明します。

前提条件

  • PKCS #12 形式で自由にブラウザーにインポートできる ユーザー証明書 がある。

手順

  1. Firefox を開き、設定プライバシーとセキュリティ に移動します。

    図10.1 設定のプライバシーおよびセキュリティセクション

    Firefox 設定ページのスクリーンショット。そのスクリーンショットで「Privacy & Security」オプションが強調表示されています。
  2. 証明書を表示 をクリックします。

    図10.2 プライバシーおよびセキュリティーで証明書を表示

    「証明書証明書」のスクリーンショット。そのスクリーンショットで「表示証明書」ボタンが強調表示されています。
  3. あなたの証明書 タブで、インポート をクリックします。PKCS12 形式のユーザー証明書を見つけて開きます。OK をクリックし、OK をクリックします。
  4. Identity Management 認証局が、Firefox で信頼できる認証局として認識されていることを確認します。

    1. IdM CA 証明書をローカルに保存します。

      • Firefox アドレスバーに IdM サーバーの名前を入力し、IdM の Web UI に移動します。接続が安全ではないことを警告するページで、詳細 をクリックします。

        図10.3 安全ではない接続

        「Your connection is not secure」という警告ダイアログボックスのスクリーンショット。 このエラーメッセージは、「The owner of idm.lab.example.net has configured their website improperly.To protect your information from being stolen Firefox has not connected to this website」と表示されています。 また、エラーメッセージの下には「Go Back」と「Advanced」の 2 つのボタンがあります。 「詳細」ボタンが強調表示されています。
      • 例外を追加 します。表示 をクリックします。

        図10.4 証明書の詳細の表示

        「Location」のテキストフィールドには IdM Web UI の URL が、「Certificate Status」には「This site attempts to identify itself with invalid information」と入力されているスクリーンショット。 右側の「表示」ボタンが強調表示されています。
      • 詳細 タブで、認証局 フィールドを強調表示します。

        図10.5 CA 証明書のエクスポート

        idm.lab.example.net 認証局の情報を表示するスクリーンショット。"Certificate Fields" の展開ツリーで "Certificate Authority" が強調表示されています。下部の "Export…​" ボタンも強調表示されています。
      • エクスポート をクリックします。CA 証明書を、CertificateAuthority.crt ファイルとして保存し、閉じる をクリックして、キャンセル をクリックします。
    2. IdM CA 証明書を、信頼できる認証局の証明書として Firefox にインポートします。

      • Firefox を起動し、設定に移動して、プライバシーおよびセキュリティに移動します。

        図10.6 設定のプライバシーおよびセキュリティセクション

        Firefox 設定ページのスクリーンショット。「Privacy & Security」オプションが強調表示されています。
      • 証明書を表示 をクリックします。

        図10.7 プライバシーおよびセキュリティーで証明書を表示

        「証明書」セクションのスクリーンショット。右下の「View Certificates」ボタンが強調表示されています。
      • 認証機関 タブで、インポート をクリックします。CertificateAuthority.crt ファイルで、上の手順で保存した CA 証明書を見つけて開きます。証明書を信頼し、Web サイトを識別したら、OK をクリックし、OK をクリックします。
  5. Identity Management ユーザーとして証明書を使用した Identity Management Web UI の認証 に進みます。

10.5. Identity Management ユーザーとして証明書を使用した Identity Management Web UI の認証

次の手順では、Identity Management クライアントのデスクトップに保存されている証明書を使用して、ユーザーが Identity Management (IdM) の Web UI を認証する方法を説明します。

手順

  1. ブラウザーで、Identity Management の Web UI (例: https://server.idm.example.com/ipa/ui) に移動します。
  2. Login Using Certificate をクリックします。

    Identity Management Web UI の Login Using Certificate

    Identity Management Web UI ログインページのスクリーンショット。パスワードプロンプトの下の「Login Using Certificate」が強調表示されています。
  3. ユーザーの証明書がすでに選択されているはずです。Remember this decision の選択を解除して、OK をクリックします。

これで、証明書に対応するユーザーとして認証されました。

関連情報

10.6. 証明書を使用して CLI への認証を可能にするように IdM クライアントを設定

IdM クライアントのコマンドラインインターフェース (CLI) で、IdM ユーザーに対して証明書認証を有効にするには、IdM ユーザーの証明書および秘密鍵を IdM クライアントにインポートします。ユーザー証明書の作成と転送方法の詳細は、新しいユーザー証明書を要求し、クライアントにエクスポート を参照してください。

手順

  • IdM クライアントにログインし、ユーザーの証明書と秘密鍵を含む .p12 ファイルを用意します。Kerberos TGT (Ticket Granting Ticket) ファイルを取得してキャッシュを取得するには、-X オプションに X509_username:/path/to/file.p12 属性を使用し、ユーザーのプリンシパルで kinit コマンドを実行して、ユーザーの X509 識別情報の場所を指定します。たとえば、~/idm_user.p12 ファイルに保存されている識別情報を使用して idm_user の TGT を取得するには、次のコマンドを実行します。

    $ kinit -X X509_idm_user='PKCS12:~/idm_user.p12' idm_user
    注記

    このコマンドは、.pem ファイル形式 (kinit -X X509_username='FILE:/path/to/cert.pem,/path/to/key' user_principal) にも対応しています。

第11章 IdM CA 更新サーバーの使用

11.1. IdM CA 更新サーバーの説明

組み込みの認証局 (CA) を使用する Identity Management (IdM) デプロイメントでは、CA 更新サーバーが IdM システム証明書を維持および更新します。IdM デプロイメントを確実に堅牢化します。

IdM システム証明書には、以下が含まれます。

  • IdM CA 認証
  • OCSP 署名証明書
  • IdM CA サブシステム 証明書
  • IdM CA 監査署名 証明書
  • IdM 更新エージェント (RA) 証明書
  • KRA トランスポート証明書およびストレージ証明書

システム証明書の特徴は、鍵がすべての CA レプリカで共有されることです。一方、IdM サービス証明書 (LDAP 証明書、HTTP 証明書、PKINIT 証明書など) には、さまざまな IdM CA サーバーに、さまざまな鍵ペアと発行先名があります。

IdM トポロジーでは、デフォルトで、最初の IdM CA サーバーが CA 更新サーバーになります。

注記

IdM CA は、アップストリームのドキュメントでは Dogtag と呼ばれています。

CA 更新サーバーのロール

IdM CA 証明書、IdM CA サブシステム 証明書、および IdM RA 証明書は、IdM デプロイメントに重要です。各証明書は、/etc/pki/pki-tomcat/ ディレクトリーの NSS データベースおよび LDAP データベースのエントリーに保存されます。LDAP に保存されている証明書は、NSS データベースに保存されている証明書に一致する必要があります。一致しない場合は、IdM フレームワークと IdM CA、および IdM CA と LDAP との間に認証エラーが発生します。

すべての IdM CA レプリカは、すべてのシステム証明書への追跡リクエストがあります。統合 CA を備えた IdM デプロイメントに CA 更新サーバーが含まれていない場合には、各 IdM CA サーバーはシステム証明書の更新を個別に要求します。これにより、異なる CA レプリカにさまざまなシステム証明書が含まれるようになり、認証に失敗します。

CA レプリカの 1 つを更新サーバーとすることで、システム証明書が必要に応じて一度だけ更新されるため、認証が失敗しないようになります。

CA レプリカ上の certmonger サービスのロール

すべての IdM CA レプリカで実行している certmonger サービスは、dogtag-ipa-ca-renew-agent 更新ヘルパーを使用して、IdM システム証明書を追跡します。更新ヘルパープログラムは、CA 更新マスター設定を読み取ります。CA 更新サーバー以外の各 CA レプリカで、更新ヘルパーが ca_renewal LDAP エントリーから最新のシステム証明書を取得します。certmonger の更新の試みが正確に行われる際に、非決定論により、CA 更新サーバーが実際に証明書を更新する前に、dogtag-ipa-ca-renew-agent ヘルパーがシステム証明書の更新を試みることがあります。この状況が発生すると、CA レプリカの certmonger サービスに、すぐに有効期限が切れる古い証明書が提供されます。certmonger は、これデータベースにすでに保存されているのと同じ証明書であることを認識し、CA 更新サーバーから更新された証明書を取得できるまで、個々の試行の間に少し遅れて証明書の更新を試行し続けます。

IdM CA 更新サーバーの適切な機能

埋め込み CA のある IdM デプロイメントは、IdM CA でインストールされた、または後で IdM CA サーバーがインストールされた IdM デプロイメントです。組み込み CA を使用した IdM デプロイメントでは、常に更新サーバーとして構成された CA レプリカが 1 つだけ必要になります。更新サーバーはオンラインで完全に機能し、その他のサーバーで正しく複製する必要があります。

ipa server-del コマンド、ipa-replica-manage del コマンド、ipa-csreplica-manage del コマンド、または ipa-server-install --uninstall コマンドを使用して、現在の CA 更新サーバーを削除すると、別の CA レプリカが CA 更新サーバーとして自動的に割り当てられます。このポリシーは、更新されたサーバー設定を有効に保つようにします。

このポリシーは、以下の状況を対象としません。

  • オフライン更新サーバー

    更新サーバーが長期間オフラインであると、更新ウィンドウが表示されない場合があります。この場合、更新されていないすべてのサーバーでは、証明書が期限切れになるまで現在のシステム証明書を再インストールし続けます。これが発生すると、証明書が失効した場合でも、その他の証明書の更新が失敗する可能性があるため、IdM デプロイメントが中断されます。

  • レプリケーションの問題

    更新サーバーと他の CA レプリカとの間でレプリケーションの問題が存在する場合は、更新が成功する可能性もありますが、その他の CA レプリカが、期限切れになる前に更新された証明書を取得できなくなる可能性があります。

    この問題を回避するには、レプリカ合意が正しく機能することを確認してください。詳細は、RHEL 7の 『Linux ドメイン ID、認証、およびポリシーガイド』一般的 または 特定 のレプリケーションのトラブルシューティングガイドラインを参照してください。

11.2. IdM CA 更新サーバーの変更およびリセット

CA 更新サーバーの使用を止めると、Identity Management (IdM) により、IdM CA サーバーの一覧から新しい CA 更新サーバーが自動的に選択されます。システム管理者は、選択に影響を与えることはできません。

新しい IdM CA 更新サーバーを選択できるようにするには、システム管理者が交換を手動で実行する必要があります。CA 更新サーバーを選択してから、現在の更新サーバーの使用を停止するプロセスを開始します。

現在の CA 更新サーバー設定が無効な場合は、IdM CA 更新サーバーをリセットします。

この手順では、CA 更新サーバーを変更またはリセットします。

前提条件

  • IdM 管理者認証情報がある。

手順

  1. IdM 管理者認証情報を取得します。

    ~]$ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  2. 任意で、デプロイメント内のどの IdM サーバーが新しい CA 更新サーバーになるのに必要な CA のロールを持っているかを確認するには、次のコマンドを実行します。

    ~]$ ipa server-role-find --role 'CA server'
    ----------------------
    2 server roles matched
    ----------------------
      Server name: server.idm.example.com
      Role name: CA server
      Role status: enabled
    
      Server name: replica.idm.example.com
      Role name: CA server
      Role status: enabled
    ----------------------------
    Number of entries returned 2
    ----------------------------

    デプロイメントには、2 つの CA サーバーがあります。

  3. 必要に応じて、どの CA サーバーが現在の CA 更新サーバーであるかを確認するには、次のコマンドを実行します。

    ~]$ ipa config-show | grep 'CA renewal'
      IPA CA renewal master: server.idm.example.com

    現在の更新サーバーは server.idm.example.com です。

  4. 更新サーバー設定を変更するには、--ca-renewal-master-server オプションを指定して ipa config-mod ユーティリティーを使用します。

    ~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com | grep 'CA renewal'
      IPA CA renewal master: replica.idm.example.com
    重要

    以下を使用して、新しい CA 更新サーバーに切り替えることもできます。

    • ipa-cacert-manage --renew コマンド。このコマンドは、CA 証明書を更新し、かつコマンドを実行する CA サーバーを新しい CA 更新サーバーにします。
    • ipa-cert-fix コマンド。このコマンドは、期限切れの証明書が失敗の原因になっている場合にデプロイメントを回復します。また、コマンドを実行する CA サーバーを新しい CA 更新サーバーにします。

      詳細は 「IdM がオフライン時に期限切れのシステム証明書の更新」を参照してください。

11.3. IdM で外部から自己署名証明書への切り替え

この手順は、外部署名から、Identity Management (IdM) 認証局 (CA) の自己署名証明書に切り替えます。自己署名の CA の場合、CA 証明書の更新は自動的に管理されます。システム管理者は、外部認証局に証明書署名リクエスト (CSR) を提出する必要はありません。

外部署名から自己署名の CA へ切り替える場合は、CA 証明書を置き換えます。以前の CA が署名する証明書は有効のままで、今でも使用されています。たとえば、LDAP 証明書の証明書チェーンは、自己署名の CA に移動した後も変更されません。

external_CA certificate > IdM CA certificate > LDAP certificate

前提条件

  • IdM CA 更新サーバーおよびすべての IdM クライアントとサーバーへの root アクセス権がある。

手順

  1. IdM CA 更新サーバーで、CA 証明書を自己署名として更新します。

    # ipa-cacert-manage renew --self-signed
    Renewing CA certificate, please wait
    CA certificate successfully renewed
    The ipa-cacert-manage command was successful
  2. root として、残りのすべての IdM サーバーとクライアントに SSH で接続します。以下に例を示します。

    # ssh root@idmclient01.idm.example.com
  3. IdM クライアントで、サーバーからの証明書を使用して、ローカルの IdM 証明書データベースを更新します。

    [idmclient01 ~]# ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  4. 必要に応じて、更新が成功したかどうかを確認して、新しい CA 証明書を /etc/ipa/ca.crt ファイルに追加します。

    [idmclient01 ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    この出力は、新規 CA 証明書が古い CA 証明書と共にリストされているため、更新が正常に行われたことを示しています。

11.4. 外部署名の証明書で IdM CA 更新サーバーの更新

このセクションでは、証明書署名要求 (CSR) に署名するために外部の CA を使用して Identity Management (IdM) 認証局 (CA) 証明書を更新する方法を説明します。この設定では、IdM CA サーバーは、外部 CA のサブ CA です。外部の CA は、Active Directory Certificate Server (AD CS) を使用することができますが、必須ではありません。

外部認証局が AD CS の場合は、CSR に、IdM CA 証明書に必要なテンプレートを指定できます。証明書テンプレートは、証明書要求の受信時に CA が使用するポリシーおよびルールを定義します。AD の証明書テンプレートは、IdM の証明書プロファイルに対応します。

オブジェクト識別子 (OID) で特定の AD CS テンプレートを定義できます。OID は、分散アプリケーションのデータ要素、構文などを一意に識別するために、さまざまな発行機関が発行する一意の数値です。

または、特定の AD CS テンプレートを名前で定義することもできます。たとえば、IdM CA から AD CS に送信された CSR で使用されるデフォルトプロファイルの名前は subCA です。

CSR で OID または名前を指定してプロファイルを定義するには、external-ca-profile オプションを使用します。詳細は、man ページの ipa-cacert-manage を参照してください。

既製の証明書テンプレートを使用する以外に、AD CS でカスタム証明書テンプレートを作成し、CSR で使用できます。

前提条件

  • IdM CA 更新サーバーへの root のアクセス権がある。

手順

この手順では、現在の CA 証明書が自己署名の証明書であるか、または外部署名であるかに関係なく、外部署名を使用して IdM CA の証明書を更新します。

  1. 外部 CA に送信される CSR を作成します。

    • 外部 CA が AD CS の場合は、--external-ca-type=ms-cs オプションを使用します。デフォルトの subCA テンプレート以外のテンプレートが必要な場合は、--external-ca-profile を使用してこれを指定します。

      ~]# ipa-cacert-manage renew --external-ca --external-ca-type=ms-cs [--external-ca-profile=PROFILE]
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful
    • 外部 CA が AD CS ではない場合は、以下のようになります。

      ~]# ipa-cacert-manage renew --external-ca
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful

      この出力は、CSR が作成され、/var/lib/ipa/ca.csr ファイルに保存されていることを示しています。

  2. /var/lib/ipa/ca.csr にある CSR を外部 CA に送信します。このプロセスは、外部 CA として使用するサービスにより異なります。
  3. 発行した証明書と、ベース 64 でエンコードされたブロブで CA を発行する CA 証明書チェーンを取得します。以下に例を示します。

    • 外部 CA が AD CS ではない場合の PEM ファイル
    • 外部 CA が AD CS の場合の Base_64 証明書

      プロセスは、各証明書サービスによって異なります。通常は Web ページか通知メールにダウンロードリンクがあり、管理者が、必要なすべての証明書をダウンロードできるようになっています。

      外部 CA が AD CS で、Microsoft Windows 認証局管理ウィンドウから既知のテンプレートで CSR を送信した場合、AD CS は証明書を直ちに発行し、その証明書を保存する「証明書の保存」ダイアログが AD CS Web インターフェースに表示されます。

  4. ipa-cacert-manage renew コマンドを再度実行し、完全な証明書チェーンを提供するのに必要な CA 証明書ファイルをすべて追加します。--external-cert-file オプションを複数回使用して、必要な数だけファイルを指定します。

    ~]# ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate_1 --external-cert-file=/path/to/external_ca_certificate_2
  5. すべての IdM サーバーおよびクライアントで、サーバーの証明書でローカルの IdM 証明書データベースを更新します。

    [client ~]$ ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  6. 必要に応じて、更新が成功したかどうかを確認して、新しい CA 証明書を /etc/ipa/ca.crt ファイルに追加します。

    [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    この出力は、新規 CA 証明書が古い CA 証明書と共にリストされているため、更新が正常に行われたことを示しています。

第12章 IdM がオフライン時に期限切れのシステム証明書の更新

システム証明書の期限が切れると、Identity Management (IdM) が起動できません。IdM は、ipa-cert-fix ツールを使用して IdM がオフラインの場合のシステム証明書の更新に対応します。

12.1. CA 更新サーバーでの期限切れのシステム証明書の更新

本セクションでは、期限切れの IdM 証明書に ipa-cert-fix ツールを適用する方法を説明します。

重要

CA 更新サーバーではないCA (認証局) ホストで ipa-cert-fix ツールを実行し、ユーティリティーが共有証明書を更新すると、そのホストは自動的にドメイン内の新しい CA 更新サーバーになります。不整合を避けるために、ドメインには常に CA 更新サーバー 1 つだけを設定する必要があります。

前提条件

  • 管理者権限でサーバーにログインしている。

手順

  1. ipa-cert-fix ツールを起動して、システムを分析し、更新を必要とする期限切れの証明書の一覧を表示します。

    # ipa-cert-fix
    ...
    The following certificates will be renewed:
    
    Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  13
      Expires: 2019-05-12 05:55:47
    ...
    Enter "yes" to proceed:
  2. 更新プロセスを開始するには、yes を入力します。

    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  268369925
      Expires: 2021-08-14 02:19:33
    ...
    
    Becoming renewal master.
    The ipa-cert-fix command was successful

    ipa-cert-fix が期限切れの証明書をすべて更新する前に、最大 1 分かかる場合があります。

  3. 必要に応じて、すべてのサービスが現在実行していることを確認します。

    # ipactl status
    Directory Service: RUNNING
    krb5kdc Service: RUNNING
    kadmin Service: RUNNING
    httpd Service: RUNNING
    ipa-custodia Service: RUNNING
    pki-tomcatd Service: RUNNING
    ipa-otpd Service: RUNNING
    ipa: INFO: The ipactl command was successful

この時点で、証明書が更新され、サービスが実行しています。次の手順は、IdM ドメイン内のその他のサーバーを確認します。

注記

複数の CA サーバーで証明書を修復する必要がある場合は、次のコマンドを実行します。

  1. トポロジー全体で LDAP レプリケーションが機能していることを確認したら、上記の手順に従って、最初に 1 つの CA サーバーで ipa-cert-fix を実行します。
  2. 別の CA サーバーで ipa-cert-fix を実行する前に、(別の CA サーバーの) getcert-resubmit を介して共有証明書の Certmonger 更新をトリガーして、共有証明書の不必要な更新を回避します。

12.2. 更新後の IdM ドメイン内の他の IdM サーバーの検証

ipa-cert-fix ツールで、CA 更新サーバーを更新したら、以下を行う必要があります。

  • ドメインのその他の Identity Management (IdM) サーバーをすべて再起動する。
  • certmonger が証明書を更新したかどうかを確認する。
  • 期限切れのシステム証明書でその他の認証局 (CA) レプリカがある場合は、証明書も ipa-cert-fix ツールで更新する。

前提条件

  • 管理者権限でサーバーにログインしている。

手順

  1. --force パラメーターで IdM を再起動します。

    # ipactl restart --force

    --force パラメーターを使用すると、ipactl ユーティリティーは個々のサービスの起動失敗を無視します。たとえば、サーバーに期限切れの証明書を持つ CA もあると、pki-tomcat サービスが起動に失敗します。--force パラメーターを使用しているため、これが予想され、無視されます。

  2. 再起動後に、certmonger サービスが証明書を更新することを確認します (証明書の状態は MONITORING になります)。

    # getcert list | egrep '^Request|status:|subject:'
    Request ID '20190522120745':
            status: MONITORING
            subject: CN=IPA RA,O=EXAMPLE.COM 201905222205
    Request ID '20190522120834':
            status: MONITORING
            subject: CN=Certificate Authority,O=EXAMPLE.COM 201905222205
    ...

    certmonger がレプリカ上で共有証明書を更新する前に時間がかかる場合があります。

  3. サーバーも CA の場合、上記のコマンドは、pki-tomcat サービスが使用する証明書の CA_UNREACHABLE を報告します。

    Request ID '20190522120835':
            status: CA_UNREACHABLE
            subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
    ...
  4. この証明書を更新するには、ipa-cert-fix ユーティリティーを使用します。

    # ipa-cert-fix
    Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM
      Serial:  3
      Expires: 2019-05-11 12:07:11
    
    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
      Serial:  15
      Expires: 2019-08-14 04:25:05
    
    The ipa-cert-fix command was successful

これで、すべての IdM 証明書が更新され、正常に機能するようになりました。

12.3. Web サーバーおよび LDAP サーバーの証明書の置き換え

Identity Management (IdM) システム管理者は、IdM サーバーで実行している Web (またはhttpd) サービスおよび LDAP (またはDirectory) サービスの証明書を手動で置き換えることができます。たとえば、certmonger ユーティリティーが証明書を自動的に更新するように設定されていない場合、または証明書が外部の認証局 (CA) により署名されている場合などに必要になります。

この例では、server.idm.example.com IdM サーバーで実行しているサービスの証明書をインストールします。外部 CA から証明書を取得する。

注記

HTTP サービス証明書と LDAP サービス証明書には異なる IdM サーバーに異なるキーペアとサブジェクト名があるため、各 IdM サーバーで証明書を個別に更新する必要があります。

前提条件

  • IdM サーバーへの root アクセス権限がある。
  • Directory Managerパスワードを把握している。
  • 外部 CA の CA 証明書チェーンを保存しているファイル (ca_certificate_chain_file.crt) にアクセスできる。

手順

  1. ca_certificate_chain_file.crt に含まれる証明書を、追加の CA 証明書として IdM にインストールします。

    # ipa-cacert-manage install
  2. ca_certicate_chain_file.crt からの証明書を使用して、ローカルの IdM 証明書データベースを更新します。

    # ipa-certupdate
  3. OpenSSL ユーティリティーを使用して、秘密鍵と証明書署名要求 (CSR) を生成します。

    $ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout new.key -out new.csr -addext "subjectAltName = DNS:ipa-ca.idm.example.test" -subj '/CN=server.idm.example.com,O=IDM.EXAMPLE.COM'

    CSR を外部 CA に送信します。このプロセスは、外部 CA として使用するサービスにより異なります。CA が証明書に署名したら、証明書を IdM サーバーにインポートします。

  4. IdM サーバーで、Apache Web サーバーの古い秘密鍵および証明書を、新しい鍵と、新しく署名した証明書に置き換えます。

    # ipa-server-certinstall -w --pin=password new.key new.crt

    上記のコマンドでは、以下のようになります。

    • -w オプションは、Web サーバーに証明書をインストールすることを指定します。
    • --pin オプションは、秘密鍵を保護するパスワードを指定します。
  5. プロンプトが表示されたら、Directory Manager パスワードを入力します。
  6. LDAP サーバーの古い秘密鍵および証明書を、新しい鍵と、新しく署名した証明書に置き換えます。

    # ipa-server-certinstall -d --pin=password new.key new.cert

    上記のコマンドでは、以下のようになります。

    • -d オプションは、LDAP サーバーに証明書をインストールすることを指定します。
    • --pin オプションは、秘密鍵を保護するパスワードを指定します。
  7. プロンプトが表示されたら、Directory Manager パスワードを入力します。
  8. httpd サービスを再起動します。

    # systemctl restart httpd.service
  9. Directory サービスを再起動します。

    # systemctl restart dirsrv@IDM.EXAMPLE.COM.service

関連情報

第13章 IdM CA サーバーでの CRL の生成

IdM デプロイメントで埋め込み認証局 (CA) を使用する場合は、証明書失効リスト (CRL) の生成を 1 つの Identity Management (IdM) サーバーから別のサーバーに移動する必要になることがあります。たとえば、サーバーを別のシステムに移行する場合に必要になる場合があります。

CRL を生成するサーバーは 1 台だけ設定します。CRL パブリッシャーロールを実行する IdM サーバーは通常、CA 更新サーバーロールを実行するサーバーと同じですが、この設定は必須ではありません。CRL パブリッシャーサーバーの使用を停止する前に、別のサーバーを選択して CRL パブリッシャーサーバーロールを実行するように設定します。

この章では、以下について説明します。

  • IdM サーバーでの CRL 生成の停止
  • IdM レプリカでの CRL 生成の開始

13.1. IdM サーバーでの CRL 生成の停止

IdM CRL パブリッシャーサーバーで証明書失効リスト (CRL) の生成を停止するには、ipa-crlgen-manage コマンドを使用します。生成を無効にする前に、サーバーで実際に CRL が生成されることを確認してください。その後、無効にすることができます。

前提条件

  • root としてログインしている。

手順

  1. サーバーが CRL を生成しているかどうかを確認します。

    [root@server ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:00:00
    Last CRL Number: 6
    The ipa-crlgen-manage command was successful
  2. サーバーで CRL の生成を停止します。

    [root@server ~]# ipa-crlgen-manage disable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
    The ipa-crlgen-manage command was successful
  3. サーバーが CRL の生成を停止したかどうかを確認します。

    [root@server ~]# ipa-crlgen-manage status

サーバーで CRL の生成が停止されました。次の手順は、IdM レプリカで CRL 生成を有効にすることです。

13.2. IdM レプリカサーバーでの CRL 生成の開始

ipa-crlgen-manage コマンドを使用して、IdM CA サーバーで証明書失効リスト (CRL) の生成を開始できます。

前提条件

  • RHEL システムは、IdM 認証局サーバーが必要である。
  • root としてログインしている。

手順

  1. CRL の生成を開始します。

    [root@replica1 ~]# ipa-crlgen-manage enable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    Forcing CRL update
    CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
    The ipa-crlgen-manage command was successful
  2. CRL が生成されているかどうかを確認します。

    [root@replica1 ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:10:00
    Last CRL Number: 7
    The ipa-crlgen-manage command was successful

第14章 CA 更新サーバーと CRL パブリッシャーのロールを実行するサーバーの使用の停止

認証局 (CA) 更新サーバーロールおよび 証明書失効リスト (CRL) パブリッシャーロールの両方を実行しているサーバーが 1 台あるとします。このサーバーをオフラインにするか、使用を停止する必要がある場合は、別の CA サーバーを選択して、このロールを実行するように設定します。

この例では、CA 更新サーバーと CRL パブリッシャーのロールに対応しているホストserver.idm.example.com の使用を停止する必要があります。この手順では、CA 更新サーバーロールおよび CRL パブリッシャーロールをホストreplica.idm.example.com に転送し、IdM 環境からserver.idm.example.com を削除します。

注記

CA 更新サーバーと CRL パブリッシャーの両方のロールを実行するために同じサーバーを設定する必要はありません。

前提条件

  • IdM 管理者認証情報がある。
  • 使用を停止しているサーバーの root パスワードがある。
  • IdM 環境に、少なくとも 2 つの CA レプリカがある。

手順

  1. IdM 管理者認証情報を取得します。

    [user@server ~]$ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  2. (オプション) どのサーバーが CA 更新サーバーおよび CRL パブリッシャーのロールを実行しているかわからない場合は、以下を実行します。

    1. 現在の CA 更新サーバーを表示します。次のコマンドは、任意の IdM サーバーから実行できます。

      [user@server ~]$ ipa config-show | grep 'CA renewal'
        IPA CA renewal master: server.idm.example.com
    2. ホストが現在の CRL パブリッシャーであるかどうかをテストします。

      [user@server ~]$ ipa-crlgen-manage status
      CRL generation: enabled
      Last CRL update: 2019-10-31 12:00:00
      Last CRL Number: 6
      The ipa-crlgen-manage command was successful

      CRL を生成しない CA サーバーは、CRL generation: disabled を表示します。

      [user@replica ~]$ ipa-crlgen-manage status
      CRL generation: disabled
      The ipa-crlgen-manage command was successful

      CRL パブリッシャーサーバーが見つかるまで、CA サーバーでこのコマンドを入力し続けます。

    3. このロールに対応するために昇格できるその他の CA サーバーをすべて表示します。この環境には 2 台の CA サーバーがあります。

      [user@server ~]$ ipa server-role-find --role 'CA server'
      ----------------------
      2 server roles matched
      ----------------------
        Server name: server.idm.example.com
        Role name: CA server
        Role status: enabled
        Server name: replica.idm.example.com
        Role name: CA server
        Role status: enabled
      ----------------------------
      Number of entries returned 2
      ----------------------------
  3. replica.idm.example.com を CA 更新サーバーとして設定します。

    [user@server ~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com
  4. server.idm.example.com で、以下を実行します。

    1. 証明書更新タスクを無効にします。

      [root@server ~]# pki-server ca-config-set ca.certStatusUpdateInterval 0
    2. IdM サービスを再起動します。

      [user@server ~]$ ipactl restart
  5. replica.idm.example.com で、以下を実行します。

    1. 証明書更新タスクを有効にします。

      [root@server ~]# pki-server ca-config-unset ca.certStatusUpdateInterval
    2. IdM サービスを再起動します。

      [user@replica ~]$ ipactl restart
  6. server.idm.example.com で、CRL の生成を中止します。

    [user@server ~]$ ipa-crlgen-manage disable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
    The ipa-crlgen-manage command was successful
  7. replica.idm.example.com で、CRL の生成を開始します。

    [user@replica ~]$ ipa-crlgen-manage enable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    Forcing CRL update
    CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
    The ipa-crlgen-manage command was successful
  8. server.idm.example.com で IdM サービスを停止します。

    [user@server ~]$ ipactl stop
  9. replica.idm.example.com で、IdM 環境から server.idm.example.com を削除します。

    [user@replica ~]$ ipa server-del server.idm.example.com
  10. server.idm.example.com で、ipa-server-install --uninstall コマンドを root アカウントとして使用します。

    [root@server ~]# ipa-server-install --uninstall
    ...
    Are you sure you want to continue with the uninstall procedure? [no]: yes

検証手順

  • 現在の CA 更新サーバーを表示します。

    [user@replica ~]$ ipa config-show | grep 'CA renewal'
      IPA CA renewal master: replica.idm.example.com
  • replica.idm.example.com ホストが CRL を生成していることを確認します。

    [user@replica ~]$ ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:10:00
    Last CRL Number: 7
    The ipa-crlgen-manage command was successful

第15章 certmonger を使用したサービスの IdM 証明書の取得

15.1. Certmonger の概要

Identity Management (IdM) が統合 IdM 認証局 (CA) とともにインストールされていると、certmonger サービスを使用してシステムおよびサービス証明書を追跡し、更新します。証明書の期限が切れると、certmonger は次の方法で更新プロセスを管理します。

  • 元の要求で提供されたオプションを使用して、証明書署名要求 (CSR) を再生成する。
  • IdM API の cert-request コマンドを使用して、CSR を IdM CA に送信する。
  • IdM CA から証明書を受け取る。
  • 元の要求で指定されている場合は、事前保存コマンドを実行する。
  • 更新要求で指定された場所 (NSS データベースまたはファイル内) に新しい証明書をインストールする。
  • 元の要求で指定されている場合は、post-save コマンドを実行する。たとえば、post-save コマンドは、関連するサービスを再起動するように certmonger に指示し、サービスが新しい証明書が取得できるようにします。

certmonger が追跡する証明書の種類

証明書は、システム証明書とサービス証明書に分けることができます。

さまざまなサーバーのさまざまなキーペアと発行名を持つサービス証明書 (HTTPLDAPPKINIT など) とは異なり、IdM システム証明書とその鍵はすべての CA レプリカで共有されます。IdM システム証明書には、以下が含まれます。

  • IdM CA 認証
  • OCSP 署名証明書
  • IdM CA サブシステム 証明書
  • IdM CA 監査署名 証明書
  • IdM 更新エージェント (RA) 証明書
  • KRA トランスポート証明書およびストレージ証明書

certmonger サービスは、統合 CA を使用した IdM 環境のインストール時に要求された IdM システム証明書およびサービス証明書を追跡します。certmonger は、IdM ホストで実行しているその他のサービスに対して、システム管理者が手動で要求した証明書を追跡します。Certmonger は、外部 CA 証明書またはユーザー証明書を追跡しません。

Certmonger のコンポーネント

certmonger サービスは、2 つの主要コンポーネントで構成されています。

  • certmonger デーモン - 証明書の一覧を追跡し、更新コマンドを実行するエンジンです。
  • コマンドラインインターフェース (CLI) のgetcert ユーティリティー。これにより、システム管理者は certmonger デーモンにアクティブにコマンドを送信できます。

具体的には、システム管理者は、getcert ユーティリティーを使用して以下のことができます。

15.2. certmonger を使用したサービスの IdM 証明書の取得

ブラウザーと、Identity Management (IdM) クライアントで実行している Web サービスとの間の通信が安全で暗号化されていることを確認するには、TLS 証明書を使用します。IdM 認証局 (CA) から Web サービスの TLS 証明書を取得します。

本セクションでは、certmonger を使用して、IdM クライアントで実行するサービス (HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM) の IdM 証明書を取得する方法を説明します。

certmonger 使用して証明書を自動的に要求するということは、certmonger 更新の期限が切れたときに証明書を管理および更新することを意味します。

certmonger がサービス証明書を要求したときに発生する内容を視覚的に表示するには、「サービス証明書を要求する certmonger の通信フロー」 を参照してください。

前提条件

  • Web サーバーが、IdM クライアントとして登録されている。
  • 手順を実行している IdM クライアントへのルートアクセス権限がある。
  • 証明書を要求しているサービスは、前もって IdM に用意する必要はない。

手順

  1. HTTP サービスが稼働している IdM クライアント my_company.idm.example.com で、以下を指定する HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM プリンシパルに対応するサービスの証明書を要求します。

    • 証明書は、ローカルの /etc/pki/tls/certs/httpd.pem ファイルに保存されます。
    • 秘密鍵は、ローカルの /etc/pki/tls/private/httpd.key ファイルに保存されます。
    • SubjectAltName の extensionRequest が、my_company.idm.example.com の DNS 名の署名要求に追加されます。

      # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -C "systemctl restart httpd"
      New signing request "20190604065735" added.

      上記のコマンドでは、以下のようになります。

      • ipa-getcert request コマンドは、証明書が IdM CA から取得することを示しています。ipa-getcert request コマンドは、getcert request -c IPA のショートカットです。
      • -g オプションは、生成先のキーのサイズ (設定されていない場合) を指定します。
      • -D オプションは、要求に追加する DNS 値 SubjectAltName を指定します。
      • -C オプションは、証明書の取得後に httpd サービスを再起動するように certmonger に指示します。
      • 特定のプロファイルで証明書を発行するように指定する場合は、-T オプションを使用します。
      • 指定した CA から名前付き発行者を使用して証明書を要求するには、-X ISSUER オプションを使用します。
  2. 必要に応じて、リクエストの状況を確認するには、次のコマンドを実行します。

    # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
    Number of certificates and requests being tracked: 3.
    Request ID '20190604065735':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
        CA: IPA
    [...]

    この出力は、要求が MONITORING 状況であることを表しています。これは、証明書が取得されていることを示しています。キーペアと証明書の場所は、要求された場所です。

15.3. サービス証明書を要求する certmonger の通信フロー

本セクションの図では、各ステージで、certmonger が Identity Management (IdM) 認証局 (CA) サーバーからサービス証明書を要求したときに何が起こるかを示しています。シーケンスは次の図で構成されています。

暗号化されていない通信 は、初期状態を示しています。HTTPS 証明書がないと、Web サーバーとブラウザー間の通信は暗号化されません。

図15.1 暗号化されていない通信

Apache Web サーバーおよび certmonger サービスを実行している IdM クライアントを表示する図。ブラウザーと Apache Web サーバーの間には、暗号化されていない HTTP 接続で接続していることを示す矢印があります。また、certmonger サービスから IdM CA サーバーへは、アクティブでない接続があります。


サービス証明書を要求する certmonger は、システム管理者が certmonger を使用して Apache Web サーバーの HTTPS 証明書を手動で要求していることを示しています。Web サーバー証明書を要求する場合、certmonger は CA と直接対話しないことに注意してください。IdM 経由でプロキシーが設定されます。

図15.2 サービス証明書を要求する certmonger

IdM クライアントと IdM CA サーバーの certmonger サービス間の矢印で ipa-getcert 要求経由で接続していることを示す図。


サービス証明書を発行する IdM CA は、Web サーバーで HTTPS 証明書を発行する IdM CA を示しています。

図15.3 サービス証明書を発行する IdM CA

IdM クライアントの IdM CA サーバーと certmonger サービス間の矢印で、HTTPS 証明書を接続および送信していることを示す図。


Certmonger によるサービス証明書の適用 は、certmonger が HTTPS 証明書を Id M クライアントの適切な場所に配置し、指示された場合は httpd サービスを再起動することを示します。その後、Apache サーバーは HTTPS 証明書を使用して、Apache サーバーとブラウザー間のトラフィックを暗号化します。

図15.4 Certmonger によるサービス証明書の適用

HTTPS 証明書が Apache Web サーバーに割り当てられている画像と、certmonger サービスに割り当てられている画像を示す図。ブラウザーと Apache Web サーバーの間には、暗号化されている HTTPS 接続でつながっていることを示す矢印があります。certmonger サービスと IdM CA サーバー間の接続はアクティブではありません。


古い証明書が有効期限に近づいているときに新しい証明書を要求する certmonger は、証明書の有効期限が切れる前に、certmonger が Id MCA からのサービス証明書の更新を自動的に要求していることを示しています。IdM CA は、新しい証明書を発行します。

図15.5 古い証明書が有効期限に近づいているときに新しい証明書を要求する certmonger

接続する IdM クライアントの certmonger サービスから IdM CA サーバーに接続する矢印で ipa-getcert 要求経由で接続していることを示す図。IdM CA サーバーから Certmonger への矢印には、「HTTPS 証明書」のラベルが付いており、HTTPS 証明書が certmonger サービスに転送されていることが分かります。


15.4. certmonger が追跡する証明書要求の詳細を表示

certmonger サービスは、証明書要求を監視します。証明書要求が正常に署名されると、証明書が作成されます。certmonger は、生成される証明書を含む証明書要求を管理します。本セクションでは、certmonger が管理する特定の証明書要求の詳細を表示する方法を説明します。

手順

  • 証明書要求の指定方法が分からない場合は、特定の証明書要求のみの詳細を一覧表示します。たとえば、次を指定できます。

    • リクエスト ID
    • 証明書の場所
    • 証明書のニックネーム

      たとえば、要求 ID が 20190408143846 である証明書の詳細を表示するには、-v オプションを使用して、証明書のリクエストが失敗した場合にエラーの詳細をすべて表示します。

      # getcert list -i 20190408143846 -v
      Number of certificates and requests being tracked: 16.
      Request ID '20190408143846':
      	status: MONITORING
      	stuck: no
      	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt'
      	certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB'
      	CA: IPA
      	issuer: CN=Certificate Authority,O=IDM.EXAMPLE.COM
      	subject: CN=r8server.idm.example.com,O=IDM.EXAMPLE.COM
      	expires: 2021-04-08 16:38:47 CEST
      	dns: r8server.idm.example.com
      	principal name: ldap/server.idm.example.com@IDM.EXAMPLE.COM
      	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
      	eku: id-kp-serverAuth,id-kp-clientAuth
      	pre-save command:
      	post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IDM-EXAMPLE-COM
      	track: yes
      	auto-renew: yes

    この出力では、証明書に関する情報の一部が表示されます。以下に例を示します。

    • 証明書の場所 - 上記の例では、/etc/dirsrv/slapd-IDM-EXAMPLE-COM ディレクトリーの NSS データベースです。
    • 証明書のニックネーム - 上記の例では Server-Cert になります。
    • ピンを保存しているファイル - 上記の例では /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt になります。
    • 証明書の更新に使用される認証局 (CA) - 上記の例では IPA CA です。
    • 有効期限 - 上記の例では 2021-04-08 16:38:47 CEST になります。
    • 証明書のステータス - 上記の例の MONITORING 状態は、証明書が有効であり、追跡されていることを意味します。
    • post-save コマンド - 上記の例では、LDAP サービスの再起動です。
  • 証明書要求の指定方法が分からない場合は、certmonger が監視または取得しようとしているすべての証明書の詳細を一覧表示します。

    # getcert list

関連情報

  • man ページの getcert list を参照してください。

15.5. 証明書追跡の開始および停止

本セクションでは、getcert stop-tracking コマンドおよび getcert start-tracking コマンドを使用して証明書を監視する方法を説明します。この 2 つのコマンドは、certmonger サービスで利用できます。証明書追跡を有効にすると、Identity Management (IdM) 認証局 (CA) が発行する証明書を、別の IdM クライアントのマシンにインポートすると特に便利です。証明書の追跡を有効にすることは、次のプロビジョニングシナリオの最終ステップでもあります。

  1. IdM サーバーでは、存在していないシステムの証明書を作成する。
  2. 新しいシステムを作成する。
  3. 新しいシステムを IdM クライアントとして登録する。
  4. IdM クライアントの IdM サーバーから、証明書および鍵をインポートする。
  5. certmonger を使用して証明書の追跡を開始し、有効期限が切れる時に証明書を更新するようにする。

手順

  • 要求 ID が 20190408143846 の証明書の監視を無効にするには、次のコマンドを実行します。

    # getcert stop-tracking -i 20190408143846

    その他のオプションは、man ページの getcert stop-tracking を参照してください。

  • /tmp/some_cert.crt ファイルに保存されている証明書の監視を有効にするには、次のコマンドを実行します。秘密鍵が /tmp/some_key.key ファイルに保存されます。

    # getcert start-tracking -c IPA -f /tmp/some_cert.crt -k /tmp/some_key.key

    certmonger は、証明書を発行した CA タイプを自動的に特定できません。そのため、IdM CA が証明書を発行した場合は、getcert start-tracking コマンドに IPA 値を付けて -c オプションを追加します。-c オプションを追加しないと、certmonger が NEED_CA 状態になります。

    その他のオプションは、man ページの getcert start-tracking を参照してください。

注記

この 2 つのコマンドは証明書を操作しません。たとえば、getcert stop-tracking は、証明書を削除しなかったり、NSS データベースまたはファイルシステムから削除したりせず、監視する証明書の一覧から証明書を削除します。同様に、getcert start-tracking は、監視された証明書の一覧に証明書のみを追加します。

15.6. 証明書を手動で更新

証明書が失効日近くになると、certmonger デーモンは、認証局 (CA) ヘルパーを使用して更新コマンドを自動的に発行し、更新された証明書を取得し、以前の証明書を新しい証明書に置き換えます。

getcert resubmit コマンドを使用して、事前に証明書を手動で更新することもできます。これにより、SAN (Subject Alternative Name) を追加したりすると、証明書に含まれる情報を更新できます。

本セクションでは、証明書を手動で更新する方法を説明します。

手順

  • リクエスト ID が 20190408143846 の証明書を更新するには、次のコマンドを実行します。

    # getcert resubmit -i 20190408143846

    特定の証明書の要求 ID を取得するには、getcert list コマンドを使用します。詳細は、man ページの getcert list を参照してください。

15.7. certmonger が CA レプリカでの IdM 証明書の追跡を再開

この手順は、証明書の追跡が中断された後、certmonger が統合認証局で Identity Management (IdM) デプロイメントに不可欠な IdM システム証明書の追跡を再開する方法を説明します。中断は、システム証明書の更新中に IdM ホストがIdM から登録解除されたか、レプリケーショントポロジーが正しく機能しないことが原因である可能性があります。この手順では、certmonger が IdM サービス証明書 (HTTPLDAPPKINIT) の追跡を再開する方法も説明します。

前提条件

  • システム証明書の追跡を再開するホストは、IdM 認証局 (CA) でもある IdM サーバーですが、IdM CA 更新サーバーではありません。

手順

  1. サブシステムの CA 証明書の PIN を取得します。

    # grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
  2. サブシステムの CA 証明書に追跡を追加します。次のコマンドの [internal PIN] を、直前の手順で取得した PIN に置き換えます。

    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "caSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert -T caCACert "caSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "auditSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert -T caSignedLogCert "auditSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert -T caOCSPCert "ocspSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert -T caSubsystemCert "subsystemCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert -T caServerCert "Server-Cert cert-pki-ca"'
  3. 残りの IdM 証明書、HTTP 証明書、LDAP 証明書、IPA 更新エージェント 証明書、および PKINIT 証明書の追跡を追加します。

    # getcert start-tracking -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/idm.example.com-443-RSA -c IPA -C /usr/libexec/ipa/certmonger/restart_httpd -T caIPAserviceCert
    
    # getcert start-tracking -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM -n "Server-Cert" -c IPA -p /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt -C '/usr/libexec/ipa/certmonger/restart_dirsrv -T caIPAserviceCert "IDM-EXAMPLE-COM"'
    
    # getcert start-tracking -f /var/lib/ipa/ra-agent.pem -k /var/lib/ipa/ra-agent.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_ra_cert -T caSubsystemCert
    
    # getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -k /var/kerberos/krb5kdc/kdc.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_kdc_cert -T KDCs_PKINIT_Certs
  4. certmonger を再起動します。

    # systemctl restart certmonger
  5. certmonger の起動後 1 分待ってから、新しい証明書の状況を確認します。

    # getcert list

関連情報

第16章 RHEL システムロールを使用した証明書の要求

証明書の発行および更新システムのロールを使用して、証明書を発行および管理できます。

本章では、以下のトピックについて説明します。

16.1. 証明書の発行と更新システムのロール

証明書の発行および更新システムのロールを使用すると、Ansible Core を使用して TLS および SSL 証明書の発行と更新を管理できます。

ロールは certmonger を証明書プロバイダーとして使用し、自己署名証明書の発行と更新、および IdM 統合認証局 (CA) の使用を現時点でサポートしています。

証明書の発行と更新システムのロールを持つ AnsiblePlaybook で次の変数を使用できます。

certificate_wait
タスクが証明書を発行するまで待機するかどうかを指定します。
certificate_requests
発行する各証明書とそのパラメーターを表すには、次のコマンドを実行します。

関連情報

16.2. 証明書の発行および更新システムのロールを使用して、新しい自己署名証明書を要求する

証明書の発行と更新システムのロールを使用すると、Ansible Core を使用して自己署名証明書を発行できます。

このプロセスは、certmonger プロバイダーを使用し、getcert コマンドで証明書を要求します。

注記

デフォルトでは、certmonger は有効期限が切れる前に証明書の更新を自動的に試行します。これは、Ansible Playbook の auto_renew パラメーターを no に設定すると無効にできます。

前提条件

  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • Playbook を実行するシステムに rhel-system-roles パッケージがインストールされている。

    RHEL システムロールとその適用方法の詳細については、RHEL System Roles 入門を 参照してください。

手順

  1. オプション: inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. インベントリーファイルを開き、証明書を要求するホストを定義します。以下に例を示します。

    [webserver]
    server.idm.example.com
  3. Playbook ファイルを作成します (例: request-certificate.yml)。

    • webserver など、証明書を要求するホストを含むように hosts を設定します。
    • certificate_requests 変数を設定して以下を追加します。

      • name パラメーターを希望する証明書の名前 (mycert など) に設定します。
      • dns パラメーターを *.example.com などの証明書に含むドメインに設定します。
      • ca パラメーターを self-sign に設定します。
    • roles の下に rhel-system-roles.certificate ロールを設定します。

      以下は、この例の Playbook ファイルです。

      ---
      - hosts: webserver
      
        vars:
          certificate_requests:
            - name: mycert
              dns: "*.example.com"
              ca: self-sign
      
        roles:
          - rhel-system-roles.certificate
  4. ファイルを保存します。
  5. Playbook を実行します。

    $ ansible-playbook -i inventory.file request-certificate.yml

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.certificate/README.md ファイルを参照してください。
  • man ページの ansible-playbook(1) を参照してください。

16.3. 証明書の発行と更新システムのロールを使用して IdM CA に新しい証明書を要求する

証明書の発行および更新システムのロールを使用すると、統合認証局 (CA) を備えた IdM サーバーを使用しながら、anible-core を使用して証明書を発行できます。したがって、IdM を CA として使用する場合に、複数のシステムの証明書トラストチェーンを効率的かつ一貫して管理できます。

このプロセスは、certmonger プロバイダーを使用し、getcert コマンドで証明書を要求します。

注記

デフォルトでは、certmonger は有効期限が切れる前に証明書の更新を自動的に試行します。これは、Ansible Playbook の auto_renew パラメーターを no に設定すると無効にできます。

前提条件

  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • Playbook を実行するシステムに rhel-system-roles パッケージがインストールされている。

    RHEL システムロールとその適用方法の詳細については、RHEL System Roles 入門を 参照してください。

手順

  1. オプション: inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. インベントリーファイルを開き、証明書を要求するホストを定義します。以下に例を示します。

    [webserver]
    server.idm.example.com
  3. Playbook ファイルを作成します (例: request-certificate.yml)。

    • webserver など、証明書を要求するホストを含むように hosts を設定します。
    • certificate_requests 変数を設定して以下を追加します。

      • name パラメーターを希望する証明書の名前 (mycert など) に設定します。
      • dns パラメーターをドメインに設定し、証明書に追加します (例: www.example.com)。
      • principal パラメーターを設定し、Kerberos プリンシパルを指定します (例: HTTP/www.example.com@EXAMPLE.COM)。
      • ca パラメーターを ipa に設定します。
    • roles の下に rhel-system-roles.certificate ロールを設定します。

      以下は、この例の Playbook ファイルです。

      ---
      - hosts: webserver
        vars:
          certificate_requests:
            - name: mycert
              dns: www.example.com
              principal: HTTP/www.example.com@EXAMPLE.COM
              ca: ipa
      
        roles:
          - rhel-system-roles.certificate
  4. ファイルを保存します。
  5. Playbook を実行します。

    $ ansible-playbook -i inventory.file request-certificate.yml

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.certificate/README.md ファイルを参照してください。
  • man ページの ansible-playbook(1) を参照してください。

16.4. 証明書発行および更新システムのロールを使用して、証明書発行の前または後に実行するコマンドを指定する

Certificate System の発行と更新のロールを使用すると、Ansible Core を使用して、証明書の発行または更新の前後にコマンドを実行できます。

以下の例では、管理者が www.example.com の自己署名証明書を発行または更新する前に httpd サービスを停止し、後で再起動します。

注記

デフォルトでは、certmonger は有効期限が切れる前に証明書の更新を自動的に試行します。これは、Ansible Playbook の auto_renew パラメーターを no に設定すると無効にできます。

前提条件

  • Ansible Core パッケージがコントロールマシンにインストールされている。
  • Playbook を実行するシステムに rhel-system-roles パッケージがインストールされている。

    RHEL システムロールとその適用方法の詳細については、RHEL System Roles 入門を 参照してください。

手順

  1. オプション: inventory.file などのインベントリーファイルを作成します。

    $ touch inventory.file
  2. インベントリーファイルを開き、証明書を要求するホストを定義します。以下に例を示します。

    [webserver]
    server.idm.example.com
  3. Playbook ファイルを作成します (例: request-certificate.yml)。

    • webserver など、証明書を要求するホストを含むように hosts を設定します。
    • certificate_requests 変数を設定して以下を追加します。

      • name パラメーターを希望する証明書の名前 (mycert など) に設定します。
      • dns パラメーターをドメインに設定し、証明書に追加します (例: www.example.com)。
      • ca パラメーターを証明書を発行する際に使用する CA に設定します (例: self-sign)。
      • この証明書を発行または更新する前に、run_before パラメーターを実行するコマンドに設定します (例: systemctl stop httpd.service)。
      • この証明書を発行または更新した後に、run_after パラメーターを実行するコマンドに設定します (例: systemctl start httpd.service)。
    • roles の下に rhel-system-roles.certificate ロールを設定します。

      以下は、この例の Playbook ファイルです。

      ---
      - hosts: webserver
        vars:
          certificate_requests:
            - name: mycert
              dns: www.example.com
              ca: self-sign
              run_before: systemctl stop httpd.service
              run_after: systemctl start httpd.service
      
        roles:
          - rhel-system-roles.certificate
  4. ファイルを保存します。
  5. Playbook を実行します。

    $ ansible-playbook -i inventory.file request-certificate.yml

関連情報

  • /usr/share/ansible/roles/rhel-system-roles.certificate/README.md ファイルを参照してください。
  • man ページの ansible-playbook(1) を参照してください。

第17章 証明書のサブセットのみを信頼するアプリケーションの制限

Identity Management (IdM) インストールが統合証明書システム (CS) 認証局 (CA) で設定されている場合は、軽量のサブ CA を作成できます。作成するすべてのサブ CA は、証明書システムのプライマリー CAである ipa CA に従属します。

このコンテキストでの 軽量サブ CA は、特定の目的のために証明書を発行するサブ CA になります。たとえば、軽量のサブ CA では、仮想プライベートネットワーク (VPN) ゲートウェイや Web ブラウザーなどのサービスを設定して、sub-CA A が発行する証明書のみを受け入れることができます。sub-CA B が発行する証明書のみを受け入れるように他のサービスを設定すると、sub-CA A、プライマリー CA、ipa CA、およびこの 2 つ間の中間サブ CA が発行する証明書を受け付けないようにすることができます。

サブ CA の中間証明書を取り消すと、このサブ CA によって発行されたすべての証明書は、正しく設定されたクライアントによって自動的に無効と見なさ れます。ルート CA (ipa)、または別のサブ CA が直接発行するその他の証明書はすべて有効のままになります。

本セクションでは、Apache Web サーバーの例を使用して、アプリケーションが証明書のサブセットのみを信頼することを制限する方法を説明します。本セクションでは、IdM クライアントで実行している Web サーバーを、IdM サブ CA webserver-ca が発行する証明書を使用するように制限し、IdM サブ CA webclient-ca が発行するユーザー証明書を使用して、Web サーバーへの認証をユーザーに対して要求します。

必要となる手順は以下の通りです。

17.1. 軽量サブ CA の管理

本セクションでは、軽量の従属認証局 (サブ CA) を管理する方法を説明します。作成するすべてのサブ CA は、証明書システムのプライマリー CAである ipa CA に従属します。サブ CA を無効にしたり、削除したりすることもできます。

注記
  • サブ CA を削除すると、そのサブ CA の失効確認は機能しなくなります。notAfter の有効期限が近づいていて、そのサブ CA が発行した証明書がなくなった場合に限り、サブ CA を削除してください。
  • サブ CA が発行した期限切れではない証明書がまだ存在する場合に限り、サブ CA を無効にしてください。サブ CA により発行された証明書がすべて期限切れになると、そのサブ CA を削除できます。
  • IdM CA を無効にしたり、削除したりすることはできません。

サブ CA の管理の詳細は、次を参照してください。

17.1.1. IdM WebUI からのサブ CA の作成

この手順では、IdM WebUI を使用して、webserver-ca および webclient-ca という名前の新しいサブ CA を作成する方法を説明します。

前提条件

  • 管理者の認証情報を取得していることを確認している。

手順

  1. Authentication メニューで、Certificates をクリックします。
  2. Certificate Authorities を選択し、Add をクリックします。
  3. webserver-ca sub-CA の名前を入力します。Subject DN フィールドに Subject DN (例: CN=WEBSERVER,O=IDM.EXAMPLE.COM) を入力します。サブジェクト DN は、IdM CA インフラストラクチャー内で一意である必要があります。
  4. webclient-ca sub-CA の名前を入力します。Subject DN CN=WEBCLIENT,O=IDM.EXAMPLE.COM を Subject DN フィールドに入力します。
  5. コマンドラインインターフェースで、ipa-certupdate コマンドを実行して、webserver-ca サブ CA 証明書および webclient-ca サブ CA 証明書の certmonger 追跡リクエストを作成します。

    [root@ipaserver ~]# ipa-certupdate
    重要

    サブ CA の作成後に ipa-certupdate コマンドを実行しておかないと、サブ CA 証明書の有効期限が切れたときに、エンドエンティティー証明書の有効期限が切れていなくても、サブ CA が発行したエンドエンティティー証明書は無効と見なされます。

検証

  • 新しいサブ CA の署名証明書が IdM データベースに追加されたことを確認します。

    [root@ipaserver ~]# certutil -d /etc/pki/pki-tomcat/alias/ -L
    
    Certificate Nickname                      Trust Attributes
                                              SSL,S/MIME,JAR/XPI
    
    caSigningCert cert-pki-ca                 CTu,Cu,Cu
    Server-Cert cert-pki-ca                   u,u,u
    auditSigningCert cert-pki-ca              u,u,Pu
    caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u
    ocspSigningCert cert-pki-ca               u,u,u
    subsystemCert cert-pki-ca                 u,u,u
    注記

    新しいサブ CA 証明書は、証明書システムインスタンスがインストールされているすべてのレプリカに自動的に転送されます。

17.1.2. IdM WebUI からのサブ CA の削除

この手順では、IdM WebUI で軽量のサブ CA を削除する方法を説明します。

注記
  • サブ CA を削除すると、そのサブ CA の失効確認は機能しなくなります。notAfter の有効期限が近づいていて、そのサブ CA が発行した証明書がなくなった場合に限り、サブ CA を削除してください。
  • サブ CA が発行した期限切れではない証明書がまだ存在する場合に限り、サブ CA を無効にしてください。サブ CA により発行された証明書がすべて期限切れになると、そのサブ CA を削除できます。
  • IdM CA を無効にしたり、削除したりすることはできません。

前提条件

手順

  1. IdM WebUI で、Authentication タブを開き、Certificates サブタブを選択します。
  2. Certificate Authoritiesを選択します。
  3. 削除するサブ CA を選択し、Delete をクリックします。

    図17.1 IdM Web UI でのサブ CA の削除

    認証局とその下位の認証局を追加および削除できる "Certificate Authorities" 画面のスクリーンショット。
  4. Delete をクリックして、確定します。

サブ CA が Certificate Authorities の一覧から削除されます。

17.1.3. IdM CLI からのサブ CA の作成

この手順では、IdM の CLI を使用して、webserver-ca および webclient-ca という名前の新しいサブ CA を作成する方法を説明します。

前提条件

  • 管理者の認証情報を取得していることを確認している。
  • CA サーバーである IdM サーバーにログインしている。

手順

  1. ipa ca-add コマンドを入力し、サブ CA webserver-ca およびそのサブジェクト識別名 (DN) の名前を指定します。

    [root@ipaserver ~]# ipa ca-add webserver-ca --subject="CN=WEBSERVER,O=IDM.EXAMPLE.COM"
    -------------------
    Created CA "webserver-ca"
    -------------------
      Name: webserver-ca
      Authority ID: ba83f324-5e50-4114-b109-acca05d6f1dc
      Subject DN: CN=WEBSERVER,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM
    名前
    CA の名前
    認証局 ID
    CA 用に自動的に作成される個別 ID。
    発行先 DN
    サブジェクト識別名 (DN)サブジェクト DN は、IdM CA インフラストラクチャーで一意である必要があります。
    発行者 DN
    サブ CA 証明書を発行した親 CA。すべてのサブ CA は、IdM のルート CA の子として作成されます。
  2. Web クライアントに証明書を発行するサブ CA webclient-ca を作成します。

    [root@ipaserver ~]# ipa ca-add webclient-ca --subject="CN=WEBCLIENT,O=IDM.EXAMPLE.COM"
    -------------------
    Created CA "webclient-ca"
    -------------------
      Name: webclient-ca
      Authority ID: 8a479f3a-0454-4a4d-8ade-fd3b5a54ab2e
      Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM
  3. ipa-certupdate コマンドを実行して、webserver-ca および webclient-ca のサブ CA 証明書の certmonger 追跡リクエストを作成します。

    [root@ipaserver ~]# ipa-certupdate
    重要

    サブ CA の作成後に ipa-certupdate コマンドを実行し忘れ、サブ CA 証明書が期限切れになった場合、そのサブ CA が発行したエンドエンティティー証明書は、エンドエンティティー証明書の有効期限が切れていなくても無効と見なされます。

検証手順

  • 新しいサブ CA の署名証明書が IdM データベースに追加されたことを確認します。

    [root@ipaserver ~]# certutil -d /etc/pki/pki-tomcat/alias/ -L
    
    Certificate Nickname                      Trust Attributes
                                              SSL,S/MIME,JAR/XPI
    
    caSigningCert cert-pki-ca                 CTu,Cu,Cu
    Server-Cert cert-pki-ca                   u,u,u
    auditSigningCert cert-pki-ca              u,u,Pu
    caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u
    ocspSigningCert cert-pki-ca               u,u,u
    subsystemCert cert-pki-ca                 u,u,u
    注記

    新しいサブ CA 証明書は、証明書システムインスタンスがインストールされているすべてのレプリカに自動的に転送されます。

17.1.4. IdM CLI からのサブ CA の無効化

この手順では、IdM CLI からサブ CA を無効にする方法を説明します。サブ CA が発行した期限切れでない証明書が依然として存在する場合は、証明書を削除しないでください。ただし、無効にすることはできます。サブ CA を削除すると、そのサブ CA に対する取消しの確認が機能しなくなります。

前提条件

  • 管理者の認証情報を取得していることを確認している。

手順

  1. ipa ca-find コマンドを実行して、削除するサブ CA の名前を確認します。

    [root@ipaserver ~]# ipa ca-find
    -------------
    3 CAs matched
    -------------
      Name: ipa
      Description: IPA CA
      Authority ID: 5195deaf-3b61-4aab-b608-317aff38497c
      Subject DN: CN=Certificate Authority,O=IPA.TEST
      Issuer DN: CN=Certificate Authority,O=IPA.TEST
    
      Name: webclient-ca
      Authority ID: 605a472c-9c6e-425e-b959-f1955209b092
      Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IPA.TEST
    
     Name: webserver-ca
      Authority ID: 02d537f9-c178-4433-98ea-53aa92126fc3
      Subject DN: CN=WEBSERVER,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IPA.TEST
    ----------------------------
    Number of entries returned 3
    ----------------------------
  2. ipa ca-disableコマンドを実行して、サブ CA (この例では webserver-ca) を無効にします。

    ipa ca-disable webserver-ca
    --------------------------
    Disabled CA "webserver-ca"
    --------------------------

17.1.5. IdM CLI からのサブ CA の削除

この手順では、IdM CLI から軽量のサブ CA を削除する方法を説明します。

注記
  • サブ CA を削除すると、そのサブ CA の失効確認は機能しなくなります。notAfter の有効期限が近づいていて、そのサブ CA が発行した証明書がなくなった場合に限り、サブ CA を削除してください。
  • サブ CA が発行した期限切れではない証明書がまだ存在する場合に限り、サブ CA を無効にしてください。サブ CA により発行された証明書がすべて期限切れになると、そのサブ CA を削除できます。
  • IdM CA を無効にしたり、削除したりすることはできません。

前提条件

  • 管理者の認証情報を取得していることを確認している。

手順

  1. サブ CA および CA の一覧を表示するには、ipa ca-find コマンドを実行します。

    # ipa ca-find
    -------------
    3 CAs matched
    -------------
      Name: ipa
      Description: IPA CA
      Authority ID: 5195deaf-3b61-4aab-b608-317aff38497c
      Subject DN: CN=Certificate Authority,O=IPA.TEST
      Issuer DN: CN=Certificate Authority,O=IPA.TEST
    
      Name: webclient-ca
      Authority ID: 605a472c-9c6e-425e-b959-f1955209b092
      Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IPA.TEST
    
     Name: webserver-ca
      Authority ID: 02d537f9-c178-4433-98ea-53aa92126fc3
      Subject DN: CN=WEBSERVER,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IPA.TEST
    ----------------------------
    Number of entries returned 3
    ----------------------------
  2. ipa ca-disableコマンドを実行して、サブ CA (この例では webserver-ca) を無効にします。

    # ipa ca-disable webserver-ca
    --------------------------
    Disabled CA "webserver-ca"
    --------------------------
  3. サブ CA (この例ではwebserver-ca) を削除します。

    # ipa ca-del webserver-ca
    -------------------------
    Deleted CA "webserver-ca"
    -------------------------

検証

  • ipa ca-find を実行して、CA およびサブ CA の一覧を表示します。webserver-caが一覧に表示されなくなりました。

    # ipa ca-find
    -------------
    2 CAs matched
    -------------
      Name: ipa
      Description: IPA CA
      Authority ID: 5195deaf-3b61-4aab-b608-317aff38497c
      Subject DN: CN=Certificate Authority,O=IPA.TEST
      Issuer DN: CN=Certificate Authority,O=IPA.TEST
    
      Name: webclient-ca
      Authority ID: 605a472c-9c6e-425e-b959-f1955209b092
      Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IPA.TEST
    ----------------------------
    Number of entries returned 2
    ----------------------------

17.2. IdM WebUI からのサブ CA 証明書のダウンロード

前提条件

  • IdM 管理者の認証情報を取得していることを確認している。

手順

  1. Authentication メニューで、Certificates > Certificates をクリックします。

    図17.2 証明書一覧に含まれるサブ CA 証明書

    2 つの証明書を示す表のスクリーンショット。
  2. サブ CA 証明書のシリアル番号をクリックして、証明書情報ページを開きます。
  3. 証明書情報ページで、Actions > Download をクリックします。
  4. CLI で、サブ CA 証明書を /etc/pki/tls/private/ ディレクトリーに移動します。

    # mv path/to/the/downloaded/certificate /etc/pki/tls/private/sub-ca.crt

17.3. Web サーバーおよびクライアント認証用の CA ACL の作成

認証局のアクセス制御リスト (CA ACL) ルールは、どのユーザー、サービス、またはホストにどのプロファイルを使用して証明書を発行するかを定義します。CA ACL は、プロファイル、プリンシパル、およびグループを関連付けることで、特定のプロファイルを使用した証明書をプリンシパルまたはグループが要求できるようにします。

たとえば、管理者は CA ACL を使用して、ロンドンのオフィスから作業する社員向けのプロファイルの使用を、そのオフィスに関連するグループのメンバーであるユーザーに限定することができます。

17.3.1. IdM CLI での CA ACL の表示

本セクションでは、IdM デプロイメントで利用可能な認証局のアクセス制御リスト (CA ACL) の一覧と、特定の CA ACL の詳細を表示します。

手順

  1. IdM 環境内のすべての CA ACL を表示するには、ipa caacl-find コマンドを入力します。

    $ ipa caacl-find
    -----------------
    1 CA ACL matched
    -----------------
      ACL name: hosts_services_caIPAserviceCert
      Enabled: TRUE
  2. CA ACL の詳細を表示するには、ipa caacl-show コマンドを入力して、CA ACL 名を指定します。たとえば、CA ACL hosts_services_caIPAserviceCert の詳細を表示するには、次のコマンドを実行します。

    $ ipa caacl-show hosts_services_caIPAserviceCert
      ACL name: hosts_services_caIPAserviceCert
      Enabled: TRUE
      Host category: all
      Service category: all
      CAs: ipa
      Profiles: caIPAserviceCert
      Users: admin

17.3.2. webserver-ca で発行される証明書を使用して Web クライアントを認証する Web サーバー用の CA ACL の作成

本セクションでは、システム管理者が HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM サービスの証明書を要求する際に、サブ CA webserver-ca および caIPAserviceCert プロファイルを使用するように要求する CA ACL を作成する方法を説明します。ユーザーが別のサブ CA またはプロファイルの証明書を要求すると、その要求は失敗します。唯一の例外は、有効になっていて一致する別の CA ACL がある場合です。利用可能な CA ACL を表示するには、「IdM CLI で CA ACL の表示」を参照してください。

前提条件

  • HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM サービスが IdM の一部であることを確認します。
  • IdM 管理者の認証情報を取得していることを確認している。

手順

  1. ipa caacl コマンドを使用して CA ACL を作成し、その名前を指定します。

    $ ipa caacl-add TLS_web_server_authentication
    --------------------------------------------
    Added CA ACL "TLS_web_server_authentication"
    --------------------------------------------
      ACL name: TLS_web_server_authentication
      Enabled: TRUE
  2. ipa caacl-mod コマンドを使用して CA ACL を変更し、CA ACL の説明を指定します。

    $ ipa caacl-mod TLS_web_server_authentication --desc="CAACL for web servers authenticating to web clients using certificates issued by webserver-ca"
    -----------------------------------------------
    Modified CA ACL "TLS_web_server_authentication"
    -----------------------------------------------
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
  3. webserver-ca sub-CA を CA ACL に追加します。

    $ ipa caacl-add-ca TLS_web_server_authentication --ca=webserver-ca
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
      CAs: webserver-ca
    -------------------------
    Number of members added 1
    -------------------------
  4. ipa caacl-add-service を使用して、プリンシパルが証明書をリクエストできるサービスを指定します。

    $ ipa caacl-add-service TLS_web_server_authentication --service=HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
      CAs: webserver-ca
      Services: HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM
    -------------------------
    Number of members added 1
    -------------------------
  5. ipa caacl-add-profile コマンドを使用して、要求された証明書の証明書プロファイルを指定します。

    $ ipa caacl-add-profile TLS_web_server_authentication --certprofiles=caIPAserviceCert
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
      CAs: webserver-ca
      Profiles: caIPAserviceCert
      Services: HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM
    -------------------------
    Number of members added 1
    -------------------------

    新たに作成した CA ACL を直接使用できます。これは、デフォルトで作成後に有効になります。

注記

CA ACL の特徴は、特定のプリンシパルまたはグループから送信される要求に対して許可される CA とプロファイルの組み合わせを指定することです。CA ACL は、証明書の検証や信頼には影響を与えません。発行された証明書の使用方法には影響しません。

17.3.3. webclient-ca が発行する証明書を使用して Web サーバーに対して認証するユーザーの Web ブラウザー用に CA ACL を作成

本セクションでは、システム管理者が証明書を要求する際に サブ CA webclient-caIECUserRoles プロファイルを使用する必要がある CA ACL を作成する方法を説明します。ユーザーが別のサブ CA またはプロファイルの証明書を要求すると、その要求は失敗します。唯一の例外は、有効になっていて一致する別の CA ACL がある場合です。利用可能な CA ACL を表示するには、「IdM CLI で CA ACL の表示」を参照してください。

前提条件

  • IdM 管理者の認証情報を取得していることを確認している。

手順

  1. ipa caacl コマンドを使用して CA ACL を作成し、その名前を指定します。

    $ ipa caacl-add TLS_web_client_authentication
    --------------------------------------------
    Added CA ACL "TLS_web_client_authentication"
    --------------------------------------------
      ACL name: TLS_web_client_authentication
      Enabled: TRUE
  2. ipa caacl-mod コマンドを使用して CA ACL を変更し、CA ACL の説明を指定します。

    $ ipa caacl-mod TLS_web_client_authentication --desc="CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca"
    -----------------------------------------------
    Modified CA ACL "TLS_web_client_authentication"
    -----------------------------------------------
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
  3. webclient-ca sub-CA を CA ACL に追加します。

    $ ipa caacl-add-ca TLS_web_client_authentication --ca=webclient-ca
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
      CAs: webclient-ca
    -------------------------
    Number of members added 1
    -------------------------
  4. ipa caacl-add-profile コマンドを使用して、要求された証明書の証明書プロファイルを指定します。

    $ ipa caacl-add-profile TLS_web_client_authentication --certprofiles=IECUserRoles
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
      CAs: webclient-ca
      Profiles: IECUserRoles
    -------------------------
    Number of members added 1
    -------------------------
  5. ipa caacl-mod コマンドを使用して CA ACL を変更し、CA ACL がすべての IdM ユーザーに適用されるように指定します。

    $ ipa caacl-mod TLS_web_client_authentication --usercat=all
    -----------------------------------------------
    Modified CA ACL "TLS_web_client_authentication"
    -----------------------------------------------
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
      User category: all
      CAs: webclient-ca
      Profiles: IECUserRoles

    新たに作成した CA ACL を直接使用できます。これは、デフォルトで作成後に有効になります。

注記

CA ACL の特徴は、特定のプリンシパルまたはグループから送信される要求に対して許可される CA とプロファイルの組み合わせを指定することです。CA ACL は、証明書の検証や信頼には影響を与えません。発行された証明書の使用方法には影響しません。

17.4. certmonger を使用したサービスの IdM 証明書の取得

ブラウザーと、IdM クライアントで実行している Web サービスとの間の通信が安全で暗号化されていることを確認するには、TLS 証明書を使用します。サブ CA webserver-ca が発行する証明書を信頼し、その他の IdM サブ CA は信頼するように Web ブラウザーを制限する場合は、サブ CA webserver-ca から Web サービスの TLS 証明書を取得します。

本セクションでは、certmonger を使用して、IdM クライアントで実行するサービス (HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM) の IdM 証明書を取得する方法を説明します。

certmonger 使用して証明書を自動的に要求するということは、certmonger 更新の期限が切れたときに証明書を管理および更新することを意味します。

certmonger がサービス証明書を要求したときに発生する内容を視覚的に表示するには、「サービス証明書を要求する certmonger の通信フロー」 を参照してください。

前提条件

  • Web サーバーが、IdM クライアントとして登録されている。
  • 手順を実行している IdM クライアントへのルートアクセス権限がある。
  • 証明書を要求しているサービスは、前もって IdM に用意する必要はない。

手順

  1. HTTP サービスが稼働している IdM クライアント my_company.idm.example.com で、以下を指定する HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM プリンシパルに対応するサービスの証明書を要求します。

    • 証明書は、ローカルの /etc/pki/tls/certs/httpd.pem ファイルに保存されます。
    • 秘密鍵は、ローカルの /etc/pki/tls/private/httpd.key ファイルに保存されます。
    • サブ CA webserver-ca は、発行している認証局になります。
    • SubjectAltName の extensionRequest が、my_company.idm.example.com の DNS 名の署名要求に追加されます。

      # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -X webserver-ca -C "systemctl restart httpd"
      New signing request "20190604065735" added.

      上記のコマンドでは、以下のようになります。

      • ipa-getcert request コマンドは、証明書が IdM CA から取得することを示しています。ipa-getcert request コマンドは、getcert request -c IPA のショートカットです。
      • -g オプションは、生成先のキーのサイズ (設定されていない場合) を指定します。
      • -D オプションは、要求に追加する DNS 値 SubjectAltName を指定します。
      • -X オプションは、証明書の発行者が、ipa ではなく webserver-ca でなければならないことを指定します。
      • -C オプションは、証明書の取得後に httpd サービスを再起動するように certmonger に指示します。
      • 特定のプロファイルで証明書を発行するように指定する場合は、-T オプションを使用します。
  2. 必要に応じて、リクエストの状況を確認するには、次のコマンドを実行します。

    # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
    Number of certificates and requests being tracked: 3.
    Request ID '20190604065735':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
        CA: IPA
        issuer: CN=WEBSERVER,O=IDM.EXAMPLE.COM
    
    [...]

    この出力は、要求が MONITORING 状況であることを表しています。これは、証明書が取得されていることを示しています。キーペアと証明書の場所は、要求された場所です。

17.5. サービス証明書を要求する certmonger の通信フロー

本セクションの図では、各ステージで、certmonger が Identity Management (IdM) 認証局 (CA) サーバーからサービス証明書を要求したときに何が起こるかを示しています。シーケンスは次の図で構成されています。

この図では、サブ CA webserver-ca は汎用 IdM CA サーバー によって表されます。

暗号化されていない通信 は、初期状態を示しています。HTTPS 証明書がないと、Web サーバーとブラウザー間の通信は暗号化されません。

図17.3 暗号化されていない通信

Apache Web サーバーおよび certmonger サービスを実行している IdM クライアントを表示する図。ブラウザーと Apache Web サーバーの間には、暗号化されていない HTTP 接続で接続していることを示す矢印があります。また、certmonger サービスから IdM CA サーバーへは、アクティブでない接続があります。


サービス証明書を要求する certmonger は、システム管理者が certmonger を使用して Apache Web サーバーの HTTPS 証明書を手動で要求していることを示しています。Web サーバー証明書を要求する場合、certmonger は CA と直接対話しないことに注意してください。IdM 経由でプロキシーが設定されます。

図17.4 サービス証明書を要求する certmonger

IdM クライアントと IdM CA サーバーの certmonger サービス間の矢印で ipa-getcert 要求経由で接続していることを示す図。


サービス証明書を発行する IdM CA は、Web サーバーで HTTPS 証明書を発行する IdM CA を示しています。

図17.5 サービス証明書を発行する IdM CA

IdM クライアントの IdM CA サーバーと certmonger サービス間の矢印で、HTTPS 証明書を接続および送信していることを示す図。


Certmonger によるサービス証明書の適用 は、certmonger が HTTPS 証明書を Id M クライアントの適切な場所に配置し、指示された場合は httpd サービスを再起動することを示します。その後、Apache サーバーは HTTPS 証明書を使用して、Apache サーバーとブラウザー間のトラフィックを暗号化します。

図17.6 Certmonger によるサービス証明書の適用

HTTPS 証明書が Apache Web サーバーに割り当てられている画像と、certmonger サービスに割り当てられている画像を示す図。ブラウザーと Apache Web サーバーの間には、暗号化されている HTTPS 接続でつながっていることを示す矢印があります。certmonger サービスと IdM CA サーバー間の接続はアクティブではありません。


古い証明書が有効期限に近づいているときに新しい証明書を要求する certmonger は、証明書の有効期限が切れる前に、certmonger が Id MCA からのサービス証明書の更新を自動的に要求していることを示しています。IdM CA は、新しい証明書を発行します。

図17.7 古い証明書が有効期限に近づいているときに新しい証明書を要求する certmonger

接続する IdM クライアントの certmonger サービスから IdM CA サーバーに接続する矢印で ipa-getcert 要求経由で接続していることを示す図。IdM CA サーバーから Certmonger への矢印には、「HTTPS 証明書」のラベルが付いており、HTTPS 証明書が certmonger サービスに転送されていることが分かります。


17.6. シングルインスタンスの Apache HTTP サーバーの設定

本セクションでは、静的 HTML コンテンツを提供するために 1 つのインスタンスの Apache HTTP Server を設定する方法を説明します。

Web サーバーが、サーバーに関連付けられたすべてのドメインに対して同じコンテンツを提供する必要がある場合は、このセクションの手順に従います。異なるドメインに異なるコンテンツを提供する場合は、名前ベースの仮想ホストを設定します。詳細は「Apache 名ベースの仮想ホストの設定」を参照してください。

手順

  1. httpd パッケージをインストールします。

    # dnf install httpd
  2. ローカルのファイアウォールで TCP ポート 80 を開きます。

    # firewall-cmd --permanent --add-port=80/tcp
    # firewall-cmd --reload
  3. httpd サービスを有効にして起動します。

    # systemctl enable --now httpd
  4. 必要に応じて、HTML ファイルを /var/www/html/ ディレクトリーに追加します。

    注記

    /var/www/html/ にコンテンツを追加する場合は、デフォルトで httpd を実行するユーザーがファイルとディレクトリーを読み取る必要があります。コンテンツの所有者は、root ユーザーおよび グループ、または管理者別のユーザーまたはグループのいずれかになります。コンテンツの所有者が root ユーザーおよび root ユーザーグループである場合は、他のユーザーがファイルを読み取る必要があります。すべてのファイルとディレクトリーの SELinux コンテキストは である必要があります。これはデフォルトで /var/www ディレクトリー内のすべてのコンテンツに適用されます。

検証手順

  • Web ブラウザーで http://my_company.idm.example.com/ または http://server_IP/ に接続します。

    /var/www/html/ ディレクトリーが空であるか、index.html またはindex.htm ファイルが含まれていない場合は、Apache が Red Hat Enterprise Linux Test Page を表示します。/var/www/html/ に異なる名前の HTML ファイルが含まれている場合は、http://server_IP/example.htmlhttp://my_company.idm.example.com/example.html などの URL をファイルに指定することで、そのファイルを読み込むことができます。

関連情報

17.7. Apache HTTP Server への TLS 暗号化の追加

本セクションでは、idm.example.com ドメイン向けに、Apache HTTP Server my_company.idm.example.com で TLS 暗号化を有効にする方法を説明します。

前提条件

  • Apache HTTP Server my_company.idm.example.com をインストールして、実行している。
  • 「certmonger を使用したサービスの IdM 証明書の取得」 の説明に従って、サブ CA webserver-ca から TLS 証明書を取得し、/etc/pki/tls/certs/httpd.pem ファイルに保存している。別のパスを使用する場合は、この手順で対応する手順を調整します。
  • 対応する秘密鍵は、/etc/pki/tls/private/httpd.key ファイルに保存されます。別のパスを使用する場合は、この手順で対応する手順を調整します。
  • CA 証明書 webserver-ca は、/etc/pki/tls/private/sub-ca.crt ファイルに保存されます。別のパスを使用する場合は、この手順で対応する手順を調整します。
  • クライアントおよび Web サーバー my_company.idm.example.com は、サーバーのホスト名を Web サーバーのホスト名に解決します。

手順

  1. mod_ssl パッケージをインストールします。

    # dnf install mod_ssl
  2. /etc/httpd/conf.d/ssl.conf ファイルを編集し、以下の設定を <VirtualHost _default_:443> ディレクティブに追加します。

    1. サーバー名を設定します。

      ServerName my_company.idm.example.com
      重要

      サーバー名は、証明書の Common Name フィールドに設定されているエントリーと一致している必要があります。

    2. 必要に応じて、Subject Alt Names (SAN) フィールドに追加のホスト名が含まれる場合、これらのホスト名にも TLS 暗号化を提供するように mod_ssl を設定できます。これを設定するには、ServerAliases パラメーターと対応する名前を追加します。

      ServerAlias www.my_company.idm.example.com server.my_company.idm.example.com
    3. 秘密鍵、サーバー証明書、および CA 証明書へのパスを設定します。

      SSLCertificateKeyFile "/etc/pki/tls/private/httpd.key"
      SSLCertificateFile "/etc/pki/tls/certs/httpd.pem"
      SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"
  3. セキュリティー上の理由から、root ユーザーのみが秘密鍵ファイルにアクセスできるように設定します。

    # chown root:root /etc/pki/tls/private/httpd.key
    # chmod 600 //etc/pki/tls/private/httpd.key
    警告

    秘密鍵に権限のないユーザーがアクセスした場合は、証明書を取り消し、新しい秘密鍵を作成し、新しい証明書を要求します。そうでない場合は、TLS 接続が安全ではなくなります。

  4. ローカルのファイアウォールでポート 443 を開きます。

    # firewall-cmd --permanent --add-port=443/tcp
    # firewall-cmd --reload
  5. httpd サービスを再起動します。

    # systemctl restart httpd
    注記

    パスワードで秘密鍵ファイルを保護した場合は、httpd サービスの起動時に毎回このパスワードを入力する必要があります。

    • ブラウザーを使用して https://my_company.idm.example.com に接続します。

関連情報

17.8. Apache HTTP サーバーでサポートされる TLS プロトコルバージョンの設定

デフォルトでは、RHEL の Apache HTTP Server は、最新のブラウザーにも互換性のある安全なデフォルト値を定義するシステム全体の暗号化ポリシーを使用します。たとえば、DEFAULT ポリシーは、apache で TLSv1.2 プロトコルバージョンおよび TLSv1.3 プロトコルバージョンのみが有効になっていることを定義します。

本セクションでは、Apache HTTP Server my_company.idm.example.com が対応する TLS プロトコルのバージョンを手動で設定する方法を説明します。たとえば、環境が特定の TLS プロトコルバージョンのみを有効にする必要がある場合には、以下の手順に従います。

  • お使いの環境で、クライアントが弱い TLS1 (TLSv1.0) プロトコルまたは TLS1.1 プロトコルも使用できるようにする必要がある場合は、
  • Apache が TLSv1.2 プロトコルまたは TLSv1.3 プロトコルのみに対応するように設定する場合。

前提条件

手順

  1. /etc/httpd/conf/httpd.conf ファイルを編集し、TLS プロトコルバージョンを設定する <VirtualHost> ディレクティブに以下の設定を追加します。たとえば、TLSv1.3 プロトコルのみを有効にするには、以下を実行します。

    SSLProtocol -All TLSv1.3
  2. httpd サービスを再起動します。

    # systemctl restart httpd

検証手順

  1. 以下のコマンドを使用して、サーバーが TLSv1.3 に対応していることを確認します。

    # openssl s_client -connect example.com:443 -tls1_3
  2. 以下のコマンドを使用して、サーバーが TLSv1.2 に対応していないことを確認します。

    # openssl s_client -connect example.com:443 -tls1_2

    サーバーがプロトコルに対応していない場合、このコマンドは以下のエラーを返します。

    140111600609088:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1543:SSL alert number 70
  3. 必要に応じて、他の TLS プロトコルバージョンのコマンドを繰り返し実行します。

関連情報

17.9. Apache HTTP サーバーで対応している暗号の設定

デフォルトでは、Apache HTTP サーバーは、安全なデフォルト値を定義するシステム全体の暗号化ポリシーを使用します。これは、最近のブラウザーとも互換性があります。システム全体の暗号化が許可する暗号化の一覧は、/etc/crypto-policies/back-ends/openssl.config ファイルを参照してください。

本セクションでは、Apache HTTP サーバー my_company.idm.example.com が対応する暗号を手動で設定する方法を説明します。お使いの環境で特定の暗号が必要な場合は、手順に従います。

前提条件

手順

  1. /etc/httpd/conf/httpd.conf ファイルを編集し、SSLCipherSuite パラメーターを、TLS 暗号を設定する <VirtualHost> ディレクティブに追加します。

    SSLCipherSuite "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!SHA1:!SHA256"

    この例では、EECDH+AESGCMEDH+AESGCMAES256+EECDH、および AES256+EDH 暗号のみを有効にし、SHA1 および SHA256 メッセージ認証コード (MAC) を使用するすべての暗号を無効にします。

  2. httpd サービスを再起動します。

    # systemctl restart httpd

検証手順

  1. Apache HTTP Server が対応するする暗号化のリストを表示するには、以下を行います。

    1. nmap パッケージをインストールします。

      # dnf install nmap
    2. nmap ユーティリティーを使用して、対応している暗号を表示します。

      # nmap --script ssl-enum-ciphers -p 443 example.com
      ...
      PORT    STATE SERVICE
      443/tcp open  https
      | ssl-enum-ciphers:
      |   TLSv1.2:
      |     ciphers:
      |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
      |       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
      |       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
      ...

関連情報

17.10. TLS クライアント証明書認証の設定

クライアント証明書認証により、管理者は、証明書を使用して認証したユーザーのみが Web サーバー my_company.idm.example.com のリソースにアクセスできます。本セクションでは、/var/www/html/Example/ ディレクトリーにクライアント証明書認証を設定する方法を説明します。

重要

Apache サーバー my_company.idm.example.com が TLS 1.3 プロトコルを使用する場合は、一部のクライアントに追加の設定が必要です。たとえば、Firefox で、about:config メニューの security.tls.enable_post_handshake_auth パラメーターを true に設定します。詳細は、「Transport Layer Security version 1.3 in Red Hat Enterprise Linux 8」を参照してください。

前提条件

手順

  1. /etc/httpd/conf/httpd.conf ファイルを編集し、以下の設定をクライアント認証を設定する <VirtualHost> ディレクティブに追加します。

    <Directory "/var/www/html/Example/">
      SSLVerifyClient require
    </Directory>

    SSLVerifyClient require の設定では、/var/www/html/Example/ ディレクトリーのコンテンツにクライアントがアクセスする前に、サーバーがクライアント証明書を正常に検証する必要があることを定義します。

  2. httpd サービスを再起動します。

    # systemctl restart httpd

検証手順

  1. curl ユーティリティーを使用して、クライアント認証なしで URL https://my_company.idm.example.com/Example/ にアクセスします。

    $ curl https://my_company.idm.example.com/Example/
    curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 **alert certificate required**, errno 0

    このエラーは、Web サーバー my_company.idm.example.com にクライアント証明書認証が必要であることを示しています。

  2. クライアントの秘密鍵と証明書、および CA 証明書を curl に渡して、クライアント認証で同じ URL にアクセスします。

    $ curl --cacert ca.crt --key client.key --cert client.crt https://my_company.idm.example.com/Example/

    要求に成功すると、curl/var/www/html/Example/ ディレクトリーに保存されている index.html ファイルを表示します。

関連情報

17.11. 新しいユーザー証明書を要求し、クライアントにエクスポート

Identity Management (IdM) 管理者として、IdM クライアントで実行している Web サーバーを設定し、Web ブラウザーを使用してサーバーにアクセスし、特定の IdM サブ CA が発行する証明書で認証するように要求できます。本セクションでは、特定の IdM サブ CA からユーザー証明書を要求し、証明書と対応する秘密鍵を、ユーザーが Web ブラウザーを使用して Web サーバーにアクセスするホストにエクスポートします。その後、ブラウザーに証明書と秘密鍵をインポート します。

手順

  1. 必要に応じて、新しいディレクトリー (例: ~/certdb/) を作成し、証明書の一時データベースを作成します。要求されたら、NSS 証明書の DB パスワードを作成し、後続の手順で生成される証明書への鍵を暗号化します。

    # mkdir ~/certdb/
    # certutil -N -d ~/certdb/
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
  2. 証明書署名要求 (CSR) を作成し、その出力をファイルにリダイレクトします。たとえば、IDM.EXAMPLE.COM レルムの idm_user ユーザーの 4096 ビット証明書に対して、certificate_request.csr という名前の CSR を作成する場合は、判別を簡単にするために、証明書の秘密鍵のニックネームを idm_user に設定し、発行先を CN=idm_user,O=IDM.EXAMPLE.COM に設定します。

    # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr
  3. プロンプトが表示されたら、certutil を使用して一時データベースを作成したときに入力したパスワードを入力します。その後、止めるように言われるまで、ランダムにタイピングし続けます。

    Enter Password or Pin for "NSS Certificate DB":
    
    A random seed must be generated that will be used in the
    creation of your key.  One of the easiest ways to create a
    random seed is to use the timing of keystrokes on a keyboard.
    
    To begin, type keys on the keyboard until this progress meter
    is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
    
    
    Continue typing until the progress meter is full:
  4. 証明書要求ファイルをサーバーに送信します。新しく発行した証明書に関連付ける Kerberos プリンシパルと、証明書を保存する出力ファイルを指定し、必要に応じて証明書のプロファイルを指定します。証明書を発行する IdM サブ CA を指定します。たとえば、idm_user@IDM.EXAMPLE.COM プリンシパルの IECUserRoles プロファイル (ユーザーロール拡張を追加したプロファイル) の証明書を webclient-ca から取得して、~/idm_user.pem ファイルに保存するには、次のコマンドを実行します。

    # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --ca=webclient-ca --certificate-out=~/idm_user.pem
  5. 証明書を NSS データベースに追加します。証明書が NSS データベースの秘密鍵に一致するように、CSR を作成する際に使用したニックネームを設定するには、-n オプションを使用します。-t オプションは信頼レベルを設定します。詳細は、man ページの certutil(1) を参照してください。-i オプションは、入力証明書ファイルを指定します。たとえば、idm_user ニックネームを持つ証明書を NSS データベースに追加するには、次のコマンドを実行します。証明書は、~/certdb/ データベースの ~/idm_user.pem ファイルに保存されます。

    # certutil -A -d ~/certdb/ -n idm_user -t "P,," -i ~/idm_user.pem
  6. NSS データベースの鍵で、ニックネームが (orphan) と表示されていないことを確認します。たとえば、~/certdb/ データベースに保存されている証明書で、対応する鍵が存在することを確認するには、以下のコマンドを実行します。

    # certutil -K -d ~/certdb/
    < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user
  7. 証明書を、NSS データベースから PKCS12 形式にエクスポートするには、pk12util コマンドを使用します。たとえば、NSS データベース /root/certdb から ~/idm_user.p12 ファイルへ、idm_user ニックネームを持つ証明書をエクスポートする場合は、次のコマンドを実行します。

    # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  8. idm_user の証明書認証を有効にするホストに、証明書を転送します。

    # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/
  9. セキュリティー上の理由から、証明書が転送されたホストの、.pkcs12 ファイルが格納されているディレクトリーに、「other」グループがアクセスできないようにします。

    # chmod o-rwx /home/idm_user/
  10. セキュリティー上の理由から、一時 NSS データベースおよび .pkcs12 ファイルを、サーバーから削除します。

    # rm ~/certdb/
    # rm ~/idm_user.p12

17.12. 証明書認証を有効にするためのブラウザーの設定

WebUI を使用して Identity Management (IdM) にログインする際に証明書で認証できるようにするには、ユーザーおよび関連の認証局 (CA) 証明書を Mozilla Firefox または Google Chrome ブラウザーにインポートする必要があります。ブラウザーが実行しているホスト自体は、IdM ドメインの一部である必要はありません。

IdM は、以下のブラウザーで WebUI への接続に対応します。

  • Mozilla Firefox 38 以降
  • Google Chrome 46 以降

次の手順は、Mozilla Firefox 57.0.1 ブラウザーを設定する方法を説明します。

前提条件

手順

  1. Firefox を開き、設定プライバシーとセキュリティ に移動します。

    図17.8 設定のプライバシーおよびセキュリティセクション

    Firefox 設定ページのスクリーンショット。そのスクリーンショットで「Privacy & Security」オプションが強調表示されています。
  2. 証明書を表示 をクリックします。

    図17.9 プライバシーおよびセキュリティーで証明書を表示

    「証明書証明書」のスクリーンショット。そのスクリーンショットで「表示証明書」ボタンが強調表示されています。
  3. あなたの証明書 タブで、インポート をクリックします。PKCS12 形式のユーザー証明書を見つけて開きます。OK をクリックし、OK をクリックします。
  4. IdM サブ CA が信頼された認証局として Firefox に認識されていることを確認するには、IdM WebUI からのサブ CA 証明書のダウンロード に保存した IdM サブ CA 証明書を信頼された認証局証明書としてインポートします。

    1. Firefox を起動し、設定に移動して、プライバシーおよびセキュリティに移動します。

      図17.10 設定のプライバシーおよびセキュリティセクション

      プライバシーとセキュリティー
    2. 証明書を表示 をクリックします。

      図17.11 プライバシーおよびセキュリティーで証明書を表示

      「証明書」セクションのスクリーンショット。右下の「View Certificates」ボタンが強調表示されています。
    3. 認証機関 タブで、インポート をクリックします。サブ CA 証明書を探して開きます。証明書を信頼し、Web サイトを識別したら、OK をクリックし、OK をクリックします。

第19章 IdM Healthcheck で証明書の検証

本セクションでは、Identity Management (IdM) で Healthcheck ツールを理解して、certmonger が維持する IPA 証明書の問題を特定する方法を説明します。

詳細については、IdM のヘルスチェックを 参照してください。

19.1. IdM 証明書の Healthcheck テスト

Healthcheck ツールには、Identity Management (IdM) の certmonger が維持する証明書の状況を確認するさまざまなテストが含まれています。certmonger の詳細については、certmonger を使用したサービスの IdM 証明書の取得を 参照してください。

このテストスイートは、有効期限、検証、信頼、およびその他の問題を確認します。根本的な問題 1 つに対して、複数のエラーが発生する可能性があります。

すべての証明書テストを表示するには、--list-sources オプションを指定して ipa-healthcheck を実行します。

# ipa-healthcheck --list-sources

すべてのテストは、ipahealthcheck.ipa.certs ソースの下にあります。

IPACertmongerExpirationCheck

このテストは、certmonger の有効期限を確認します。

証明書の有効期限が切れている場合は、エラーが報告されます。

証明書の有効期限が間近な場合は、警告が表示されます。デフォルトでは、このテストは、証明書の有効期限が 28 日以内のものを対象としています。

/etc/ipahealthcheck/ipahealthcheck.conf ファイルで日数を設定できます。ファイルを開くと、デフォルトセクションにある cert_expiration_days オプションを変更します。

注記

certmonger は証明書の有効期限に関する独自のビューを読み込んで維持します。この確認では、ディスク上の証明書は検証されません。

IPACertfileExpirationCheck

このテストは、証明書ファイルまたは NSS データベースを開けないかを確認します。このテストでは、有効期限も確認します。したがって、エラー出力または警告の出力で、msg 属性を慎重に読み取ります。このメッセージは問題を指定します。

注記

このテストでは、ディスク上の証明書が確認されます。証明書がない、読み取りができないなどの問題が発生した場合は、別のエラーを出力することもできます。

IPACertNSSTrust
このテストは、NSS データベースに保存されている証明書の信頼を比較します。NSS データベースで期待される、追跡された証明書では、信頼が、期待される値と比較され、一致しないとエラーが発生します。
IPANSSChainValidation
このテストは、NSS 証明書の証明書チェーンを検証します。テストは、certutil -V -u V -e -d [dbdir] -n [nickname] を実行します。
IPAOpenSSLChainValidation

このテストは、OpenSSL 証明書の証明書チェーンを検証します。NSSChain 検証を比較するには、以下を実行する OpenSSL コマンドになります。

openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt [cert file]
IPARAAgent
このテストは、ディスクの証明書を、uid=ipara,ou=People,o=ipaca の LDAP の同等のレコードと比較します。
IPACertRevocation
このテストは certmonger を使用して、証明書が取り消されていないことを確認します。したがって、テストでは certmonger でのみメンテナンスされる証明書に接続している問題を見つけることができます。
IPACertmongerCA

このテストでは、certmonger の Certificate Authority (CA) の設定を検証します。IdM は、CA を使用しない証明書を発行できません。

certmonger は、CA ヘルパーのセットを維持します。IdM には、IdM を介して証明書を発行し、ホストまたはサービスの証明書に対して、ホストまたはユーザーのプリンシパルとして認証する IPA という名前の CA があります。

また、CA サブシステム証明書を更新する dogtag-ipa-ca-renew-agent および dogtag-ipa-ca-renew-agent-reuse があります。

注記

問題を確認するには、すべての IdM サーバーで上記のテストを実行します。

19.2. Healthcheck ツールで証明書のスクリーニング

本セクションでは、Healthcheck ツールを使用した Identity Management (IdM) 証明書のヘルスチェックのスタンドアロンの手動テストを説明します。

Healthcheck ツールには多くのテストが含まれるため、以下の方法で結果を短くすることができます。

  • 成功したテストをすべて除外する - --failures-only
  • 証明書テストのみを含める - --source=ipahealthcheck.ipa.certs

前提条件

  • Healthcheck テストは root ユーザーで実行する。

手順

  • 証明書に関する警告、エラー、および重大な問題で Healthcheck を実行するには、次のコマンドを実行します。

    # ipa-healthcheck --source=ipahealthcheck.ipa.certs --failures-only

テストに成功すると、空の括弧が表示されます。

[]

失敗したテストでは、以下の出力が表示されます。

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "dbdir": "/path/to/nssdb",
    "error": [error],
    "msg": "Unable to open NSS database '/path/to/nssdb': [error]"
  }
}

この IPACertfileExpirationCheck テストは、NSS データベースを開く際に失敗します。

関連情報

  • man ipa-healthcheck を参照してください。

第20章 IdM Healthcheck でシステム証明書の検証

本セクションでは、Identity Management (IdM) の Healthcheck ツールを説明し、システム証明書の問題を特定します。

詳細については、IdM のヘルスチェックを 参照してください。

20.1. システム証明書の Healthcheck テスト

Healthcheck ツールには、システム (DogTag) 証明書を検証するさまざまなテストがあります。

すべてのテストを表示するには、--list-sources オプションを指定して ipa-healthcheck を実行します。

# ipa-healthcheck --list-sources

すべてのテストは、ipahealthcheck.dogtag.ca ソースの下にあります。

DogtagCertsConfigCheck

このテストは、その NSS データベースの CA (認証局) 証明書を、CS.cfg に保存されているものと同じ値と比較します。一致しないと、CA は起動できません。

具体的には、以下を確認します。

  • ca.audit_signing.cert の場合は auditSigningCert cert-pki-ca
  • ca.ocsp_signing.cert の場合は ocspSigningCert cert-pki-ca
  • ca.signing.cert の場合は caSigningCert cert-pki-ca
  • ca.subsystem.cert の場合は subsystemCert cert-pki-ca
  • ca.sslserver.cert の場合は Server-Cert cert-pki-ca

Key Recovery Authority (KRA) がインストールされている場合は、以下になります。

  • ca.connector.KRA.transportCert の場合は transportCert cert-pki-kra
DogtagCertsConnectivityCheck

このテストでは、接続性を検証します。このテストは、以下の確認を行う ipa cert-show 1 コマンドと同等です。

  • Apache の PKI プロキシー設定
  • CA を見つけることができる IdM
  • RA エージェントクライアント証明書
  • 要求に対する CA 返信の正確性

テストは、cert-show を実行し、CA から期待される結果 (証明書または「not fount」) を返すため、シリアル番号 #1 の証明書を確認します。

注記

問題を確認するには、すべての IdM サーバーで上記のテストを実行します。

20.2. Healthcheck を使用したシステム証明書のスクリーニング

本セクションでは、Healthcheck ツールを使用して、Identity Management (IdM) 証明書のスタンドアロンの手動テストを説明します。

Healthcheck ツールには多くのテストが含まれるため、Dogtag テスト (--source=ipahealthcheck.dogtag.ca) のみを含めることで結果を絞り込むことができます。

手順

  • Healthcheck を Dogtag 証明書に制限して実行するには、次のコマンドを実行します。

    # ipa-healthcheck --source=ipahealthcheck.dogtag.ca

テストに成功すると、以下のようになります。

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: SUCCESS",
  "uuid: 9b366200-9ec8-4bd9-bb5e-9a280c803a9c",
  "when: 20191008135826Z",
  "duration: 0.252280",
  "kw:" {
    "key": "Server-Cert cert-pki-ca",
    "configfile":  "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg"
    }
}

テストに失敗すると、以下のようになります。

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: CRITICAL",
  "uuid: 59d66200-1447-4b3b-be01-89810c803a98",
  "when: 20191008135912Z",
  "duration: 0.002022",
  "kw:" {
    "exception": "NSDB /etc/pki/pki-tomcat/alias not initialized",
    }
}

関連情報

  • man ipa-healthcheck を参照してください。