Skip to main content

Device Certificate Status List

Device Certificate Status List (DCSL) is published by Google and contains the status of the device model certificate for client devices. Clients that do not have a model certificate in this list cannot receive a DRM license. You receive the initial state of the list as a part of the Configuration Package, but according to Google requirements you have to regularly update this list.

Google recommends updating the list every 24 to 72 hours, but the update should be performed as soon as possible if this is not feasible. Disadvantages of having an older version of the list:

  • Not complying with Google policies
  • Newer devices on the market fail on playback as they are "unknown"
  • In case of a breach, vulnerable devices still can play, as the local system is not aware of their status.

See also: Configuration Options, Deployment Guide, Updating On-board Setup.

Device Certificate Status List​

Device Certificate Status List is published by Google and contains the status of the device model certificate ("OK", "revoked") for client devices. Clients that do not have a model certificate in this list are categorized as "unknown". By default, license requests from the "unknown" devices are rejected.

You receive the initial state of the list as a part of the Configuration Package (DeviceCertificateStatusList.json). The file shall be stored in the Config folder.

DeviceCertificateStatusList.json
{
  "signedList": "<base64-encoded status list>"
}

Obtaining Device Certificate Status List​

You can get a fresh copy of the list anytime from an endpoint in Axinom DRM Management API:

GET <BaseUrl>/Sync/DeviceCertificateStatusList
Authorization: Basic base64(<TenantID>:<ManagementKey>)

The response is a JSON object which you should save as DeviceCertificateStatusList.json.

The BaseUrl is:

You can find the URL valid to your tenant from My Mosaic area.

The TenantID and the ManagementKey you receive from Axinom when you register for use of Axinom DRM.

warning

Earlier, Google published the Device Certificate Status List publicly. Since 2021 it is not the case anymore. You should use Axinom endpoint as described below to get a valid list to be used on-board with Axinom DRM.

Updating Device Certificate Status List​

Once you have obtained the list (see Obtaining Device Certificate Status List above), you can store it in the Config folder. The License Service will reload the new list in one of the three ways:

  • After a container restart
  • Automatically, per default every 5 minutes (configurable using DeviceCertificateStatusListUpdateInterval)
  • Ad-hoc, after a POST /Sync/Now (see the authorization details of the Sync API).

Alternatively, you can send the JSON object directly to the Sync API of the License Service without storing it on file before. The new list will immediately take effect:

POST <apiUrl>/Sync/DeviceCertificateStatusList 
Authorization: Basic base64(:<API key>)
Content-Type: application/json

{
  "signedList": "<base64-encoded status list>"
}

Disabling Automatic Reload​

Per default the License Service reloads the DeviceCertificateStatusList.json every 5 minutes.

If you decide to restart the container manually when you update the list or to use the Sync API to push the updates, you should disable automatic reloading, as you know the file will not change in between.

To disable automatic reloading set the DeviceCertificateStatusListUpdateInterval to 0 in the Application Configuration.

Allowing Unknown Devices​

Clients that do not have a model certificate in this list are categorized as "unknown". By default, license requests from the "unknown" devices are rejected.

But there is a way to allow unknown devices to obtain licenses. Setting the AllowUnknownDevices option to "true" in the application configuration allows unknown devices, i.e. the devices not present in the device certificate status list, to obtain licenses.

warning

Enabling this option poses a security risk. Unknown devices may be insecure and compromise content keys in licenses. They can also cause a leakage of content and content keys. Use it only if you understand the implications. For example for testing or troubleshooting purpose.

A valid use case is, for example, if you design a new device on your own and this device is not yet registered on the official list, but you would like to test the playback on the device already.