De forma predeterminada, el instalador de Horizon Agent for Linux genera un certificado autofirmado para el daemon de BlastServer, que controla las comunicaciones con los clientes mediante el protocolo de visualización Blast. Para cumplir con las normativas de seguridad o del sector, puede reemplazar el certificado autofirmado para BlastServer con un certificado firmado por una entidad de certificación (CA).
-
Cuando Blast Security Gateway no está habilitado en Horizon Connection Server, BlastServer presenta este certificado autofirmado predeterminado al navegador que utiliza Horizon Web Client para conectarse con el escritorio Linux. Nota: Horizon Web Client está disponible con Horizon 8 versión 2412 y posteriores. En Horizon 8 versión 2406 y anteriores, Horizon Web Client se llama "HTML Access". En esta página se utiliza el nombre "Horizon Web Client" para hacer referencia a Horizon Web Client y HTML Access.
-
Cuando Blast Security Gateway está habilitado en Horizon Connection Server, Blast Security Gateway presenta el certificado al navegador.
Para reemplazar el certificado autofirmado predeterminado para el daemon de BlastServer por un certificado firmado por una CA, puede usar uno de los siguientes métodos.
- Almacén de claves BCFKS: con este método, se utiliza el script de implementación
DeployBlastCert.shpara almacenar el certificado y la clave privada en un almacén de claves cifrado Bouncy Castle FIPS (BCFKS) en el directorio/etc/omnissa/ssl. - Almacenamiento sin cifrar: con este método, se copia manualmente el certificado y la clave privada sin cifrado en el nivel raíz del directorio
/etc/omnissa/ssl.
El daemon de BlastServer primero busca en el keyring de Linux el certificado y la clave privada de un almacén de claves BCFKS. Si no encuentra un almacén de claves BCFKS, leerá el certificado y la clave privada que hay en el nivel raíz del directorio /etc/omnissa/ssl.
Implementar el certificado de la entidad de certificación BlastServer en un almacén de claves BCFKS
El script de implementación de DeployBlastCert.sh crea un nuevo almacén de claves BCFKS denominado hznblast.bcfks en el directorio /etc/omnissa/ssl y almacena el certificado y la clave privada en este almacén de claves. A continuación, la información del almacén de claves se agrega al keyring de Linux.
-
Utilice las opciones de configuración SSLCertName y SSLKeyName para personalizar el nombre del certificado y el nombre de la clave privada, respectivamente, tal como aparecen en el keyring de Linux. Si desea obtener más información, consulte la Tabla 2 Editar archivos de configuración en un escritorio Linux.
-
Ejecute el script de implementación de
DeployBlastCert.shcomo se muestra en el siguiente ejemplo.sudo /usr/lib/omnissa/viewagent/bin/DeployBlastCert.sh -c /root/rui.cert -k /root/rui.keyUtilice las siguientes marcas de parámetros para el script de implementación:
Marca de parámetro Descripción -c Especifica el archivo de certificado firmado por la entidad de certificación. -k Especifica el archivo de clave privada.
Implementar el certificado de la entidad de certificación BlastServer en un almacenamiento sin cifrar
-
Agregue la clave privada y el certificado firmado por una CA a
/etc/omnissa/ssl.-
Cambie el nombre de la clave privada a rui.key y el del certificado a rui.crt.
-
Establezca permisos de lectura y ejecutables en
/etc/omnissa/ssl.sudo chmod 550 /etc/omnissa/ssl -
Copie rui.key y rui.crt en
/etc/omnissa/ssl. -
Elimine los permisos de ejecutables en
/etc/omnissa/ssl.sudo chmod 440 /etc/omnissa/ssl
-
-
Instale los certificados de la entidad de certificación raíz e intermedia en el almacén de entidades de certificación del SO Linux.
Para obtener información sobre otros ajustes del sistema que se deben cambiar para admitir la cadena de certificados de CA, consulte la documentación de su distribución Linux.
¿Le resultó útil esta página?