Actualice el almacén de confianza para la nueva jerarquía de certificados mTLS de Adobe update-your-trust-store-for-adobes-new-mtls-certificate-hierarchy

Adobe está actualizando la jerarquía de entidades emisoras de certificados (CA) utilizada para emitir los certificados de cliente para las conexiones salientes de seguridad de la capa de transporte mutuo (mTLS) a los extremos. Si los sistemas validan el certificado de cliente mTLS de Adobe, debe agregar los nuevos certificados de CA raíz e intermedios de Adobe al almacén de confianza antes de que Adobe empiece a presentar los certificados emitidos desde la nueva jerarquía. Esta guía explica qué está cambiando, por qué y cómo actualizar el almacén de confianza en plataformas comunes.

Quién se ve afectado who-is-affected

Este cambio afecta a cualquier punto de conexión que administre y que valide el certificado de cliente mTLS de Adobe, incluida la recepción de puntos de conexión para destinos de API HTTP, acciones personalizadas de Adobe Journey Optimizer e integraciones de reenvío de eventos. Si ya utiliza mTLS con cualquier integración de Adobe Experience Platform, revise esta guía y complete la actualización del almacén de confianza que se describe a continuación.

Lo que tiene que hacer what-you-need-to-do

Agregue los nuevos certificados de CA raíz e intermedia de Adobe al almacén de confianza o al paquete de CA de confianza utilizado por el extremo que valida el certificado de cliente mTLS de Adobe.

Siga esta secuencia:

Solo es una actualización de almacén de confianza. NO es necesario:

Cuándo completar esta actualización when-to-update

Complete esta actualización lo antes posible, en lugar de esperar a que una conexión específica se vea afectada. Dado que un almacén de confianza puede contener varias jerarquías válidas al mismo tiempo, agregar la nueva raíz y el intermedio ahora no tiene ningún efecto en las conexiones de trabajo actuales.

Adobe está realizando la transición de los certificados de cliente mTLS a la nueva jerarquía de certificados desde mediados de 2026 y hasta la primavera de 2027.

Qué sucede si no se actualiza what-happens-if-you-dont-update

Una vez que Adobe presenta un certificado emitido desde la nueva jerarquía en una conexión al extremo, el protocolo de enlace TLS falla si el almacén de confianza aún no incluye los nuevos certificados raíz e intermedios. Esto aparece como un error de conexión o envío en la integración afectada. Por ejemplo, un error de entrega de destino o una llamada de acción personalizada que ha fallado, hasta que actualice el almacén de confianza.

¿Cómo sabes que estás listo? readiness

Comprobar los archivos de certificado no es lo mismo que confirmar que el punto final de producción está listo. La verificación del certificado confirma que los archivos descargados son válidos y están correctamente encadenados, pero no confirma que el servicio que finaliza la conexión mTLS de Adobe esté utilizando la configuración de confianza actualizada.

Después de completar los pasos específicos de la plataforma que se indican a continuación, siga los pasos descritos en la sección Verificar la actualización del almacén de confianza para confirmar que los archivos de certificado y la cadena son válidos. Adobe no proporciona actualmente una prueba completa universal que confirme que el punto final de producción está utilizando la configuración actualizada. Confirme la preparación utilizando el método de validación que admita su plataforma o entorno.

Qué está cambiando what-is-changing

Adobe emite certificados de cliente mTLS para autenticar conexiones salientes a puntos de conexión que usted controla, como un destino de API HTTP que recibe el punto de conexión, una acción personalizada de Adobe Journey Optimizer o una integración de reenvío de eventos. Adobe está moviendo estos certificados de una jerarquía de certificados compartida entre la autenticación del servidor y del cliente a una jerarquía dedicada únicamente a la autenticación del cliente.

Esto significa que las autoridades de certificación raíz e intermedias detrás del certificado de cliente mTLS de Adobe están cambiando. Este cambio no afecta al funcionamiento del certificado ni a la configuración de mTLS en las integraciones de Adobe.

Por qué está cambiando esto why-this-is-changing

Los estándares del sector para las autoridades de certificación ahora requieren que los certificados utilizados para la autenticación de servidores y clientes se emitan desde jerarquías independientes. Esta separación ayuda a evitar que los certificados se utilicen fuera del propósito previsto. El requisito se aplica ampliamente en todo el ecosistema de certificados de confianza pública. No es específico de Adobe ni de ninguna integración individual.

La nueva jerarquía de certificados new-certificate-hierarchy

La siguiente tabla compara la jerarquía de certificados actual con la nueva.

Ambas jerarquías son emitidas por DigiCert, pero son programas raíz independientes. Un almacén de confianza que sólo confía en DigiCert Global Root G2 no confiará en un certificado emitido desde la nueva jerarquía.

Descargar los nuevos certificados de CA download-certificates

Agregue los dos certificados siguientes al almacén de confianza. Algunas plataformas pueden requerir únicamente el certificado raíz si recuperan automáticamente certificados intermedios. Adobe recomienda agregar los certificados raíz e intermedios para garantizar que la cadena completa esté disponible para la validación.

DigiCert mantiene información sobre sus certificados raíz de confianza y las autoridades de certificación en su referencia de Certificados de autoridad raíz de confianza.

DigiCert distribuye ambos archivos en formato DER. La mayoría de las plataformas que se tratan más adelante en esta guía utilizan el formato PEM, por lo que debe convertir ambos archivos a PEM a menos que utilice 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 que ha descargado los certificados esperados y que forman una cadena válida. Compruebe que el sujeto de cada certificado coincide con el nombre común esperado y, a continuación, compruebe que el certificado intermedio se encadena a la raíz:

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

Una verificación de cadena correcta devuelve DigiCertAssuredIDClientCAG2.pem: OK.

Actualizar el almacén de confianza update-trust-store

Los pasos para agregar un nuevo certificado de CA al almacén de confianza dependen de la plataforma o el software que finaliza la conexión mTLS en el extremo. En cada una de las secciones siguientes se da por hecho que ya ha descargado y convertido los certificados tal como se describe en Descargar la nueva sección Certificados de CA. Las siguientes secciones tratan sobre plataformas y configuraciones comunes.

Linux y OpenSSL linux-openssl

Esto actualiza el paquete de CA para todo el sistema que usan OpenSSL y la mayoría de las bibliotecas TLS en distribuciones basadas en Debian y Ubuntu.

Copie los archivos PEM que descargó y convirtió en el directorio de la CA del sistema y, a continuación, vuelva a compilar el paquete de confianza:

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

Archivos de paquete de CA personalizados custom-ca-bundle

Si el servicio hace referencia a un archivo de paquete de CA personalizado (por ejemplo, a través de --cacert, SSL_CERT_FILE o CURL_CA_BUNDLE), anexe los nuevos certificados que descargó directamente a ese archivo:

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

Asegúrese de que cada bloque de certificado esté separado por una nueva línea, sin espacios en blanco adicionales entre el final de un bloque -----END CERTIFICATE----- y el inicio del siguiente bloque -----BEGIN CERTIFICATE-----.

Java (keytool) java-keytool

Las aplicaciones Java utilizan su propio almacén de confianza, normalmente un archivo de nombre cacerts, en lugar del almacén de confianza del sistema operativo, por lo que debe importar los certificados que descargó directamente desde allí. En primer lugar, busque el archivo cacerts de JVM:

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

A continuación, importe ambos certificados (la contraseña predeterminada de cacerts es 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 que se han añadido ambos certificados:

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 ver el conjunto completo de keytool opciones, consulte referencia de comando keytool de Oracle.

nginx nginx

nginx usa la directiva ssl_client_certificate para especificar en qué CA confía para la validación de certificados de cliente. Anexe los nuevos certificados que descargó al archivo del paquete al que hace referencia esa directiva:

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

Pruebe la configuración y vuelva a cargar nginx para aplicar el cambio:

nginx -t && nginx -s reload

Consulte la documentación del módulo ngx_http_ssl de nginx para obtener una lista completa de las directivas SSL/TLS, entre ellas ssl_client_certificate.

Apache httpd apache-httpd

Apache httpd utiliza la directiva SSLCACertificateFile para especificar las CA de cliente de confianza. Anexe los nuevos certificados que descargó al archivo del paquete al que hace referencia esa directiva:

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

Pruebe la configuración y reinicie Apache httpd para aplicar el cambio:

apachectl configtest && apachectl graceful

Para ver el conjunto completo de mod_ssl directivas, entre ellas SSLCACertificateFile, consulte la documentación de mod_ssl de Apache.

Windows windows

Use certutil desde un símbolo del sistema con privilegios elevados para agregar los certificados que descargó a los almacenes apropiados:

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

También puede usar la interfaz gráfica Windows para agregar los certificados a los almacenes de certificados del equipo local. Para ello, abra el complemento Certificados en Microsoft Management Console (MMC) y siga estos pasos:

Para obtener información general sobre cómo Windows organiza los almacenes de certificados, consulte la descripción general de los almacenes de certificados de Microsoft.

AWS aws

AWS utiliza diferentes mecanismos de almacén de confianza mTLS según el servicio que termine la conexión.

Para las API de REST Amazon API Gateway que usan TLS mutuos, carga un paquete PEM combinado de los certificados que descargaste en Amazon S3 y, a continuación, actualiza tu dominio personalizado para que haga referencia a él.

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 la documentación de TLS mutuos para las API de REST de AWS para obtener la guía de configuración completa.

Para un(a) Application Load Balancer o Network Load Balancer que utiliza TLS mutuo, utilice la API ELBv2 para crear o actualizar el almacén de confianza que contiene los certificados de CA utilizados para validar los 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

Si ya tiene un almacén de confianza para este oyente, actualícelo en lugar de crear uno nuevo:

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

A continuación, asocie el almacén de confianza con el oyente que administra la conexión 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 la documentación de TLS mutuo del equilibrador de carga de aplicaciones de AWS para obtener la guía de configuración completa.

Si administra esta configuración con CloudFormation, actualice AWS::ApiGateway::DomainName para hacer referencia al almacén de confianza actualizado a través de MutualTlsAuthentication.TruststoreUri o actualice AWS::ElasticLoadBalancingV2::TrustStore para incluir los nuevos certificados de CA. Para Terraform, actualice aws_api_gateway_domain_name (mutual_tls_authentication.truststore_uri) o aws_lb_trust_store con los cambios correspondientes del almacén de confianza.

Azure azure

Para Azure Application Gateway, cargue los certificados raíz e intermedios que descargó como certificados de cliente de confianza y, a continuación, adjúntelos al perfil SSL que tenga habilitada la autenticación de cliente:

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 Introducción a la autenticación mutua de Application Gateway de Microsoft para obtener información general sobre esta configuración.

Para Azure API Management, agregue los certificados de CA raíz e intermedios a los almacenes de certificados de CA utilizados por la puerta de enlace administrada. Esto permite que Azure API Management establezca confianza al validar el certificado de cliente de Adobe con la nueva jerarquía.

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

También puede agregar los certificados de CA en el portal de Azure. En su instancia de administración de API, seleccione Seguridad > Certificados > Certificados de CA.

Consulte la guía de Microsoft para agregar un certificado de CA personalizado en Administración de API para obtener instrucciones paso a paso.

Si administra esta configuración con Terraform, actualice la configuración del certificado de cliente de confianza en azurerm_application_gateway (ssl_profile.trusted_client_certificate_names) o la configuración del certificado de CA en azurerm_api_management_certificate.

Google Cloud google-cloud

Google Cloud Load Balancing usa un Administrador de certificados TrustConfig para definir las CA de confianza para mTLS.

Cree un archivo de configuración de confianza que agregue los nuevos certificados de CA raíz e intermedia que descargó al conjunto de certificados de confianza para la autenticación de clientes:

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

Crear el recurso TrustConfig:

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

A continuación, cree una directiva TLS de servidor que haga referencia a la configuración de confianza:

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

Adjunte ServerTlsPolicy al proxy HTTPS de destino:

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

Si administra esta configuración con Terraform, actualice google_certificate_manager_trust_config para incluir la nueva CA raíz en trust_stores.trust_anchors y la nueva CA intermedia en trust_stores.intermediate_cas.

Para ver el tutorial completo de esta configuración, consulte la guía Configurar mTLS de front-end con certificados proporcionados por el usuario de Google Cloud.

Compruebe la actualización del almacén de confianza verify

Después de actualizar el almacén de confianza, compruebe que un certificado emitido desde la nueva jerarquía se valida con la nueva cadena de CA. Genere un paquete combinado a partir de los nuevos certificados de CA raíz e intermedia y, a continuación, utilícelo para verificar un certificado emitido para la autenticación del cliente:

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

Si tiene un certificado de cliente emitido desde la nueva jerarquía, reemplace client-cert.pem por la ruta a ese certificado. Un resultado correcto confirma que OpenSSL puede validar el certificado con la nueva cadena de CA para la autenticación del cliente TLS.

Si no tiene un certificado de cliente emitido desde la nueva jerarquía, aún puede comprobar que el certificado intermedio se valida con la nueva raíz:

openssl verify -CAfile DigiCertAssuredIDRootG2.pem DigiCertAssuredIDClientCAG2.pem

Un resultado correcto devuelve DigiCertAssuredIDClientCAG2.pem: OK, lo que confirma que el certificado intermedio se valida con la nueva raíz.

Para confirmar que un certificado se emite solo para la autenticación del cliente, inspeccione el uso de claves extendidas:

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

Para un certificado solo de autenticación de cliente, el uso de clave extendida debe incluir TLS Web Client Authentication y no TLS Web Server Authentication.

Resolución de problemas troubleshooting

Utilice los siguientes síntomas para identificar si un error de conexión está relacionado con esta migración.

Si sigue viendo errores después de agregar los nuevos certificados raíz e intermedios, compruebe que se agregaron al almacén de confianza o al paquete utilizado por el servicio que finaliza la conexión. Si su plataforma lo requiere, confirme también que el servicio se recargó o reinició para aplicar la configuración de confianza actualizada.

Preguntas frecuentes faq

¿Debo hacer algo?

Sí. Si el extremo valida el certificado de cliente mTLS de Adobe, agregue los nuevos certificados de CA raíz e intermedios de Adobe al almacén de confianza. No se requieren otros cambios de configuración.

¿Está esto relacionado con la recuperación automatizada de certificados disponible a través de la API del servicio mTLS?

No. La API del servicio mTLS automatiza la recuperación y el ciclo de vida del certificado de cliente de Adobe, y esa automatización no se ve afectada por este cambio. La actualización del almacén de confianza para incluir la nueva jerarquía de CA es una acción independiente y única que se realiza en sus propios sistemas.

¿Dejará de funcionar mi integración existente?

No inmediatamente. Consulte Qué sucede si no actualiza para ver cuándo y cómo se ve afectada una integración.

¿Debo reemplazar mi certificado de cliente?

No. El certificado de cliente de Adobe se emite y rota automáticamente, tal como sucede hoy en día. Su responsabilidad se limita a confiar en la nueva jerarquía de CA emisora de su parte.

¿Puedo agregar la nueva jerarquía de CA antes de que Adobe empiece a usarla?

Sí, y Adobe recomienda hacerlo. Consulte Cuándo completar esta actualización para saber por qué agregarla antes no interrumpe las conexiones existentes.

¿Cuándo afectará esto a mi integración?

La transición es gradual, desde mediados de 2026 y continúa hasta la primavera de 2027. Ver Cuándo completar esta actualización para saber qué hacer mientras tanto.

Documentación relacionada related-documentation

Utilice los siguientes recursos para obtener más información sobre la configuración de mTLS, la recuperación de certificados y la administración del ciclo de vida de certificados en Experience Platform.