Atualizar seu armazenamento de confiança para a nova hierarquia de certificados mTLS da Adobe update-your-trust-store-for-adobes-new-mtls-certificate-hierarchy

A Adobe está atualizando a hierarquia de autoridade de certificação (CA) usada para emitir os certificados de cliente para conexões mTLS (Segurança da Camada de Transporte Mútuo) de saída com seus pontos de extremidade. Se os seus sistemas validarem o certificado de cliente mTLS da Adobe, será necessário adicionar os novos certificados de CA raiz e intermediária da Adobe à sua área de armazenamento confiável, antes que a Adobe comece a apresentar certificados emitidos pela nova hierarquia. Este guia explica o que está mudando, por que e como atualizar seu armazenamento de confiança em plataformas comuns.

Quem é afetado who-is-affected

Essa alteração afeta qualquer endpoint gerenciado que valide o certificado de cliente mTLS do Adobe, incluindo o recebimento de endpoints para destinos de API HTTP, ações personalizadas do Adobe Journey Optimizer e integrações de encaminhamento de eventos. Se você já usa o mTLS com qualquer integração do Adobe Experience Platform, consulte este guia e conclua a atualização da loja de confiança descrita abaixo.

O que você precisa fazer what-you-need-to-do

Adicione os novos certificados de CA raiz e intermediária da Adobe ao armazenamento de confiança ou ao pacote de CA confiável usado pelo endpoint que valida o certificado de cliente mTLS da Adobe.

Siga esta sequência:

Esta é apenas uma atualização de repositório de confiança. Você NÃO precisa:

Quando concluir esta atualização when-to-update

Conclua esta atualização o mais rápido possível, em vez de esperar que uma conexão específica seja afetada. Como um armazenamento de confiança pode conter várias hierarquias válidas ao mesmo tempo, adicionar a nova raiz e o intermediário agora não tem efeito sobre suas conexões atuais em funcionamento.

A Adobe está fazendo a transição de certificados de cliente mTLS para a nova hierarquia de certificados de meados de 2026 e continuará até a primavera de 2027.

O que acontece se você não atualizar what-happens-if-you-dont-update

Depois que o Adobe apresenta um certificado emitido da nova hierarquia em uma conexão com o endpoint, o handshake TLS falha se o armazenamento de confiança ainda não incluir os novos certificados raiz e intermediário. Isso é exibido como uma falha de conexão ou delivery na integração afetada. Por exemplo, uma falha de entrega de destino ou uma falha na chamada de ação personalizada, até que você atualize seu armazenamento de confiança.

Como você sabe que está pronta? readiness

Verificar os arquivos de certificado não é o mesmo que confirmar se o endpoint de produção está pronto. A verificação de certificado confirma que os arquivos baixados são válidos e estão encadeados corretamente, mas não confirma se o serviço que está encerrando a conexão mTLS do Adobe está usando a configuração de confiança atualizada.

Após concluir as etapas específicas da plataforma abaixo, siga as etapas descritas na seção Verificar se a atualização do armazenamento de confiança é válida para confirmar se os arquivos de certificado e a cadeia são válidos. Atualmente, a Adobe não fornece um teste completo e universal que confirma se o terminal de produção está usando a configuração atualizada. Confirme a prontidão usando qualquer método de validação compatível com sua plataforma ou ambiente.

O que está mudando what-is-changing

A Adobe emite certificados de clientes mTLS para autenticar conexões de saída para pontos de extremidade controlados por você, como um destino da API HTTP recebendo ponto de extremidade, uma ação personalizada de Adobe Journey Optimizer ou uma integração de Encaminhamento de Eventos. A Adobe está movendo esses certificados de uma hierarquia de certificados compartilhada entre autenticação de servidor e cliente para uma hierarquia dedicada exclusivamente à autenticação de cliente.

Isso significa que as autoridades de certificação raiz e intermediárias por trás do certificado de cliente mTLS da Adobe estão mudando. Essa alteração não afeta como o certificado funciona ou como você configura o mTLS nas integrações do Adobe.

Por que isso está mudando why-this-is-changing

Os padrões do setor para autoridades de certificação agora exigem que os certificados usados para autenticação de servidor e de cliente sejam emitidos de hierarquias separadas. Essa separação ajuda a impedir que certificados sejam usados fora da finalidade desejada. O requisito aplica-se amplamente ao ecossistema de certificados de confiança pública. Não é específico do Adobe ou de qualquer integração única.

A nova hierarquia de certificados new-certificate-hierarchy

A tabela a seguir compara a hierarquia de certificados atual com a nova.

Ambas as hierarquias são emitidas por DigiCert, mas são programas raiz separados. Um armazenamento de confiança que confia somente em DigiCert Global Root G2 não confiará em um certificado emitido da nova hierarquia.

Baixar os novos certificados de autoridade de certificação download-certificates

Adicione ambos os certificados a seguir ao armazenamento de confiança. Algumas plataformas podem exigir somente o certificado raiz se recuperarem automaticamente certificados intermediários. A Adobe recomenda adicionar os certificados raiz e intermediário para garantir que a cadeia completa esteja disponível para validação.

O DigiCert mantém informações sobre seus certificados raiz confiáveis e autoridades de certificação na sua referência de Certificados de Autoridade Raiz Confiável.

DigiCert distribui ambos os arquivos no formato DER. A maioria das plataformas abordadas posteriormente neste guia usam o formato PEM, portanto, converta ambos os arquivos para PEM, a menos que você esteja usando o 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

Antes de continuar, confirme se você baixou os certificados esperados e se eles formam uma cadeia válida. Verifique se cada requerente do certificado corresponde ao nome comum esperado e se o certificado intermediário está vinculado à raiz:

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

Uma verificação de cadeia bem-sucedida retorna DigiCertAssuredIDClientCAG2.pem: OK.

Atualizar armazenamento de confiança update-trust-store

As etapas para adicionar um novo certificado CA ao seu armazenamento de confiança dependem da plataforma ou do software que encerra a conexão mTLS no seu ponto de extremidade. Cada seção abaixo presume que você já baixou e converteu os certificados conforme descrito na seção Baixar os novos certificados da autoridade de certificação. As seções a seguir abordam plataformas e configurações comuns.

Linux e OpenSSL linux-openssl

Isso atualiza o pacote CA em todo o sistema usado por OpenSSL e pela maioria das bibliotecas TLS em distribuições baseadas em Debian e Ubuntu.

Copie os arquivos PEM que você baixou e converteu no diretório da autoridade de certificação do sistema e recrie o pacote de confiança:

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

Arquivos de pacote de autoridade de certificação personalizados custom-ca-bundle

Se o serviço fizer referência a um arquivo de pacote de autoridade de certificação personalizado (por exemplo, por meio de --cacert, SSL_CERT_FILE ou CURL_CA_BUNDLE), anexe os novos certificados que você baixou diretamente nesse arquivo:

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

Verifique se cada bloco de certificado está separado por uma nova linha, sem nenhum espaço em branco extra entre o final de um bloco -----END CERTIFICATE----- e o início do próximo bloco -----BEGIN CERTIFICATE-----.

Java (keytool) java-keytool

Os aplicativos Java usam seu próprio armazenamento de confiança, normalmente um arquivo chamado cacerts, em vez do armazenamento de confiança do sistema operacional, portanto, você precisa importar os certificados que baixou diretamente para lá. Primeiro, localize o arquivo cacerts do JVM:

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

Em seguida, importe os dois certificados (a senha padrão 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

Confirme se ambos os certificados foram adicionados:

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

Para obter o conjunto completo de opções keytool, consulte a referência de comando keytool de Oracle.

nginx nginx

nginx usa a diretiva ssl_client_certificate para especificar quais autoridades de certificação ele confia para validação de certificado de cliente. Anexe os novos certificados que você baixou ao arquivo de pacote referenciado por essa diretiva:

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

Teste a configuração e recarregue nginx para aplicar a alteração:

nginx -t && nginx -s reload

Consulte a ngx_http_ssl_module de nginx para obter a lista completa de diretivas SSL/TLS, incluindo ssl_client_certificate.

Apache httpd apache-httpd

Apache httpd usa a diretiva SSLCACertificateFile para especificar CAs de cliente confiáveis. Anexe os novos certificados que você baixou ao arquivo de pacote referenciado por essa diretiva:

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

Teste a configuração e reinicie o Apache httpd para aplicar a alteração:

apachectl configtest && apachectl graceful

Para obter o conjunto completo de diretivas mod_ssl, incluindo SSLCACertificateFile, consulte a documentação mod_ssl de Apache.

Windows windows

Use certutil de um prompt de comando com privilégios elevados para adicionar os certificados baixados aos repositórios apropriados:

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

Como alternativa, você pode usar a interface gráfica Windows para adicionar os certificados aos armazenamentos de certificados do computador local. Para fazer isso, abra o snap-in Certificados no Microsoft Management Console (MMC) e siga estas etapas:

Para obter informações sobre como o Windows organiza armazenamentos de certificados, consulte visão geral sobre armazenamentos de certificados de Microsoft.

AWS aws

AWS usa diferentes mecanismos de armazenamento de confiança mTLS, dependendo de qual serviço encerra a conexão.

Para APIs REST do Amazon API Gateway usando TLS mútuo, carregue um pacote PEM combinado dos certificados que você baixou para Amazon S3 e, em seguida, atualize seu domínio personalizado para referenciá-lo.

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)

Consulte TLS mútuo para a documentação de APIs REST de AWS para obter o guia de configuração completo.

Para um Application Load Balancer ou Network Load Balancer usando TLS mútuo, use a API ELBv2 para criar ou atualizar o repositório de confiança que contém os certificados de CA usados para validar certificados de cliente:

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 você já tiver um armazenamento confiável para esse listener, atualize-o em vez de criar um novo:

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

Em seguida, associe o armazenamento de confiança ao ouvinte que manipula a conexão 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

Consulte a documentação de TLS mútuo do Balanceador de Carga de Aplicativo de AWS para obter o guia de configuração completo.

Se você gerenciar essa configuração com CloudFormation, atualize AWS::ApiGateway::DomainName para fazer referência ao armazenamento de confiança atualizado por meio de MutualTlsAuthentication.TruststoreUri, ou atualize AWS::ElasticLoadBalancingV2::TrustStore para incluir os novos certificados da autoridade de certificação. Para Terraform, atualize aws_api_gateway_domain_name (mutual_tls_authentication.truststore_uri) ou aws_lb_trust_store com as alterações correspondentes do armazenamento de confiança.

Azure azure

Para Azure Application Gateway, carregue os certificados raiz e intermediário que você baixou como certificados de cliente confiáveis e anexe-os ao perfil SSL que tem a autenticação de cliente habilitada:

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

Consulte Visão geral da autenticação mútua do Gateway de Aplicativo de Microsoft para obter informações em segundo plano sobre esta configuração.

Para Azure API Management, adicione os certificados raiz e intermediária da autoridade de certificação aos armazenamentos de certificados da autoridade de certificação usados pelo gateway gerenciado. Isso permite que Azure API Management estabeleça confiança ao validar o certificado de cliente da Adobe em relação à nova hierarquia.

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

Você também pode adicionar os certificados CA no portal Azure. Na instância do Gerenciamento de API, selecione Segurança > Certificados > Certificados de autoridade de certificação.

Consulte o guia de Microsoft para adicionar um certificado de autoridade de certificação personalizado no Gerenciamento de API para obter instruções passo a passo.

Se você gerenciar essa configuração com o Terraform, atualize a configuração de certificado de cliente confiável em azurerm_application_gateway (ssl_profile.trusted_client_certificate_names) ou a configuração de certificado de autoridade de certificação em azurerm_api_management_certificate.

Google Cloud google-cloud

Google Cloud Load Balancing usa um Gerenciador de Certificados TrustConfig para definir as autoridades de certificação confiáveis para mTLS.

Crie um arquivo de configuração de confiança que adicione os novos certificados de autoridade de certificação raiz e intermediários que você baixou ao conjunto de certificados confiáveis para autenticação de cliente:

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

Criar o recurso TrustConfig:

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

Em seguida, crie uma política TLS do servidor que faça referência à configuração de confiança:

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

Anexe o ServerTlsPolicy ao seu proxy HTTPS de destino:

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

Se você gerenciar essa configuração com Terraform, atualize google_certificate_manager_trust_config para incluir a nova CA raiz em trust_stores.trust_anchors e a nova CA intermediária em trust_stores.intermediate_cas.

Para obter a apresentação completa dessa configuração, consulte o guia Configurar mTLS de front-end do Google Cloud com certificados fornecidos pelo usuário.

Verifique a atualização do armazenamento de confiança verify

Depois de atualizar o armazenamento de confiança, verifique se um certificado emitido da nova hierarquia é validado em relação à nova cadeia de CA. Crie um pacote combinado dos novos certificados raiz e CA intermediária e use-o para verificar um certificado emitido para autenticação de cliente:

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

Se você tiver um certificado de cliente emitido da nova hierarquia, substitua client-cert.pem pelo caminho desse certificado. Um resultado bem-sucedido confirma que o OpenSSL pode validar o certificado em relação à nova cadeia de CA para autenticação de cliente TLS.

Se você não tiver um certificado de cliente emitido da nova hierarquia, ainda poderá verificar se o certificado intermediário é validado em relação à nova raiz:

openssl verify -CAfile DigiCertAssuredIDRootG2.pem DigiCertAssuredIDClientCAG2.pem

Um resultado bem-sucedido retorna DigiCertAssuredIDClientCAG2.pem: OK, confirmando que o certificado intermediário valida em relação à nova raiz.

Para confirmar se um certificado é emitido apenas para autenticação de cliente, inspecione o uso estendido de chave:

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

Para um certificado somente de autenticação de cliente, o uso estendido de chave deve incluir TLS Web Client Authentication e não TLS Web Server Authentication.

Solução de problemas troubleshooting

Use os seguintes sintomas para identificar se uma falha de conexão está relacionada a essa migração.

Se você continuar a ver falhas após adicionar os novos certificados raiz e intermediário, verifique se eles foram adicionados ao armazenamento ou pacote de confiança usado pelo serviço que encerra a conexão. Se exigido pela sua plataforma, confirme também se o serviço foi recarregado ou reiniciado para aplicar a configuração de confiança atualizada.

Perguntas frequentes faq

Preciso fazer alguma coisa?

Sim. Se o seu ponto de extremidade validar o certificado de cliente mTLS da Adobe, adicione os novos certificados de CA raiz e intermediária da Adobe ao armazenamento de confiança. Nenhuma outra alteração de configuração é necessária.

Isso está relacionado à recuperação automática de certificado disponível por meio da API de Serviço mTLS?

Não. A API de Serviço mTLS automatiza a recuperação e o ciclo de vida do certificado de cliente da Adobe, e essa automação não é afetada por essa alteração. Atualizar seu armazenamento de confiança para incluir a nova hierarquia de CA é uma ação separada e única que você executa em seus próprios sistemas.

Minha integração existente deixará de funcionar?

Não imediatamente. Consulte O que acontece se você não atualizar para saber quando e como uma integração é afetada.

Preciso substituir meu certificado de cliente?

Não. O certificado de cliente da Adobe é emitido e girado automaticamente, como é hoje. Sua responsabilidade está limitada a confiar na nova hierarquia de CA de emissão do seu lado.

É possível adicionar a nova hierarquia de autoridade de certificação antes que o Adobe comece a usá-la?

Sim, e a Adobe recomenda fazê-lo. Consulte Quando concluir esta atualização para saber por que adicioná-la antecipadamente não interrompe suas conexões existentes.

Quando isso afetará minha integração?

A transição é gradual, de meados de 2026 até à primavera de 2027. Consulte Quando concluir esta atualização para saber o que fazer enquanto isso.

Documentação relacionada related-documentation

Use os seguintes recursos para saber mais sobre a configuração mTLS, a recuperação de certificados e o gerenciamento do ciclo de vida do certificado no Experience Platform.