Mettez à jour votre Trust Store pour Adobe la nouvelle hiérarchie de certificat mTLS update-your-trust-store-for-adobes-new-mtls-certificate-hierarchy

Adobe met à jour la hiérarchie d’autorité de certification (CA) utilisée pour émettre les certificats clients pour les connexions mTLS (Mutual Transport Layer Security) sortantes vers vos points d’entrée. Si vos systèmes valident le certificat client mTLS d’Adobe, vous devez ajouter les nouveaux certificats racine et intermédiaires d’Adobe à votre Trust Store avant qu’Adobe ne commence à présenter les certificats émis à partir de la nouvelle hiérarchie. Ce guide explique ce qui change, pourquoi et comment mettre à jour votre Trust Store sur les plateformes courantes.

Qui est affecté who-is-affected

Cette modification affecte tous les points d’entrée que vous gérez qui valident le certificat client mTLS d’Adobe, y compris les points d’entrée de réception pour les destinations d’API HTTP, les actions personnalisées de Adobe Journey Optimizer et les intégrations de transfert d’événement. Si vous utilisez déjà mTLS avec une intégration de Adobe Experience Platform, consultez ce guide et effectuez la mise à jour du Trust Store décrite ci-dessous.

Ce que vous devez faire what-you-need-to-do

Ajoutez les nouveaux certificats d’autorité de certification racine et intermédiaires Adobe au Trust Store ou au lot d’autorité de certification approuvé utilisé par le point d’entrée qui valide le certificat client mTLS Adobe.

Suivez cette séquence :

Il s’agit uniquement d’une mise à jour du Trust Store. Vous n’avez PAS besoin de :

Quand terminer cette mise à jour ? when-to-update

Terminez cette mise à jour dès que possible au lieu d’attendre qu’une connexion spécifique soit affectée. Étant donné qu’un Trust Store peut contenir plusieurs hiérarchies valides en même temps, l’ajout de la nouvelle racine et de la nouvelle intermédiaire n’a désormais aucun effet sur vos connexions en cours.

Adobe effectue la transition des certificats clients mTLS vers la nouvelle hiérarchie de certificats à partir de la mi-2026 et jusqu’au printemps 2027.

Ce qui se passe si vous ne mettez pas à jour what-happens-if-you-dont-update

Une fois qu’Adobe présente un certificat émis à partir de la nouvelle hiérarchie lors d’une connexion à votre point d’entrée, l’établissement de liaison TLS échoue si votre Trust Store n’inclut pas encore les nouveaux certificats racine et intermédiaires. Cela se traduit par un échec de connexion ou de diffusion sur l’intégration affectée. Par exemple, un échec de diffusion de destination ou un appel d’action personnalisée ayant échoué jusqu’à ce que vous mettiez à jour votre Trust Store.

Comment savez-vous que vous êtes prêt ? readiness

La vérification des fichiers de certificat et la confirmation que le point d’entrée de production est prêt diffèrent. La vérification du certificat confirme que les fichiers téléchargés sont valides et correctement chaînés, mais ne confirme pas que le service qui met fin à votre connexion Adobe mTLS utilise la configuration d’approbation mise à jour.

Après avoir suivi les étapes spécifiques à la plateforme ci-dessous, suivez les étapes décrites dans la section Vérifier la mise à jour de votre Trust Store pour confirmer que vos fichiers de certificat et votre chaîne sont valides. Actuellement, Adobe ne fournit pas de test universel de bout en bout qui confirme que votre point d’entrée de production utilise la configuration mise à jour. Confirmez le niveau de préparation en utilisant la méthode de validation prise en charge par votre plateforme ou environnement.

Changements en cours what-is-changing

Adobe émet des certificats client mTLS pour authentifier les connexions sortantes aux points d’entrée que vous contrôlez, tels qu’une destination d’API HTTP un point d’entrée de réception, une action personnalisée Adobe Journey Optimizer ou une intégration de transfert d’événement. Adobe déplace ces certificats d’une hiérarchie de certificats partagée entre l’authentification du serveur et du client vers une hiérarchie dédiée uniquement à l’authentification du client.

Cela signifie que les autorités de certification racine et intermédiaire derrière le certificat client mTLS d’Adobe changent. Cette modification n’affecte pas le fonctionnement du certificat ni la configuration de mTLS dans vos intégrations Adobe.

Pourquoi cela change-t-il ? why-this-is-changing

Les normes du secteur pour les autorités de certification exigent désormais que les certificats utilisés pour l’authentification du serveur et l’authentification du client soient émis à partir de hiérarchies distinctes. Cette séparation permet d’empêcher l’utilisation des certificats en dehors de leur utilisation prévue. Cette exigence s’applique globalement à l’écosystème de certificats public-trust. Il n’est pas spécifique à Adobe ni à une intégration unique.

La nouvelle hiérarchie de certificat new-certificate-hierarchy

Le tableau suivant compare la hiérarchie de certificats actuelle à la nouvelle.

Les deux hiérarchies sont générées par DigiCert, mais il s’agit de programmes racines distincts. Un Trust Store qui n’approuve que DigiCert Global Root G2 n’approuve pas un certificat émis à partir de la nouvelle hiérarchie.

Télécharger les nouveaux certificats d’autorité de certification download-certificates

Ajoutez les deux certificats suivants à votre Trust Store. Certaines plateformes peuvent ne nécessiter que le certificat racine si elles récupèrent automatiquement les certificats intermédiaires. Adobe vous recommande d’ajouter les certificats racine et intermédiaires pour vous assurer que la chaîne complète est disponible pour la validation.

DigiCert conserve des informations sur ses certificats racine de confiance et ses autorités de certification dans sa référence Certificats d’autorité racine de confiance.

DigiCert distribue les deux fichiers au format DER. La plupart des plateformes décrites plus loin dans ce guide utilisent le format PEM. Par conséquent, convertissez les deux fichiers en PEM, sauf si vous utilisez Windows.

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

Avant de poursuivre, vérifiez que vous avez téléchargé les certificats attendus et qu’ils forment une chaîne valide. Vérifiez que l’objet de chaque certificat correspond au nom commun attendu, puis vérifiez que le certificat intermédiaire enchaîne à la racine :

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

Une vérification de chaîne réussie renvoie DigiCertAssuredIDClientCAG2.pem: OK.

Mettre à jour votre Trust Store update-trust-store

Les étapes d’ajout d’un nouveau certificat d’autorité de certification à votre Trust Store dépendent de la plateforme ou du logiciel qui met fin à la connexion mTLS au niveau de votre point d’entrée. Chaque section ci-dessous suppose que vous avez déjà téléchargé et converti les certificats comme décrit dans la section ​ Télécharger les nouveaux certificats d’autorité de certification ​. Les sections suivantes couvrent les plateformes et configurations courantes.

Linux et OpenSSL linux-openssl

Cette opération met à jour le lot d’autorité de certification à l’échelle du système utilisé par OpenSSL et la plupart des bibliothèques TLS sur les distributions basées sur Debian et Ubuntu.

Copiez les fichiers PEM que vous avez téléchargés et convertis dans le répertoire de l’autorité de certification du système, puis recréez le lot approuvé :

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

Fichiers de bundle d’autorité de certification personnalisés custom-ca-bundle

Si votre service fait référence à un fichier de lots d’autorité de certification personnalisé (par exemple, par le biais de --cacert, SSL_CERT_FILE ou CURL_CA_BUNDLE), ajoutez directement le nouveaux certificats que vous avez téléchargés à ce fichier :

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

Assurez-vous que chaque bloc de certificat est séparé par une nouvelle ligne, sans espace supplémentaire entre la fin d’un bloc de -----END CERTIFICATE----- et le début du bloc de -----BEGIN CERTIFICATE----- suivant.

Java (keytool) java-keytool

Les applications Java utilisent leur propre Trust Store, généralement un fichier nommé cacerts, plutôt que le Trust Store du système d’exploitation. Vous devez donc importer directement les certificats que vous avez téléchargés. Tout d’abord, recherchez le fichier cacerts de votre JVM :

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

Importez ensuite les deux certificats (le mot de passe cacerts par défaut est 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

Vérifiez que les deux certificats ont été ajoutés :

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

Pour obtenir l’ensemble complet des options de keytool, consultez le guide de référence des commandes keytool de Oracle.

nginx nginx

nginx utilise la directive ssl_client_certificate pour spécifier les autorités de certification auxquelles elle fait confiance pour la validation du certificat client. Ajoutez les nouveaux certificats que vous avez téléchargés au fichier de lot référencé par cette directive :

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

Testez la configuration et rechargez le nginx pour appliquer la modification :

nginx -t && nginx -s reload

Consultez la documentation ngx_http_ssl_module de nginx pour obtenir la liste complète des directives SSL/TLS, y compris les ssl_client_certificate.

Apache httpd apache-httpd

Apache httpd utilise la directive SSLCACertificateFile pour spécifier les autorités de certification clientes approuvées. Ajoutez les nouveaux certificats que vous avez téléchargés au fichier de lot référencé par cette directive :

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

Testez la configuration et redémarrez Apache httpd pour appliquer la modification :

apachectl configtest && apachectl graceful

Pour obtenir l’ensemble complet des directives mod_ssl, y compris SSLCACertificateFile, consultez la documentation mod_ssl de Apache.

Windows windows

Utilisez les certutil d’une invite de commande avec élévation de privilèges pour ajouter les certificats que vous avez téléchargés aux magasins appropriés :

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

Vous pouvez également utiliser l’interface graphique Windows pour ajouter les certificats aux magasins de certificats de l’ordinateur local. Pour ce faire, ouvrez le composant logiciel enfichable Certificats dans Microsoft Management Console (MMC) et procédez comme suit :

Pour en savoir plus sur la façon dont Windows organise les magasins de certificats, consultez la présentation des magasins de certificats de Microsoft.

AWS aws

AWS utilise différents mécanismes de Trust Store mTLS en fonction du service qui met fin à la connexion.

Pour les API REST Amazon API Gateway utilisant le protocole TLS mutuel, chargez un lot PEM combiné des certificats que vous avez téléchargés vers Amazon S3, puis mettez à jour votre domaine personnalisé pour le référencer.

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

aws apigateway update-domain-name \
      --domain-name api.example.com \
      --patch-operations op=replace,path=/mutualTlsAuthentication/truststoreVersion,value=$(date +%s)

Consultez la documentation TLS mutuel pour les API REST de AWS pour obtenir le guide de configuration complet.

Pour un Application Load Balancer ou un Network Load Balancer utilisant le protocole TLS mutuel, utilisez l’API ELBv2 pour créer ou mettre à jour le Trust Store contenant les certificats CA utilisés pour valider les certificats clients :

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

Si vous disposez déjà d’un Trust Store pour ce listener, mettez-le à jour au lieu d’en créer un nouveau :

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

Associez ensuite le Trust Store au listener qui gère la connexion 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

Consultez la Documentation TLS mutuelle de répartition de charge d’application de AWS pour obtenir le guide de configuration complet.

Si vous gérez cette configuration avec CloudFormation, mettez à jour AWS::ApiGateway::DomainName pour référencer le Trust Store mis à jour via MutualTlsAuthentication.TruststoreUri ou mettez à jour AWS::ElasticLoadBalancingV2::TrustStore pour inclure les nouveaux certificats d’autorité de certification. Par Terraform, mettez à jour aws_api_gateway_domain_name (mutual_tls_authentication.truststore_uri) ou aws_lb_trust_store avec les modifications du Trust Store correspondantes.

Azure azure

Par Azure Application Gateway, chargez les certificats racine et intermédiaires que vous avez téléchargés en tant que certificats clients approuvés, puis joignez-les au profil SSL pour lequel l’authentification du client est activée :

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

Voir Présentation de l’authentification mutuelle de la passerelle d’application de Microsoft pour obtenir des informations sur cette configuration.

Par Azure API Management, ajoutez les certificats d’autorité de certification racine et intermédiaires aux magasins de certificats d’autorité de certification utilisés par la passerelle gérée. Cela Azure API Management permet d’établir la confiance lors de la validation du certificat client Adobe par rapport à la nouvelle hiérarchie.

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

Vous pouvez également ajouter les certificats d’autorité de certification sur le portail Azure. Dans votre instance de gestion des API, sélectionnez Sécurité > Certificats > Certificats d’autorité de certification.

Pour obtenir des instructions détaillées🔗 consultez le guide de Microsoft ajout d’un certificat d’autorité de certification personnalisé dans la gestion des API.

Si vous gérez cette configuration avec Terraform, mettez à jour la configuration de certificat client approuvée dans azurerm_application_gateway (ssl_profile.trusted_client_certificate_names) ou la configuration de certificat d’autorité de certification dans azurerm_api_management_certificate.

Google Cloud google-cloud

Google Cloud Load Balancing utilise un TrustConfig de gestionnaire de certificats pour définir les autorités de certification approuvées pour mTLS.

Créez un fichier de configuration d’approbation qui ajoute les nouveaux certificats d’autorité de certification racine et intermédiaires que vous avez téléchargés au jeu de certificats approuvés pour l’authentification du client :

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

Créez la ressource TrustConfig :

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

Créez ensuite une stratégie TLS de serveur qui référence la configuration d’approbation :

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

Joignez le ServerTlsPolicy à votre proxy HTTPS cible :

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

Si vous gérez cette configuration avec Terraform, mettez à jour google_certificate_manager_trust_config pour inclure la nouvelle autorité de certification racine dans trust_stores.trust_anchors et la nouvelle autorité de certification intermédiaire dans trust_stores.intermediate_cas.

Pour la présentation complète de cette configuration, consultez le guide Configurer le mTLS front-end avec des certificats fournis par l’utilisateur de Google Cloud.

Vérifier la mise à jour de votre Trust Store verify

Après avoir mis à jour votre Trust Store, vérifiez qu’un certificat émis à partir de la nouvelle hiérarchie est validé par rapport à la nouvelle chaîne d’autorité de certification. Créez un lot combiné à partir des nouveaux certificats d’autorité de certification racine et intermédiaires, puis utilisez-le pour vérifier un certificat émis pour l’authentification du client :

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

Si un certificat client est émis à partir de la nouvelle hiérarchie, remplacez client-cert.pem par le chemin d’accès à ce certificat. Un résultat réussi confirme qu’OpenSSL peut valider le certificat par rapport à la nouvelle chaîne d’autorité de certification pour l’authentification du client TLS.

Si aucun certificat client n’est émis à partir de la nouvelle hiérarchie, vous pouvez toujours vérifier que le certificat intermédiaire est validé par rapport à la nouvelle racine :

openssl verify -CAfile DigiCertAssuredIDRootG2.pem DigiCertAssuredIDClientCAG2.pem

Un résultat réussi renvoie DigiCertAssuredIDClientCAG2.pem: OK, confirmant que le certificat intermédiaire est validé par rapport à la nouvelle racine.

Pour confirmer qu’un certificat est émis pour l’authentification du client uniquement, examinez son utilisation de clé étendue :

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

Pour un certificat d’authentification du client uniquement, l’utilisation étendue de la clé doit inclure TLS Web Client Authentication et non TLS Web Server Authentication.

Dépannage troubleshooting

Utilisez les symptômes suivants pour déterminer si un échec de connexion est lié à cette migration.

Si les échecs persistent après l’ajout des nouveaux certificats racine et intermédiaires, vérifiez qu’ils ont été ajoutés au trust store ou au lot utilisé par le service qui met fin à la connexion. Si votre plateforme l’exige, vérifiez également que le service a été rechargé ou redémarré pour appliquer la configuration d’approbation mise à jour.

Questions fréquentes faq

Dois-je faire quoi que ce soit ?

Oui. Si votre point d’entrée valide le certificat client mTLS d’Adobe, ajoutez les nouveaux certificats d’autorité de certification racine et intermédiaires d’Adobe à votre Trust Store. Aucune autre modification de configuration n’est requise.

Est-ce lié à la récupération automatisée des certificats disponible via l’API du service mTLS ?

Non. L’API du service mTLS automatise la récupération et le cycle de vie du certificat client Adobe, et cette automatisation n’est pas affectée par cette modification. La mise à jour de votre Trust Store pour y inclure la nouvelle hiérarchie d’autorité de certification est une action ponctuelle distincte que vous effectuez sur vos propres systèmes.

Mon intégration existante cessera-t-elle de fonctionner ?

Pas immédiatement. Voir Que se passe-t-il si vous ne mettez pas à jour ​ pour savoir quand et comment une intégration est affectée.

Dois-je remplacer mon certificat client ?

Non. Le certificat client Adobe est émis et pivoté automatiquement, comme aujourd’hui. Votre responsabilité se limite à faire confiance à la nouvelle hiérarchie de l’autorité de certification émettrice de votre côté.

Puis-je ajouter la nouvelle hiérarchie d’autorité de certification avant qu’Adobe ne commence à l’utiliser ?

Oui, et Adobe recommande de le faire. Consultez Quand terminer cette mise à jour ​ pour savoir pourquoi son ajout précoce n’interrompt pas vos connexions existantes.

Quand mon intégration sera-t-elle affectée ?

La transition s’effectue par étapes, de la mi-2026 jusqu’au printemps 2027. Voir Quand terminer cette mise à jour pour savoir ce que vous devez faire en attendant.

Documentation connexe related-documentation

Utilisez les ressources suivantes pour en savoir plus sur la configuration mTLS, la récupération des certificats et la gestion du cycle de vie des certificats dans Experience Platform.