Frequently Asked Questions
The following information answers frequently asked questions about requesting and implementing CNAME support in Target:
Can I provide my own certificate (Bring Your Own Certificate or BYOC)?
You can provide your own certificate. However, Adobe does not recommend this practice. Management of the SSL certificate lifecycle is easier for both Adobe and you if Adobe purchases and controls the certificate. SSL certificates must be renewed every year. Therefore, Adobe Client Care must contact you every year to obtain a new certificate in a timely manner. Some customers can have difficulty producing a renewed certificate in a timely manner. Your Target implementation is jeopardized when the certificate expires because browsers refuse connections.
How long until my new SSL certificate expires?
All Adobe-purchased certificates are valid for one year. See DigiCert’s article on 1-year certificates for more information.
What hostnames should I choose? How many hostnames per domain should I choose?
Target CNAME implementations require only one hostname per domain on the SSL certificate and in the customer’s DNS. Adobe recommends one hostname per domain. Some customers require more hostnames per domain for their own purposes (testing in staging, for example), which is supported.
Most customers choose a hostname like target.example.com
. Adobe recommends following this practice, but the choice is ultimately yours. Do not request a hostname of an existing DNS record. Doing so causes a conflict and delays time to resolution of your Target CNAME request.
I already have a CNAME implementation for Adobe Analytics, can I use the same certificate or hostname?
No, Target requires a separate hostname and certificate.
Is my current implementation of Target impacted by ITP 2.x?
Apple Intelligent Tracking Prevention (ITP) version 2.3 introduced its CNAME Cloaking Mitigation feature, which is able to detect Target CNAME implementations and reduces the cookie’s expiration to seven days. Currently Target has no workaround for ITP’s CNAME Cloaking Mitigation. For more information about ITP, see Apple Intelligent Tracking Prevention (ITP) 2.x.
What kind of service disruptions can I expect when my CNAME implementation is deployed?
There is no service disruption when the certificate is deployed (including certificate renewals).
However, after you change the hostname in your Target implementation code (serverDomain
in at.js) to the new CNAME hostname (target.example.com
), web browsers treat returning visitors as new visitors. Returning visitors’ profile data is lost because the previous cookie is inaccessible under the old hostname (clientcode.tt.omtrdc.net
). The previous cookie is inaccessible due to browser security models. This disruption occurs only on the initial cut-over to the new CNAME. Certificate renewals do not have the same effect because the hostname doesn’t change.
What key type and certificate signature algorithm is used for my CNAME implementation?
All certificates are RSA SHA-256 and keys are RSA 2048-bit, by default. Key sizes larger than 2048-bit should be requested explicitly through Customer Care.