Add Digital Certificates

brightsign players use digital certificates to ensure secure connectivity and content delivery players use client certificates to authenticate to secure networks over wi fi or ethernet to interact with secure websites (e g , displaying web pages via https), players rely on root ca certificates to verify server certificates these certificates are issued by trusted certificate authorities (cas), ensuring robust security for both network authentication and web interactions client certificates in order to access a secure network, whether wireless (e g , wi fi) or wired (e g , ethernet), players need to provide authentication a client certificate is a digital certificate issued to a player to authenticate its identity to a network or server players use client certificates to prove their identity to secure wi fi (e g , wpa2/wpa3 enterprise with eap tls) or ethernet networks while players do offer the ability to use password based network authentication, many customers prefer using client certificates, not only because of the added security, but also for their ability to provide network revocation of specific players with a password based authentication system, network access revocation of specific players is not possible since changing the password necessarily affects all players using that password client certificates are typically issued by an organization's it department and can be applied to players using either brightsign author or the brightscript scripting language root ca certificates a root ca certificate is the top level certificate in a ca’s trust chain, issued by a root ca they can be installed on players to establish trust for certificates signed by that ca players typically use a root ca certificate to verify the identity of a secure website’s server certificate in order to display the website's content and/or to enable encrypted communication between the player and server root ca certificates can be added to players using either the brightsign author app or the brightscript scripting language brightsign partners who operate their own content mangement systems (cms) must include the ability to manage these types of certificates certificate format the brightsignos uses nss for all certificates and supports the pem format type 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 note that your os or browser may indicate that this file cannot be downloaded securely this is only a warning and you can choose to "keep" the file inside the nss 3 42 1 package, the certs data is located at nss/lib/ckfw/builtins/certdata txt adding certificates both client and root ca certificates can be added using either the brightsign author app or by using brightscript to access the player's apis the easiest way to do this is through the app, as coding in brightscript requires a higher level of technical skill brightsign author to add a certificate to a player using the brightsign author app, follow the steps below obtain the necessary certificate the info on this page https //gist github com/mtigas/952344 may be useful in converting certificates to the proper format and/or concatenating multiple certificates into a single, combined file add the certificate to a setup file for more info about setup files, refer here https //docs brightsign biz/user guides/setup from admin > setup , click network configuration > network options if adding a root ca certificate, select the player tab and go to the certificates section if adding a client certificate, select the wired or wireless tab depending on your network type, and go to the security section enter the relevant certificate info select done and save setup to save the setup file save the setup file to a storage device (e g , microsd card) install the storage device to the player there is unfortunately no way to modify certificates over the network the only way to modify the certificate(s) is to repeat the above process self signed certificates there may be situations where it is desired for players to use self signed certificates (i e , certificates not issued by a ca but instead created and signed by the user themselves) since self signed certificates are not widely trusted, they are typically used only in testing or controlled environments the brightsign author app can be used to apply self signed certificates to players through the use of a plugin https //github com/brightsign/brightauthor plugins/tree/master/add client certificates brightscript certificates can also be added to player using the brightscript scripting language, although this requires more technical skills users can install an unsigned certificate package through rokeystore docid\ ghsznw9es8temurqxq du (or keystore docid 6alp0aixrzlhv4cbkebvz ), addclientcertificate docid\ ghsznw9es8temurqxq du or addcacertificate 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 addcapackage 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 customers upgrading from cisco ise 3 1 to ise 3 4 or later may experience 802 1x eap tls authentication failures even when using the same certificate files and player configuration that previously worked ise 3 4 enforces strict rfc certificate chain ordering the player certificate file must present the root ca (rca) before the intermediate ca (ica) ise 3 1 accepted the reversed order; ise 3 4 does not when the chain is reversed, the player sends an ise error 12520 "eap tls failed ssl/tls handshake because the client rejected the ise local certificate"; openssl reports "unknown ca" (tls alert 48) to resolve this, open the player certificate file and reorder the chain so the root ca appears first, followed by the intermediate ca redeploy the updated file to the player and retry authentication