What is ads.cert, and what does a signed request prove?
Part of Supply path transparency
The short answer
ads.cert is an IAB Tech Lab protocol suite that lets ad businesses sign the requests they send each other. Each company publishes public keys in DNS under a domain called a Call Sign, and the Authenticated Connections protocol adds a signature header showing which business sent a request and that its URL and body were not altered.
Key takeaways
- ads.cert 2.0 has two parts: Call Signs, which publish a business's public keys in DNS, and Authenticated Connections, which signs server to server HTTP requests.
- IAB Tech Lab calls ads.cert 2.0 a complete departure from the original 2018 design, which signed OpenRTB 3.0 bid requests at the publisher.
- Protection for bid requests as they travel the supply path, called Authenticated Delivery, is listed by Tech Lab as future work.
- A valid signature proves which business sent a request; Tech Lab's own primer says outside processes are still needed to vet that business.
What is ads.cert?
IAB Tech Lab's ads.cert page (opens in a new tab), last updated February 14, 2024, describes ads.cert as the umbrella term for a protocol suite that provides an open standard cryptographic security foundation for programmatic advertising. Any party buying, selling or facilitating ad trades can deploy the free tools, and the page says the federated design creates no central authority acting as arbiter of business identity. The same page states that Authenticated Connections is ready for adoption.
Definition
- ads.cert
- A set of IAB Tech Lab protocols that let advertising businesses prove to each other, with cryptographic keys published in DNS, which company sent a message and that the message was not changed on the way.
The suite is about companies, not people. The ads.cert Primer (opens in a new tab), dated January 2022 on its cover, says all forms of consumer profile identifiers are completely out of scope and warns readers not to confuse ads.cert with end user identifiers or cookies. It divides the suite into a way to declare a business identity by distributing public keys, and individual authentication protocols built on that foundation.
| Protocol | What it does | Status listed |
|---|---|---|
| Call Signs | Establishes a domain name that identifies a business and publishes its public keys in DNS | Specification published |
| Authenticated Connections | Adds origin authentication and tamper resistance to server to server HTTP requests | Specification published; described as ready for adoption |
| Authenticated Delivery | Would add authentication and tamper resistance to bid requests and bid parameters along the supply path | Future |
| Authenticated Devices | Would let devices attest that bid requests and other signals came from them | Future |
How do signed requests work in ads.cert?
Under the Call Signs specification (opens in a new tab), a business picks an Internet domain and publishes records under the _adscert subdomain of its public suffix plus one domain. Only ICANN assigned suffixes count, and domains must be written in ASCII, with Punycode for localized names. The spec recommends, but does not require, DNSSEC for the zone.
The Authenticated Connections specification (opens in a new tab) puts the public key in a TXT record named _delivery._adscert, using the X25519 algorithm from RFC 7748. Two businesses each combine their own private key with the other's public key to arrive at the same shared secret, and use it with an HMAC over SHA-256 hashes of the request. The signature travels in an X-Ads-Cert-Auth HTTP header.
| Field | Meaning in the spec |
|---|---|
| from and from_key | The sender's Call Sign domain and the first 6 characters of its public key |
| to and to_key | The receiver's Call Sign domain and the first 6 characters of its public key |
| invoking | The domain of the URL hostname being called |
| nonce and timestamp | A random 12 character value and the signing time in UTC |
| status | Signing status, for example a suppressed signature or a DNS problem fetching the other party's keys |
| sigb and sigu | Signatures over the message and body, and over the message, body and URL |
How did the original ads.cert for bid requests differ?
The first ads.cert was written into OpenRTB 3.0 (opens in a new tab). There the publisher, or a trusted agent, signed a digest of attributes that intermediaries should never change, such as the site domain or app bundle. The digest had to include the transaction ID or the request origination timestamp to avoid replay attacks, and the signature, key file name and digest map travelled in Source.ds, Source.cert and Source.dsmap. The 3.0 text notes these attributes were in a beta state, like the specification they supported.
| Question | ads.cert 1.0 (OpenRTB 3.0 signed bid requests) | ads.cert 2.0 (Call Signs and Authenticated Connections) |
|---|---|---|
| Who signs | The publisher or its trusted agent | Each business that sends a server to server request |
| What is signed | Selected immutable bid request fields in a digest | The request URL, body and message fields |
| Where keys live | In the publisher's ads.txt directory | In DNS under the business's Call Sign |
| Strength | Tied the signature to the inventory's claimed domain | Works with any message format and does not need OpenRTB 3.0 |
| Limit | Depended on OpenRTB 3.0 support and was marked beta in the 3.0 text | Authenticates the sender, not the inventory claims inside the message |
Tech Lab's page says readers should view the 2021 ads.cert 2.0 as a complete departure from the design and direction pursued in the original 2018 strategy, while keeping the brand name. Material that describes ads.cert as publishers signing each bid request is describing the older design.
What problems does ads.cert solve, and which does it leave open?
The Authenticated Connections specification names its first target: server side ad insertion. It says security research had highlighted schemes in which parties impersonated SSAI platforms, which are hard to spot because the traffic comes from the same cloud hosts real SSAI businesses use. It recommends signing billing notifications, so a recipient can identify the SSAI platform claiming to send one and decide whether to trust it. The Primer adds server to server creative fetches and impression pings as uses.
Two design choices matter to buyers. Because ads.cert uses a shared secret rather than public key signatures, the Primer explains, signatures are exclusive to the intended recipient and either party could have created them, so a signature has no evidential value to an outside party. And tampering with bid requests as they pass between sellers is the job of Authenticated Delivery, which Tech Lab still lists as future work.
How far has ads.cert been adopted?
No public primary source located for this page reports how many companies in the United States or Canada sign or verify traffic with ads.cert. The documented status is this. Tech Lab's page says Authenticated Connections is ready for adoption. The open source repository (opens in a new tab) states in bold that it is a proof of concept and not meant for use in its current form, offers a Go client, and lists Java and C++ clients as coming soon. Whether a partner runs its own production implementation is a question for that partner.
The specification also expects partial coverage. It says signers should transmit a signature message on all requests, even when the information cannot be verified, filling at least the from and status fields, so that non participating recipients can understand the coverage of counterparties. An unsigned or partly signed request is therefore an expected state during rollout rather than proof of a problem.
What should buyers ask partners about ads.cert?
ads.cert questions for exchanges, SSAI platforms and demand platforms
- Does the partner publish an ads.cert Call Sign, and under which domain?
- Which protocol and version does it run: Authenticated Connections, or the older OpenRTB 3.0 signed bid request fields?
- Which requests does it sign: billing notifications, impression pings, creative fetches or bid requests?
- Does it verify signatures it receives, and what happens to traffic that fails verification?
- Does it run the Tech Lab reference code, which is labeled a proof of concept, or its own implementation?
- How does it store private keys, and how would it rotate them after a compromise?
- Does it enable DNSSEC on its Call Sign zone, which the spec recommends but does not require?
What does an ads.cert review look like on a real plan?
Fictional example
A coworking space operator checks its streaming video partners
An unnamed coworking space operator with locations in Newark, Jersey City and Princeton plans English video ads on business news sites and on streaming news apps whose ads are stitched in by SSAI platforms. Its agency sends the checklist above to the two exchanges and the demand platform on the plan.
One exchange answers that it publishes a Call Sign and verifies signed billing notifications from the SSAI platforms it works with, and names which ones sign. The second exchange says it has no ads.cert deployment. The agency records both answers with the date and does not drop the second exchange, since ads.txt, sellers.json and schain checks still apply to its supply.
For the streaming apps, the agency asks the first exchange to route the plan through SSAI platforms whose notifications it verifies, and keeps the answers in the plan file so the next flight can check whether coverage has grown.
How does PlacementGraph help with the seller checks ads.cert does not cover?
Frequently asked questions
Does ads.cert replace ads.txt?
No. ads.txt lets a publisher declare which systems and accounts may sell its inventory. ads.cert 2.0 authenticates which business sent a server to server request. They answer different questions, and the original OpenRTB 3.0 text described signing as most effective in conjunction with ads.txt.
Does ads.cert track users or replace cookies?
No. IAB Tech Lab says the ads.cert 2.0 protocols focus solely on businesses that buy, sell, measure, verify or facilitate programmatic advertising, and that all forms of consumer profile identifiers are completely out of scope. A Call Sign identifies a company, never a person or a device.
Can a buyer check a signature on a request sent to someone else?
No. The Primer explains that signatures are exclusive to the intended recipient: only the sender and the receiver hold the shared secret, so no other party can tell a signature from a random number. A buyer relies on its partner's verification results, not on checking another company's traffic itself.
Where are ads.cert public keys published?
In DNS. The Call Signs specification places them under the _adscert subdomain of the business's registered domain, and the Authenticated Connections specification uses a TXT record named _delivery._adscert with the key algorithm, hash algorithm and the public key itself.
Sources
- ads.cert (last updated February 14, 2024) (opens in a new tab)IAB Tech Lab
- ads.cert Primer (January 2022) (opens in a new tab)IAB Tech Lab
- ads.cert Call Signs Protocol Specification (opens in a new tab)IAB Tech Lab
- ads.cert Authenticated Connections Protocol Specification (opens in a new tab)IAB Tech Lab
- adscert open source repository (README) (opens in a new tab)IAB Tech Lab on GitHub
- OpenRTB 3.0, Source object and Inventory Authentication (opens in a new tab)IAB Tech Lab
Researched and written by PlacementGraph Research. Read how we research, source and update these pages. Corrections: diana@placementgraph.com.