What is Ads.cert and How Does It Work?

Despite years of advancement in programmatic advertising — header bidding, rapidly growing ad spend, increasingly sophisticated targeting — two stubborn problems remain: ad fraud and a persistent lack of supply chain transparency. Ads.cert is one of the more technically substantive attempts to address both.

This article explains what ads.cert is, how it relates to ads.txt, and how the cryptographic signing mechanism works in practice.

What is Ads.cert?

Ads.cert is the Interactive Advertising Bureau's (IAB) cryptographic upgrade to the ads.txt standard — "authorized digital sellers." Where ads.txt establishes a whitelist of authorized inventory sellers, ads.cert goes a step further by introducing cryptographically signed bid requests. The goal is to authenticate publisher inventory end-to-end and give buyers a way to verify that the inventory they're bidding on is what it claims to be.

The underlying driver is scale of the problem: it is estimated that companies investing in online advertising may lose approximately one-third of their advertising dollars to invalid traffic. The rise of mobile, video, and OTT channels has only expanded the attack surface available to fraudsters.

Ads.cert specifically targets domain spoofing — where fraudulent inventory is passed off as premium publisher inventory — and the related practice of arbitrage, where impressions are purchased from publishers and then repackaged and resold at a higher price with manipulated attributes.

What is Ads.txt?

To understand ads.cert, it helps to understand the mechanism it builds on.

Ads.txt is an IAB Tech Lab solution for verifying authorized resellers of ad inventory. Publishers add an ads.txt file to their website, which acts as a whitelist of the supply-side platforms (SSPs) and ad exchanges permitted to sell that publisher's inventory. Programmatic buyers crawl the web to collect these files and use them to filter against OpenRTB bid request data — specifically the seller ID fields — to verify that the entity offering inventory is actually authorized to do so.

A real-world example of what an ads.txt file looks like can be found hosted at www.nytimes.com. Because the file lives on the publisher's own domain, it carries inherent trust. A representative extract looks like this:

amazon-adsystem.com, 3030, DIRECT
appnexus.com, 3661, DIRECT
facebook.com, 907986699290885, DIRECT
facebook.com, 1517497888551829, DIRECT
facebook.com, 785027118203148, DIRECT
google.com, pub-4177862836555934, DIRECT
google.com, pub-9542126426993714, DIRECT
indexexchange.com, 183760, DIRECT
indexexchange.com, 184733, DIRECT
liveintent.com, 130, DIRECT
openx.com, 537145107, DIRECT
openx.com, 539052954, DIRECT
openx.com, 539936340, DIRECT
rubiconproject.com, 12330, DIRECT
rubiconproject.com, 17470, DIRECT
yieldmo.com, New%20York%20Times, DIRECT
yieldmo.com, 1364526672772446209, DIRECT

In the open exchange, if a seller's ID matches an entry in the ads.txt file, the DSP can proceed with a bid. Third parties not listed are excluded from pushing ads to that publisher's site.

However, ads.txt has documented limitations:

• Misspellings in the ads.txt file can cause DSPs to ignore otherwise valid inventory.
• Inventory type is not always specified, which means display inventory can be repackaged and sold as video inventory, artificially inflating CPMs.
• Publishers are sometimes pressured into adding unknown or dubious third parties to their ads.txt lists.

These are the gaps that ads.cert was designed to close.

What is Ads.cert For?

The IAB's response to ads.txt's shortcomings is OpenRTB 3.0 Authentication via Signed Bid Requests — commonly referred to as ads.cert.

Unlike ads.txt, ads.cert is not a file in the conventional sense. It is a cryptographic signing protocol for bid requests. It was designed to complement ads.txt, not replace it: while ads.txt validates which SSPs and ad exchanges are authorized to sell a publisher's inventory, ads.cert validates the integrity of the data being transmitted at each stage of the supply chain.

In the open exchange, buyers make purchasing decisions based on a range of signals, including:

• Publisher's domain
• User location
• User's IP address
• User's device
• Ad position on the page
• Impression type
• Other contextual variables

It has become straightforward for bad actors to manipulate these variables along the supply chain, making low-quality or fraudulent inventory appear premium. Ads.cert is designed to make that manipulation detectable.

Benefits for Publishers (Sellers of Ad Space)

• Greater control over which inventory is sold and which ads are displayed.
• A mechanism to exclude fraudulent inventory sellers and reduce unfair competition.
• Improved pricing due to greater overall transparency in the programmatic ecosystem.

Benefits for Advertisers (Buyers of Ads)

• A free, reliable way to identify authorized publishers.
• Better return on programmatic spend through more trustworthy inventory signals.
• Reduced risk of ads appearing on fraudulent or brand-unsafe sites.
• Exposure of attempts to misrepresent display inventory as video inventory for higher monetary gain.

How Does Ads.cert Work?

Ads.cert works by cryptographically signing bid requests. Every stakeholder in the ad supply chain is required to use an encrypted signature, and buyers must use a matching public key to confirm that the source of the inventory is legitimate.

The encryption is based on a two-key system:

• Public key — disseminated widely; used by recipients to verify the bid request.
• Private key — known only to the publisher; used to generate the signature attached to the bid request.

This two-key approach achieves two goals simultaneously:

Authentication: The public key verifies that the holder of the private key actually sent the bid request.

Encryption: Only the private-key holder can decrypt the bid request encrypted with the public key — meaning only the publisher (or authorized SSP acting on their behalf) can make changes to it.

Publishers — or their AdTech partners — communicating with exchanges create a signature for a bid request that is then re-transmitted by the ad exchange or SSP.

Here is the step-by-step process, based on the IAB Tech Lab's documentation:

1. Key generation: The publisher uses OpenSSL to generate a pair of ECDSA keys based on the bid request:

   • Public key — secured yet accessible, to be read by systems that validate bid requests against signatures. The public key file must be shared via HTTP and/or HTTPS from the publisher's website under a relative path on the server: /ads.cert. Although ads.cert is referred to as a file, the resource does not need to come from a file system.
   • Private key — secret, secure, and inaccessible to outside systems, yet accessible to the systems that generate and sign bid requests (e.g., the SSP). Private keys are in a standard format recognized by compatible security packages.

2. Signature generation: An encrypted signature based on the bid request is generated using the private key. The SSP attaches this signature to the bid request and sends it on behalf of the publisher, along with impression details such as the publisher's website or app, industry, language, and so on.

3. Recipient verification: The recipient of the request uses the public key to generate a second signature for the same bid request.

4. Signature comparison: The two signatures — the publisher's and the recipient's — are compared. If they match, the bid request is considered legitimate. Any alterations to the signed elements can be detected by the recipient or other servers in the chain.

Challenges of Ads.cert

Ads.cert is a meaningful improvement on ads.txt, but it comes with real adoption hurdles:

• OpenRTB 3.0 dependency: Ads.cert only works with OpenRTB 3.0. Unlike the transition from OpenRTB 2.3 to 2.4 or 2.5 — which was largely seamless — OpenRTB 3.0 is not backward compatible with existing technology. DSPs, SSPs, and ad exchanges all need to invest in platform development before they can participate. That is a significant barrier to rapid adoption.
• Network effect requirement: As with ads.txt, ads.cert's effectiveness depends directly on how broadly it is adopted. A partially adopted standard leaves gaps that fraudsters can exploit.

Conclusion

Cryptographically signed bid requests represent a logical and technically sound progression from the whitelist-based approach of ads.txt. Ads.cert doesn't replace ads.txt — it addresses the layer of supply chain manipulation that ads.txt cannot reach on its own.

The relatively rapid adoption of ads.txt across major publishers is an encouraging precedent. Whether ads.cert follows a similar trajectory will largely depend on how quickly DSPs, SSPs, and ad exchanges invest in OpenRTB 3.0 compatibility. The lack of backward compatibility makes this a heavier lift than previous OpenRTB version transitions, and the practical impact of ads.cert will scale in proportion to the industry's willingness to make that investment.