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. 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 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í.
- 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.
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 (o keystore), Agregar certificado de cliente o Agregar certificado CA antes de acceder al recurso.
- Los objetos roKeyStore (o keystore) permiten a los usuarios registrar certificados de cliente con el reproductor. En roKeystore, use Agregar paquete CA 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 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 vencidosFix Expired CA Certificates.
- 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.