CA Certificates on BrightSign Players

1 Overview
2 Requirements for BrightSign Players
3 Adding CA Certificates
4 Unsigned Certificate Limitations
5 Per-Access Certificates vs. Semi-Permanent Certificates
- 5.1 Per-Access Certificates
- 5.2 Semi-Permanent Certificates
6 Other

Overview

To load HTTP or HTTPS content, BrightSign players must be able to add the certificates that correspond to that content. You can add this ability through BrightAuthor, BrightAuthor:connected, or through scripts used by BrightAuthor:connected. BrightSign partners who write their own CMS solutions must add the ability to manage certificates.

Requirements for BrightSign Players

The requirements for CA certificates that can be used with our players are on the https://support.brightsign.biz/hc/en-us/articles/360008543093-Root-CA-Certificates page. The PEM format type is supported.

Adding CA Certificates

For instructions on how to add a CA certificate in BrightAuthor, see https://support.brightsign.biz/hc/en-us/articles/360024205233-How-do-I-display-a-webpage-that-requires-a-client-certificate-

For instructions on how to add a CA certificate in BrightAuthor:connected, see Network Options | Certificates

To add CA Certificates through scripts:

Users can install an unsigned certificate package through roKeystore (or keystore), AddClientCertificate or AddCACertificate, before accessing the resource.
The roKeystore (or keystore) objects allow users to register client certificates with the player. In roKeystore, use AddCAPackage to install persistent .bsca packages.
A .bsca is required if the client is using an HTTPS URL with a certificate signed by a non-public root or intermediate for recovery, because there’s no way to add the certificate before the recovery URL is accessed. This is also true when an HTTPS proxy is used and that proxy uses internal/self-signed certificates. HTTPS URLs using certificates the player already trusts are okay, as long as the player’s clock is set so certificate selection can happen.

Unsigned Certificate Limitations

When the certificate is not signed and permanently installed, the certificate file will need to be on the SD card which could have security implications. When a signed certificate is installed, it cannot be recovered from storage in a usable form and can be removed from the SD card.

Unsigned certificates do not persist if a player reboots.

Per-Access Certificates vs. Semi-Permanent Certificates

BrightSign recommends that you use a per-access certificate unless you have a CMS that requires HTTPS that cannot be publicly validated.

Per-Access Certificates

This defines a client certificate for a specific HTTP widget. Specific code needs to be run to load the certificate when creating the HTML widget, so this must be "enabled" in the content management system through an option or plugin. You can manage changes to these certificates without BrightSign intervention, but you may need CMS intervention depending on how your system handles certificates.

The disadvantage to per-access certificates is that because the client certificate is loaded at runtime, early processes like recovery, and processes that run outside of the CMS client runtime like device setup cannot use the client certificate so there must be a non-HTTPS link to the server for setup.

Semi-Permanent Certificates

A .bsca certificate package can be semi-permanently installed on a player, and will apply to all player functionality, so recovery and other processes will work as long as the player has the .bsca package installed. The disadvantages are:

BrightSign must sign the certificate package into a .bsca that can be installed on the player.
If the player requires multiple client certificates or trust chains, they must all be included in the .bsca. So .bsca packages must be updated frequently if different sets of servers have differing certificate expiration dates.
The player must be temporarily offline from the CMS to install the .bsca and it generally requires manual intervention/attention from someone with direct network access to the player.
Factory reset clears installed .bsca certificates. This can be an issue for CMS systems that deliver configuration files that issue a factory reset and then (re)apply settings, as the (re)applied settings would not include the .bsca installation, potentially resulting in the player not being able to contact the CMS, mandating on-site or near-site (on-network) access to the player.