Content Modernization

The Customer Care Team can assist you with making this update to your Appspace Cloud.

Ping device task:

appspace-app_-check-modern-content-url.admpkg

Use this URL in the device task: https://test0000000000000000000000000000772719d13381x66d5prd-st1.appspaceusercontent.com/content/90a3b11b-1592-4cda-b8d9-a8110a43938d/a72ddaae-e23f-4565-83d7-11a472041eb2/o/1747931517/test.txt

Whitelist:

Appspace Supported Browsers, Required URLs & Ports

Overview of the Situation: Content Modernization

To optimize our content delivery, Appspace transitioned content downloads to one of our existing, pre-approved wildcard domains. While this was an internal change aimed at improving performance, it unexpectedly surfaced two distinct issues within some customer environments:

• Issue 1: Incomplete Wildcard Domain Whitelisting:

  • What happened: Some customer network configurations did not include all of Appspace's required wildcard domains on their approved whitelist. When the content download URL changed, these devices were unable to connect to the new, un-whitelisted domain.

  • Resolution: Customers needed to update their network whitelist to include all specified Appspace wildcard domains.

  • Appspace Role: Our change highlighted an existing gap in network configuration for some customers.

• Issue 2: Chromium-based Device Certificate Validation:

  • What happened: Even after complete domain whitelisting, a subset of customers using devices with later versions of Chromium (the open-source browser project that Chrome is built upon) continued to experience issues. This was due to stricter enforcement within these Chromium versions regarding Certificate Authority (CA) validation.

    • Specifically, these Chromium versions now require successful communication with ocsp.pki.goog and other pki.goog URLs for Online Certificate Status Protocol (OCSP) and general Public Key Infrastructure (PKI) operations.

    • When Appspace changed the content download URL, devices treated this as a "new location" for certificate validation purposes. The stricter Chromium enforcement then required a fresh validation process, including reaching out to Google's PKI servers.

Resolution: Ensuring network access to p.pki.goog and o.pki.goog URLs is crucial for these devices to properly validate certificates.

On *.appspaceusercontent.com

The key piece of information is this URL has been used since 2018: Appspace Supported Browsers, Required URLs & Ports.

It must be a wildcard (*), because the subdomain (where the * is) is randomly generated for each piece of content when the device goes to download the file.

The change that we made was redirecting to a different URL based on appspaceusercontent.com instead of a legacy URL. This URL has been used in other areas of the platform.

On pki.goog whitelistings

It has come to our attention that certain devices, such as BrightSign and Logitech Tap, require a connection to the public CA OCSP responder in order to validate the TLS certificate. The OCSP responder is responsible for letting the browser know if the certificate has been revoked by the Certificate Authority (CA). Normally this check is optional and will only delay the connection if it is blocked; however, in the case of certain devices, their implementation appears to have made the OCSP check mandatory.

Appspace utilizes Google Trust Services as our CA (pki.goog), and they specify in their FAQ here: https://pki.goog/faq/#faq-ocsp that their OCSP responder is on ocsp.google.com and o.pki.goog These domains need to be allow listed on port 80. Port 80 is required by the OCSP protocol, and the content is signed to ensure it cannot be modified in transit over the HTTP connection.

Additional Notes

This is a change by Google, and is not related to Appspace.

This also does not apply to every device (Brightsign S5, Logitech Taps, Mediavues) based on the Chromium version and requirements.