¶ºÒõ¹Ý

¶ºÒõ¹Ý first and only public CA to issue TLS certificates that enable Signed HTTP Exchange

Web operators using the Google AMP (Accelerated Mobile Pages) platform for fast mobile pages now have a solution for displaying their own URL on AMP-developed mobile sites and in Google search results. Recently, Google announced the availability of Signed HTTP Exchange (SXG) in the Chrome browser, which allows AMP publishers to use SXG-enabled TLS/SSL certificates to properly display the site owner’s domain. ¶ºÒõ¹Ý is currently the only public CA in the world to offer TLS certificates with SXG enabled.

SXG is a technical framework that enables browsers to display publisher URLs on cached AMP results. Currently, SXG is available for Chrome 73 and newer versions (and is expected to arrive in an update of Microsoft Edge).

¶ºÒõ¹Ý provides SXG-compatible certificates via our leading TLS platform: ¶ºÒõ¹Ý CertCentral®. Our SXG certificates are specially designed to be trusted in the same ecosystem as typical HTTPS content and to work synchronously alongside traditional TLS certificates.

If you’re interested, sign up for a CertCentral account here or reach out to your account rep to have SXG enabled for your account.

AMP pages are most commonly recognized by the little lightning bolt symbol next to the URL in Google search results on a mobile device. The lack of AMP’s ability to display the website owner’s URL, instead of a URL starting with Google (https://google.com/amp/example.com/amp-content-example) has been an issue for developers since AMP launched in 2015. Using TLS certificates with SXG-enabled overcomes this issue and provides a major advantage to digital marketers, especially those with brand- and revenue-dependent sites that receive heavy mobile traffic.

AMP is widely used because it allows web publishers to create special, and often pared-down, versions of their web content, which are cached and served to mobile users, often directly from search results. This allows mobile users to get the information they are searching for much more quickly, with lightning-fast page loads. While it may not sound like much, a millisecond or two in page load times can make a major difference in the user experience and how long site visitors will stay on a page before they abandon for a faster-loading page. A 2017 revealed that every 100-millisecond delay in website load time can hurt conversion rates by 7%. That adds up to lost revenue and opportunity.

AMP was developed by Google as an open source project to support content publishers in need of streamlined versions of their desktop sites for mobile web users. In 2016, Google integrated AMP pages into search results to further encourage mobile web performance and mobile web browsing.

Because most major sites were not optimized for the web, AMP required Google to pre-render everything and use the cached google.com/amp URL structure. This made it possible for Google to serve mobile pages more quickly across the web. The downside was that the required URL structure for AMP eroded the company URL from the search results.

Introduction of SXG also strengthens mobile web security. Previously, AMP did not provide cryptographic proof to an end user that the content served by Google’s servers was, in fact, byte-for-byte identical to the content created by the publisher. In effect, the origin shifted mid-stream from the publisher to AMP.

Using current technologies for AMP to solve this problem, we would likely have ended up with a situation common in other circles, where the content publisher provisions a TLS certificate on behalf of the domain owner. This is, itself, a less than ideal approach to the problem, as it causes further private key sprawl (and other technologies, like delegated credentials, are being worked on to help diminish such risks).

Instead of leveraging the status quo, Google invested in identifying novel approaches to solving this problem of immutable content delivery. The result is Signed HTTP Exchanges, which utilize web packaging standards to provide a mechanism of signing a concrete tuple of information: a request URL, content negotiation information, and a response.

These data are packaged together, signed by the content publisher, and then handed off to AMP. AMP can then serve the content and display the signature on the content as cryptographic proof that it hasn’t been tampered with in any way. The origin gets to stay the origin, with AMP acting only as an accelerator for serving the content.

Developers of AMP pages can use TLS certificates from ¶ºÒõ¹Ý for SXG to solve their previous issues. ¶ºÒõ¹Ý is the only CA currently to offer SXG support and is able to do this because of our broad industry standards participation and understanding. Using this solution ensures that the cache served by such third parties as Google can be independently verified with their own URL displaying, and can gain proof against any potential content tampering.

Find more information about CertCentral and ¶ºÒõ¹Ý’s support of SXG here.