Show Menu
TÓPICOS×

CNAME e Adobe Target

Instructions for working with Adobe Client Care to implement CNAME (Canonical Name) support in Adobe Target. Para melhor lidar com problemas de bloqueio de anúncios, ou políticas de cookies relacionadas ao ITP, um CNAME é usado, portanto, as chamadas são feitas para um domínio pertencente ao cliente em vez de um domínio pertencente à Adobe.

Solicitar suporte CNAME

Execute as etapas a seguir para solicitar o suporte CNAME no Target:
  1. Determine a lista de nomes de host necessários para seu certificado SSL (consulte as Perguntas frequentes).
  2. Para cada nome de host, crie um registro CNAME em seu DNS apontando para seu Target nome de host comum clientcode.tt.omtrdc.net .
    Por exemplo, se o código do cliente for "cnamecustomer" e o nome do host proposto for target.example.com , o registro CNAME de DNS deverá ser semelhante a:
    target.example.com.  IN  CNAME  cnamecustomer.tt.omtrdc.net.
    
    
    • A autoridade de certificação da Adobe, DigiCert, não poderá emitir um certificado até que essa etapa seja concluída. Portanto, a Adobe não poderá atender à solicitação de uma implementação CNAME até que essa etapa seja concluída.
  3. Preencha o formulário a seguir e inclua-o ao abrir um ticket do Adobe Client Care solicitando suporte CNAME:
    • Adobe Target client code:
    • Nomes de host de certificado SSL (por exemplo: target.example.com target.example.org ):
    • Comprador de certificados SSL (a Adobe é altamente recomendada, consulte as Perguntas frequentes): Adobe/cliente
    • Se o cliente estiver comprando o certificado (conhecido como BYOC), preencha estes detalhes adicionais:
      • Organização do certificado (por exemplo: Exemplo de Empresa Inc):
      • Unidade organizacional do certificado (opcional, por exemplo: Comercialização):
      • País do certificado (por exemplo: EUA):
      • Estado/região do certificado (exemplo: Califórnia):
      • Cidade do certificado (por exemplo: San Jose):
  4. Se a Adobe comprar o certificado, a Adobe trabalhará com a DigiCert para comprar e implantar seu certificado nos servidores de produção da Adobe.
    Se o cliente estiver comprando o certificado (BYOC), o Adobe Client Care enviará a você a solicitação de assinatura de certificado (CSR), que você precisará usar ao adquirir o certificado por meio da autoridade de certificação escolhida. Depois que o certificado for emitido, você deverá enviar uma cópia do certificado e quaisquer certificados intermediários de volta ao Atendimento ao cliente da Adobe para implantação.
    O Atendimento ao cliente da Adobe notificará você quando sua implementação estiver pronta.
  5. Depois de concluir o tarefa anterior e o Adobe Client Care ter notificado que a implementação está pronta, você deve atualizá-la serverDomain para o novo CNAME em at.js.

Perguntas frequentes

As informações a seguir respondem a perguntas frequentes sobre como solicitar e implementar o suporte CNAME em Target:

Posso fornecer meu próprio certificado (também conhecido como trazer seu próprio certificado ou BYOC)?

Sim, você pode fornecer seu próprio certificado; no entanto, não é recomendado. O gerenciamento do ciclo de vida do certificado SSL é significativamente mais fácil para a Adobe e para você quando a Adobe compra e controla o certificado. Os certificados SSL devem ser renovados todos os anos, o que significa que o Adobe Client Care deve entrar em contato com você todos os anos para enviar um novo certificado à Adobe em tempo hábil. Alguns clientes podem ter dificuldade em produzir um certificado renovado em tempo hábil a cada ano, o que compromete sua Target implementação porque os navegadores recusarão as conexões quando o certificado expirar.
Esteja ciente de que, se você solicitar uma implementação CNAME de Target trazer seu próprio certificado, é responsável por fornecer certificados renovados ao Atendimento ao cliente da Adobe todos os anos. Permitir que seu certificado CNAME expire antes que a Adobe possa implantar um certificado renovado resultará em uma interrupção para sua Target implementação específica.

Quanto tempo até que meu novo certificado SSL expire?

Os certificados emitidos antes de 1º de setembro de 2020 serão certificados de dois anos. Os certificados emitidos a partir de 1º de setembro de 2020 serão de um ano. Você pode ler mais sobre a mudança para certificados de um ano aqui .

Quais nomes de host devo escolher? Quantos nomes de host por domínio devo escolher?

Target As implementações CNAME exigem apenas um nome de host por domínio no certificado SSL e no DNS do cliente, portanto, é isso que recomendamos. Alguns clientes podem exigir nomes de host adicionais por domínio para seus próprios fins (teste em armazenamento temporário, por exemplo), o que é suportado.
A maioria dos clientes escolhe um nome de host como target.example.com , então é isso que recomendamos, mas a escolha é, em última análise, sua. Certifique-se de não solicitar um nome de host de um registro DNS existente, pois isso causaria um conflito e atrasaria o tempo para a resolução de sua solicitação de Target CNAME.

Já tenho uma implementação CNAME para Adobe Analytics, podemos usar o mesmo certificado ou nome do host?

Não, Target requer um nome de host e um certificado separados.

Minha implementação atual do Público alvo é afetada pelo ITP 2.x?

Em um navegador Safari, navegue até seu site no qual você tem uma biblioteca JavaScript de Públicos alvos. If you see a Target cookie set in the context of a CNAME, such as analytics.company.com , then you are not impacted by ITP 2.x.
Os problemas de ITP podem ser resolvidos para Público alvo com apenas um Analytics CNAME. Você precisará de um Público alvo separado CNAME somente no caso de cenários de bloqueio de anúncios em que o Público alvo estiver bloqueado.
Para obter mais informações sobre o ITP, consulte Apple Intelligent Tracking Prevention (ITP) 2.x .

Que tipo de interrupções de serviço posso esperar quando minha implementação CNAME é implantada?

Não há interrupção de serviço quando o certificado é implantado (incluindo renovações de certificados). No entanto, quando você altera o nome do host em seu código de Target implementação ( serverDomain em at.js) para o novo nome do host CNAME ( target.example.com ), os navegadores da Web tratarão os visitantes recorrentes como novos visitantes e seus dados de perfil serão perdidos porque o cookie anterior estará inacessível sob o nome do host antigo ( clientcode.tt.omtrdc.net ) devido aos modelos de segurança do navegador. Esta é uma interrupção única somente no recorte inicial do novo CNAME. As renovações de certificados não têm o mesmo efeito, pois o nome do host não é alterado.

Que tipo de chave e algoritmo de assinatura de certificado serão usados para minha implementação CNAME?

Todos os certificados são RSA SHA-256 e as chaves são RSA 2048-bit, por padrão. Os tamanhos de chave maiores que 2048 bits não são suportados no momento.

Como posso validar se minha implementação CNAME está pronta para o tráfego?

Use o seguinte conjunto de comandos (no terminal de linha de comando do MacOs ou do Linux, usando bash e curl 7.49+):
  1. Primeiro cole esta função bash no seu terminal:
    function validateEdgeFpsslSni {
        domain=$1
        for edge in mboxedge{31,32,{34..38}}.tt.omtrdc.net; do
            echo "$edge: $(curl -sSv --connect-to $domain:443:$edge:443 https://$domain 2>&1 | grep subject:)"
        done
    }
    
    
  2. Em seguida, cole este comando (substituindo target.example.com pelo nome do host):
    validateEdgeFpsslSni target.example.com
    
    
    Se a implementação estiver pronta, você deverá ver a saída como abaixo. A parte importante é que todas as linhas são exibidas CN=target.example.com , o que corresponde ao nome do host desejado. Se algum deles mostrar CN=*.tt.omtrdc.net , a implementação não está pronta.
    $ validateEdgeFpsslSni target.example.com
    mboxedge31.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
    mboxedge32.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
    mboxedge34.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
    mboxedge35.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
    mboxedge36.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
    mboxedge37.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
    mboxedge38.tt.omtrdc.net: *  subject: C=US; ST=California; L=San Jose; O=Adobe Systems Incorporated; CN=target.example.com
    
    
  3. Valide seu novo CNAME DNS com outra solicitação de curva, que também deve mostrar CN=target.example.com :
    curl -sSv https://target.example.com 2>&1 | grep subject:
    
    
    Se esse comando falhar, mas o validateEdgeFpsslSni comando acima for bem-sucedido, talvez seja necessário aguardar a propagação completa das atualizações de DNS. Os registros de DNS têm um TTL associado (time-to-live) que determina o tempo de expiração do cache para as respostas de DNS desses registros, portanto talvez seja necessário aguardar pelo menos tanto tempo quanto seus TTLs. Você pode usar o dig target.example.com comando ou a G Suite Toolbox para procurar seus TTLs específicos.

Limitações conhecidas

  • O modo de QA não ficará fixo quando você tiver CNAME e at.js 1.x porque ele é baseado em um cookie de terceiros. A solução alternativa é adicionar os parâmetros de pré-visualização a cada URL para o qual você navega. O modo de QA é fixo quando você tem CNAME e at.js 2.x.
  • Atualmente, a overrideMboxEdgeServer configuração não funciona corretamente com CNAME. Isso deve ser definido como false para evitar solicitações com falha.