Agregar certificados digitales

los reproductores brightsign utilizan certificados digitales para garantizar una conectividad segura y la entrega de contenido los reproductores utilizan certificados de cliente para autenticarse en redes seguras mediante wi‑fi o ethernet para interactuar con sitios web seguros (p ej , mostrar páginas web mediante https), los reproductores dependen de certificados ca raíz para verificar los certificados del servidor estos certificados son emitidos por autoridades de certificación (ca) de confianza, lo que garantiza una seguridad sólida tanto para la autenticación de red como para las interacciones web certificados de cliente para acceder a una red segura, ya sea inalámbrica (p ej , wi‑fi) o cableada (p ej , ethernet), los reproductores necesitan proporcionar autenticación un certificado de cliente es un certificado digital emitido para un reproductor con el fin de autenticar su identidad ante una red o servidor los reproductores utilizan certificados de cliente para demostrar su identidad en redes wi‑fi seguras (p ej , wpa2/wpa3 enterprise con eap tls) o redes ethernet aunque los reproductores ofrecen la posibilidad de utilizar autenticación de red basada en contraseña, muchos clientes prefieren utilizar certificados de cliente, no solo por la seguridad adicional, sino también por su capacidad para proporcionar la revocación de red de reproductores específicos con un sistema de autenticación basado en contraseña, no es posible revocar el acceso a la red de reproductores específicos, ya que cambiar la contraseña afecta necesariamente a todos los reproductores que utilizan esa contraseña los certificados de cliente normalmente son emitidos por el departamento de ti de una organización y pueden aplicarse a los reproductores utilizando brightsign author o el lenguaje de scripting brightscript certificados ca raíz un certificado ca raíz es el certificado de nivel superior en la cadena de confianza de una ca, emitido por una ca raíz pueden instalarse en reproductores para establecer confianza en certificados firmados por esa ca los reproductores normalmente utilizan un certificado ca raíz para verificar la identidad del certificado del servidor de un sitio web seguro con el fin de mostrar el contenido del sitio web y/o habilitar la comunicación cifrada entre el reproductor y el servidor los certificados ca raíz pueden añadirse a los reproductores utilizando la aplicación brightsign author o el lenguaje de scripting brightscript los socios de brightsign que operan sus propios sistemas de gestión de contenido (cms) deben incluir la capacidad de administrar estos tipos de certificados formato de certificado brightsignos utiliza nss para todos los certificados y admite el tipo de formato pem nuestra versión actual es la 3 51 1 y se obtiene de esta ubicación http //ftp mozilla org/pub/security/nss/releases/nss 3 42 1 rtm/src/nss 3 42 1 tar gz tenga en cuenta que su so o navegador puede indicar que este archivo no puede descargarse de forma segura esto es solo una advertencia y puede elegir "mantener" el archivo dentro del paquete nss 3 42 1, los datos de certificados se encuentran en nss/lib/ckfw/builtins/certdata txt agregar certificados tanto los certificados de cliente como los certificados ca raíz pueden añadirse utilizando la aplicación brightsign author o mediante brightscript para acceder a las apis del reproductor la forma más sencilla de hacerlo es mediante la aplicación, ya que programar en brightscript requiere un mayor nivel de habilidad técnica brightsign author para agregar un certificado a un reproductor utilizando la aplicación brightsign author, siga los pasos a continuación obtenga el certificado necesario la información de esta página https //gist github com/mtigas/952344 puede ser útil para convertir certificados al formato adecuado y/o concatenar varios certificados en un único archivo combinado agregue el certificado a un setup file para obtener más información sobre setup files, consulte aquí https //docs brightsign biz/user guides/setup desde administración > configuración , haga clic en configuración de red > opciones de red si agrega un certificado root ca, seleccione la pestaña jugador y vaya a la sección certificados si agrega un certificado de cliente, seleccione la pestaña wired o inalámbrico dependiendo del tipo de red, y vaya a la sección seguridad introduzca la información relevante del certificado seleccione hecho y guardar configuración para guardar el setup file guarde el setup file en un dispositivo de almacenamiento (por ejemplo, una tarjeta microsd) instale el dispositivo de almacenamiento en el reproductor desafortunadamente, no hay forma de modificar certificados a través de la red la única forma de modificar el/los certificado(s) es repetir el proceso anterior certificados autofirmados puede haber situaciones en las que se desee que los reproductores utilicen certificados autofirmados (es decir, certificados no emitidos por una ca, sino creados y firmados por el propio usuario) dado que los certificados autofirmados no son ampliamente confiables, normalmente se utilizan solo en entornos de prueba o controlados la aplicación brightsign author se puede utilizar para aplicar certificados autofirmados a los reproductores mediante el uso de un plugin https //github com/brightsign/brightauthor plugins/tree/master/add client certificates brightscript los certificados también se pueden agregar al reproductor mediante el lenguaje de scripting brightscript, aunque esto requiere más habilidades técnicas los usuarios pueden instalar un paquete de certificados sin firmar mediante rokeystore docid\ ghsznw9es8temurqxq du (o keystore docid 6alp0aixrzlhv4cbkebvz ), agregar certificado de cliente docid\ ghsznw9es8temurqxq du o agregar certificado ca docid\ ghsznw9es8temurqxq du antes de acceder al recurso los objetos rokeystore docid\ ghsznw9es8temurqxq du (o keystore docid 6alp0aixrzlhv4cbkebvz ) permiten a los usuarios registrar certificados de cliente con el reproductor en rokeystore, use agregar paquete ca docid\ ghsznw9es8temurqxq du para instalar paquetes persistentes bsca se requiere un archivo bsca si el cliente está usando una url https con un certificado firmado por una raíz no pública o un certificado intermedio para la recuperación, porque no hay forma de agregar el certificado antes de que se acceda a la url de recuperación esto también es cierto cuando se usa un proxy https y ese proxy usa certificados internos/autofirmados las url https que usan certificados en los que el reproductor ya confía son válidas, siempre que el reloj del reproductor esté configurado para que pueda realizarse la selección del certificado para confirmar que el archivo bsca está instalado, revise el registro del sistema para ver el nombre del archivo bsca que aparecerá allí cuando se haya agregado también puede descargar el archivo pem de certificados ca instalados introduciendo su dirección ip en un navegador web ( http //{{ip address}}/ca certificates ) agregue una extensión pem o crt para abrirlo en windows también puede usar una utilidad como openssl https //www openssl org/ para inspeccionarlo limitaciones de certificados sin firmar cuando el certificado no está firmado ni instalado permanentemente, el archivo de certificado deberá estar en la tarjeta microsd, lo que podría tener implicaciones de seguridad cuando se instala un certificado firmado, no puede recuperarse del almacenamiento en una forma utilizable y puede eliminarse de la tarjeta microsd los certificados sin firmar no persisten si un reproductor se reinicia certificados por acceso vs certificados semipermanentes brightsign recomienda que use un certificado por acceso a menos que tenga un cms que requiera https y que no pueda validarse públicamente certificados por acceso esto define un certificado de cliente para un widget http específico se debe ejecutar código específico para cargar el certificado al crear el widget html, por lo que esto debe estar "habilitado" en el sistema de administración de contenido mediante una opción o plugin puede administrar cambios en estos certificados sin intervención de brightsign, pero puede necesitar intervención del cms dependiendo de cómo su sistema maneje los certificados la desventaja de los certificados por acceso es que, debido a que el certificado de cliente se carga en tiempo de ejecución, los procesos tempranos como la recuperación y los procesos que se ejecutan fuera del entorno de ejecución del cliente cms, como la configuración del dispositivo, no pueden usar el certificado de cliente, por lo que debe existir un enlace no https al servidor para la configuración certificados semipermanentes un paquete de certificados bsca puede instalarse de forma semipermanente en un reproductor y se aplicará a toda la funcionalidad del reproductor, por lo que la recuperación y otros procesos funcionarán siempre que el reproductor tenga instalado el paquete bsca las desventajas son brightsign debe firmar el paquete de certificados en un archivo bsca que pueda instalarse en el reproductor si el reproductor requiere múltiples certificados de cliente o cadenas de confianza, todos deben incluirse en el archivo todo bsca por lo tanto, los paquetes bsca deben actualizarse con frecuencia si diferentes conjuntos de servidores tienen distintas fechas de vencimiento de certificados el reproductor debe estar temporalmente desconectado del cms para instalar el archivo bsca y, por lo general, requiere intervención/atención manual de alguien con acceso directo a la red del reproductor el restablecimiento de fábrica elimina los certificados bsca instalados esto puede ser un problema para los sistemas cms que entregan archivos de configuración que realizan un restablecimiento de fábrica y luego vuelven a aplicar la configuración, ya que la configuración reaplicada no incluiría la instalación bsca, lo que podría provocar que el reproductor no pueda contactar al cms y requiera acceso en el sitio o cercano al sitio (en la red) al reproductor otros solo puede agregarse un archivo bsca al reproductor por lo tanto, si envía un archivo bsca diferente, reemplazará al anterior no puede eliminar ningún certificado preinstalado que ya esté en el almacén de claves solo puede eliminar su archivo bsca y los certificados que contiene instalando un nuevo archivo consulte también corregir certificados ca vencidos docid\ lobfc45ngx1zc4rzbrcoq los reproductores deben sincronizarse con un servidor horario para garantizar que la fecha y hora del reproductor sean precisas los clientes que actualicen de cisco ise 3 1 a ise 3 4 o posterior pueden experimentar fallos de autenticación 802 1x eap tls incluso cuando usan los mismos archivos de certificados y la misma configuración del reproductor que anteriormente funcionaban ise 3 4 aplica un orden estricto de cadena de certificados rfc el archivo de certificado del reproductor debe presentar la ca raíz (rca) antes de la ca intermedia (ica) ise 3 1 aceptaba el orden inverso; ise 3 4 no cuando la cadena está invertida, el reproductor envía un error ise 12520 "eap tls failed ssl/tls handshake because the client rejected the ise local certificate"; openssl informa "unknown ca" (tls alert 48) para resolver esto, abra el archivo de certificado del reproductor y reordene la cadena para que la ca raíz aparezca primero, seguida de la ca intermedia vuelva a implementar el archivo actualizado en el reproductor y vuelva a intentar la autenticación