TLS 証明書の自動証明書管理

  • リリースバージョン: Washingtondc
  • 更新日 2024年02月01日
  • 読む19読むのに数分
  • 証明書インベントリと管理 バージョン 1.3.8 では、新しい証明書、更新、または証明書の取り消しの要求フローを自動化する機能が追加されています。

    証明書インベントリと管理 は、PKI チームからの手動の介入なしに、CA から証明書を自動的に取得できます。証明書インベントリと管理 バージョン 2.1.0 は、自動履行フローに対して DigiCert と Entrust CA Gateway をサポートしています。OV DigiCert 証明書のみを要求できます。詳細については、プロバイダーのドキュメントを参照してください。証明書インベントリと管理 バージョン 2.3.2 は Microsoft CA Gateway をサポートしています。

    自動フローに使用される DigiCert または Entrust CA Gateway ユーザーには、証明書の要求、更新、および取り消しの権限が必要です。

    Microsoft Gateway のユーザーには、次の権限が必要です。
    • CredSSP は、CA および MID サーバー で構成する必要があります。
    • ユーザーはエンタープライズ管理者の一部である必要があります。
    • ユーザーは、使用するテンプレートのセキュリティグループに属している必要があります。
    • ユーザーは、証明書の読み取り、発行および管理、CA の管理、および CA での証明書の要求権限を持っている必要があります。

    中間サーバーを使用している場合は、MID サーバー と中間サーバーの間で CredSSP を構成する必要があります。

    証明書管理に自動フローを使用する

    証明書インベントリと管理 で TLS 証明書の自動証明書管理を使用するには、特定の前提条件と手順に従う必要があります。

    始める前に

    必要なロール:PKI 管理者または管理者

    手順

    1. システムのプロパティ (sn_disco_certmgmt.cert_task_default_approval_group) をデフォルトの承認グループ名に設定します。
      承認グループ名は、証明書要求が手動モードに移行する場合 (たとえば、一致するポリシーがない場合、または一致する 3 つ以上のポリシーがある場合) に使用されるデフォルトのグループです。複数の承認グループをカンマで区切って追加できます。タスクドメインに属するリスト上の最初のグループが承認に使用されます。ドメイン固有のグループが見つからない場合は、グローバルドメインリストの最初の名前が使用されます。
    2. システムのプロパティ (sn_disco_certmgmt.default_cert_order_validity_period) を更新して、証明書注文の有効期間を設定します。
      デフォルトは 730 日 (2 年) です。
    3. 各認証局 (たとえば、DigiCert、Entrust、または Microsoft CA Gateway) に対するルーティングポリシーを設定します。
      単一の CA に対して複数のルーティングポリシーを定義し、異なるアカウントを使用して証明書をフェッチできます。Microsoft CA の場合は、次のいずれかを実行できます。
      • ルーティングポリシーの ca_host_ip フィールドに CA サーバーの IP を追加する。または、
      • ルーティングポリシーの ca_host_ip フィールドにある中間サーバーの IP を追加する。中間サーバーは、Microsoft CA サーバーと同じドメイン内にあり、PowerShell で利用可能な certutil コマンドおよび certreq コマンドにアクセスできる任意の Windows サーバーにすることができます。

        中間サーバーを使用している場合、MID サーバー は Invoke-Command を使用して中間サーバー上で Powershell スクリプトを実行し、次にリモートプロシージャコール (RPC) を使用して CA サーバー上で certutil コマンドおよび certreq コマンドを実行します。

    4. 証明書資格情報を作成し、資格情報エイリアスにマップします。
      詳細については、「Discovery 用資格情報エイリアス」を参照してください。

      各資格情報は、一意の資格情報エイリアスとマッピングする必要があります。

    5. 証明書と証明書 URL 情報が認証局 [sn_disco_certmgmt_ca] テーブルと認証局 API URL [sn_disco_certmgmt_ca_api_url] テーブルにあることを確認します。
      DigiCert または Entrust CA Gateway のデフォルト URL は、すべての検証タイプの URL を提供します。必要に応じて URL を追加できます。
    6. タスクの優先度を設定します。

      タスクの優先度に基づいて、変更要求の優先度とタイプがマッピングされます。変更要求のタスク優先度は、P5 を除いて、同じ優先度になります (変更要求には P5 がないため、この場合は P4 にマッピングされます)。

      変更要求のタイプを変更するには、変更管理プロパティ [com.snc.change_management.change_model.type_compatibility] を true に設定する必要があります。デフォルトは False です。

      1. タスクを設定し、必要に応じてシステムのプロパティ [sn_disco_certmgmt.default_cert_task_priority] を変更して、新規および更新タスクの優先度を設定します。
        優先度のデフォルトは P3 です。指定可能な値は 1、2、3、4、5 です。値が 1 の場合、優先度は P1 に設定されるといった具合になります。無効な値が指定された場合、優先度はデフォルトの P3 にリセットされます。
      2. タスクを設定し、必要に応じてシステムのプロパティ [sn_disco_certmgmt.default_revoke_cert_task_priority] を変更して、取り消しタスクの優先度を設定します。
        優先度のデフォルトは P1 です。指定可能な値は 1、2、3、4、5 です。値が 1 の場合、優先度は P1 に設定されるといった具合になります。無効な値が指定された場合、優先度はデフォルトの P1 にリセットされます。
    7. オプション:統合ハブプラグイン [com.glide.hub.integrations] をインストールします。
      [com.glide.hub.integrations] プラグインは、DigiCert または Entrust CA Gateway 証明書を要求し、証明書の注文ステータスを追跡するためには必要ありません。ただし、顧客が証明書サブフローアクションをデバッグするか、DigiCert、Entrust、または Microsoft CA Gateway に対して独自のカスタマイズフローを追加する場合は、このプラグインをインストールする必要があります。

    自動証明書管理のルーティングポリシーを設定する

    PKI 管理者または管理者は、TLS 証明書の自動証明書管理を機能させるために、CA、環境、およびその他の機能に基づいてルーティングポリシーを作成する必要があります。

    始める前に

    必要なロール:PKI 管理者または管理者

    注:

    証明書要求の重複は許可されていません。ただし、[重複要求を許可 (Allow duplicate requests)] チェックボックスをオンにすると、この設定を上書きできます。まだ進行中の同じドメイン名を持つ別の証明書タスクがある場合、証明書要求は重複と見なされます。

    Approvals は、現時点では履行者承認エクスペリエンスでのみサポートされています。

    このタスクについて

    ルーティングポリシーは、証明書操作のために連絡する必要がある CA を決定します。これには、CA、CA URL、資格情報、承認グループ、アサイン先グループ、および CSR 属性が含まれます。ルーティングポリシーは、特定の CA の証明書を要求するためのフローをトリガーします。

    手順

    1. 移動先 すべて > 証明書管理 > 証明書ルーティングポリシー.
    2. [新規] を選択して、フォームの必須フィールドに入力します。
      新しい証明書と証明書の更新の要求は自動化できますが、多くの PKI チームは履行前に人手によって検証することを希望します。その場合は、[承認が必要] ボックスをオンにします。
      注:

      [組織]、[組織単位]、[市区町村 (Locality)]、[州 (State)]、[国]、および [メール] は、カンマ区切り値を受け入れます。 * は任意と見なされます。

      RegEx では、サブジェクトの共通名とサブジェクトの代替名がサポートされています。RegEx 形式には、カンマを含めることはできないという制限があります。スラッシュ (/) で開始および終了しないでください。* は任意のドメインに一致します。

    3. 次の CSR 属性は、ルーティングポリシー [sn_disco_certmgmt_routing_policy] テーブルのエントリと照合されます。
      • 組織
      • 組織単位
      • 市区町村
      • ステータス
      • メール
      • 環境
      • 証明書の目的 (内部/外部)
      • サブジェクトの共通名
      • サブジェクトの代替名
      注:

      Entrust CA Gateway には、[認証局の識別子]、[証明書プロファイル]、および [証明書形式] のフィールドもあります。

      Microsoft CA Gateway の場合は、[認証局]、[CA テンプレート名]、[CA ホスト IP]、[資格情報]、および [CSR 属性 (CSR attributes)] のフィールドも使用します。

    4. 次のオプションが発生する可能性があります。
      オプション説明
      単一のルーティングポリシーが一致する場合 次の条件を確認します。
      • ルーティングポリシーテーブル、ドメイン名、または * で指定された RegEx パターンを使用して、サブジェクトの共通名を検証します。
      • 証明書要求の有効期間がルーティングポリシーテーブルの最大有効期間を超えていないことを確認します。
      • ルーティングポリシーテーブルで重複証明書要求の許可フラグを確認します。
      複数のルーティングポリシーが適格である場合 タスクはデフォルトの承認者グループにアサインされます。
      ルーティングポリシーが見つからない場合 タスクはデフォルトの承認者グループにアサインされます。
      単一のポリシーが一致し、[承認が必要] フラグが true の場合 タスクは、ルーティングポリシーで定義されたタスク承認グループにアサインされます。
    5. 承認グループはルーティングポリシーにアサインされ、pki_approver ロールとそのグループで利用可能なアクティブなグループメンバーの少なくとも 1 人が含まれます。
    6. ルーティングポリシーで手動承認が必要な場合は、承認グループでの承認が要求されます。

    ルーティングポリシーの詳細

    TLS 証明書の自動証明書管理でルーティングポリシーが機能する仕組みについては、3 つの異なるシナリオがあります。

    • シナリオ 1:単一のルーティングポリシーが一致し、手動の承認が必要である。承認者は、タスクの詳細を確認し、証明書要求を承認できます。承認されると、自動フローがトリガーされます。
    • シナリオ 2:一致するルーティングポリシーがないか、一致するルーティングポリシーが複数ある。承認者はタスクの詳細を確認し、[ルーティングポリシーを選択して承認] を選択できます。承認者はルーティングポリシーを手動で選択する必要があります。その後、更新されたルーティングポリシーが表示されます。承認者がルーティングポリシーを選択すると、自動フローがトリガーされます。
    • シナリオ 3:単一のルーティングポリシーが一致し、手動の承認が不要で、[承認が必要] フラグが非アクティブである。自動フローがトリガーされます。
    注:

    承認者が証明書要求タスクを却下した場合、タスクは [失敗] としてマークされます。

    自動フローの進行をトリガーするには、単一の承認で十分です。

    自動証明書管理を使用して新しい証明書を要求する

    自動証明書管理を使用して、新しい証明書を要求し、アプリケーションの証明書を自動的に取得します。証明書インベントリと管理 バージョン 2.1.0 では、DigiCert または Entrust CA Gateway からの証明書の要求がサポートされています。バージョン 2.3.2 は Microsoft CA Gateway もサポートしています。

    始める前に

    証明書管理カタログが有効になっており、ルーティングポリシーが作成済みであることを確認します。

    必要なロール:証明書要求者、PKI 管理者、PKI ユーザー、または管理者。証明書要求者は、PKI 管理者ロールまたは PKI ユーザーロールを持たないユーザーです。

    DigiCert の場合のみ:DigiCert によって既に検証されているドメインを使用して、DigiCert から API キーを取得する必要があります。DigiCert によって検証されていない新しいドメインを使用して証明書要求を送信すると、要求は [処理待ち] と表示され、自動フローは証明書情報をフェッチできなくなり、要求は失敗とマークされます。

    注:
    Approvals は、現時点では履行者承認エクスペリエンスでのみサポートされています。

    手順

    1. 移動先 すべて > サービスカタログ > 証明書管理.
    2. [新しい証明書の要求 - 自動フロー] をクリックします。
    3. 必須フィールドの [CSR] と [有効期間] に情報を入力します。
    4. フォームのその他の詳細を入力または選択し、[送信] をクリックして依頼します。

      ルーティングポリシー [sn_disco_certmgmt_routing_policy] テーブルは、CA ルーティングポリシー ID をフェッチするために役立ちます。単一のルーティングポリシー ID が返されない場合、承認者はルーティングポリシーを選択してタスクを承認する必要があります。

      詳細については、「証明書タスクの承認」を参照してください。
    5. これにより、新しい証明書タスクが作成され、自動フローがトリガーされます。
      ルーティングポリシーで [承認が必要] フィールドがオンになっている場合、自動フローを開始する前にタスクが承認を要求します。

    タスクの結果

    1. 要求が送信されると、自動フローは CA に証明書を取得するように要求します。
      注:
      Powershell ステップは Microsoft CA に使用されます。これにはプラグイン com.glide.hub.action_step.powershell が必要です。
    2. 証明書が正常にフェッチされると、証明書拡張 [sn_disco_certmgmt_certificate_extension] テーブルにレコードが作成されます。
    3. 30 分ごとに、「DigiCert – 証明書注文ステータスの追跡」スケジュール設定済みジョブが実行され、ステータスがチェックされます。
      注:
      Entrust および Microsoft CA Gateway には、ジョブスケジュールはありません。
    4. 証明書が利用可能な場合、証明書タスクに添付されます。
    5. 証明書タスクが [完了] とマークされ、変更要求が作成されます。
    6. 同じ CSR に対して複数のタスクが作成され、ルーティングポリシーで [重複を許可 (Allow Duplication)] がオンになっていない場合、タスクは失敗します。
    7. 有効期間が一致したルーティングポリシーの有効期間を超えると、タスクは失敗します。

    証明書タスクの承認

    証明書タスクを手動で承認する必要がある場合があります。

    始める前に

    注:

    ルーティングポリシーの承認が要求された場合は、作成されたルーティングポリシーを選択します。

    Approvals は、現時点では履行者承認エクスペリエンスでのみサポートされています。

    必要なロール:管理者

    手順

    1. 移動先 すべて > セルフサービス > 自分の承認.
    2. 自動的に作成された承認タスクを開きます。
    3. 新しい証明書の詳細を確認し、ルーティングポリシーを選択して承認します。

    タスクの結果

    1. これにより、新しい証明書を要求するための自動フローが開始されます。
    2. 移動先 証明書管理 > 新しい証明書タスク 証明書タスクを開きます
    3. 自動フローがトリガーされたことを確認します。
    4. CA が証明書要求を承認すると、新たに要求された証明書の注文 ID と証明書 ID がフェッチされます。CA が承認しない場合、注文 ID のみがフェッチされます。
      注:
      Entrust CA Gateway の場合、証明書のシリアル番号と登録 ID がフェッチされます。

    自動証明書管理を使用して証明書を更新する

    証明書の更新を要求し、アプリケーションの証明書を自動的に取得します。

    始める前に

    証明書管理カタログが有効になっており、ルーティングポリシーが作成済みであることを確認します。

    必要なロール:PKI 管理者、管理者、証明書所有者、または証明書所有者グループに属するユーザー。証明書所有者および証明書所有者グループには、証明書要求者ロール (最小ロール) が含まれています。

    Approvals は、現時点では履行者承認エクスペリエンスでのみサポートされています。

    注:
    現在、Entrust CA および Microsoft CA Gateway の証明書で利用可能な更新 API はありません。更新要求時には、選択した証明書と同じ属性で新しい証明書が内部で生成されます。

    このタスクについて

    既存の証明書を更新するには、CSR が必須です。要求者は、利用可能な場合は既存の CSR を使用するか、新しい CSR を使用できます。既存の CSR を使用する場合は、同じ CSR を使用して CA に新しい証明書を要求します。Vault および Java API を使用してフィールドに入力すると、CSR が生成されます。

    手順

    1. 移動先 すべて > サービスカタログ > 証明書管理.
    2. [証明書の更新 – 自動フロー] をクリックします。
    3. 必須フィールドの [CSR] と [有効期間] に情報を入力します。
    4. フォームのその他の詳細を入力または選択し、[送信] をクリックして依頼します。

    タスクの結果

    1. ルーティングポリシー [sn_disco_certmgmt_routing_policy] テーブルは、CA ルーティングポリシー ID をフェッチするために役立ちます。
      • 単一のルーティングポリシーが一致しない場合、承認者は CA を選択してフローをトリガーする必要があります。
      • CSR に発行された証明書ドメイン名とは異なるドメイン名が含まれている場合、タスクは承認を要求します。
      • 単一のルーティングポリシーに一致するが、証明書拡張 [sn_disco_certmgmt_certificate_extension] テーブルで証明書の更新情報を利用できない場合は、タスクが承認を要求します。
      • 証明書拡張 [sn_disco_certmgmt_certificate_extension] テーブルの証明書に、認証局と注文 ID またはサムプリントの詳細が欠落している場合は、証明書を更新できません。認証局クエリーを介して証明書を検出し、証明書拡張テーブルに必要な詳細を入力します。ディスカバリー の後に、ルーティングポリシーを選択し、タスクを承認します。
    2. これにより、注文された証明書のタスクが作成され、証明書の更新を要求するフローがトリガーされます。
    3. 要求が送信されると、自動フローは CA に証明書を取得するように要求します。
      注:
      Powershell ステップは Microsoft CA に使用されます。これにはプラグイン com.glide.hub.action_step.powershell が必要です。
    4. その後、注文 ID は証明書タスク [sn_disco_certmgmt_certificate_task] テーブルと証明書拡張 [sn_disco_certmgmt_certificate_extension] テーブルに格納されます。
      注:
      Entrust CA Gateway の場合、証明書のシリアル番号と登録 ID がフェッチされます。シリアル番号は、証明書の拡張機能 [sn_disco_certmgmt_certificate_extension] テーブルに保存されます。
    5. 30 分ごとに、「DigiCert – 証明書注文ステータスの追跡」スケジュール設定済みジョブが実行され、ステータスがチェックされます。
    注:

    選択した証明書に関する詳細が証明書拡張 [sn_disco_certmgmt_certificate_extension] テーブルからフェッチされ、証明書を更新するように CA に要求します。認証局、注文 ID、またはサムプリントがこのテーブルに欠落している場合は、証明書を更新できません。何らかの理由で証明書を更新するための追加の詳細が欠落している場合、システムはメッセージを記録し、何をすべきかを提案します。この場合、CA ベースの検出を使用して証明書を検出する必要があります。証明書拡張テーブルに詳細を入力する方法については、「認証局クエリーによる証明書検出の実行」を参照してください。

    自動証明書管理を使用して証明書を取り消す

    アプリケーションの証明書の取り消しを要求します。注文 ID と証明書 ID が証明書拡張テーブルに存在する場合、取り消しには承認は必要ありません。注文 ID と証明書 ID が証明書拡張テーブルに存在しない場合は、タスクが承認を要求します。

    始める前に

    証明書管理カタログが有効になっており、ルーティングポリシーが作成済みであることを確認します。

    必要なロール:PKI 管理者または管理者

    注:
    Approvals は、現時点では履行者承認エクスペリエンスでのみサポートされています。

    手順

    1. 移動先 すべて > サービスカタログ > 証明書管理.
    2. [証明書の取り消し – 自動フロー] をクリックします。
    3. 取り消す発行済み証明書を入力します (例:www.undefined.com)。
      複数の証明書を選択して取り消すことができます。
    4. 証明書の取り消しに関する適切な理由を入力します。
      Microsoft CA の場合、理由は整数値である必要があります。他の値が指定された場合は、未指定を意味するデフォルト値の 0 が使用されます。
    5. [送信] をクリックして取り消しを注文します。
    6. 「選択された証明書を取り消してもよろしいですか? (Are you sure you want to revoke the selected certificate(s)?)」というポップアップが表示されたら、[OK] を選択します。

    タスクの結果

    1. 取り消しを要求すると、タスクが自動的に作成されます。
      • 注文 ID と証明書 ID が証明書拡張 [sn_disco_certmgmt_certificate_extension] テーブルに存在する場合、取り消しには承認は必要ありません。
      • 注文 ID と証明書 ID が証明書拡張 [sn_disco_certmgmt_certificate_extension] テーブルに存在しない場合は、タスクが承認を要求します。
      • Entrust CA Gateway のシリアル番号が証明書拡張 [sn_disco_certmgmt_certificate_extension] テーブルに存在しない場合は、タスクが承認を要求します。
    2. PKI チームが承認を提供すると、選択されたルーティングポリシーに基づいて証明書と CA 間のマッピングが行われます。
    3. これにより、CA API を使用する選択された CA の取り消す操作がトリガーされます。
    4. 詳細は証明書拡張テーブルに保存されます。
    5. 30 分ごとに、「DigiCert – 証明書注文ステータスの追跡」スケジュール設定済みジョブが実行され、ステータスがチェックされます。
      注:
      Entrust および Microsoft CA Gateway には、ジョブスケジュールはありません。
    6. 証明書のステータスは取り消し済みとしてマークされます。
    注:

    証明書拡張 [sn_disco_certmgmt_certificate_extension] テーブルの証明書に、認証局と証明書 ID の詳細が欠落している場合は、証明書を取り消すことはできません。Entrust CA Gateway では、シリアル番号が欠落している場合は、証明書を取り消すことができません。認証局クエリーを介して証明書を検出し、証明書拡張テーブルに必要な詳細を入力します。その後、ディスカバリー がルーティングポリシーを選択し、タスクを承認します。

    証明書 API 要求を取り消します。「skip_approval」が true の場合、取り消しプロセスはより迅速に完了します。「skip_approval」が false の場合、DigiCert CA または Entrust CA Gateway 管理者が取り消し要求を承認または却下すると、取り消しプロセスが完了します。承認ステップをスキップするには、API キーに管理者権限が必要です。