Aggiorna l’archivio fonti attendibili per la nuova gerarchia di certificati mTLS di Adobe update-your-trust-store-for-adobes-new-mtls-certificate-hierarchy

Adobe sta aggiornando la gerarchia di autorità di certificazione (CA) utilizzata per emettere i certificati client per le connessioni mTLS (Mutual Transport Layer Security) in uscita agli endpoint. Se i sistemi convalidano il certificato client mTLS di Adobe, è necessario aggiungere i nuovi certificati CA radice e intermedia di Adobe all’archivio fonti attendibili prima che Adobe inizi a presentare i certificati rilasciati dalla nuova gerarchia. Questa guida spiega cosa cambia, perché e come aggiornare il tuo Trust Store su piattaforme comuni.

Chi è interessato who-is-affected

Questa modifica interessa qualsiasi endpoint gestito che convalida il certificato client mTLS di Adobe, inclusi gli endpoint di ricezione per le destinazioni API HTTP, le azioni personalizzate Adobe Journey Optimizer e le integrazioni di Inoltro eventi. Se utilizzi già mTLS con un’integrazione Adobe Experience Platform, consulta questa guida e completa l’aggiornamento dell’archivio fonti attendibili descritto di seguito.

Operazioni da eseguire what-you-need-to-do

Aggiungi i nuovi certificati CA radice e intermedia di Adobe all’archivio fonti attendibili o al bundle di CA attendibili utilizzato dall’endpoint che convalida il certificato client mTLS di Adobe.

Segui questa sequenza:

Questo è solo un aggiornamento dell’archivio fonti attendibili. NON è necessario:

Quando completare l’aggiornamento when-to-update

Completa questo aggiornamento il prima possibile invece di attendere che venga interessata una connessione specifica. Poiché un archivio fonti attendibili può contenere più gerarchie valide contemporaneamente, l’aggiunta della nuova radice e della intermedia non ha alcun effetto sulle connessioni correnti in esecuzione.

Adobe sta passando i certificati client mTLS alla nuova gerarchia di certificati da metà 2026 e continuerà fino alla primavera 2027.

Cosa succede se non aggiorni what-happens-if-you-dont-update

Una volta che Adobe presenta un certificato rilasciato dalla nuova gerarchia su una connessione all’endpoint, l’handshake TLS non riesce se l’archivio fonti attendibili non include ancora i nuovi certificati principali e intermedi. Ciò si manifesta come un errore di connessione o consegna nell’integrazione interessata. Ad esempio, un errore di consegna di destinazione o una chiamata di azione personalizzata non riuscita, fino all’aggiornamento dell’archivio fonti attendibili.

Come lo sapete che siete pronte? readiness

La verifica dei file di certificato non è la stessa cosa della conferma che l’endpoint di produzione è pronto. La verifica del certificato conferma che i file scaricati sono validi e correttamente concatenati, ma non conferma che il servizio che termina la connessione Adobe mTLS stia utilizzando la configurazione di attendibilità aggiornata.

Dopo aver completato i passaggi specifici per la piattaforma riportati di seguito, seguire i passaggi descritti nella sezione Verificare che l’aggiornamento dell’archivio fonti attendibili sia valido per i file di certificato e la catena. Al momento Adobe non fornisce un test end-to-end universale che confermi che l’endpoint di produzione utilizza la configurazione aggiornata. Conferma la conformità utilizzando qualsiasi metodo di convalida supportato dalla piattaforma o dall’ambiente in uso.

Che cosa sta cambiando what-is-changing

Adobe rilascia certificati client mTLS per autenticare connessioni in uscita agli endpoint controllati, ad esempio una destinazione API HTTP che riceve l’endpoint, un’azione personalizzata Adobe Journey Optimizer o un’integrazione di Inoltro eventi. Adobe sta spostando questi certificati da una gerarchia di certificati condivisa tra l’autenticazione server e client a una gerarchia dedicata esclusivamente all’autenticazione client.

Ciò significa che le autorità di certificazione principali e intermedie alla base del certificato client mTLS di Adobe stanno cambiando. Questa modifica non influisce sul funzionamento del certificato o sulla configurazione di mTLS nelle integrazioni Adobe.

Perché questo sta cambiando why-this-is-changing

Gli standard di settore per le autorità di certificazione ora richiedono che i certificati utilizzati per l’autenticazione server e l’autenticazione client vengano rilasciati da gerarchie separate. Questa separazione aiuta a evitare che i certificati vengano utilizzati al di fuori dello scopo previsto. Il requisito si applica in generale all’intero ecosistema dei certificati con attendibilità pubblica. Non è specifico per Adobe o per una singola integrazione.

La nuova gerarchia di certificati new-certificate-hierarchy

Nella tabella seguente viene confrontata la gerarchia di certificati corrente con quella nuova.

Entrambe le gerarchie sono emesse da DigiCert, ma sono programmi principali separati. Un archivio fonti attendibili solo per DigiCert Global Root G2 non considererà attendibile un certificato emesso dalla nuova gerarchia.

Scarica i nuovi certificati CA download-certificates

Aggiungere entrambi i certificati seguenti all’archivio fonti attendibili. Alcune piattaforme possono richiedere solo il certificato radice se recuperano automaticamente i certificati intermedi. Adobe consiglia di aggiungere i certificati radice e intermedi per garantire che la catena completa sia disponibile per la convalida.

DigiCert mantiene le informazioni sui certificati radice attendibili e sulle autorità di certificazione nel suo riferimento Certificati autorità radice attendibili.

DigiCert distribuisce entrambi i file in formato DER. La maggior parte delle piattaforme descritte più avanti in questa guida utilizzano il formato PEM, pertanto è possibile convertire entrambi i file in PEM a meno che non si utilizzi 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

Prima di continuare, verifica di aver scaricato i certificati previsti e che formino una catena valida. Verifica che il soggetto di ciascun certificato corrisponda al nome comune previsto, quindi verifica che il certificato intermedio sia concatenato alla radice:

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

Una verifica a catena ha restituito DigiCertAssuredIDClientCAG2.pem: OK.

Aggiornare l’archivio fonti attendibili update-trust-store

I passaggi per aggiungere un nuovo certificato CA all’archivio fonti attendibili dipendono dalla piattaforma o dal software che termina la connessione mTLS nell’endpoint. Ogni sezione seguente presuppone che tu abbia già scaricato e convertito i certificati come descritto in Scarica i nuovi certificati CA. Le sezioni seguenti descrivono piattaforme e configurazioni comuni.

Linux e OpenSSL linux-openssl

Questo aggiorna il bundle CA a livello di sistema utilizzato da OpenSSL e dalla maggior parte delle librerie TLS sulle distribuzioni basate su Debian e Ubuntu.

Copiare i file PEM scaricati e convertiti nella directory CA di sistema, quindi ricreare il bundle di attendibilità:

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

File bundle CA personalizzati custom-ca-bundle

Se il servizio fa riferimento a un file del bundle CA personalizzato (ad esempio tramite --cacert, SSL_CERT_FILE o CURL_CA_BUNDLE), aggiungere i nuovi certificati scaricati direttamente a tale file:

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

Assicurarsi che ogni blocco di certificato sia separato da una nuova riga, senza spazi vuoti aggiuntivi tra la fine di un blocco -----END CERTIFICATE----- e l’inizio del blocco -----BEGIN CERTIFICATE----- successivo.

Java (keytool) java-keytool

Le applicazioni Java utilizzano un proprio archivio di attendibilità, in genere un file denominato cacerts, anziché l’archivio di attendibilità del sistema operativo, pertanto è necessario importare direttamente i certificati scaricati. Individua innanzitutto il file cacerts della JVM:

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

Importare quindi entrambi i certificati (la password predefinita di 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

Conferma l’aggiunta di entrambi i certificati:

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

Per il set completo di keytool opzioni, vedere riferimento comando keytool di Oracle.

nginx nginx

nginx utilizza la direttiva ssl_client_certificate per specificare le CA considerate attendibili per la convalida del certificato client. Aggiungi i nuovi certificati scaricati al file del bundle a cui fa riferimento la direttiva:

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

Verificare la configurazione e ricaricare nginx per applicare la modifica:

nginx -t && nginx -s reload

Per l’elenco completo delle direttive SSL/TLS, incluso ssl_client_certificate, consulta la documentazione di nginx relativa a {ngx_http_ssl_module.

Apache httpd apache-httpd

Apache httpd utilizza la direttiva SSLCACertificateFile per specificare le CA client attendibili. Aggiungi i nuovi certificati scaricati al file del bundle a cui fa riferimento la direttiva:

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

Verificare la configurazione e riavviare Apache httpd per applicare la modifica:

apachectl configtest && apachectl graceful

Per il set completo di mod_ssl direttive, incluso SSLCACertificateFile, consulta la documentazione mod_ssl di Apache.

Windows windows

Utilizza certutil da un prompt dei comandi con privilegi elevati per aggiungere i certificati scaricati agli archivi appropriati:

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

In alternativa, è possibile utilizzare l’interfaccia grafica Windows per aggiungere i certificati agli archivi certificati del computer locale. Per eseguire questa operazione, aprire lo snap-in Certificati in Microsoft Management Console (MMC) e seguire la procedura seguente:

Per informazioni generali su come Windows organizza gli archivi certificati, vedi panoramica sugli archivi certificati di Microsoft.

AWS aws

AWS utilizza diversi meccanismi dell’archivio di attendibilità mTLS a seconda del servizio che termina la connessione.

Per le API REST Amazon API Gateway che utilizzano TLS reciproco, carica un bundle PEM combinato dei certificati scaricati in Amazon S3, quindi aggiorna il dominio personalizzato in modo che faccia riferimento a esso.

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)

Per la guida alla configurazione completa, consulta la documentazione TLS reciproco di AWS per le API REST.

Per un Application Load Balancer o un Network Load Balancer che utilizza TLS reciproco, utilizzare l’API ELBv2 per creare o aggiornare l’archivio fonti attendibili contenente i certificati CA utilizzati per convalidare i certificati client:

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

Se si dispone già di un archivio fonti attendibili per questo listener, aggiornarlo anziché crearne uno nuovo:

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

Associare quindi l’archivio fonti attendibili al listener che gestisce la connessione 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

Per la guida alla configurazione completa, consulta la documentazione TLS reciproca del load balancer dell’applicazione di AWS.

Se gestisci questa configurazione con CloudFormation, aggiorna AWS::ApiGateway::DomainName per fare riferimento all’archivio fonti attendibili aggiornato tramite MutualTlsAuthentication.TruststoreUri oppure aggiorna AWS::ElasticLoadBalancingV2::TrustStore per includere i nuovi certificati CA. Per Terraform, aggiornare aws_api_gateway_domain_name (mutual_tls_authentication.truststore_uri) o aws_lb_trust_store con le modifiche dell’archivio fonti attendibili corrispondenti.

Azure azure

Per Azure Application Gateway, caricare i certificati radice e intermedi scaricati come certificati client attendibili, quindi allegarli al profilo SSL in cui è abilitata l’autenticazione client:

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

Per informazioni sulla configurazione in background, vedere Panoramica sull’autenticazione reciproca di Gateway applicazioni di Microsoft.

Per Azure API Management, aggiungere i certificati CA radice e intermedia agli archivi certificati CA utilizzati dal gateway gestito. Ciò consente a Azure API Management di stabilire l’attendibilità durante la convalida del certificato client di Adobe rispetto alla nuova gerarchia.

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

Puoi anche aggiungere i certificati CA nel portale Azure. Dall’istanza di gestione API, selezionare Sicurezza > Certificati > Certificati CA.

Per istruzioni dettagliate, consulta la guida di Microsoft all’aggiunta di un certificato CA personalizzato in Gestione API.

Se si gestisce questa configurazione con Terraform, aggiornare la configurazione del certificato client attendibile in azurerm_application_gateway (ssl_profile.trusted_client_certificate_names) o la configurazione del certificato CA in azurerm_api_management_certificate.

Google Cloud google-cloud

Google Cloud Load Balancing utilizza un gestore certificati TrustConfig per definire le CA attendibili per mTLS.

Creare un file di configurazione dei trust che aggiunga i nuovi certificati CA radice e intermedia scaricati al set di certificati attendibili per l’autenticazione client:

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

Crea la risorsa TrustConfig:

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

Creare quindi un criterio TLS server che faccia riferimento alla configurazione di attendibilità:

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

Allega ServerTlsPolicy al proxy HTTPS di destinazione:

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

Se si gestisce questa configurazione con Terraform, aggiornare google_certificate_manager_trust_config per includere la nuova CA radice in trust_stores.trust_anchors e la nuova CA intermedia in trust_stores.intermediate_cas.

Per informazioni dettagliate su questa configurazione, vedere Guida alla configurazione di mTLS front-end con certificati forniti dall’utente di Google Cloud.

Verificare l’aggiornamento dell’archivio fonti attendibili verify

Dopo aver aggiornato l’archivio fonti attendibili, verificare che un certificato emesso dalla nuova gerarchia venga convalidato in base alla nuova catena di CA. Crea un bundle combinato dai nuovi certificati CA radice e intermedio, quindi utilizzalo per verificare un certificato rilasciato per l’autenticazione client:

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

Se si dispone di un certificato client emesso dalla nuova gerarchia, sostituire client-cert.pem con il percorso di tale certificato. Un risultato positivo conferma che OpenSSL può convalidare il certificato rispetto alla nuova catena di CA per l’autenticazione client TLS.

Se non disponi di un certificato client emesso dalla nuova gerarchia, puoi comunque verificare che il certificato intermedio sia convalidato in base alla nuova radice:

openssl verify -CAfile DigiCertAssuredIDRootG2.pem DigiCertAssuredIDClientCAG2.pem

In caso di esito positivo, viene restituito DigiCertAssuredIDClientCAG2.pem: OK, a conferma che il certificato intermedio viene convalidato in base alla nuova radice.

Per confermare che un certificato viene rilasciato solo per l’autenticazione client, controlla l’utilizzo della chiave estesa:

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

Per un certificato di sola autenticazione client, l’utilizzo della chiave estesa deve includere TLS Web Client Authentication e non TLS Web Server Authentication.

Risoluzione dei problemi troubleshooting

Utilizza i seguenti sintomi per identificare se un errore di connessione è correlato a questa migrazione.

Se dopo l’aggiunta dei nuovi certificati radice e intermedi continuano a verificarsi errori, verificare che siano stati aggiunti all’archivio o al bundle attendibili utilizzato dal servizio che interrompe la connessione. Se richiesto dalla piattaforma, verificare inoltre che il servizio sia stato ricaricato o riavviato per applicare la configurazione di attendibilità aggiornata.

Domande frequenti faq

Devo fare qualcosa?

Sì. Se l’endpoint convalida il certificato client mTLS di Adobe, aggiungi i nuovi certificati CA radice e intermedia di Adobe all’archivio fonti attendibili. Non sono richieste altre modifiche alla configurazione.

È correlato al recupero automatico dei certificati disponibile tramite l’API del servizio mTLS?

No. L’API del servizio mTLS automatizza il recupero e il ciclo di vita del certificato client di Adobe e tale automazione non è influenzata da questa modifica. L’aggiornamento dell’archivio fonti attendibili per includere la nuova gerarchia CA è un’azione separata eseguita una tantum sui tuoi sistemi.

L’integrazione esistente smetterà di funzionare?

Non immediatamente. Vedi Cosa succede se non aggiorni per quando e come viene interessata un’integrazione.

Sostituire il certificato client?

No. Il certificato client di Adobe viene rilasciato e ruotato automaticamente, come avviene attualmente. La tua responsabilità è limitata all’affidabilità della nuova gerarchia di CA emittente da parte tua.

Posso aggiungere la nuova gerarchia di CA prima che Adobe inizi a utilizzarla?

Sì, e Adobe consiglia di farlo. Vedi Quando completare l’aggiornamento per sapere perché aggiungerlo in anticipo non interrompe le connessioni esistenti.

Quando questo influirà sulla mia integrazione?

La transizione è graduale, dalla metà del 2026 fino alla primavera del 2027. Per sapere cosa fare nel frattempo, vedi Quando completare l’aggiornamento.

Documentazione correlata related-documentation

Utilizza le risorse seguenti per ulteriori informazioni sulla configurazione mTLS, sul recupero dei certificati e sulla gestione del ciclo di vita dei certificati in Experience Platform.