Omnissa Horizon Connection Server
Kopiér link til siden “Omnissa Horizon Connection Server”
Fornyer Connection Servers maskincertifikat via Windows-service-agenten med TLS-kontrol og gendannelse.
Sådan forløber det
- Service-agenten på serveren henter opgaven fra appliancen over udgående HTTPS, port 443.
- Discovery matcher lokale TLS-fingeraftryk med ét certifikat med præcis lowercase friendly name vdm og privat nøgle. Installeret version og services afgrænser broker eller broker_and_blast. Uklar tilstand ændres ikke.
- Windows grundfunktioner importerer først certifikatet i Windows-certifikatlageret (LocalMachine\My). Det gamle certifikat og nøgle bevares. Backup registrerer certifikatnavne, nøglens ACL, valgte services, konti og kørende tilstand efter Windows-baseimport. Agenten kontrollerer den nye nøgle og giver de nødvendige servicekonti læseadgang.
- Den importerede Thumbprint bindes ved at flytte det præcise vdm-navn; certifikatet importeres ikke igen. Agenten overtager denne binding automatisk og genstarter kun de valgte broker/Blast-services.
- Friske TLS-handshakes med SNI skal vise den nye identitet på de valgte endpoints. Fejl forsøger automatisk gendannelse af navne, ACL og service-tilstand; recovery kræver, at den gamle identitet igen serveres. Hvis det fejler: Fremmede ændringer overskrives ikke. Hvis gendannelsen ikke kan bekræftes, rapporteres recovery-fejl med en beskyttet packet og en log uden hemmeligheder.
Tekniske detaljer
- Forbindelse
- Pakken kører gennem service-agenten på serveren. Agenten forbinder over udgående HTTPS til appliancen, port 443 som standard. I åbner ingen port ind til serveren.
- Tjenestens porte
- 443, 8443
- I skal bruge
- Service-agenten installeret på serveren. Service-agenten skal kunne læse og ændre LocalMachine\My, nøglens læserettigheder og de valgte Horizon-services. TLS-kontrollen går direkte til den lokale server med klienternes DNS/SNI-navn på 443 og, når valgt, 8443; en load balancers identitet erstatter ikke denne kontrol. VerifyHostname skal indeholde et klientnavn fra det udstedte certifikat; tomt bruger serverens eget FQDN. Det gamle lokale certifikat bevises mod vdm-lagerets fingeraftryk, også ved selvsignering eller udløb.
- Platform
- Connection Server på en Windows-version understøttet af den installerede Horizon-version; ECDSA fra Server 8.19 (2606)
- Handlinger
- Discovery, Installation, Kontrol, Rollback
- Pakker
-
vmware-horizon-connection-server - Bemærk
-
- Kun maskinidentiteten ændres. vdm.ec, vdm.es, LDAP/VDMDS, Enrollment, Script Host og peers er separate. Erstatning af vdm-bindingen deaktiverer ikke en ekstern writer; ingen dokumenteret pausekontrol er etableret.
- Recovery gendanner den serverede identitet og den ændrede produktkonfiguration. Tilføjede certifikat-, kæde- og truststore-objekter fra en gennemført Windows-baseimport bevares; det er ikke en fuld gendannelse af lageret før import.
- Pakken vmware-horizon-connection-server 1.0.0 kræver signering og installation gennem sslbrains katalog før brug.
Krav til certifikatet
Agentens accepted_key_types er RSA 2048/3072/4096 bit og ECDSA P-256/P-384. ECDSA kræver opdaget Server 8.19 (2606) eller nyere; ældre/ukendt version bruger RSA. CSR-guidens sædvanlige RSA-størrelser er ikke en eksklusiv liste eller et producentmaksimum. RSA minimum for denne offentlige profil er 2048; producentens generelle maksimum og præcise ECC-kurvegrænser er ikke angivet.
Navnene skal dække klienternes FQDN og relevante load balancer-navne. CN findes i producentens CSR-eksempel; det beviser ikke, at CN er obligatorisk. SAN-only-profiler uden CN, som Let’s Encrypt tlsserver og Google minimal, har ingen udtrykkelig acceptregel i de kontrollerede producentkilder.
Maskinens offentligt betroede TLS-certifikat skal bruges til serverAuth. 2606-guiden siger, at det ikke må indeholde clientAuth, og advarer om browsertillid efter 15. marts 2026. Et keyEncipherment-KU i et CSR-eksempel beviser ikke et generelt krav; et ekstra keyEncipherment-krav er ikke angivet i de kontrollerede kilder. Cluster-clientAuth er et separat formål.
Wildcard på ét DNS-niveau er dokumenteret. Producenten anbefaler FQDN frem for IP-adresser og simple navne; anbefalingen er ikke bevis for strukturel afvisning af IP-SAN. Accept af IP-SAN og maksimum antal SAN er ikke angivet. Ukendt betyder ikke ubegrænset.
Windows-baseimport leverer PFX/PKCS#12 med matchende privat nøgle og eksportbar maskinnøgle til LocalMachine\My. Produktagenten modtager kun samme kørsels Thumbprint. Horizon Console kan bruge PEM/PFX, men dens grænser er ikke automatisk Windows-lagerets grænser. DER uden nøgle er utilstrækkeligt; JKS er ikke et direkte vdm-bindingsformat.
De kontrollerede Horizon-kilder angiver ikke accept af PFX-ciphers AES, 3DES eller RC2. Brug Windows-baseimportens eksisterende OS/versionstilpassede forberedelse; et gammelt eksempel er ikke bevis for AES-afvisning.
Mellemcertifikater skal være i Intermediate Certification Authorities og rod i Trusted Root Certification Authorities. Windows-baseimport importerer ikke nye rod-trustankre: send PFX uden rod, eller tilføj den nødvendige rod separat før kørslen. Kæden leveres fra nærmeste udsteder opad; separate Windows-lagre er ikke én PEM-kædefil. Additive importobjekter bevares ved produkt-recovery.
Friendly name skal være unikt og præcis lowercase vdm i LocalMachine\My. vdm.ec og vdm.es er separate certifikater og ændres ikke. Den gamle identitet beholder sin nøgle og registrerede navne til recovery.
Certifikatet skal være gyldigt på aktiveringstidspunktet. Producentens minimum/maksimum for udstedte certifikaters levetid er ikke angivet; Horizons seks måneders standardcertifikat er ikke en grænse for CA-certifikater. Recovery skal også kunne gendanne en kendt tidligere udløbet identitet.