Adobe의 새 mTLS 인증서 계층에 대한 Trust Store 업데이트 update-your-trust-store-for-adobes-new-mtls-certificate-hierarchy

Adobe이 끝점에 대한 아웃바운드 mTLS(상호 전송 계층 보안) 연결을 위한 클라이언트 인증서를 발급하는 데 사용되는 인증 기관(CA) 계층을 업데이트하고 있습니다. 시스템이 Adobe의 mTLS 클라이언트 인증서의 유효성을 검사하는 경우 Adobe이 새 계층에서 발급된 인증서를 제공하기 전에 Adobe의 새 루트 및 중간 CA 인증서를 신뢰 저장소에 추가해야 합니다. 이 안내서에서는 일반적인 플랫폼에서 Trust Store를 업데이트하는 이유, 변경 사항 및 방법을 설명합니다.

영향을 받는 사용자 who-is-affected

이 변경 사항은 HTTP API 대상에 대한 수신 엔드포인트, Adobe Journey Optimizer 사용자 지정 작업 및 이벤트 전달 통합을 포함하여 Adobe의 mTLS 클라이언트 인증서의 유효성을 검사하는 관리하는 모든 엔드포인트에 영향을 줍니다. Adobe Experience Platform 통합에서 이미 mTLS를 사용하는 경우 이 안내서를 검토하고 아래 설명된 Trust Store 업데이트를 완료하십시오.

수행할 작업 what-you-need-to-do

Adobe의 새 루트 및 중간 CA 인증서를 Adobe의 mTLS 클라이언트 인증서의 유효성을 검사하는 끝점에서 사용하는 트러스트 저장소 또는 트러스트된 CA 번들에 추가합니다.

다음 순서를 따르십시오.

Trust Store 업데이트만 해당됩니다. 다음을 수행할 필요가 없습니다.

이 업데이트 완료 시기 when-to-update

특정 연결이 영향을 받을 때까지 기다리지 않고 가능한 한 빨리 이 업데이트를 완료합니다. Trust Store에는 유효한 여러 계층이 동시에 포함될 수 있으므로 이제 새 루트 및 중간을 추가해도 현재 작업 중인 연결에 영향을 주지 않습니다.

Adobe은 2026년 중반부터 mTLS 클라이언트 인증서를 새 인증서 계층 구조로 전환하고 2027년 봄까지 계속합니다.

업데이트하지 않으면 어떻게 됩니까 what-happens-if-you-dont-update

Adobe이 끝점에 연결된 새 계층에서 발급된 인증서를 제공하면 신뢰 저장소에 아직 새 루트 및 중간 인증서가 포함되어 있지 않으면 TLS 핸드셰이크가 실패합니다. 이는 영향을 받는 통합에서 연결 또는 게재 실패로 표시됩니다. 예를 들어, Trust Store를 업데이트할 때까지 대상 게재 실패 또는 실패한 사용자 지정 작업 호출이 있습니다.

준비가 되었는지 어떻게 알아? readiness

인증서 파일 확인과 프로덕션 엔드포인트가 준비되었는지 확인하는 것은 다릅니다. 인증서 확인에서는 다운로드한 파일이 유효하고 올바르게 체인 상태인지 확인하지만, Adobe mTLS 연결을 종료하는 서비스가 업데이트된 트러스트 구성을 사용하는지 확인하지는 않습니다.

아래의 플랫폼별 단계를 완료한 후 Trust Store 업데이트 확인 섹션에 설명된 단계에 따라 인증서 파일 및 체인이 유효한지 확인하십시오. Adobe은 현재 프로덕션 종단점이 업데이트된 구성을 사용하고 있는지 확인하는 범용 종단 간 테스트를 제공하지 않습니다. 플랫폼 또는 환경이 지원하는 유효성 검사 방법을 사용하여 준비 상태를 확인합니다.

변경 사항 what-is-changing

Adobe은 사용자가 제어하는 엔드포인트에 대한 아웃바운드 연결(예: HTTP API 대상 수신 엔드포인트, Adobe Journey Optimizer 사용자 지정 작업 또는 이벤트 전달 통합)을 인증하기 위해 mTLS 클라이언트 인증서를 발행합니다. Adobe은 이러한 인증서를 서버와 클라이언트 인증 간에 공유되는 인증서 계층에서 클라이언트 인증 전용 계층으로 이동하고 있습니다.

즉, Adobe의 mTLS 클라이언트 인증서 뒤에 있는 루트 및 중간 인증 기관이 변경됩니다. 이 변경 사항은 인증서 작동 방식이나 Adobe 통합에서 mTLS를 구성하는 방식에는 영향을 주지 않습니다.

이 변경 사항의 이유 why-this-is-changing

이제 인증 기관에 대한 업계 표준에서는 서버 인증 및 클라이언트 인증에 사용되는 인증서를 별도의 계층에서 발급해야 합니다. 이렇게 분리하면 인증서가 의도한 목적 외에 사용되는 것을 방지할 수 있습니다. 그 요건은 공공-신뢰 인증서 생태계 전반에 걸쳐 광범위하게 적용된다. Adobe 또는 단일 통합에만 국한되지 않습니다.

새 인증서 계층 new-certificate-hierarchy

다음 표에서는 현재 인증서 계층 구조를 새 계층 구조와 비교합니다.

두 계층 모두 DigiCert에서 실행되지만 별도의 루트 프로그램입니다. DigiCert Global Root G2만 신뢰하는 신뢰 저장소는 새 계층에서 발급된 인증서를 신뢰하지 않습니다.

새 CA 인증서 다운로드 download-certificates

다음 인증서를 모두 Trust Store에 추가합니다. 일부 플랫폼은 중간 인증서를 자동으로 검색하는 경우 루트 인증서만 필요할 수 있습니다. Adobe에서는 루트 인증서와 중간 인증서를 모두 추가하여 전체 체인을 유효성 검사에 사용할 수 있도록 할 것을 권장합니다.

DigiCert은(는) 신뢰할 수 있는 루트 인증 기관 인증서 참조에서 신뢰할 수 있는 루트 인증서 및 인증 기관에 대한 정보를 유지 관리합니다.

DigiCert에서 두 파일을 DER 형식으로 배포합니다. 이 안내서의 뒷부분에서 다루는 대부분의 플랫폼은 PEM 형식을 사용하므로 Windows을 사용하지 않는 한 두 파일을 모두 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이(가) 반환됩니다.

Trust Store 업데이트 update-trust-store

새 CA 인증서를 신뢰 저장소에 추가하는 단계는 끝점에서 mTLS 연결을 종료하는 플랫폼 또는 소프트웨어에 따라 다릅니다. 아래의 각 섹션은 새 CA 인증서 다운로드 섹션에 설명된 대로 인증서를 이미 다운로드하고 전환했다고 가정합니다. 다음 섹션에서는 일반적인 플랫폼 및 구성을 다룹니다.

Linux 및 OpenSSL linux-openssl

이렇게 하면 Debian 및 Ubuntu 기반 배포의 OpenSSL 및 대부분의 TLS 라이브러리에서 사용하는 시스템 전체 CA 번들이 업데이트됩니다.

다운로드하고 전환한 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

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_client_certificate을(를) 포함한 전체 SSL/TLS 지시문 목록은 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)에서 인증서 스냅인을 열고 다음 단계를 수행하십시오.

Windows에서 인증서 저장소를 구성하는 방법에 대한 배경은 Microsoft의 인증서 저장소 개요를 참조하십시오.

AWS aws

AWS은(는) 연결을 종료하는 서비스에 따라 다른 mTLS 신뢰 저장소 메커니즘을 사용합니다.

상호 TLS를 사용하는 Amazon API Gateway개의 REST API의 경우 다운로드한의 결합된 PEM 번들을 Amazon S3에 업로드한 다음 참조하도록 사용자 지정 도메인을 업데이트하십시오.

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)

전체 구성 안내서는 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을(를) 사용하여 이 구성을 관리하는 경우 MutualTlsAuthentication.TruststoreUri을(를) 통해 업데이트된 신뢰 저장소를 참조하도록 AWS::ApiGateway::DomainName을(를) 업데이트하거나 새 CA 인증서를 포함하도록 AWS::ElasticLoadBalancingV2::TrustStore을(를) 업데이트하십시오. Terraform의 경우 해당 Trust Store 변경 내용으로 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의 Application Gateway 상호 인증 개요를 참조하십시오.

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를 정의합니다.

다운로드한 새 루트 및 중간 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

대상 HTTPS 프록시에 ServerTlsPolicy 연결:

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 설정 안내서를 참조하십시오.

Trust Store 업데이트 확인 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 Server Authentication이(가) 아닌 TLS Web Client Authentication이(가) 포함되어야 합니다.

문제 해결 troubleshooting

연결 실패가 이 마이그레이션과 관련이 있는지 확인하려면 다음 증상을 사용하십시오.

새 루트 및 중간 인증서를 추가한 후 계속 오류가 표시되면 연결을 종료하는 서비스에서 사용하는 Trust Store 또는 번들에 해당 인증서가 추가되었는지 확인하십시오. 플랫폼에 필요한 경우 업데이트된 트러스트 구성을 적용하기 위해 서비스가 다시 로드되었거나 다시 시작되었는지도 확인합니다.

자주 묻는 질문 faq

작업을 수행해야 합니까?

예. 종단점이 Adobe의 mTLS 클라이언트 인증서의 유효성을 검사하는 경우 Adobe의 새 루트 및 중간 CA 인증서를 신뢰 저장소에 추가하십시오. 다른 구성 변경은 필요하지 않습니다.

mTLS 서비스 API를 통해 사용할 수 있는 자동화된 인증서 검색과 관련이 있습니까?

아니요. mTLS 서비스 API은(는) Adobe의 클라이언트 인증서 검색 및 라이프사이클을 자동화하며 이러한 자동화는 이 변경의 영향을 받지 않습니다. 새 CA 계층 구조를 포함하도록 Trust Store를 업데이트하는 것은 자체 시스템에서 수행하는 별도의 일회성 작업입니다.

기존 통합이 작동하지 않습니까?

바로 그런 건 아니에요. 통합이 영향을 받는 시기와 방법에 대해서는 업데이트하지 않으면 어떻게 됩니까를 참조하십시오.

클라이언트 인증서를 바꾸어야 합니까?

아니요. Adobe의 클라이언트 인증서는 오늘날과 같이 자동으로 발급되고 회전됩니다. 귀하의 책임은 귀하 측의 새로운 발급 CA 계층을 신뢰하는 것으로 제한됩니다.

Adobe에서 사용하기 전에 새 CA 계층을 추가할 수 있습니까?

예, Adobe은 그렇게 할 것을 권장합니다. 일찍 추가해도 기존 연결이 끊어지지 않는 이유를 알아보려면 이 업데이트를 완료해야 하는 시기를 참조하십시오.

통합에 언제 영향을 줍니까?

전환은 2026년 중반부터 2027년 봄까지 단계적으로 진행됩니다. 그동안 수행할 작업에 대해서는 이 업데이트를 언제 완료할지를 참조하십시오.

관련 설명서 related-documentation

다음 리소스를 사용하여 Experience Platform의 mTLS 구성, 인증서 검색 및 인증서 수명 주기 관리에 대해 자세히 알아보십시오.