文档Experience PlatformExperience Platform 概述

为Adobe的新mTLS证书层次结构更新信任存储区 update-your-trust-store-for-adobes-new-mtls-certificate-hierarchy

最近更新： 2026年8月19日

创建对象：

  • Developer
  • Admin

Adobe正在更新证书颁发机构(CA)层次结构，该层次结构用于向端点的出站双向传输层安全性(mTLS)连接颁发客户端证书。 如果您的系统验证Adobe的mTLS客户端证书，则需要先将Adobe的新根证书和中间CA证书添加到您的信任存储区，然后Adobe才能开始提交从新层次结构颁发的证书。 本指南将说明更改的内容、更改原因以及如何更新常见平台上的信任存储区。

IMPORTANT
此更新是对您的信任存储区的一次性更改。 它不同于您通过mTLS服务API已使用的自动证书检索和生命周期，也不会取代它。 在此迁移过程中，您不需要请求、下载或替换Adobe的客户端证书。

受影响的人员 who-is-affected

此更改会影响您管理用于验证Adobe mTLS客户端证书的任何端点，包括HTTP API目标的接收端点、Adobe Journey Optimizer自定义操作和事件转发集成。 如果您已将mTLS与任何Adobe Experience Platform集成一起使用，请查看本指南并完成如下所述的信任存储区更新。

您需要执行的操作 what-you-need-to-do

将Adobe的新根证书和中间CA证书添加到信任存储区或由验证Adobe mTLS客户端证书的端点使用的受信任CA捆绑包中。

请遵循以下顺序：

  1. 将新的根证书和中间CA证书添加到信任存储区，以及现有的信任证书。
  2. 将您当前受信任的层级保留在适当位置。 您不会将它作为此更新的一部分删除。
  3. 如果您的平台需要，请应用或重新加载信任配置。
  4. 验证更新，如验证信任存储区更新中所述。
  5. 在转换的其余部分中，将两个层级都保留为可信状态。

这是仅信任存储区更新。 您不需要：

  • 从Adobe请求新的客户端证书。
  • 更改在Adobe集成中启用或配置mTLS的方式。
  • 修改通过mTLS服务API检索证书的方式。

何时完成此更新 when-to-update

尽快完成此更新，而不是等待特定连接受到影响。 由于信任存储区可以同时保存多个有效层次结构，因此现在添加新的根和中间对当前工作连接没有影响。

Adobe将从2026年中开始将mTLS客户端证书转换为新证书层次结构，并将一直持续到2027年春季。

如果不更新将发生什么情况 what-happens-if-you-dont-update

一旦Adobe在连接到端点的连接上提供从新层次结构颁发的证书，如果您的信任存储不包括新的根证书和中间证书，则TLS握手将失败。 这会在受影响的集成中显示为连接或投放失败。 例如，在更新信任存储区之前，目标投放失败或自定义操作调用失败。

你怎么知道你准备好了？ readiness

验证您的证书文件与确认您的生产端点已就绪不是一回事。 证书验证会确认下载的文件是否有效以及链接是否正确，但不会确认终止Adobe mTLS连接的服务是否使用更新的信任配置。

完成以下特定于平台的步骤后，请按照验证信任存储区更新部分中描述的步骤操作，以确认您的证书文件和链有效。 Adobe当前不提供通用端到端测试来确认您的生产端点正在使用更新的配置。 使用您的平台或环境支持的任何验证方法确认就绪性。

更改内容 what-is-changing

Adobe发出mTLS客户端证书来对到您控制的端点的出站连接进行身份验证，例如HTTP API目标接收端点、Adobe Journey Optimizer自定义操作或事件转发集成。 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和大多数基于Debian和Ubuntu的发布上的TLS库使用的系统范围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

请确保每个证书块都用换行符分隔，并且一个-----END CERTIFICATE-----块的结尾与另一个-----BEGIN CERTIFICATE-----块的开头之间没有额外的空格。

Java(keytool) 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/TLS指令（包括ssl_client_certificate）的完整列表，请参阅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命令，使用下载的原始.crt文件，而不是转换的.pem版本。 使用MMC管理单元时，这两种格式都有效。

有关Windows如何组织证书存储的背景，请参阅Microsoft的证书存储概述。

AWS aws

AWS使用不同的mTLS信任存储机制，具体取决于终止连接的服务。

对于使用双方TLS的Amazon API Gateway个REST API，请将下载🔗的证书的组合PEM捆绑包上载到Amazon S3，然后更新您的自定义域以引用它。

NOTE
如果您已经拥有与其他CA的信任存储捆绑包，则也将其包含在组合捆绑包中 — 下面的命令将创建一个仅包含两个新证书的捆绑包。
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的REST API双方TLS文档🔗。

对于使用双方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的应用程序负载平衡器双向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的应用程序网关相互身份验证概述。

对于Azure API Management，将根证书和中间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管理实例中，选择​安全 > 证书 > 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证书添加到受信任用于客户端身份验证的证书集：

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

将ServerTlsPolicy附加到目标HTTPS代理：

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

如果使用Terraform管理此配置，请更新google_certificate_manager_trust_config以在trust_stores.trust_anchors中包含新根CA，在trust_stores.intermediate_cas中包含新中间CA。

有关此配置的完整演练，请参阅Google Cloud的使用用户提供的证书设置前端mTLS指南。

验证信任存储区更新 verify

更新信任存储区后，验证从新层次结构颁发的证书是否针对新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 Client Authentication而非TLS Web Server Authentication。

故障排除 troubleshooting

使用以下症状来确定连接失败是否与此迁移有关。

症状
可能的原因
以前工作的mTLS连接上的TLS握手失败，没有进行其他配置更改
您的信任存储区尚未包含新的根证书和中间CA证书。
引用未知或不受信任的颁发者的证书验证错误
您的信任存储区缺少中间证书和/或根证书。
仅影响某些mTLS身份验证连接，而不影响其他连接的故障
单个连接在不同时间转换为新层次结构。 对于已使用新层次结构的连接，没有更新信任存储的端点将失败。
证书导入失败，或导入的证书似乎已损坏
您对平台使用的文件格式不正确。 本指南中的大多数平台都需要转换的.pem文件；Windows需要原始.crt (DER)文件。 请参阅下载新的CA证书。

如果在添加新根证书和中间证书后继续看到故障，请验证它们是否已添加到信任存储区或服务终止连接所使用的捆绑包中。 如果您的平台需要，还要确认服务已重新加载或重新启动以应用更新的信任配置。

常见问题 faq

我需要做任何事情吗？

是的。 如果您的端点验证Adobe的mTLS客户端证书，请将Adobe的新根证书和中间CA证书添加到您的信任存储区。 不需要更改其他配置。

这是否与通过mTLS服务API提供的自动证书检索相关？

没有。 mTLS服务API可自动检索Adobe的客户端证书，并使该自动化不受此更改的影响。 更新您的信任存储区以包括新的CA层次结构是在您自己的系统上执行的一次性单独操作。

我现有的集成是否会停止工作？

不是马上。 请参阅如果不更新将发生什么情况，以了解集成受到的时间和方式影响。

是否需要替换我的客户端证书？

没有。 Adobe的客户端证书现在将自动颁发和轮换。 您的责任仅限于信任您这边的新发行CA层次结构。

我能否在Adobe开始使用新的CA层次结构之前添加它？

是的，Adobe建议这样做。 请参阅何时完成此更新，了解提前添加它不会中断现有连接的原因。

这何时会影响我的集成？

过渡阶段从2026年年中开始分阶段进行，一直持续到2027年春。 请参阅何时完成此更新，了解在此期间要做什么。

使用以下资源了解有关Experience Platform中mTLS配置、证书检索和证书生命周期管理的更多信息。

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