Add CA Certificates

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

Root CA certificates are used by all components of the BrightSign system. The BrightSign operating system uses NSS for all certificates and the PEM format type is supported. Our current version is 3.51.1 and it is sourced from this location. This version is correct for all version 8.2.x BrightSign operating systems. 

Inside the NSS 3.42.1 package, the certs data is located at nss/lib/ckfw/builtins/certdata.txt. 

Adding CA Certificates

To add a CA certificate, use this BrightAuthor plugin (which also works with BrightAuthor:connected) to register a client certificate with a player. The player will then send the client certificate when requested by a website.

See Network Options | Certificates see for instructions on how to add a CA certificate in BrightAuthor:connected, and this page to learn more about generating client 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 file 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.

To confirm that the .bsca file is installed, check the system log for the .bsca file name which will appear there when it has been added. You can also download the installed CA certificates .pem file by entering your IP address in a web browser (http://{{ip_address}}/ca_certificates). Add a .pem or .crt extension to open it in Windows. You can also use utility like OpenSSL to inspect it.

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

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.

Other

• Only one .bsca file can be added to the player. So, if you send a different .bsca, it will replace the prior one.

• You can't delete any preinstalled certs already in the keystore. You can only delete your .bsca file and the certificates that are inside it by installing a new file.

• See also Fix Expired CA Certificates