ドキュメントExperience PlatformExperience Platform の概要

Adobeの新しいmTLS証明書階層のトラストストアを更新する update-your-trust-store-for-adobes-new-mtls-certificate-hierarchy

最終更新日： 2026年8月19日

作成対象：

  • Developer
  • Admin

Adobeは、エンドポイントに対する送信Mutual Transport Layer Security （mTLS）接続のクライアント証明書の発行に使用される認証局（CA）階層を更新しています。 システムがAdobeのmTLS クライアント証明書を検証する場合は、Adobeが新しい階層から発行された証明書の表示を開始する前に、Adobeの新しいルート証明書と中級CA証明書をトラストストアに追加する必要があります。 このガイドでは、一般的なプラットフォームでトラストストアを更新する理由と方法を説明します。

IMPORTANT
この更新は、信頼ストアに対する1回限りの変更です。 mTLS サービス APIを通じて既に使用している自動証明書の取得とライフサイクルは、とは別のもので、置き換えるものではありません。 この移行の一環として、Adobeのクライアント証明書をリクエスト、ダウンロード、交換する必要はありません。

対象ユーザー who-is-affected

この変更は、HTTP API宛先、Adobe Journey Optimizer カスタムアクション、イベント転送統合のエンドポイントなど、AdobeのmTLS クライアント証明書を検証する管理するすべてのエンドポイントに影響します。 Adobe Experience Platformとの統合でmTLSを既に使用している場合は、このガイドを確認し、以下に説明するtrust storeのアップデートを完了してください。

連携の強化 what-you-need-to-do

Adobeの新しいルート CA証明書と中間CA証明書を、AdobeのmTLS クライアント証明書を検証するエンドポイントで使用されるトラストストアまたは信頼CA バンドルに追加します。

次の順序に従います。

  1. 新しいルート CA証明書と中間CA証明書を、既存の信頼済み証明書と共にトラストストアに追加します。
  2. 現在の信頼できる階層を維持します。 この更新の一部として削除しないでください。
  3. プラットフォームで必要な場合は、信頼設定を適用するか、再読み込みします。
  4. 「​ トラストストアの更新を確認する」の説明に従って、更新を確認します。
  5. 移行の残りの部分では、両方の階層を信頼したままにします。

これはトラストストアの更新のみです。 次の操作は不要です。

  • Adobeから新しいクライアント証明書をリクエストします。
  • Adobe統合でmTLSを有効または設定する方法を変更します。
  • mTLS サービス APIを使用して証明書を取得する方法を変更します。

この更新を完了するタイミング when-to-update

特定の接続が影響を受けるのを待つのではなく、できるだけ早くこの更新を完了します。 トラストストアは複数の有効な階層を同時に保持できるため、新しいルートと中間を追加しても、現在の作業中の接続には影響しません。

Adobeは、2026年半ばから2027年春まで、mTLS クライアント証明書を新しい証明書の階層に移行しています。

更新しない場合はどうなるか what-happens-if-you-dont-update

Adobeがエンドポイントへの接続で新しい階層から発行された証明書を提示すると、トラストストアに新しいルート証明書と中間証明書がまだ含まれていない場合、TLS ハンドシェイクは失敗します。 これは、影響を受ける統合で接続または配信の失敗として表示されます。 例えば、信頼ストアを更新するまで、宛先配信の失敗やカスタムアクション呼び出しの失敗などです。

準備ができていることをどうやって知りますか？ readiness

証明書ファイルを検証することは、実稼動エンドポイントの準備が整っていることを確認することとは異なります。 証明書の検証では、ダウンロードしたファイルが有効で正しく連結されていることを確認しますが、Adobe mTLS接続を終了するサービスが更新された信頼設定を使用していることを確認しません。

以下のプラットフォーム固有の手順を完了したら、「​ トラストストアの更新を確認」セクションで説明されている手順に従って、証明書ファイルとチェーンが有効であることを確認します。 Adobeでは、更新された設定を実稼動エンドポイントが使用していることを確認するエンドツーエンドのユニバーサルテストは現在提供されていません。 プラットフォームや環境がサポートしている検証方法を使用して、準備状況を確認します。

何が変化しているのか what-is-changing

Adobeは、HTTP API destination受信エンドポイント、Adobe Journey Optimizer カスタムアクション、イベント転送の統合など、制御するエンドポイントへのアウトバウンド接続を認証するためにmTLS クライアント証明書を発行します。 Adobeでは、これらの証明書を、サーバー認証とクライアント認証の間で共有される証明書階層から、クライアント認証のみに専用の階層に移行しています。

つまり、AdobeのmTLS クライアント証明書の背後にあるルート証明機関と中間証明機関が変化しています。 この変更は、証明書の機能や、Adobe統合でのmTLSの設定方法には影響しません。

なぜこれが変わるのか why-this-is-changing

証明機関の業界標準では、サーバー認証とクライアント認証に使用される証明書を別の階層から発行する必要が生じるようになりました。 この分離は、証明書が意図した目的外で使用されるのを防ぐのに役立ちます。 この要件は、一般的に公的信用の証明書エコシステム全体に適用されます。 Adobeや他の統合に固有のものではありません。

新しい証明書の階層 new-certificate-hierarchy

次の表は、現在の証明書階層と新しい証明書階層を比較したものです。

現在の階層
新しい階層
拡張キーの使用
TLS Web サーバー認証+ TLS Web クライアント認証
TLS Web クライアント認証のみ
中間型CA
DigiCert Global G2 TLS RSA SHA256 2020 CA1
DigiCert Assured ID Client CA G2
ルート CA
DigiCert Global Root G2
DigiCert Assured ID Root G2

両方の階層はDigiCertによって発行されますが、これらは別々のルートプログラムです。 DigiCert Global Root G2のみを信頼するトラストストアは、新しい階層から発行された証明書を信頼しません。

新しいCA証明書のダウンロード download-certificates

次の両方の証明書をトラストストアに追加します。 一部のプラットフォームでは、中間証明書を自動的に取得する場合、ルート証明書のみを必要とする場合があります。 Adobeでは、ルート証明書と中間証明書の両方を追加して、チェーン全体を検証可能にすることをお勧めします。

証明書
タイプ
共通の名前
ダウンロード
DigiCert Assured ID Root G2
ルート
DigiCert Assured ID Root G2
DigiCertAssuredIDRootG2.crt
DigiCert Assured ID Client CA G2
中間値
DigiCert Assured ID Client CA G2
DigiCertAssuredIDClientCAG2.crt

DigiCertは、信頼されるルート証明書と証明書認証局に関する情報を信頼されるルート認証局証明書参照に保持します。

DigiCertは両方のファイルをDER形式で配布します。 このガイドの後半で説明するプラットフォームのほとんどはPEM形式を使用しているため、Windowsを使用していない限り、両方のファイルをPEMに変換します。

NOTE
Windowsは、元の.crt （DER） ファイルを直接受け入れます。 このガイドの他のすべてのプラットフォームでは、変換された.pem ファイルを使用しています。
curl -O http://cacerts.digicert.com/DigiCertAssuredIDRootG2.crt
curl -O http://cacerts.digicert.com/DigiCertAssuredIDClientCAG2.crt

openssl x509 -inform DER -in DigiCertAssuredIDRootG2.crt -out DigiCertAssuredIDRootG2.pem
openssl x509 -inform DER -in DigiCertAssuredIDClientCAG2.crt -out DigiCertAssuredIDClientCAG2.pem

続行する前に、必要な証明書をダウンロードし、それらが有効なチェーンを形成していることを確認してください。 各証明書のサブジェクトが想定される共通名と一致することを確認し、中間証明書がルートに連鎖していることを確認します。

openssl x509 -in DigiCertAssuredIDRootG2.pem -noout -subject -issuer
openssl x509 -in DigiCertAssuredIDClientCAG2.pem -noout -subject -issuer
openssl verify -CAfile DigiCertAssuredIDRootG2.pem DigiCertAssuredIDClientCAG2.pem

チェーン検証が成功すると、DigiCertAssuredIDClientCAG2.pem: OKが返されます。

トラストストアを更新する update-trust-store

トラストストアに新しいCA証明書を追加する手順は、エンドポイントでmTLS接続を終了するプラットフォームまたはソフトウェアによって異なります。 以下の各セクションでは、新しいCA証明書のダウンロード ​ セクションで説明されているように、証明書を既にダウンロードおよび変換していることを前提としています。 次の節では、一般的なプラットフォームと設定について説明します。

LinuxとOpenSSL linux-openssl

これにより、OpenSSLおよびほとんどのTLS ライブラリがDebian ベースおよびUbuntu ベースのディストリビューションで使用しているシステム全体のCA バンドルが更新されます。

NOTE
RHEL、CentOS、またはFedoraで、PEM ファイルを/etc/pki/ca-trust/source/anchors/にコピーし、代わりにsudo update-ca-trustを実行します。

ダウンロードして変換したPEM ファイル ​をシステム CA ディレクトリにコピーしてから、信頼バンドルを再構築します。

sudo cp DigiCertAssuredIDRootG2.pem /usr/local/share/ca-certificates/DigiCertAssuredIDRootG2.crt
sudo cp DigiCertAssuredIDClientCAG2.pem /usr/local/share/ca-certificates/DigiCertAssuredIDClientCAG2.crt
sudo update-ca-certificates

カスタム CA バンドルファイル custom-ca-bundle

サービスがカスタム CA バンドルファイルを参照している場合（例：--cacert、SSL_CERT_FILE、またはCURL_CA_BUNDLE）、ダウンロードした新しい証明書をそのファイルに直接追加します。

cat DigiCertAssuredIDRootG2.pem >> /path/to/your/ca-bundle.crt
cat DigiCertAssuredIDClientCAG2.pem >> /path/to/your/ca-bundle.crt

各証明書ブロックが改行で区切られていることを確認してください。1つの-----END CERTIFICATE----- ブロックの終わりから次の-----BEGIN CERTIFICATE----- ブロックの始まりまでの間に余白がないことを確認してください。

Java （キーツール） java-keytool

Java アプリケーションは、オペレーティングシステムのトラストストアではなく、通常はcacertsという名前のファイルを独自のトラストストアで使用するため、そこでダウンロードした証明書を直接インポートする必要があります。 まず、JVMのcacerts ファイルを探します。

JAVA_CACERTS="$(dirname $(dirname $(readlink -f $(which java))))/lib/security/cacerts"

次に、両方の証明書をインポートします（デフォルトのcacerts パスワードはchangeitです）。

keytool -importcert -trustcacerts \
  -alias digicert-assured-id-root-g2 \
  -file DigiCertAssuredIDRootG2.pem \
  -keystore "$JAVA_CACERTS" \
  -storepass changeit \
  -noprompt

keytool -importcert -trustcacerts \
  -alias digicert-assured-id-client-ca-g2 \
  -file DigiCertAssuredIDClientCAG2.pem \
  -keystore "$JAVA_CACERTS" \
  -storepass changeit \
  -noprompt

両方の証明書が追加されたことを確認します。

keytool -list -keystore "$JAVA_CACERTS" -storepass changeit -alias digicert-assured-id-root-g2
keytool -list -keystore "$JAVA_CACERTS" -storepass changeit -alias digicert-assured-id-client-ca-g2
NOTE
アプリケーションでカスタム信頼ストア（-Djavax.net.ssl.trustStore=/path/to/truststore.jksで指定）を使用している場合は、JVMのデフォルトのcacerts ファイルではなく、そのファイルに証明書をインポートします。

keytool オプションの完全なセットについては、Oracleのkeytool コマンド リファレンス ​を参照してください。

nginx nginx

nginxは、ssl_client_certificate ディレクティブを使用して、クライアント証明書の検証に信頼するCAを指定します。 ダウンロードした新しい証明書を、そのディレクティブによって参照されるバンドルファイルに追加します。

cat DigiCertAssuredIDRootG2.pem >> /etc/nginx/ssl/trusted-client-cas.pem
cat DigiCertAssuredIDClientCAG2.pem >> /etc/nginx/ssl/trusted-client-cas.pem

設定をテストし、nginxを再読み込みして変更を適用します。

nginx -t && nginx -s reload

ssl_client_certificateを含むSSL/TLS ディレクティブの完全なリストについては、nginxのngx_http_ssl_module ドキュメント ​を参照してください。

Apache httpd apache-httpd

Apache httpdはSSLCACertificateFile ディレクティブを使用して、信頼できるクライアント CAを指定します。 ダウンロードした新しい証明書を、そのディレクティブによって参照されるバンドルファイルに追加します。

cat DigiCertAssuredIDRootG2.pem >> /etc/httpd/ssl/trusted-client-cas.pem
cat DigiCertAssuredIDClientCAG2.pem >> /etc/httpd/ssl/trusted-client-cas.pem

設定をテストし、Apache httpdを再起動して変更を適用します。

apachectl configtest && apachectl graceful

SSLCACertificateFileを含むmod_ssl ディレクティブの完全なセットについては、Apacheのmod_ssl ドキュメント ​を参照してください。

Windows windows

昇格されたコマンドプロンプトからcertutilを使用して、ダウンロードした証明書を適切なストアに追加します。

certutil -addstore Root DigiCertAssuredIDRootG2.crt
certutil -addstore CA DigiCertAssuredIDClientCAG2.crt

または、Windows グラフィカル インターフェイスを使用して、ローカル コンピューターの証明書ストアに証明書を追加することもできます。 これを行うには、Microsoft Management Console （MMC）で証明書スナップインを開き、次の手順に従います。

  1. mmc.exeを実行します。
  2. File > Add/Remove Snap-in​を選択します。
  3. Add or Remove Snap-ins ウィンドウで、Certificates​を選択してから、Add​を選択します。
  4. Certificates snap-in ウィンドウで、Computer account​を選択してから、Next​を選択します。
  5. Select Computer ウィンドウで、Local computer​を選択したままにして、Finish​を選択します。
  6. Add or Remove Snap-in ウィンドウで、OK​を選択します。
  7. コンソールツリーで、Certificates (Local Computer) > Trusted Root Certification Authorities > Certificates​を展開します。
  8. Certificates​を右クリックし、All Tasks > Import​を選択して、DigiCertAssuredIDRootG2.crtを読み込みます。
  9. Intermediate Certification Authorities > Certificates​を展開します。
  10. Certificates​を右クリックし、All Tasks > Import​を選択して、DigiCertAssuredIDClientCAG2.crtを読み込みます。
NOTE
certutil コマンドの場合は、変換された.pem バージョンではなく、ダウンロードされた元の.crt ファイルを使用します。 MMC スナップインを使用する場合は、どちらの形式でも機能します。

Windowsが証明書ストアを整理する方法の背景については、Microsoftの証明書ストアの概要を参照してください。

AWS aws

AWSは、どのサービスが接続を終了するかによって、異なるmTLS トラストストストメカニズムを使用します。

相互TLSを使用するAmazon API GatewayのREST APIの場合、ダウンロードした証明書の結合PEM バンドルをからAmazon S3にアップロードし、カスタムドメインを更新して参照します。

NOTE
まだ必要な他のCAとのトラストストストアバンドルが既にある場合は、それらを組み合わせバンドルにも含めます。以下のコマンドは、2つの新しい証明書のみを含むバンドルを作成します。
cat DigiCertAssuredIDRootG2.pem DigiCertAssuredIDClientCAG2.pem > truststore.pem
aws s3 cp truststore.pem s3://your-bucket/truststore.pem

aws apigateway update-domain-name \
  --domain-name api.example.com \
  --patch-operations op=replace,path=/mutualTlsAuthentication/truststoreUri,value=s3://your-bucket/truststore.pem
IMPORTANT
API Gatewayがトラストストアをキャッシュします。 S3 オブジェクトを更新した後、truststoreVersionをバンプ （またはURIを変更）して、API Gatewayが変更をピックアップします。
code language-shell 
aws apigateway update-domain-name \
      --domain-name api.example.com \
      --patch-operations op=replace,path=/mutualTlsAuthentication/truststoreVersion,value=$(date +%s)

完全な設定ガイドについては、AWSのmutual TLS for REST APIs ドキュメント ​を参照してください。

相互TLSを使用するApplication Load BalancerまたはNetwork Load Balancerの場合、ELBv2 APIを使用して、クライアント証明書の検証に使用するCA証明書を含む信頼ストアを作成または更新します。

aws elbv2 create-trust-store \
  --name digicert-assured-id-trust-store \
  --ca-certificates-bundle-s3-bucket your-bucket \
  --ca-certificates-bundle-s3-key truststore.pem

このリスナーの信頼ストアが既にある場合は、新しいリスナーを作成する代わりに更新してください。

aws elbv2 modify-trust-store \
  --trust-store-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:truststore/your-trust-store/abc123 \
  --ca-certificates-bundle-s3-bucket your-bucket \
  --ca-certificates-bundle-s3-key truststore.pem

次に、トラストストアを、mTLS接続を処理するリスナーに関連付けます。

aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:listener/app/my-alb/abc123/def456 \
  --mutual-authentication Mode=verify,TrustStoreArn=arn:aws:elasticloadbalancing:us-east-1:123456789012:truststore/your-trust-store/abc123

完全な設定ガイドについては、AWSのApplication Load Balancer mutual TLS ドキュメント ​を参照してください。

この設定をCloudFormationで管理する場合は、AWS::ApiGateway::DomainNameを更新してMutualTlsAuthentication.TruststoreUri経由で更新されたトラストストアを参照するか、AWS::ElasticLoadBalancingV2::TrustStoreを更新して新しいCA証明書を含めます。 Terraformの場合、aws_api_gateway_domain_name （mutual_tls_authentication.truststore_uri）またはaws_lb_trust_storeを更新し、対応するトラストストアを変更します。

Azure azure

Azure Application Gatewayの場合、ダウンロードした​ ルート証明書と中間証明書を信頼できるクライアント証明書としてアップロードし、クライアント認証が有効になっているSSL プロファイルに添付します。

az network application-gateway root-cert create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name DigiCertAssuredIDRootG2 \
  --cert-file DigiCertAssuredIDRootG2.pem

az network application-gateway root-cert create \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name DigiCertAssuredIDClientCAG2 \
  --cert-file DigiCertAssuredIDClientCAG2.pem

az network application-gateway ssl-profile update \
  --gateway-name myAppGateway \
  --resource-group myResourceGroup \
  --name myMtlsSslProfile \
  --client-auth-configuration verify-client-cert-issuer-dn=true \
  --trusted-client-certificates DigiCertAssuredIDRootG2 DigiCertAssuredIDClientCAG2

この設定の背景については、MicrosoftのApplication Gateway相互認証の概要を参照してください。

Azure API Managementの場合、ルート CA証明書と中間CA証明書を、管理対象ゲートウェイで使用されるCA証明書ストアに追加します。 これにより、Azure API Managementは、新しい階層に対してAdobeのクライアント証明書を検証する際に信頼を確立できます。

az apim certificate create \
  --resource-group myResourceGroup \
  --service-name myApiManagement \
  --certificate-id digicert-assured-id-root-g2 \
  --certificate-file DigiCertAssuredIDRootG2.pem

az apim certificate create \
  --resource-group myResourceGroup \
  --service-name myApiManagement \
  --certificate-id digicert-assured-id-client-ca-g2 \
  --certificate-file DigiCertAssuredIDClientCAG2.pem

Azure ポータルにCA証明書を追加することもできます。 API Management インスタンスから、セキュリティ > 証明書 > CA証明書​を選択します。

詳しい手順については、Microsoftの​ ガイド「API管理でのカスタム CA証明書の追加」を参照してください。

この設定をTerraformで管理する場合は、azurerm_application_gatewayの信頼できるクライアント証明書設定（ssl_profile.trusted_client_certificate_names）またはazurerm_api_management_certificateのCA証明書設定を更新してください。

Google Cloud google-cloud

Google Cloud Load Balancingは、証明書マネージャーTrustConfigを使用して、mTLS用に信頼されるCAを定義します。

NOTE
既に他の信頼できるCAとのTrustConfigがある場合は、更新されたYAML ファイルでgcloud certificate-manager trust-configs updateを使用して、新しいトラストアンカーと中間を含めるのではなく、新しいトラストアンカーと中間を含めるように更新します。

ダウンロードした新しいルート CA証明書と中間CA証明書を、クライアント認証に対して信頼される証明書セットに追加する信頼設定ファイルを作成します。

trustStores:
  - trustAnchors:
      - pemCertificate: |
          <paste contents of DigiCertAssuredIDRootG2.pem here>
    intermediateCas:
      - pemCertificate: |
          <paste contents of DigiCertAssuredIDClientCAG2.pem here>

TrustConfig リソースを作成します。

gcloud certificate-manager trust-configs create digicert-assured-id-trust-config \
  --source=trust-config.yaml \
  --location=global

次に、信頼設定を参照するサーバーのTLS ポリシーを作成します。

mtlsPolicy:
  clientValidationMode: REJECT_INVALID
  clientValidationTrustConfig: projects/YOUR_PROJECT/locations/global/trustConfigs/digicert-assured-id-trust-config

gcloud network-security server-tls-policies create my-mtls-policy \
  --source=server-tls-policy.yaml \
  --location=global

ターゲット HTTPS プロキシにServerTlsPolicyを添付します。

gcloud compute target-https-proxies update my-https-proxy \
  --server-tls-policy=my-mtls-policy \
  --region=global

この設定をTerraformで管理する場合は、google_certificate_manager_trust_configを更新して、新しいルート CAをtrust_stores.trust_anchorsに、新しい中間CAをtrust_stores.intermediate_casに含めます。

この設定の完全なチュートリアルについては、Google Cloudの​ ユーザーが提供する証明書を使用したフロントエンド mTLSの設定 ガイドを参照してください。

トラストストアの更新を確認する verify

トラストストアを更新した後、新しい階層から発行された証明書が新しいCA チェーンに対して検証されていることを確認します。 新しいルート CA証明書と中間CA証明書を組み合わせたバンドルを作成し、それを使用してクライアント認証用に発行された証明書を検証します。

cat DigiCertAssuredIDRootG2.pem DigiCertAssuredIDClientCAG2.pem > digicert-assured-id-chain.pem
openssl verify -CAfile digicert-assured-id-chain.pem -purpose sslclient client-cert.pem

新しい階層から発行されたクライアント証明書がある場合は、client-cert.pemをその証明書へのパスに置き換えます。 結果が成功すると、OpenSSLがTLS クライアント認証用に新しいCA チェーンに対して証明書を検証できることを確認します。

新しい階層から発行されたクライアント証明書がない場合でも、中間証明書が新しいルートに対して検証されていることを確認できます。

openssl verify -CAfile DigiCertAssuredIDRootG2.pem DigiCertAssuredIDClientCAG2.pem

正常な結果はDigiCertAssuredIDClientCAG2.pem: OKを返し、中間証明書が新しいルートに対して検証されることを確認します。

証明書がクライアント認証用にのみ発行されていることを確認するには、その拡張キーの使用状況を調べます。

openssl x509 -in client-cert.pem -noout -ext extendedKeyUsage

クライアント認証のみの証明書の場合、拡張キーの使用にはTLS Web Server AuthenticationではなくTLS Web Client Authenticationを含める必要があります。

トラブルシューティング troubleshooting

次の現象を使用して、接続障害がこの移行に関連しているかどうかを特定します。

症状
考えられる原因
以前に動作していたmTLS接続でTLS ハンドシェイクが失敗し、他の設定変更は行われませんでした
トラストストアには、新しいルート CA証明書と中間CA証明書がまだ含まれていません。
未知または信頼されていない発行者を参照する証明書の検証エラー
トラストストアに、中間証明書、ルート証明書、またはその両方がありません。
一部のmTLS認証済み接続のみに影響し、他の接続には影響しないエラー
個々の接続は、異なるタイミングで新しい階層に移行します。 更新されたトラストストアのないエンドポイントは、新しい階層を既に使用している接続に対してのみ失敗します。
証明書の読み込みに失敗するか、読み込まれた証明書が破損しています
プラットフォームに間違ったファイル形式を使用しています。 このガイドのほとんどのプラットフォームでは、変換された.pem ファイルが必要です。Windowsでは、元の.crt （DER）ファイルが必要です。 新しいCA証明書のダウンロード ​を参照してください。

新しいルート証明書と中間証明書を追加した後も引き続きエラーが表示される場合は、接続を終了するサービスで使用されるトラストストアまたはバンドルに追加されたことを確認します。 プラットフォームで必要な場合は、更新された信頼設定を適用するために、サービスがリロードまたは再起動されたことも確認します。

よくある質問 faq

何かする必要がありますか？

はい。 エンドポイントがAdobeのmTLS クライアント証明書を検証する場合は、Adobeの新しいルート CA証明書と中間CA証明書をトラストストアに追加します。 他の設定の変更は必要ありません。

これは、mTLS サービス APIを通じて利用できる自動証明書取得に関連していますか？

いいえ。 mTLS サービス APIは、Adobeのクライアント証明書の取得とライフサイクルを自動化します。この自動化機能は、この変更の影響を受けません。 新しいCA階層を含めるようにトラストストアを更新することは、独自のシステムに対して実行する個別の1回限りのアクションです。

既存の統合は機能しませんか？

すぐには無理です。 統合がいつ、どのように影響を受けるかについてを更新しなかった場合はどうなりますか。

クライアント証明書を置き換える必要がありますか？

いいえ。 Adobeのクライアント証明書は、現在と同様に自動的に発行およびローテーションされます。 お客様の責任は、新しい発行CA階層を自分の側で信頼することに限定されます。

Adobeが新しいCA階層を使用する前に、新しいCA階層を追加できますか？

はい、Adobeでは行うことをお勧めします。 この更新を完了するタイミング を参照して、早期に追加しても既存の接続が中断されない理由を確認してください。

これは統合にどの程度影響しますか？

移行は、2026年半ばから2027年春まで段階的に進められます。 この更新を完了するタイミングについては、この更新を完了するタイミング ​を参照してください。

Experience PlatformでのmTLS設定、証明書の取得、証明書ライフサイクル管理について詳しくは、次のリソースを参照してください。

recommendation-more-help
experience-platform-help-landing