IBM Cloud Docs
SSL/TLS 公開証明書の注文

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 を使用すると、証明書をオーダーできます。

  1. コンソールで、**「メニュー」**アイコン「メニュー」アイコン **>「リソース・リスト」**をクリックします。

  2. サービスのリストから、Secrets Manager のインスタンスを選択します。

  3. **「シークレット」テーブルで、「追加」**をクリックします。

  4. 公開証明書の注文 」タイルをクリックします。

  5. 証明書を簡単に識別するための名前と説明を追加します。

  6. シークレットに割り当てるシークレット・グループを選択します。

    シークレット・グループがありませんか。 「シークレット・グループ」フィールドで、「作成」 をクリックすると、新規グループの名前と説明を入力できます。 新しいグループにシークレットが自動的に追加されます。 シークレット・グループについて詳しくは、シークレットの編成をチェックしてください。

  7. オプション: インスタンス内の類似シークレットを検索しやすくするためのラベルを追加します。

  8. オプション: シークレットまたは特定のバージョンのシークレットにメタデータを追加します。

    1. ファイルをアップロードするか、メタデータとバージョン・メタデータを JSON 形式で入力します。
  9. 次へ をクリックします。

  10. 認証局構成を選択します。

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

  11. 証明書の公開鍵の生成に使用する鍵アルゴリズムを選択します。

選択した鍵アルゴリズムによって、キーの生成および証明書の署名に使用する暗号化アルゴリズム(RSAまたはECDSA)とキーサイズが決まります。 より長い有効期間の証明書については、より長いキー長を使用して、より強固な暗号化保護を提供することが推奨されます。 オプションには、RSA2048RSA4096ECDSA256、およびECDSA384があります。

  1. オプション: 証明書の拡張オプションを有効にします。

  2. 発行された証明書を中間証明書とバンドルするには、バンドル・トグルを**「オン」**に切り替えます。 証明書をバンドルした後に、バンドルを解除することはできません。 証明書をバンドルしないことを選択した場合、これを後で変更することはできません。変更するには、新規シークレットを作成する必要があります。

  3. 証明書の自動ローテーションを有効にするには、ローテーション・トグルを**「オン」**に切り替えます。 証明書の有効期限が切れる 31 日前に、ローテーションが行われます。

  4. 各ローテーション時に証明書を使用して新しいシークレット・キーを要求するには、キー再設定トグルを**「オン」**に切り替えます。

  5. DNS プロバイダー構成を選択します。

選択した構成によって、ドメインの所有権を検証する DNS プロバイダーが決まります。 インスタンスに定義されている構成を表示するには、**「シークレット・エンジン」 > 「パブリック証明書」**に移動します。

  1. 要求に含めるドメインを追加します。

  2. **「ドメインの選択」**をクリックします。

  3. ドメインのリストから、証明書の共通名を選択します。

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

    オプションで、有効なドメインを手動で追加することもできます。ドメインを手動で追加する分野。

  4. 次へ をクリックします。

  5. 証明書の詳細を確認します。

  6. 追加 をクリックします。

証明書を注文すると、ドメイン検証が行われ、選択したドメインの所有権が確認されます。 このプロセスが完了するまでに数分かかることがあります。 証明書詳細を送信すると、選択された認証局に 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-prototype=
'{
    "name": "example-public-certificate",
    "description": "Extended description for this secret.",
    "secret_type": "public_cert",
    "secret_group_id": "bc656587-8fda-4d05-9ad8-b1de1ec7e712",
    "labels": [
        "dev","us-south"
    ],
    "dns": "dns_provider",
    "common_name": "cert_common_name"
    "alt_names": [
        "alt_name1", "alt_name2"
    ],
    "ca": "lets-encrypt-config",
    "key_algorithm": "RSA2048",
    "rotation": {
        "auto_rotate": true,
        "rotate_keys":false
        },
    "custom_metadata" : {
        "anyKey" : "anyValue"
    },
    "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
        }
    }

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

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

  1. コンソールで、**「メニュー」**アイコン「メニュー」アイコン **>「リソース・リスト」**をクリックします。

  2. サービスのリストから、Secrets Manager のインスタンスを選択します。

  3. **「シークレット」テーブルで、「追加」**をクリックします。

  4. 公開証明書の注文 」タイルをクリックします。

  5. 証明書を簡単に識別するための名前と説明を追加します。

  6. シークレットに割り当てるシークレット・グループを選択します。

    シークレット・グループがありませんか。 「シークレット・グループ」フィールドで、「作成」 をクリックすると、新規グループの名前と説明を入力できます。 新しいグループにシークレットが自動的に追加されます。 シークレット・グループについて詳しくは、シークレットの編成をチェックしてください。

  7. オプション: インスタンス内の類似シークレットを検索しやすくするためのラベルを追加します。

  8. オプション: シークレットまたは特定のバージョンのシークレットにメタデータを追加します。

    1. ファイルをアップロードするか、メタデータとバージョン・メタデータを JSON 形式で入力します。
  9. 次へ をクリックします。

  10. 認証局構成を選択します。

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

  1. 証明書の公開鍵の生成に使用する鍵アルゴリズムを選択します。

選択した鍵アルゴリズムによって、キーの生成および証明書の署名に使用する暗号化アルゴリズム(RSAまたはECDSA)とキーサイズが決まります。 より長い有効期間の証明書については、より長いキー長を使用して、より強固な暗号化保護を提供することが推奨されます。 オプションには、RSA2048RSA4096ECDSA256、およびECDSA384があります。

  1. オプション: 証明書の拡張オプションを有効にします。
  2. 発行された証明書を中間証明書とバンドルするには、バンドル・トグルを**「オン」**に切り替えます。 証明書をバンドルした後に、バンドルを解除することはできません。 証明書をバンドルしないことを選択した場合、これを後で変更することはできません。変更するには、新規シークレットを作成する必要があります。
  3. 各ローテーション時に証明書を使用して新しいシークレット・キーを要求するには、キー再設定トグルを**「オン」**に切り替えます。
  4. DNS プロバイダーとして 「手動」 を選択します。
  5. 要求に含めるドメインを追加します。

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

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

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

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

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

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

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

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

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

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

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

  4. 追加した TXT レコードが伝搬されていることを確認します。 DNS プロバイダーによっては、完了までに時間がかかる場合があります。

  5. レコードが伝搬されたら、 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 を使用できます。 ただし、 Secrets Manager内の手動 DNS プロバイダー証明書を自動的にローテートすることはできません。

  6. 証明書が発行されたら、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-prototype \
'{
    "name": "example-public-certificate",
    "description": "Extended description for this secret.",
    "secret_group_id": "bc656587-8fda-4d05-9ad8-b1de1ec7e712",
    "labels": [
        "dev","us-south"
    ],
    "dns": "manual",
    "common_name": "cert_common_name"
    "alt_names": [
        "alt_name1", "alt_name2"
    ],
    "ca": "lets-encrypt-config",
    "key_algorithm": "RSA2048",
    "rotation": {
        "enabled": false,
        "rotate_keys":false
        },
    "custom_metadata" : {
        "anyKey" : "anyValue"
    },
    "version_custom_metadata" : {
        "anyKey" : "anyValue"
    }
}

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

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

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

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

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

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

    1. .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
      				}
      		}
      
      
      
    	2. Provide your Akamai's authentication credentials.
    
    		```terraform {: pre}
    			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 プロバイダーでのパブリック証明書の注文

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

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

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

  2. 追加した TXT レコードが伝搬されていることを確認します。 DNS プロバイダーによっては、完了までに時間がかかる場合があります。

  3. レコードが伝搬されたら、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"
  1. 証明書が発行された後(ステータスが active )、Terraformコマンド terraform apply を再度実行して、公開証明書のTerraformリソースを更新し、新たに発行された証明書を使用する必要があります。

  2. DNS プロバイダー・アカウント内のドメインから TXT レコードをクリーンアップして削除します。