Aktualisieren des Trust Store für die neue mTLS-Zertifikatshierarchie von Adobe update-your-trust-store-for-adobes-new-mtls-certificate-hierarchy

Adobe aktualisiert die Zertifizierungsstellen-Hierarchie (CA), die zum Ausstellen der Client-Zertifikate für ausgehende MTLS-Verbindungen (Mutual Transport Layer Security) an Ihre Endpunkte verwendet wird. Wenn Ihre Systeme das mTLS-Client-Zertifikat von Adobe validieren, müssen Sie die neuen Stamm- und Zwischenzertifikate von Adobe zu Ihrem Trust Store hinzufügen, bevor Adobe Zertifikate präsentiert, die aus der neuen Hierarchie ausgestellt wurden. In diesem Handbuch wird erläutert, was sich ändert und warum sich Ihr Trust Store über gängige Plattformen hinweg aktualisiert.

Wer ist betroffen who-is-affected

Diese Änderung wirkt sich auf alle von Ihnen verwalteten Endpunkte aus, die das mTLS-Client-Zertifikat von Adobe validieren, einschließlich Empfangsendpunkte für HTTP-API-Ziele, benutzerdefinierte Adobe Journey Optimizer-Aktionen und Ereignisweiterleitungs-Integrationen. Wenn Sie bereits mTLS mit einer Adobe Experience Platform-Integration verwenden, lesen Sie dieses Handbuch und schließen Sie das unten beschriebene Trust Store-Update ab.

Was Sie tun müssen what-you-need-to-do

Fügen Sie die neuen Stamm- und Zwischenzertifikat-Zertifikate von Adobe dem Trust Store oder dem vertrauenswürdigen CA-Bundle hinzu, das vom Endpunkt verwendet wird, der das mTLS-Client-Zertifikat von Adobe validiert.

Dieser Reihenfolge folgen:

Dies ist nur ein Trust Store-Update. Sie müssen NICHT:

Wann diese Aktualisierung abgeschlossen werden soll when-to-update

Schließen Sie dieses Update so bald wie möglich ab, anstatt darauf zu warten, dass eine bestimmte Verbindung betroffen ist. Da ein Trust Store mehrere gültige Hierarchien gleichzeitig enthalten kann, hat das Hinzufügen des neuen Stamm- und Zwischenspeichers jetzt keine Auswirkungen auf Ihre aktuellen, funktionierenden Verbindungen.

Adobe stellt ab Mitte 2026 und bis zum Frühjahr 2027 mTLS-Client-Zertifikate auf die neue Zertifikatshierarchie um.

Was passiert, wenn Sie nicht aktualisieren? what-happens-if-you-dont-update

Sobald Adobe ein Zertifikat, das von der neuen Hierarchie für eine Verbindung zu Ihrem Endpunkt ausgestellt wurde, vorlegt, schlägt der TLS-Handshake fehl, wenn Ihr Trust Store die neuen Stamm- und Zwischenzertifikate noch nicht enthält. Dies kann in der betroffenen Integration als Verbindungs- oder Versandfehler angezeigt werden. Dies kann beispielsweise ein Zielbereitstellungsfehler oder ein fehlgeschlagener benutzerdefinierter Aktionsaufruf sein, bis Sie Ihren Trust Store aktualisieren.

Woher weißt du, dass du bereit bist? readiness

Die Überprüfung Ihrer Zertifikatdateien ist nicht dasselbe wie die Bestätigung, dass Ihr Produktionsendpunkt bereit ist. Die Zertifikatsprüfung bestätigt, dass die heruntergeladenen Dateien gültig und korrekt verkettet sind, aber nicht, dass der Dienst, der Ihre Adobe-mTLS-Verbindung beendet, die aktualisierte Vertrauenskonfiguration verwendet.

Nachdem Sie die unten stehenden plattformspezifischen Schritte ausgeführt haben, führen Sie die Schritte aus, die im Abschnitt Überprüfen der Aktualisierung ​ Trust Store“ beschrieben sind, um zu bestätigen, dass Ihre Zertifikatdateien und -ketten gültig sind. Adobe bietet derzeit keinen universellen End-to-End-Test, der bestätigt, dass Ihr Produktionsendpunkt die aktualisierte Konfiguration verwendet. Bestätigen Sie die Bereitschaft mit einer Validierungsmethode, die Ihre Plattform oder Umgebung unterstützt.

Änderungen what-is-changing

Adobe stellt mTLS-Client-Zertifikate zur Authentifizierung ausgehender Verbindungen zu Endpunkten aus, die Sie steuern, z. B. ein HTTP-APIZiel, ein Empfangs-Endpunkt, eine benutzerdefinierte Adobe Journey Optimizer-Aktion oder eine Ereignisweiterleitungsintegration. Adobe verschiebt diese Zertifikate von einer Zertifikatshierarchie, die von der Server- und Client-Authentifizierung gemeinsam genutzt wird, in eine Hierarchie, die ausschließlich der Client-Authentifizierung dient.

Dies bedeutet, dass sich die Stamm- und Zwischenzertifikatstellen hinter dem mTLS-Client-Zertifikat von Adobe ändern. Diese Änderung wirkt sich nicht darauf aus, wie das Zertifikat funktioniert und wie Sie mTLS in Ihren Adobe-Integrationen konfigurieren.

Warum sich das ändert why-this-is-changing

Branchenstandards für Zertifizierungsstellen verlangen jetzt, dass Zertifikate, die für die Server- und Client-Authentifizierung verwendet werden, aus separaten Hierarchien ausgestellt werden. Durch diese Trennung wird verhindert, dass Zertifikate außerhalb ihres Verwendungszwecks verwendet werden. Die Anforderung gilt allgemein für das gesamte System der Zertifikate, denen die Öffentlichkeit vertraut. Sie ist nicht spezifisch für Adobe oder eine einzelne Integration.

Die neue Zertifikatshierarchie new-certificate-hierarchy

In der folgenden Tabelle wird die aktuelle Zertifikatshierarchie mit der neuen verglichen.

Beide Hierarchien werden von DigiCert ausgegeben, sind aber separate Stammprogramme. Ein Trust Store, der nur DigiCert Global Root G2 vertraut, vertraut einem von der neuen Hierarchie ausgestellten Zertifikat nicht.

Neue Zertifizierungsstellenzertifikate herunterladen download-certificates

Fügen Sie die beiden folgenden Zertifikate zu Ihrem Trust Store hinzu. Einige Plattformen benötigen möglicherweise nur das Stammzertifikat, wenn sie automatisch Zwischenzertifikate abrufen. Adobe empfiehlt, sowohl das Stamm- als auch das Zwischenzertifikat hinzuzufügen, um sicherzustellen, dass die vollständige Kette zur Validierung verfügbar ist.

DigiCert speichert Informationen zu vertrauenswürdigen Stammzertifikaten und Zertifizierungsstellen in seiner Referenz Vertrauenswürdige Stammzertifikate.

DigiCert verteilt beide Dateien im DER-Format. Die meisten Plattformen, die weiter unten in diesem Handbuch behandelt werden, verwenden das PEM-Format. Konvertieren Sie daher beide Dateien in PEM, es sei denn, Sie verwenden 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

Bevor Sie fortfahren, vergewissern Sie sich, dass Sie die erwarteten Zertifikate heruntergeladen haben und dass sie eine gültige Kette bilden. Überprüfen Sie, ob der Betreff jedes Zertifikats mit dem erwarteten allgemeinen Namen übereinstimmt, und stellen Sie dann sicher, dass das Zwischenzertifikat mit dem Stamm verkettet ist:

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

Eine erfolgreiche Kettenüberprüfung gibt DigiCertAssuredIDClientCAG2.pem: OK zurück.

Aktualisieren des Trust Store update-trust-store

Die Schritte zum Hinzufügen eines neuen Zertifizierungsstellen-Zertifikats zu Ihrem Trust Store hängen von der Plattform oder Software ab, die die mTLS-Verbindung an Ihrem Endpunkt beendet. In jedem der folgenden Abschnitte wird davon ausgegangen, dass Sie die Zertifikate bereits heruntergeladen und konvertiert haben, wie im Abschnitt Herunterladen der neuen Zertifizierungsstellenzertifikate beschrieben. In den folgenden Abschnitten werden gängige Plattformen und Konfigurationen beschrieben.

Linux und OpenSSL linux-openssl

Dies aktualisiert das systemweite CA-Bundle, das von OpenSSL und den meisten TLS-Bibliotheken auf Debian- und Ubuntu-basierten Distributionen verwendet wird.

Kopieren Sie die PEM-Dateien, die Sie heruntergeladen und konvertiert haben in das CA-Verzeichnis des Systems und erstellen Sie dann das Trust Bundle neu:

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

Benutzerdefinierte CA-Bundle-Dateien custom-ca-bundle

Wenn Ihr Dienst auf eine benutzerdefinierte CA-Bundle-Datei verweist (z. B. über --cacert, SSL_CERT_FILE oder CURL_CA_BUNDLE), hängen Sie die neuen von Ihnen heruntergeladenen Zertifikate direkt an diese Datei an:

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

Stellen Sie sicher, dass jeder Zertifikatblock durch einen Zeilenumbruch getrennt ist, sodass zwischen dem Ende eines -----END CERTIFICATE----- und dem Beginn des nächsten -----BEGIN CERTIFICATE----- keine zusätzlichen Leerzeichen auftreten.

Java (Keytool) java-keytool

Java-Anwendungen verwenden ihren eigenen Trust Store, normalerweise eine Datei mit dem Namen cacerts anstelle des Trust Store für das Betriebssystem, sodass Sie die Zertifikate, die Sie heruntergeladen haben direkt dorthin importieren müssen. Suchen Sie zunächst die cacerts-Datei Ihrer JVM:

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

Importieren Sie dann beide Zertifikate (das Standardkennwort für cacerts lautet 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

Bestätigen Sie, dass beide Zertifikate hinzugefügt wurden:

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

Die vollständige Liste der keytool Optionen finden Sie in der Oracle-keytool-Befehlsreferenz.

nginx nginx

nginx verwendet die ssl_client_certificate-Direktive, um anzugeben, welchen CAs sie für die Validierung von Client-Zertifikaten vertraut. Hängen Sie die neuen Zertifikate, die Sie heruntergeladen haben an die Paketdatei an, auf die diese Anweisung verweist:

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

Testen Sie die Konfiguration und laden Sie nginx neu, um die Änderung anzuwenden:

nginx -t && nginx -s reload

In der Dokumentation ngx_http_ssl_module“ von nginx finden ​ eine vollständige Liste der SSL-/TLS-Anweisungen, einschließlich ssl_client_certificate.

Apache httpd apache-httpd

Apache httpd verwendet die SSLCACertificateFile-Direktive, um vertrauenswürdige Client-CAs anzugeben. Hängen Sie die neuen Zertifikate, die Sie heruntergeladen haben an die Paketdatei an, auf die diese Anweisung verweist:

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

Testen Sie die Konfiguration und starten Sie Apache httpd neu, um die Änderung anzuwenden:

apachectl configtest && apachectl graceful

Den vollständigen Satz der mod_ssl-Anweisungen, einschließlich SSLCACertificateFile, finden Sie in der Apache-Dokumentation mod_ssl.

Windows windows

Verwenden Sie certutil von einer Eingabeaufforderung mit erhöhten Rechten, um die Zertifikate, die Sie heruntergeladen haben den entsprechenden Stores hinzuzufügen:

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

Alternativ können Sie die Windows grafische Oberfläche verwenden, um die Zertifikate zu den Zertifikatspeichern des lokalen Computers hinzuzufügen. Öffnen Sie dazu das Zertifikat-Snap-In Microsoft Management Console (MMC) und führen Sie die folgenden Schritte aus:

Hintergrundinformationen zum Organisieren von Zertifikatspeichern durch Windows finden Sie unter Übersicht über Zertifikatspeicher von Microsoft.

AWS aws

AWS verwendet verschiedene mTLS-Trust-Store-Mechanismen, je nachdem, welcher Service die Verbindung beendet.

Laden Sie für Amazon API Gateway REST-APIs mit gegenseitigem TLS ein kombiniertes PEM-Bundle der Zertifikate, die Sie heruntergeladen haben in Amazon S3 hoch und aktualisieren Sie dann Ihre benutzerdefinierte Domain, um darauf zu verweisen.

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)

Weitere Informationen finden Sie ​ vollständigen Konfigurationshandbuch in der Dokumentation zu TLS für RESTAPIs von AWS.

Verwenden Sie für einen Application Load Balancer oder Network Load Balancer mit gegenseitigem TLS die ELBv2-API, um den Trust Store zu erstellen oder zu aktualisieren, der die zum Überprüfen von Client-Zertifikaten verwendeten CA-Zertifikate enthält:

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

Wenn Sie bereits über einen Trust Store für diesen Listener verfügen, aktualisieren Sie ihn, anstatt einen neuen zu erstellen:

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

Verknüpfen Sie dann den Trust Store mit dem Listener, der die mTLS-Verbindung verarbeitet:

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

Das vollständige Konfigurationshandbuch finden Sie in der ​ zur gegenseitigen TLS- von AWS.

Wenn Sie diese Konfiguration mit CloudFormation verwalten, aktualisieren Sie AWS::ApiGateway::DomainName, um über MutualTlsAuthentication.TruststoreUri auf den aktualisierten Trust Store zu verweisen, oder aktualisieren Sie AWS::ElasticLoadBalancingV2::TrustStore, um die neuen CA-Zertifikate einzuschließen. Aktualisieren Sie Terraform aws_api_gateway_domain_name (mutual_tls_authentication.truststore_uri) oder aws_lb_trust_store mit den entsprechenden Trust Store-Änderungen.

Azure azure

Laden Sie Azure Application Gateway die Stamm- und Zwischenzertifikate, die Sie heruntergeladen haben als vertrauenswürdige Client-Zertifikate hoch und fügen Sie sie dann an das SSL-Profil an, für das die Client-Authentifizierung aktiviert ist:

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

Siehe MicrosoftÜbersicht über die gegenseitige ​ des Anwendungs-Gateways für Hintergrundinformationen zu dieser Konfiguration.

Fügen Sie Azure API Management die Stamm- und Zwischenzertifikat-Zertifikate zu den vom verwalteten Gateway verwendeten Zertifizierungsstellen-Zertifikatspeichern hinzu. Auf diese Weise können Azure API Management beim Überprüfen des Adobe-Client-Zertifikats anhand der neuen Hierarchie Vertrauenswürdigkeit herstellen.

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

Sie können die Zertifizierungsstellenzertifikate auch im Azure-Portal hinzufügen. Wählen Sie in Ihrer API-Verwaltungsinstanz Sicherheit > Zertifikate > CA-Zertifikate.

Eine schrittweise Anleitung finden Sie ​ Handbuch von Microsoft zum Hinzufügen eines benutzerdefinierten CAZertifikats in der API-Verwaltung .

Wenn Sie diese Konfiguration mit Terraform verwalten, aktualisieren Sie die Konfiguration des vertrauenswürdigen Client-Zertifikats in azurerm_application_gateway (ssl_profile.trusted_client_certificate_names) oder die Konfiguration des CA-Zertifikats in azurerm_api_management_certificate.

Google Cloud google-cloud

Google Cloud Load Balancing verwendet eine Certificate Manager-TrustConfig, um die CAs zu definieren, die für mTLS als vertrauenswürdig eingestuft sind.

Erstellen Sie eine Vertrauenskonfigurationsdatei, die die neuen Stammzertifikate und Zwischenzertifikate, die Sie heruntergeladen haben zum Satz von Zertifikaten hinzufügt, die für die Client-Authentifizierung als vertrauenswürdig eingestuft sind:

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

Erstellen Sie die TrustConfig Ressource:

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

Erstellen Sie dann eine Server-TLS-Richtlinie, die auf die Vertrauenskonfiguration verweist:

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

Fügen Sie den ServerTlsPolicy an Ihren Ziel-HTTPS-Proxy an:

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

Wenn Sie diese Konfiguration mit Terraform verwalten, aktualisieren Sie google_certificate_manager_trust_config, um die neue Stamm-CA in trust_stores.trust_anchors und die neue zwischengeschaltete CA in trust_stores.intermediate_cas einzuschließen.

Eine vollständige Anleitung für diese Konfiguration finden Sie im Handbuch Einrichten von Frontend-mTLS mit vom Benutzer bereitgestellten Zertifikaten von Google Cloud.

Trust Store-Aktualisierung überprüfen verify

Nachdem Sie Ihren Trust Store aktualisiert haben, überprüfen Sie, ob ein von der neuen Hierarchie ausgestelltes Zertifikat mit der neuen Zertifizierungsstellenkette übereinstimmt. Erstellen Sie ein kombiniertes Bundle aus den neuen Stamm- und Zwischenzertifikat-Zertifikaten und verwenden Sie es dann, um ein für die Client-Authentifizierung ausgestelltes Zertifikat zu überprüfen:

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

Wenn Sie ein von der neuen Hierarchie ausgestelltes Client-Zertifikat haben, ersetzen Sie client-cert.pem durch den Pfad zu diesem Zertifikat. Ein erfolgreiches Ergebnis bestätigt, dass OpenSSL das Zertifikat für die TLS-Client-Authentifizierung anhand der neuen Zertifizierungsstellenkette überprüfen kann.

Wenn Sie kein über die neue Hierarchie ausgestelltes Client-Zertifikat haben, können Sie dennoch überprüfen, ob das Zwischenzertifikat anhand des neuen Stamms validiert wird:

openssl verify -CAfile DigiCertAssuredIDRootG2.pem DigiCertAssuredIDClientCAG2.pem

Ein erfolgreiches Ergebnis gibt DigiCertAssuredIDClientCAG2.pem: OK zurück, das bestätigt, dass das Zwischenzertifikat anhand des neuen Stamms validiert wird.

Um zu bestätigen, dass ein Zertifikat nur für die Client-Authentifizierung ausgestellt wird, überprüfen Sie die Verwendung des erweiterten Schlüssels:

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

Bei einem Zertifikat, das nur die Client-Authentifizierung enthält, sollte die erweiterte Schlüsselverwendung TLS Web Client Authentication und nicht TLS Web Server Authentication umfassen.

Fehlerbehebung troubleshooting

Verwenden Sie die folgenden Symptome, um festzustellen, ob ein Verbindungsfehler mit dieser Migration zusammenhängt.

Wenn nach dem Hinzufügen der neuen Stamm- und Zwischenzertifikate weiterhin Fehler auftreten, stellen Sie sicher, dass diese zu dem Trust Store oder Bundle hinzugefügt wurden, der/das vom Dienst verwendet wird, der die Verbindung beendet. Falls von Ihrer Plattform benötigt, überprüfen Sie auch, ob der Dienst neu geladen oder neu gestartet wurde, um die aktualisierte Vertrauenskonfiguration anzuwenden.

Häufig gestellte Fragen faq

Muss ich etwas tun?

Ja. Wenn Ihr Endpunkt das mTLS-Client-Zertifikat von Adobe validiert, fügen Sie die neuen Stamm- und Zwischenzertifikat von Adobe zu Ihrem Trust Store hinzu. Es sind keine weiteren Konfigurationsänderungen erforderlich.

Bezieht sich dies auf den automatisierten Zertifikatabruf, der über die mTLS-Service-API verfügbar ist?

Nein. Die mTLS Service-API automatisiert den Abruf und den Lebenszyklus des Adobe-Client-Zertifikats. Diese Automatisierung ist von dieser Änderung nicht betroffen. Die Aktualisierung Ihres Trust Stores zur Aufnahme der neuen Zertifizierungsstellen-Hierarchie ist eine separate, einmalige Aktion, die Sie auf Ihren eigenen Systemen durchführen.

Funktioniert meine vorhandene Integration nicht mehr?

Nicht sofort. Siehe Was passiert, wenn Sie nicht aktualisieren, wann und wie eine Integration betroffen ist.

Muss ich mein Client-Zertifikat ersetzen?

Nein. Das Client-Zertifikat von Adobe wird wie gewohnt automatisch ausgestellt und rotiert. Ihre Verantwortung beschränkt sich darauf, der neuen ausstellenden Zertifizierungsstellen-Hierarchie auf Ihrer Seite zu vertrauen.

Kann ich die neue Zertifizierungsstellen-Hierarchie hinzufügen, bevor Adobe sie verwendet?

Ja, und Adobe empfiehlt dies. Unter Wann Sie dieses Update abschließen erfahren Sie, warum das frühzeitige Hinzufügen keine Unterbrechung Ihrer vorhandenen Verbindungen verursacht.

Wann wird sich dies auf meine Integration auswirken?

Der Übergang erfolgt schrittweise von Mitte 2026 bis zum Frühjahr 2027. Was ​ in der Zwischenzeit tun ​, finden Sie unter „Wann ist dieses Update abzuschließen?“.

Verwandte Dokumentation related-documentation

Verwenden Sie die folgenden Ressourcen, um mehr über die mTLS-Konfiguration, den Zertifikatabruf und die Verwaltung des Zertifikatlebenszyklus in Experience Platform zu erfahren.