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\ connected, {{brightauthor classic}} , or through scripts used by brightauthor\ connected brightsign partners who write their own cms solutions must add the ability to manage certificates player requirements 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 http //ftp mozilla org/pub/security/nss/releases/nss 3 42 1 rtm/src/nss 3 42 1 tar gz 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 add ca certificates to add a ca certificate, use this plugin https //github com/brightsign/brightauthor plugins/tree/master/add client certificates which works with both brightauthor\ connected as well as brightauthor classic to register a client certificate with a player the player will then send the client certificate when requested by a website see network options docid\ gfqm5hvphjqijhzxb2ngy for instructions on how to add a ca certificate in brightauthor\ connected, and this page https //gist github com/mtigas/952344 to learn more about generating client certificates to add ca certificates through scripts users can install an unsigned certificate package through rokeystore docid\ ghsznw9es8temurqxq du (or keystore docid 6alp0aixrzlhv4cbkebvz ), rokeystore docid\ ghsznw9es8temurqxq du or rokeystore docid\ ghsznw9es8temurqxq du before accessing the resource the rokeystore docid\ ghsznw9es8temurqxq du (or keystore docid 6alp0aixrzlhv4cbkebvz ) objects allow users to register client certificates with the player in rokeystore, use rokeystore docid\ ghsznw9es8temurqxq du 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 https //www openssl org/ to inspect it unsigned certificate limitations when the certificate is not signed and permanently installed, the certificate file will need to be on the microsd 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 microsd 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 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 docid\ otepknukirruin8yxjv6t players must sync with a time server to ensure that the player date and time is accurate