Automatic Signed Exchanges (SXGs) Beta Launch

Hi Everyone,

I’m Firat, the Product Manager for Automatic Signed Exchanges (SXGs). We’re excited to announce that, starting today, Cloudflare customers will be able to generate signed exchanges (SXGs) for Google Search with just one click.

You can enable SXGs Beta for your zones with a Pro or Higher plan, or for your zones with the APO subscription, by visiting the Speed tab in your dashboard:

  • Dashboard > Speed > Optimization > Automatic Signed Exchanges (SXGs)

Note: There are some requirements / limitations surrounding this Beta launch [ you can read about them below ]: we kindly ask you to keep those in mind.

What are signed exchanges?

Signed HTTP exchanges are an open, standard delivery mechanism that make it possible to authenticate the origin of a resource, independent of how it was delivered — enabling massively faster delivery of a website from a third party, such as Google itself from its search results page, or from a news aggregator that is linking out to other sites. This decoupling enables a variety of use cases, such as prefetching, offline Internet experiences, and serving from third-party caches. It does so in a secure and privacy-preserving manner, and Cloudflare automatically handles all packaging and certificate handling.

The advantage to you as a website owner? You can improve your website’s performance by making cacheable resources available on Google’s Signed Exchanges, enable Chromium based browsers to prefetch your website on Google’s search results page and make your website faster. You can also improve the Largest Contentful Paint (LCP) which is part of the Core Web Vitals and increase your SEO ranking.

How do signed exchanges work?

Now, imagine yourself as the ruler of your kingdom with an important message to deliver to all your subjects. You have too many people to reach, so you can’t do it alone:

You decide to enlist your trusty knights to ride out with large chests filled with copies of your message. There are villains everywhere that would love to take these messages and modify them for their own nefarious machinations for their own profit.

You, being the wise ruler you are, have a crafty plan: you have a very special stamp made that can imprint a seal that everyone can recognize, yet no one can recreate. With this wondrous seal, no one can tamper with the messages without breaking the seal and proving the forgery for all to see.

Now, your knights can bring these chests to all corners of the kingdom and hand out the messages to the masses, and your subjects can trust that the message came from you. There is a side benefit for your people, too. They can come whenever they want to pick up the message without your watchful eye, so they’re more inclined to read it at their leisure.

Maybe this is stretching the analogy a bit, but in the case of signed exchanges, a cryptographic signature on a digest of the response and headers acts as the tamper proof seal for the message. Fast forwarding our example to the present day: you want to get your newest web experience out to global distribution with the understanding that just about everyone will come through a search engine or aggregator site. Ahead of time, when you publish your content, the search engine crawls your site for content, but instead of delivering the raw content, you negotiate the delivery of the signed exchange. (This is accomplished simply through additional “Accept: application/signed-exchange;v=” request headers from the crawler that announces the preference for signed exchanges).

Then Cloudflare generates the signed exchange, using the following process:

  1. Cloudflare fetches the original content that you want to sign, including the response headers.
  2. An additional Digest header is added that uses Merkle Integrity Content Encoding to support the progressive detection of data modification/corruption.
  3. We also strip out headers that don’t make sense within the context of signed exchanges (like Connection, Keep-Alive, etc.) as well as security sensitive headers (Set-Cookie, Authentication-Info, etc.).
  4. Then these headers, including the digest, along with additional metadata, like request URL, URL of the certificate, hash of the certificate, expiration time, etc., are all chained together into a stream that is used to calculate the final signature.
  5. The original content, along with the headers, signature, and a fallback URL are then packed into a final binary for delivery.

This signed exchange is then cached and sent to the crawler, which also stores the signed exchange. After indexing the content, it can now show up in searches. The user then discovers the link to your content in the search results. The search engine also preloads the signed exchange for your content in the background in the meantime, effectively pre-filling the cache in the client’s browser. This exchange was delivered from the search engine, so no signal has gone to the origin yet. Thus, the search intent of the user isn’t leaked to the origin. Since the exchange is signed and validated against your certificate, the browser trusts the contents and can display the content with attribution to the original URL. Now, when the user clicks on the link to view the contents, it magically loads instantaneously from the local cache.

There are many resources on the web available that go into detail about the specific format of signed exchanges, so we won’t rehash them here in detail. But one important aspect that isn’t obvious at first glance is the complexity of managing the signing process itself. The many details involve:

  • The inclusion of the atypical CanSignHttpExchanges extension to your certificate.
  • The requirement to deliver your certificates in a specific CBOR (like binary JSON) format.
  • OCSP stapling to ensure the validity of the certificates is required.
  • Renewals of these certificates on a more frequent basis (i.e. requires automation).
  • Caching of the generated signed exchanges, since they can be expensive to generate.

Luckily, all of these are in Cloudflare’s wheelhouse, since we already have deep expertise in Certificate Management and TLS delivery infrastructure. By partnering with Google on the signed exchange implementation, we can ensure the consistency of implementation, but improve the simplicity of integrating the technology with the single push of a button.

Bigger than search alone

The broader implication of SXGs is that they make content portable: content delivered via an SXG can be easily distributed by third parties while maintaining full assurance and attribution of its origin. Historically, the only way for a site to use a third party to distribute its content while maintaining attribution has been for the site to share its SSL certificates with the distributor. This has security drawbacks. Moreover, it is a far stretch from making content truly portable.

In the long-term, truly portable content can be used to achieve use cases like fully offline experiences. In the immediate term, the primary use case of SXGs is the delivery of faster user experiences by providing content in an easily cacheable format. Specifically, Google Search will cache and sometimes prefetch SXGs. For sites that receive a large portion of their traffic from Google Search, SXGs can be an important tool for delivering faster page loads to users.

It’s also possible that all sites could eventually support this standard. Every time a site is loaded, all the linked articles could be pre-loaded. Web speeds across the board would be dramatically increased. Matthew’s blog post talks more about this possibility.

What are the requirements for enabling SXGs?

  1. Automatic Signed Exchanges (SXGs) is available for the zones with a Pro or Higher plan, or for the zones with the APO subscription.
  2. SXGs only works with zones that are using Cloudflare Nameservers with orange clouded DNS records.

Note: To change your domain nameservers, please follow the instructions in this article. Then, turn on the Cloudflare proxy (orange cloud) for any relevant DNS record.

  1. The certificates for the zone need to be managed by Cloudflare.

Note: To obtain an SXG certificate, you need to add a CAA Record for issuance of the certificate from the Certificate Authority. Cloudflare adds the corresponding CAA records in DNS on behalf of users after they enable SXGs, to make sure issuance is not blocked. If you would like to obtain SSL certificates thatare issued by other CAs, please ensure that you add the CAA records for the CAs after enabling SXGs.

  1. Content needs to be cached every 120 seconds or longer.

Note: Google checks to make sure that content is cached over two minutes to generate an SXG. Please ensure that content is cached every two minutes or longer:
Dashboard > Caching > Configuration > Browser Cache TTL

  1. AMP Real URL needs to be disabled if SXGs is enabled:

Dashboard > Speed > Optimization > AMP Real URL

Limitations

  1. Currently, signed exchanges are used by Google for Android search.
  2. Google does not load signed exchanges for all search results on a page, only a selection.
  3. Signed exchanges can strip out certain cookies and headers, and create problems with dynamic content. The following hop-by-hop and other uncached headers will be stripped during the signed exchange generation:
  • Hop-by-hop header fields listed in the Connection header field (Section 6.1 of [RFC7230]).
  • Header fields listed in the no-cache response directive in the Cache-Control header field (Section 5.2.2.2 of [RFC7234]).
  • Header fields defined as hop-by-hop: Connection, Keep-Alive, Proxy-Connection Trailer, Transfer-Encoding, Upgrade
  1. Since Cloudflare cannot be sure whether a signed exchange does or does not include private information, a signed exchange will not be generated in the presence of the following headers:

Authentication-Control, Authentication-Info, Clear-Site-Data, Optional-WWW-Authenticate, Proxy-Authenticate, Proxy-Authentication-Info, Public-Key-Pins, Sec-WebSocket-Accept, Set-Cookie, Set-Cookie2, SetProfile, Strict-Transport-Security, Vary, WWW-Authenticate

FAQs

How can I verify that Automatic Signed Exchanges (SXGs) is working as expected?

There are a couple of ways to ensure that SXGs is working properly for your zone:

Method 1:

  1. Run the following command in your terminal:

curl -svo /dev/null https://example.com -H "Accept: application/signed-exchange;v=b3"

  1. Verify that the Content-Type is set to application/signed-exchange;v=b3

Method 2:

  1. On desktop, open Chrome and click on F12.
  2. Select an Android phone via the Device Mode.
  3. Navigate to the Network tab.
  4. Search for your zone in a way that it appears as a top result. For example, yourdomain.com + website
  5. Under Type, you should see the result with signed-exchange / Redirect.

Method 3:

  1. Open Google Search Console
  2. Do a Mobile Usability URL Live Inspection of a URL link on your site
  3. Inspect the MORE INFO → HTTP Response
  4. If content-encoding: mi-sha256-03 is displayed, it means SXGs is working properly for your zone.

How can I debug SXGs?

  1. For a list of tools that you can use to debug SXGs, please check out web.dev’s guide to SXG tools.
  2. If it’s an AMP page, you can check out the AMP status report - Search Console Help, which explains the impact.
  3. For non-AMP cases, or non-AMP SXGs customers, unfortunately, a help page doesn’t exist yet which would describe the error type breakdown, but if there are any critical errors that would warrant disabling SXGs:
  1. You should be able to detect them for a specific URL by following the steps in Verify SXGs Setup.
  2. They should show up later in Search Console as "Fetch error"s, per Monitor and debug SXGs.
  1. To ensure that Googlebot is able to crawl and index a page served by SXGs, take these steps:
  1. Verify that the Content-Type is set to application/signed-exchange;v=b3.
  2. Make sure that the dump-signedexchange command succeeds.
  3. Check that the signed URL matches the request URL exactly.

I am getting the following error in the Search Console (AMP pages): “The dates for the signed exchange are invalid.”. Is this a problem?

No. Google can still parse the signed exchange and treat it like normal HTML, so it falls back to earlier behavior. In this case, it’s an AMP page, so it should fall back to AMP behavior.

What CA do we use for SXGs?

We use Digicert for SXGs certificate issuance, and once SXGs is enabled, we add the CAA records on behalf of the zones:

% dig example.com caa

> ;; ANSWER SECTION:
> example.com. XXXX IN CAA 0 issue "digicert.com; cansignhttpexchanges=yes"
> example.com. XXXX IN CAA 0 issuewild "digicert.com; cansignhttpexchanges=yes"

There are requests from the “/.well-known/sxg-map” path that I am not familiar with. Should I be concerned?

No. This is for an unreleased/in-development feature. It’s safe to block those requests, and the Users can ignore them.

There are “Content type of cert-url must be application/cert-chain+cbor” errors in my console. Is this a problem?

No. It represents a cache miss when the website gets a 200 with a Location header and without a Warning header; it should be temporary.

Please let us know if you have any questions.

Thanks again for choosing Cloudflare!

#SXGs

8 Likes

Thank you @firat

I have enabled it.

How do we know that its working in our site? Where we can check?

Thanks
Giri

I assume if something goes bad with SXG, we would see a report as far as any error would happen as it would be shown in Google Search Console - that was for at least with the AMP Real URL option (if I disable it, but have AMP URLs on my domain, I got warnings and errors under the AMP section in GSC) - just guessing.

2 Likes

Hi Giri.

When you search for your website in Android [ either on mobile or on Chrome desktop with Device Mode ], you should see the SXG for your zone under the Network tab, when you sort by Type.

Though Google does not generate an SXG for all the search results, only a selection, in most cases for the top results.

Since this is still in Beta, please also ensure that your zone meets the requirements.

1 Like

Thank You @firat

I will check later as you instructed. Hope it will take some time to reflect in the results.

I have disabled the AMP earlier itself and no more AMP, so I have disabled the AMP real URL too.

AMP is creating more troubles and creating confusion in the search console. I’m going to stick with Page Experience which is fine for me. I would like to have a single URL.

Thank you for your update. Will check and update.

Giri

1 Like

Might want to warn users enabling SXGs, enables CAA DNS records which could prevent folks from obtaining SSL certificates from CA providers other than those auto added to domain zone’s CAA DNS records

cf-caa-01

Had to add CAA for ZeroSSL/Sectigo, Amazon AWS, SSL.com and Buypass SSL too

test CAA https://caatest.co.uk/

6 Likes

Very useful info!

1 Like

Any chance of having a more detailed step by step example, maybe a screenshot of what it should look like when it’s enabled and working fine?

Thanks,
Flo

I have SXGs enabled and getting this error from Search Console (AMP pages): The dates for the signed exchange are invalid.? I’ve followed all the recommendations from the blog post.

2 Likes

I am also having a problem where the search console is showing The certificate chain referenced by 'cert-url' is invalid for the signed exchange for Google Web Stories. I have disabled AMP Real URL and tried to revalidate it but that did not fix the problem.

Hi Yoav. Google can still parse the SXG and treat it like normal HTML, so it falls back to earlier behavior. In this case, it’s an AMP page, so it should fall back to AMP behavior.

You don’t need to disable SXGs.

1 Like

Hi flo1.

1 - On desktop, open the Chrome and click on F12.
2 - Select an Android phone via the Device Mode.
3 - Navigate to the Network tab.
4 - Search for your zone in a way that it appears as a top result. For example,yourdomain.com + website
5 - When you sort by Type, you should see the result with the signed exchange.

I hope this helps.

6 Likes

Hi eva2000,

If someone wants to obtain a SXG certificate, they need to add a certain CAA Record for issuance. Cloudflare does that on behalf of the Users upon enablement of SXGs. We add these records to make sure issuance is not blocked. If you have issuance of SSL certificates from other CAs, please ensure that you add the additional CAA records after enabling the SXGs.

We will also put this as a warning, thank you for flagging this.

4 Likes

That’s brilliant, many thanks!

1 Like

Hello @firat

Thank You for your details.

I tried for my site (https://www.giriblog.com) as you instructed, but it’s not showing.

Should I wait? Am I doing anything wrong? I don’t have AMP.

Giri

1 Like

Thank you, Cloudflare!

It’s working on my website upon checking on the Chrome inspect tool.

2 Likes

Hi Giri.

Do you see any of these errors in your search console?

https://support.google.com/webmasters/answer/7450883#zippy=%2Csigned-exchange-issues

Same here, doesn’t seem to work :face_with_monocle:

Hello @firat

I couldn’t find error in the search console. I have removed AMP a month back as well.

Thanks
Giri

Cheers @firat

SXGs looking good. Here’s throttled 5Mbps cable network tests for the Wordpress HTML doc where first 2 requests are from SXGs via Google search on emulated Android mobile and then the 4 subsequent F5 refresh are from non-SXGs so you can compare the response times (top value) vs network times (bottom value) of each request.

SXGs cumulative time is 4+8 = 12ms versus non-SXGs of 96-109ms total or 37-53ms network time.

1 Like