Omnissa Horizon Connection Server
Kopiera länk till sidan “Omnissa Horizon Connection Server”
Förnyar Connection Servers maskincertifikat via Windows service-agent med TLS-kontroll och återställning.
Så går det till
- Serviceagenten på servern hämtar uppgiften från appliancen över utgående HTTPS, port 443.
- Discovery matchar lokala TLS-fingeravtryck med ett certifikat med exakt friendly name vdm i gemener och privat nyckel. Installerad version och tjänster avgränsar broker eller broker_and_blast. Oklart tillstånd ändras inte.
- Windows grundfunktioner importerar först certifikatet i Windows certifikatarkiv (LocalMachine\My). Det gamla certifikatet och nyckeln behålls. Backup registrerar certifikatnamn, nyckelns ACL, valda tjänster, konton och körande tillstånd efter Windows-basimport. Agenten kontrollerar den nya nyckeln och ger nödvändiga tjänstkonton läsåtkomst.
- Importerad Thumbprint binds genom att flytta det exakta vdm-namnet; certifikatet importeras inte igen. Agenten tar över denna bindning automatiskt och startar bara om valda broker/Blast-tjänster.
- Nya TLS-handshakes med SNI måste visa den nya identiteten på valda endpoints. Fel utlöser automatisk återställning av namn, ACL och tjänsttillstånd; återställning kräver att den gamla identiteten serveras igen. Om det misslyckas: Andras ändringar skrivs inte över. Om återställningen inte kan bekräftas rapporteras återställningsfel med ett skyddat paket och en logg utan hemligheter.
Tekniska detaljer
- Anslutning
- Paketet körs genom serviceagenten på servern. Agenten ansluter över utgående HTTPS till appliancen, port 443 som standard. Ni öppnar ingen port in till servern.
- Tjänstens portar
- 443, 8443
- Ni behöver
- Serviceagenten installerad på servern. Service-agenten måste kunna läsa och ändra LocalMachine\My, nyckelns läsbehörigheter och valda Horizon-tjänster. TLS-kontrollen går direkt till den lokala servern med klienternas DNS/SNI-namn på 443 och, när valt, 8443; en lastbalanserares identitet ersätter inte denna kontroll. VerifyHostname måste innehålla ett klientnamn från det utfärdade certifikatet; tomt använder serverns eget FQDN. Det gamla lokala certifikatet bevisas mot vdm-arkivets fingeravtryck, även vid självsignering eller utgång.
- Plattform
- Connection Server på en Windows-version som stöds av installerad Horizon-version; ECDSA från Server 8.19 (2606)
- Åtgärder
- Discovery, Installation, Kontroll, Rollback
- Paket
-
vmware-horizon-connection-server - Observera
-
- Bara maskinidentiteten ändras. vdm.ec, vdm.es, LDAP/VDMDS, Enrollment, Script Host och peers är separata. Byte av vdm-bindningen stänger inte av en extern skrivare; ingen dokumenterad pauskontroll är etablerad.
- Återställning återställer den serverade identiteten och ändrad produktkonfiguration. Tillagda certifikat-, kedje- och truststore-objekt från genomförd Windows-basimport behålls; detta är inte en full återställning av arkivet före import.
- Paketet vmware-horizon-connection-server 1.0.0 kräver signering och installation genom sslbrains katalog före användning.
Krav på certifikatet
Agentens accepted_key_types är RSA 2048/3072/4096 bitar och ECDSA P-256/P-384. ECDSA kräver upptäckt Server 8.19 (2606) eller senare; äldre/okänd version använder RSA. CSR-guidens vanliga RSA-storlekar är inte en exklusiv lista eller ett tillverkarmaximum. RSA-minimum för denna offentliga profil är 2048; tillverkarens generella maximum och exakta ECC-kurvgränser anges inte.
Namnen måste täcka klienternas FQDN och relevanta lastbalanserarnamn. CN finns i tillverkarens CSR-exempel; det bevisar inte att CN är obligatoriskt. SAN-only-profiler utan CN, som Let’s Encrypt tlsserver och Google minimal, har ingen uttrycklig acceptregel i kontrollerade tillverkarkällor.
Maskinens offentligt betrodda TLS-certifikat används för serverAuth. 2606-guiden säger att det inte får innehålla clientAuth och varnar för webbläsartillit efter 15 mars 2026. keyEncipherment-KU i ett CSR-exempel bevisar inte ett generellt krav; ytterligare keyEncipherment-krav anges inte i kontrollerade källor. Cluster-clientAuth är ett separat ändamål.
Wildcard på en DNS-nivå är dokumenterat. Tillverkaren rekommenderar FQDN framför IP-adresser och enkla namn; rekommendationen bevisar inte strukturell avvisning av IP-SAN. Acceptans av IP-SAN och maximalt antal SAN anges inte. Okänt betyder inte obegränsat.
Windows-basimport levererar PFX/PKCS#12 med matchande privat nyckel och exporterbar maskinnyckel till LocalMachine\My. Produktagenten tar bara emot samma körnings Thumbprint. Horizon Console kan använda PEM/PFX, men dess gränser är inte automatiskt Windows-arkivets gränser. DER utan nyckel räcker inte; JKS är inget direkt vdm-bindningsformat.
Kontrollerade Horizon-källor anger inte acceptans av PFX-ciphers AES, 3DES eller RC2. Använd Windows-basimportens befintliga OS/versionsanpassade förberedelse; ett gammalt exempel bevisar inte AES-avvisning.
Mellanliggande certifikat ska finnas i Intermediate Certification Authorities och rot i Trusted Root Certification Authorities. Windows-basimport importerar inte nya rot-trustankare: skicka PFX utan rot, eller lägg till nödvändig rot separat före körningen. Kedjan levereras från närmaste utfärdare uppåt; separata Windows-arkiv är inte en PEM-kedjefil. Additiva importobjekt behålls vid produktåterställning.
Friendly name måste vara unikt och exakt vdm i gemener i LocalMachine\My. vdm.ec och vdm.es är separata certifikat och ändras inte. Den gamla identiteten behåller sin nyckel och registrerade namn för återställning.
Certifikatet måste vara giltigt vid aktivering. Tillverkarens minimum/maximum för utfärdade certifikats livslängd anges inte; Horizons standardcertifikat på sex månader är inte en gräns för CA-certifikat. Återställning måste även kunna återställa en känd tidigare utgången identitet.