Standardmäßig generiert das installationsprogramm für Horizon Agent for Linux ein selbstsigniertes Zertifikat für den BlastServer-Daemon, der die Kommunikation mit Clients mithilfe des Blast-Anzeigeprotokolls verarbeitet. Um die Einhaltung von Branchen- oder Sicherheitsbestimmungen sicherzustellen, können Sie das selbstsignierte Zertifikat für BlastServer durch ein von einer Zertifizierungsstelle (CA, Certificate Authority) signiertes Zertifikat ersetzen.
-
Wenn das Blast Security Gateway auf dem Horizon Connection Server nicht aktiviert ist, übergibt BlastServer das standardmäßige selbstsignierte Zertifikat an den Browser, der mithilfe von Horizon Web Client eine Verbindung mit dem Linux-Desktop herstellt. Hinweis: Horizon Web Client ist mit den Horizon 8-Versionen 2412 und höher verfügbar. Bei den Horizon 8-Versionen 2406 und früher trägt Horizon Web Client die Bezeichnung „HTML Access“. Auf dieser Seite wird der Name „Horizon Web Client“ verwendet, um sowohl auf Horizon Web Client als auch auf HTML Access zu verweisen.
-
Wenn das Blast Security Gateway auf dem Horizon Connection Server aktiviert ist, übergibt das Blast Secure Gateway das Zertifikat an den Browser.
Um das standardmäßige selbstsignierte Zertifikat für BlastServer durch ein von einer Zertifizierungsstelle signiertes Zertifikat zu ersetzen, können Sie eine der folgenden Methoden verwenden.
- BCFKS-Keystore: Bei dieser Methode verwenden Sie das
DeployBlastCert.sh-Bereitstellungsskript, um das Zertifikat und den privaten Schlüssel in einem verschlüsselten Bouncy Castle FIPS-Keystore (BCFKS) im Verzeichnis/etc/omnissa/sslzu speichern. - Unverschlüsselter Speicher: Bei dieser Methode kopieren Sie das Zertifikat und den privaten Schlüssel manuell und unverschlüsselt in die Stammebene des Verzeichnisses
/etc/omnissa/ssl.
Der BlastServer-Daemon sucht zunächst im Linux-Schlüsselbund nach dem Zertifikat und dem privaten Schlüssel aus einem BCFKS-Keystore. Wenn er keinen BCFKS-Keystore findet, liest er das Zertifikat und den privaten Schlüssel, die auf der Stammebene von /etc/omnissa/ssl gespeichert sind.
Bereitstellen des BlastServer-CA-Zertifikats in einem BCFKS-Keystore
Das DeployBlastCert.sh-Bereitstellungsskript erstellt einen neuen BCFKS-Keystore namens hznblast.bcfks im Verzeichnis /etc/omnissa/ssl und speichert das Zertifikat und den privaten Schlüssel in diesem Keystore. Die Informationen im Keystore werden dann dem Linux-Schlüsselbund hinzugefügt.
-
Verwenden Sie die Konfigurationsoptionen SSLCertName und SSLKeyName, um den Namen des Zertifikats bzw. den Namen des privaten Schlüssels, wie er im Linux-Schlüsselbund angezeigt wird, anzupassen. Weitere Informationen finden Sie in der Tabelle 2 unter Bearbeiten von Konfigurationsdateien auf einem Linux-Desktop.
-
Führen Sie das
DeployBlastCert.sh-Bereitstellungsskript aus, wie im folgenden Beispiel gezeigt.sudo /usr/lib/omnissa/viewagent/bin/DeployBlastCert.sh -c /root/rui.cert -k /root/rui.keyVerwenden Sie die folgenden Parameter-Flags für das Bereitstellungsskript:
Parameter-Flag Beschreibung -c Gibt die von einer Zertifizierungsstelle (CA) signierte Zertifikatsdatei an. -k Gibt die Datei des privaten Schlüssels an.
Bereitstellen des BlastServer-CA-Zertifikats auf unverschlüsseltem Speicher
-
Fügen Sie den privaten Schlüssel und das von der Zertifizierungsstelle signierte Zertifikat zu
/etc/omnissa/sslhinzu.-
Benennen Sie den privaten Schlüssel in rui.key und das Zertifikat in rui.crt um.
-
Legen Sie Lese- und Ausführungsberechtigungen für
/etc/omnissa/sslfest.sudo chmod 550 /etc/omnissa/ssl -
Kopieren Sie rui.key und rui.crt in
/etc/omnissa/ssl. -
Entfernen Sie Ausführungsberechtigungen für
/etc/omnissa/ssl.sudo chmod 440 /etc/omnissa/ssl
-
-
Speichern Sie das Root- und das CA-Zwischenzertifikat unter den Zertifizierungsstellen für Linux OS.
Informationen zu weiteren Systemeinstellungen, die zur Unterstützung der Zertifikatskette der Zertifizierungsstelle geändert werden müssen, finden Sie in der Dokumentation für Ihre Linux-Distribution.
War diese Seite hilfreich?