SSL / TLS パブリック証明書の注文

IBM Cloud® Secrets Manager を使用して、アプリやサービスで使用できる公開証明書 SSL / TLS を保存、要求、生成できます。

SSL/TLS 証明書は、サーバーとクライアントの間の通信プライバシーを確立するために使用されるデジタル証明書の一種です。証明書は認証局（CAデジタル証明書を発行する、信頼できるサード・パーティーの組織または企業。一般に、認証局は、固有の証明書を付与された個人の ID を検証します。）によって発行され、エンドポイント間の信頼できる安全な接続を作成するために使用される情報が含まれている。 Secrets Manager インスタンスに証明書を追加したら、その証明書を使用して、クラウドまたはオンプレミスのデプロイメントのネットワーク通信を保護できます。証明書は、専用の Secrets Manager サービス・インスタンス内に安全に保管されます。このインスタンスでは、証明書のライフサイクルを一元管理できます。

Secrets Manager では、 Secrets Manager を通じてサードパーティの認証局に発注する証明書は、パブリック証明書です。サービスにインポートする証明書は、インポートされた証明書 (imported_cert) です。プライベート認証局を使用して作成する証明書は、プライベート証明書 (private_cert) です。

開始前に

開始する前に、必要なレベルのアクセス権限を持っていることを確認してください。シークレットを作成または追加するには、ライター・サービス・ロールまたはそれ以上が必要です。

証明書を注文する前に、以下のことを確認してください。

証明書を注文するためのインスタンスを準備します。
利用可能な認証局とDNSプロバイダーの設定を確認する。インスタンスで定義されている構成を表示するには、Secrets Manager UI の**「シークレット・エンジン (Secrets engines)」>「パブリック証明書 (Public certificates)」**ページに移動します。

現在サービスに統合されていない DNS プロバイダーを操作する場合は、パブリック証明書を注文するための構成を追加する必要はありません。

公開証明書の注文

インスタンスの公開証明書エンジンを設定した後、 Secrets Manager を使用して、Let's Encrypt に公開証明書 SSL / TLS を要求することができます。証明書を発行する前に、Secrets Manager はドメイン検証を使用して、ドメインの所有権を検証します。証明書を注文すると、以下のようになります。

Secrets Manager が、選択された認証局に要求を送信します。要求が処理中であることを示すために、証明書のステータスが 「プレアクティベーション」 に変わります。
検証が正常に終了すると、証明書が発行され、証明書のステータスが 「アクティブ」 に変わります。
検証が正常に終了しなかった場合は、証明書のステータスが 「非アクティブ」 に変わります。「シークレット」テーブルから証明書発行の詳細を確認するには、**「アクション」**アイコン **>「詳細の表示」**をクリックします。
検証が正常に終了しなかった場合は、証明書のステータスが 「非アクティブ」 に変わります。「シークレット」テーブルから証明書発行の詳細を確認するには、**「アクション」**アイコン **>「詳細の表示」**をクリックします。
検証が正常に終了しなかった場合は、証明書のステータスが 「非アクティブ」 に変わります。シークレット・メタデータの取得 API を使用して、resources.issuance_info フィールドで証明書発行の詳細情報を確認できます。
証明書が発行されたら、その証明書を統合アプリにデプロイしたり、ダウンロードしたり、ローテーション・オプションを変更したりできます。

UI での統合 DNS プロバイダーを使用したパブリック証明書の注文

Secrets Manager UI を使用すると、証明書をオーダーできます。

コンソールで、**「メニュー」**アイコン **>「リソース・リスト」**をクリックします。
サービスのリストから、Secrets Manager のインスタンスを選択します。
**「シークレット」テーブルで、「追加」**をクリックします。
Order public certificate タイルをクリックします。
証明書を簡単に識別するための名前と説明を追加します。
シークレットに割り当てるシークレット・グループを選択します。シークレット・グループがありませんか。 「シークレット・グループ」フィールドで、「作成」 をクリックすると、新規グループの名前と説明を入力できます。新しいグループにシークレットが自動的に追加されます。シークレット・グループについて詳しくは、シークレットの編成をチェックしてください。
オプション: インスタンス内の類似シークレットを検索しやすくするためのラベルを追加します。
オプション: シークレットまたは特定のバージョンのシークレットにメタデータを追加します。ファイルをアップロードするか、メタデータとバージョン・メタデータを JSON 形式で入力します。
次へをクリックします。
認証局構成を選択します。

選択した構成によって、証明書の署名と発行に使用する認証局が決まります。インスタンスに定義されている構成を表示するには、**「シークレット・エンジン」 > 「パブリック証明書」**に移動します。
証明書の公開鍵の生成に使用する鍵アルゴリズムを選択します。

選択した鍵アルゴリズムによって、キーの生成および証明書の署名に使用する暗号化アルゴリズム（RSAまたはECDSA）とキーサイズが決まります。より長寿命の証明書については、より長い鍵長を使用し、暗号化保護を強化することを推奨する。オプションには、RSA2048、RSA4096、ECDSA256、およびECDSA384があります。

オプション: 証明書の拡張オプションを有効にします。
発行された証明書を中間証明書とバンドルするには、バンドル・トグルを**「オン」**に切り替えます。証明書をバンドルした後に、バンドルを解除することはできません。証明書をバンドルしないことを選択した場合、これは後から変更することはできない。
証明書の自動ローテーションを有効にするには、ローテーション・トグルを**「オン」**に切り替えます。証明書の有効期限が切れる 31 日前に、ローテーションが行われます。
ローテーションのたびに証明書とともに新しい秘密鍵を要求するには、リキートグルをオンに切り替える。
DNS プロバイダー構成を選択します。選択した構成によって、ドメインの所有権を検証する DNS プロバイダーが決まります。インスタンスに定義されている構成を表示するには、**「シークレット・エンジン」 > 「パブリック証明書」**に移動します。
要求に含めるドメインを追加します。
**「ドメインの選択」**をクリックします。
ドメインのリストから、証明書の共通名を選択します。

コモンネームは任意入力です。コモンネームが明示的に指定されていない場合、Let's encryptは自動的に64文字以内の最初の代替名をコモンネームとして割り当てます。そのような代替名が見つからない場合、証明書は共通名なしで発行されます。

オプションで、有効なドメインを手動で追加することもできます。ドメインを手動で追加する分野。
次へをクリックします。
証明書の詳細を確認します。
追加をクリックします。

証明書を注文すると、ドメイン検証が行われ、選択したドメインの所有権が確認されます。このプロセスが完了するまでに数分かかることがあります。証明書詳細を送信すると、選択された認証局に Secrets Manager が要求を送信します。証明書が発行されたら、その証明書を統合アプリにデプロイしたり、ダウンロードしたり、手動ローテーションを行ったりできます。 SSL/TLS のプライベート・キーは Secrets Manager で直接生成され、安全に保管されます。

オーダー・ステータスのチェックが必要ですか。「シークレット」テーブルから証明書発行の詳細を確認するには、**「アクション」**アイコン **>「詳細の表示」**をクリックします。

統合 DNS プロバイダーを使用した CLI からのパブリック証明書の注文

始める前に、CLIのドキュメントに従ってAPIエンドポイントを設定してください。

Secrets Manager CLI プラグインを使用して、統合 DNS プロバイダーでパブリック証明書を注文するには、 ibmcloud secrets-manager secret-create command.For コマンドは、指定した認証局からパブリック証明書シークレットを要求します。

証明書を注文すると、ドメイン検証が行われ、選択したドメインの所有権が確認されます。このプロセスが完了するまでに数分かかることがあります。

ibmcloud secrets-manager secret-create \
    --secret-name example-public-certificate \
    --secret-description "Extended description for this secret." \
    --secret-type public_cert \
    --secret-group-id bc656587-8fda-4d05-9ad8-b1de1ec7e712 \
    --secret-labels dev,us-south \
    --public-cert-dns dns_provider \
    --certificate-common-name cert_common_name \
    --certificate-alt-names alt_name1,alt_name2 \
    --public-cert-ca lets-encrypt-config \
    --public-cert-key-algorithm RSA2048 \
    --secret-rotation '{"auto_rotate": true, "rotate_keys": false}' \
    --secret-custom-metadata '{"anyKey": "anyValue"}' \
    --secret-version-custom-metadata '{"anyKey": "anyValue"}'

このコマンドでは、シークレットの ID 値と他のメタデータが出力されます。コマンド・オプションについては、ibmcloud secrets-manager secret-create を参照してください。

API を使用した統合 DNS プロバイダーでのパブリック証明書の注文

Secrets Manager API を呼び出すと、証明書をプログラムでオーダーできます。

証明書を注文するために使用できる照会の例を以下に示します。 API を呼び出す場合は、ID 変数と IAM トークンを、ご使用の Secrets Manager インスタンス固有の値で置き換えます。

custom_metadata および version_custom_metadata 要求パラメーターを使用して、組織のニーズに関連するメタデータを保管できます。 version_custom_metadata の値は、シークレットのバージョンについてのみ返されます。シークレットのカスタム・メタデータは、最大 50 バージョンの他のすべてのメタデータとして保管されます。機密データを含めることはできません。

curl -X POST  
    -H "Authorization: Bearer {iam_token}" \
    -H "Accept: application/json" \
    -H "Content-Type: application/json" \
    -d '{
            "name": "example-public-certificate",
            "description": "Description of my public certificate",
            "secret_type": "public_cert",
            "secret_group_id": "bfc0a4a9-3d58-4fda-945b-76756af516aa",
            "labels": [
                "dev",
                "us-south"
            ],
            "common_name": "example.com",
            "alt_names": [
                "s1.example.com",
                "*.s2.example.com"
            ],
            "ca": "lets-encrypt-config",
            "dns": "cloud-internet-services-config",
            "rotation": {
                "auto_rotate": true,
                "rotate_keys": true
            },
            "bundle_certs": true,
            "custom_metadata": {
                "metadata_custom_key": "metadata_custom_value"
            },
            "version_custom_metadata": {
                "custom_version_key": "custom_version_value"
            }
        }' \
    "https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets"

証明書詳細を送信すると、選択された認証局に Secrets Manager が要求を送信します。証明書が発行されたら、その証明書を統合アプリにデプロイしたり、ダウンロードしたり、手動ローテーションを行ったりできます。 SSL/TLS のプライベート・キーは Secrets Manager で直接生成され、安全に保管されます。必須およびオプションのリクエスト・パラメータの詳細については、秘密の作成を参照してください。

オーダー・ステータスのチェックが必要ですか。秘密メタデータの取得APIを使用して、resources.issuance_info証明書の発行詳細のフィールドを確認します。

Terraform を使用した統合 DNS プロバイダーでのパブリック証明書の注文

次の例は、パブリック証明書を注文するために使用できる設定を示している。

    resource "ibm_sm_public_certificate" "sm_public_certificate" {
        instance_id = local.instance_id
        region = local.region
        name = "test-public-certificate"
        secret_group_id = "default"
        ca = ibm_sm_public_certificate_configuration_ca_lets_encrypt.my_lets_encrypt_config.name
        dns = ibm_sm_public_certificate_configuration_dns_cis.my_cis_dns_config.name
        rotation {
            auto_rotate = true
            rotate_keys = false
        }
    }

Terraform IBM Modules (TIM) for Secrets Manager Public Certificate を使ってパブリック証明書の発注を簡素化し、証明書のライフサイクル管理をコードで行う。 Terraform IBM Modules でベストプラクティスを探そう。

UI での独自の DNS プロバイダーを使用したパブリック証明書の注文

UI で手動 DNS プロバイダーを使用してパブリック証明書を作成するには、以下の手順を実行します。

コンソールで、**「メニュー」**アイコン **>「リソース・リスト」**をクリックします。
サービスのリストから、Secrets Manager のインスタンスを選択します。
**「シークレット」テーブルで、「追加」**をクリックします。
Order public certificate タイルをクリックします。
証明書を簡単に識別するための名前と説明を追加します。
シークレットに割り当てるシークレット・グループを選択します。シークレット・グループがありませんか。 「シークレット・グループ」フィールドで、「作成」 をクリックすると、新規グループの名前と説明を入力できます。新しいグループにシークレットが自動的に追加されます。シークレット・グループについて詳しくは、シークレットの編成をチェックしてください。
オプション: インスタンス内の類似シークレットを検索しやすくするためのラベルを追加します。
オプション: シークレットまたは特定のバージョンのシークレットにメタデータを追加します。ファイルをアップロードするか、メタデータとバージョン・メタデータを JSON 形式で入力します。
次へをクリックします。
認証局構成を選択します。選択した構成によって、証明書の署名と発行に使用する認証局が決まります。インスタンスに定義されている構成を表示するには、**「シークレット・エンジン」 > 「パブリック証明書」**に移動します。
証明書の公開鍵の生成に使用する鍵アルゴリズムを選択します。選択した鍵アルゴリズムによって、キーの生成および証明書の署名に使用する暗号化アルゴリズム（RSAまたはECDSA）とキーサイズが決まります。より長寿命の証明書については、より長い鍵長を使用し、暗号化保護を強化することを推奨する。オプションには、RSA2048、RSA4096、ECDSA256、およびECDSA384があります。
オプション: 証明書の拡張オプションを有効にします。
発行された証明書を中間証明書とバンドルするには、バンドル・トグルを**「オン」**に切り替えます。証明書をバンドルした後に、バンドルを解除することはできません。証明書をバンドルしないことを選択した場合、これは後から変更することはできない。
ローテーションのたびに証明書とともに新しい秘密鍵を要求するには、リキートグルをオンに切り替える。
DNS プロバイダーとして 「手動」 を選択します。
要求に含めるドメインを追加します。

最大 100 個のドメイン、サブドメイン、またはワイルドカードを含めることができます。証明書の共通名または完全修飾ドメイン・ネームの長さは 64 文字以下でなければなりません。共通名としてワイルドカードを選択することもできます。

「共通名」 セクションで、ドメインのリストから証明書の共通名を選択します。
次へをクリックします。
証明書の詳細を確認します。
追加をクリックします。
「アクション」 アイコン >「詳細の表示」 をクリックして、証明書の発行の詳細を確認します。
「チャレンジ (Challenges)」 をクリックして、各ドメインに関連付けられた TXT レコード名と値にアクセスしてください。チャレンジを完了するには、これらのユーザーが必要です。
ドメインの所有権を検証するには、ドメインごとに提供される TXT レコードを DNS プロバイダー・アカウントに手動で追加します。有効期限までに検証されていないユーザー確認用の質問にのみ対応する必要があります。

サブドメイン (例えば、 sub1.sub2.domain.com) の証明書を注文する場合は、TXT レコードを登録済みドメイン domain.com に追加する必要があります。

ドメインに追加した TXT レコードが伝搬されていることを確認します。 DNS プロバイダーによっては、完了までに時間がかかる場合があります。
レコードが伝搬されたことを確認したら、 「検証」 をクリックして Let 's Encrypt を要求し、ドメインに対するチャレンジを検証して公開証明書を作成します。

TXT レコードが正常に伝搬されなかったためにオーダーが失敗した場合は、続行するために新しいオーダーを開始する必要があります。

証明書が発行されたら、DNS プロバイダー・アカウント内のドメインから TXT レコードをクリーンアップして削除します。

API を使用した、独自の DNS プロバイダーによるパブリック証明書の注文

手動 DNS プロバイダーを使用してパブリック証明書を作成するには、以下の手順を実行します。

CA 構成の追加で定義されているステップに従って、認証局 (CA) 構成を作成します。

DNS 構成として manual を指定して、新しいパブリック証明書を作成します。

 curl -X POST
     -H "Authorization: Bearer {iam_token}" \
     -H "Accept: application/json" \
     -H "Content-Type: application/json" \
     -d '{
             "name": "example-public-certificate",
             "description": "description of my public certificate",
             "secret_type": "public_cert",
             "secret_group_id": "bfc0a4a9-3d58-4fda-945b-76756af516aa",
             "labels": [
                 "dev",
                 "us-south"
             ],
             "common_name": "example.com",
             "alt_names": [
                 "s1.example.com",
                 "*.s2.example.com"
             ],
             "ca": "lets-encrypt-config",
             "dns": "manual",
             "rotation": {
                 "auto_rotate": true,
                 "rotate_keys": true
             },
             "bundle_certs": true,
             "custom_metadata": {
                 "metadata_custom_key": "metadata_custom_value"
             },
             "version_custom_metadata": {
                 "custom_version_key": "custom_version_value"
             }
             }' \
         "https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets"

応答の例:

"metadata": {
   "collection_type": "application/vnd.ibm.secrets-manager.secret+json",
   "collection_total": 1
 },
"resources": [
 {
   "alt_names": [
     "domain2",
     "domain3"
   ],
   "common_name": "domain1",
   "created_by": "User",
   "creation_date": "2022-09-13T06:21:33Z",
   "crn": "secret crn",
   "description": "Description for ordered certificate.",
   "downloaded": false,
   "id": "38747ae6-8c69-d745-5276-cdf3157b9021",
   "issuance_info": {
   "auto_rotated": false,
   "bundle_certs": false,
   "ca": "ca_config_name",
   "challenges": [
     {
         "domain": "domain1",
         "expiration": "2022-09-20T06:21:36Z",
         "status": "pending",
         "txt_record_name": "_acme-challenge.domain1.",
         "txt_record_value": "TA6J7fFYrwP3Jg-S_IAQSj2Ydqfw4Ycm4sMwlzuCcxk"
     },
         {
            "domain": "domain2",
            "expiration": "2022-09-20T06:21:36Z",
            "status": "pending",
            "txt_record_name": "_acme-challenge.domain2.",
            "txt_record_value": "qSDrCkFAViX4xANKuEPcMNairWm1PUtROm6kp9bmSS0"
         },
         {
            "domain": "domain3",
            "expiration": "2022-09-20T06:21:36Z",
            "status": "pending",
            "txt_record_name": "_acme-challenge.domain3.",
            "txt_record_value": "8dcgan91fW6aK3aIhPAVZRkHpbYEoMcCNPpVh1n4tSA"
         }
      ],
   "dns": "manual",
   "ordered_on": "2022-09-13T06:21:33Z",
   "state": 0,
   "state_description": "Pre-activation"
   },
   "key_algorithm": "RSA2048",
   "labels": [],
   "last_update_date": "2022-09-13T06:21:33Z",
   "locks_total": 0,
   "name": "my-public-certificate",
   "rotation": {
   "auto_rotate": false,
   "rotate_keys": false
   },
   "secret_type": "public_cert",
   "state": 0,
   "state_description": "Pre-activation",
   "versions": [],
   "versions_total": 1
   }
]

ドメインの所有権を検証するために、チャレンジに指定されている TXT レコードを DNS プロバイダー・アカウントのドメインに追加することにより、有効期限が切れる前に pending としてマークされているチャレンジを完了します。

サブドメイン用の証明書 (例えば、 sub1.sub2.domain.com) を注文する場合は、TXT レコードを登録済みドメイン domain.com に追加する必要があります。
追加した TXT レコードが伝搬されていることを確認します。 DNS プロバイダーによっては、完了までに時間がかかる場合があります。
レコードが伝搬されたら、 Secrets Manager 秘密アクションの作成 API を呼び出して、ドメインへのチャレンジを検証してパブリック証明書を作成するように Let 's Encrypt に要求します。
```
 curl -X POST
 --header "Authorization: Bearer {iam_token}"
 --header "Accept: application/json"
 --header "Content-Type: application/json"
 --data '{
     "action_type": "public_cert_action_validate_dns_challenge"
 }'\
 "https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets/{id}/actions"
```
後で証明書を更新する必要がある場合は、シークレット・アクションの作成 API を使用できますが、アクション rotate を使用できます。ただし、手動DNSプロバイダー証明書を Secrets Manager で自動的にローテーションすることはできない。
証明書が発行されたら、DNS プロバイダー・アカウント内のドメインから TXT レコードをクリーンアップして削除します。

パブリック証明書の作成を自動化しますか? ドメインが DNS プロバイダーを介して構成されている場合は、チャレンジを完了するためのスクリプトを作成できます。一部の DNS プロバイダーには、新規レコードが完全に送信されたかどうかを検査する API が用意されています。 DNS プロバイダーがこのオプションを提供していない場合は、指定された時間 (場合によっては最大 1 時間) 待機するようにクライアントを構成できます。 Secrets Manager では、 validate-dns-challenges を呼び出した後、証明書のメタデータを取得することで、証明書の発行状況を確認できる。返された IssuanceInfo.State フィールドが active に変更されると、証明書が発行されます。

CLI を使用した、独自の DNS プロバイダーによるパブリック証明書の注文

Secrets Manager CLI プラグインを使用して、独自の DNS プロバイダーでパブリック証明書を注文するには、 ibmcloud secrets-manager secret-create コマンドを実行します。例えば、以下のコマンドは、指定した認証局からパブリック証明書のシークレットを要求します。

ibmcloud secrets-manager secret-create \
    --secret-name example-public-certificate \
    --secret-description "Extended description for this secret." \
    --secret-type public_cert \
    --secret-group-id bc656587-8fda-4d05-9ad8-b1de1ec7e712 \
    --secret-labels dev,us-south \
    --public-cert-dns manual \
    --certificate-common-name cert_common_name \
    --certificate-alt-names alt_name1,alt_name2 \
    --public-cert-ca lets-encrypt-config \
    --public-cert-key-algorithm RSA2048 \
    --secret-rotation '{"enabled": false, "rotate_keys": false}' \
    --secret-custom-metadata '{"anyKey": "anyValue"}' \
    --secret-version-custom-metadata '{"anyKey": "anyValue"}'

Terraform を使用した Akamai DNS プロバイダーでのパブリック証明書の注文

DNS プロバイダーとして Akamai を使用してパブリック証明書を作成するには、以下の手順を実行します。

CA 構成の追加で定義されているステップに従って、認証局 (CA) 構成を作成します。
DNS 構成として akamai を指定して、新しいパブリック証明書を作成します。

以下のアカマイの認証方法のいずれかを使用します。 edgerc ファイルを使用することも、Akamai 認証資格情報を直接指定することもできます。 Akamai の認証資格情報について詳しくは、こちらを参照してください。

.edgerc ファイルへのパスと、関連する config_section を指定します。

		resource "ibm_sm_public_certificate" "sm_public_certificate" {
				instance_id = local.instance_id
				region = local.region
				name = "test-public-certificate"
				secret_group_id = "default"
				ca = ibm_sm_public_certificate_configuration_ca_lets_encrypt.my_lets_encrypt_config.name
				dns = “akamai”
				akamai {
					edgerc {
						path_to_edgerc = “/path/to/your/edgerc/file”
						config_section = “default”
					}
				}
				rotation {
					auto_rotate = true
					rotate_keys = false
				}
		}

       ```

アカマイの認証情報を入力してください。

		resource "ibm_sm_public_certificate" "sm_public_certificate" {
				instance_id = local.instance_id
				region = local.region
				name = "test-public-certificate"
				secret_group_id = "default"
				ca = ibm_sm_public_certificate_configuration_ca_lets_encrypt.my_lets_encrypt_config.name
				dns = “akamai”
				akamai {
					config {
						client_secret = “your_client_secret”
						host = “your_host”
						access_token = "your_access_token"
						client_token = "your_client_token"
					}
				}
				rotation {
					auto_rotate = true
					rotate_keys = false
				}
		}
         ```

アカマイの該当するドメインに新しく作成されたTXTレコードは自動的に削除されません。

Terraform を使用した独自の DNS プロバイダーでのパブリック証明書の注文

CA 構成の追加で定義されているステップに従って、認証局 (CA) 構成を作成します。

DNS 構成として manual を指定して、新しいパブリック証明書を作成します。

 resource "ibm_sm_public_certificate" "sm_public_certificate" {
     instance_id = local.instance_id
     region = local.region
     name = "test-public-certificate"
     secret_group_id = "default"
     ca = ibm_sm_public_certificate_configuration_ca_lets_encrypt.my_lets_encrypt_config.name
     dns = “manual”
     rotation {
         auto_rotate = true
         rotate_keys = false
     }
 }

応答の例:

{
   "alt_names": [
     "domain2",
     "domain3"
   ],
   "bundle_certs": false,
   "ca": "ca_config_name",
   "common_name": "domain1",
   "created_by": "User",
   "creation_date": "2022-09-13T06:21:33Z",
   "crn": "secret crn",
   "description": "Description for ordered certificate.",
   "downloaded": false,
   "id": "38747ae6-8c69-d745-5276-cdf3157b9021",
   "issuance_info": {
       "auto_rotated": false,
       "challenges": [
         {
             "domain": "domain1",
             "expiration": "2022-09-20T06:21:36Z",
             "status": "pending",
             "txt_record_name": "_acme-challenge.domain1.",
             "txt_record_value": "TA6J7fFYrwP3Jg-S_IAQSj2Ydqfw4Ycm4sMwlzuCcxk"
         },
             {
               "domain": "domain2",
               "expiration": "2022-09-20T06:21:36Z",
               "status": "pending",
               "txt_record_name": "_acme-challenge.domain2.",
               "txt_record_value": "qSDrCkFAViX4xANKuEPcMNairWm1PUtROm6kp9bmSS0"
             },
             {
               "domain": "domain3",
               "expiration": "2022-09-20T06:21:36Z",
               "status": "pending",
               "txt_record_name": "_acme-challenge.domain3.",
               "txt_record_value": "8dcgan91fW6aK3aIhPAVZRkHpbYEoMcCNPpVh1n4tSA"
             }
         ],
       "dns": "manual",
       "ordered_on": "2022-09-13T06:21:33Z",
       "state": 0,
       "state_description": "Pre-activation"
       },
   "key_algorithm": "RSA2048",
   "labels": [],
   "last_update_date": "2022-09-13T06:21:33Z",
   "locks_total": 0,
   "name": "my-public-certificate",
   "rotation": {
       "auto_rotate": false,
       "rotate_keys": false
    },
   "secret_type": "public_cert",
   "state": 0,
   "state_description": "Pre-activation",
   "versions": [],
   "versions_total": 1
}

ドメインの所有権を検証するために、チャレンジに指定されている TXT レコードを DNS プロバイダー・アカウントのドメインに追加することにより、有効期限が切れる前に pending としてマークされているチャレンジを完了します。

サブドメイン用の証明書 (例えば、 sub1.sub2.domain.com) を注文する場合は、TXT レコードを登録済みドメイン domain.com に追加する必要があります。
追加した TXT レコードが伝搬されていることを確認します。 DNS プロバイダーによっては、完了までに時間がかかる場合があります。
レコードが伝搬されたら、Let 's Encrypt を要求して、ドメインに対するユーザー確認用の質問を検証し、パブリック証明書を作成します。

Terraformの ibm_sm_public_certificate_action_validate_manual_dns リソースを使います：
```
 resource "ibm_sm_public_certificate_action_validate_manual_dns" "sm_public_certificate_action_validate_manual_dns_instance" {
     instance_id = local.instance_id
     region = local.region
     secret_id = ibm_sm_public_certificate.sm_public_certificate.secret_id
 }
```
以下の説明に示すように、 Terraform の depends_on メタ引数を使用して、Terraform の構成が正しい論理順序で作成されるようにすることができます。

あるいは、 Secrets Manager シークレット・アクションの作成 API を呼び出して、ドメインへのチャレンジを検証してパブリック証明書を作成するように Let 's Encrypt に要求することもできます。
```
 curl -X POST
 --header "Authorization: Bearer {iam_token}"
 --header "Accept: application/json"
 --header "Content-Type: application/json"
 --data '{
    "action_type": "public_cert_action_validate_dns_challenge"
 }'\
 "https://{instance_ID}.{region}.secrets-manager.appdomain.cloud/api/v2/secrets/{id}/actions"
```
証明書が発行された後（ステータスが active ）、Terraformコマンド terraform apply を再度実行して、公開証明書のTerraformリソースを更新し、新たに発行された証明書を使用する必要があります。
DNS プロバイダー・アカウント内のドメインから TXT レコードをクリーンアップして削除します。