Omnissa Unified Access Gateway
Kopiér link til siden “Omnissa Unified Access Gateway”
Fornyer certifikatet på det valgte UAG-interface og kontrollerer den serverede TLS-identitet.
Sådan forløber det
- Appliancen forbinder til Omnissa Unified Access Gateway gennem UAG REST API på port 9443.
- Discovery matcher det faktisk serverede SHA-256-fingeraftryk med API-lageret for end_user eller admin. Kunden vælger ét interface; uklar identitet ændres ikke.
- Før import gemmes det gamle certifikat og den matchende nøgle i en beskyttet lokal backup. Hvis API-eksporten kun indeholder offentlig kæde, bruges et matchende tidligere agentrecord eller beskyttet recovery-materiale. Ved manglende eksport oprettes en ejerbeskyttet JSON med certChainPem og privateKeyPem på executoren, og PREVIOUS_MATERIAL_FILE peger på filen; materialet kontrolleres mod det serverede certifikat. Hvis det fejler: Uden matchende recovery-materiale ændres interfacet ikke. En offentlig kæde alene kan ikke gendanne den gamle nøgle.
- Agenten overtager det valgte certifikats destination gennem UAGs PEM/PFX-import uden ekstra tilvalg. UAG aktiverer certifikatet; agenten genforbinder ved tabt svar uden global genstart.
- API-identiteten og det faktisk serverede certifikat kontrolleres over TLS med SNI. Ved aktiveringsfejl forsøges automatisk gendannelse, og det gamle serverede fingeraftryk kontrolleres. Når SERVE_NAME er valgt, skal det nye certifikat dække navnet før import; kontrol uden valgt klientnavn rapporterer dette særskilt. Hvis det fejler: Hvis management viser en ukendt tredje identitet, sendes ingen credentials til den. Recovery markeres kun som gennemført efter bekræftet gammel TLS-identitet; ellers bevares recovery-pakken til lokal gendannelse.
Tekniske detaljer
- Forbindelse
- Pakken kører på appliancen, som forbinder over HTTPS til UAG REST API, port 9443. Der installeres ingen agent.
- Tjenestens porte
- 9443
- I skal bruge
- UAG-administrator med API-rettigheder til certifikatets læsning og import. Appliancen skal nå management-HTTPS på 9443 og det valgte TLS-interface med korrekt SNI-navn. Management bruger systemtillid, privat CA eller SHA-256-certifikatpin; credentials leveres beskyttet.
- Platform
- VMware/Omnissa Unified Access Gateway; ECC fra 2606
- Handlinger
- Discovery, Installation, Kontrol, Rollback
- Pakker
-
vmware-uag-api - Bemærk
-
- Kun det valgte interface ændres. Andre interfaces og konkurrerende konfiguration bevares. Import er ikke dokumentation for, at en ekstern certifikatskriver er deaktiveret; ingen dokumenteret pausekontrol er etableret for disse UAG-endpoints.
- Admin-certifikatet kan indgå i SAML-signering. Discovery viser konkret kobling; IdP-tillid skal koordineres separat. Agenten ændrer ikke IdP, load balancer eller andre UAG-noder.
- Et afbrudt executor-job kan efterlade en lås i CERTOPS_BACKUP_DIR. Bekræft lokalt, at ingen installation eller rollback længere kører for interfacet, før den tomme lock-<SHA-256>-mappe fjernes. Bevar state.json og tidligere recovery-materiale; en lås fjernes aldrig automatisk som forældet.
- Pakken vmware-uag-api 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. ECC TLS-identiteter tilføjes i UAG 2606; ældre versioner bruger RSA, og ukendt version rapporteres med destinationens observerede accept. Producentens generelle RSA-minimum/maksimum og præcise ECC-kurvestørrelser er ikke angivet i de kontrollerede kilder. FedRAMPs RSA 2048+-krav gælder den tilstand, ikke alle UAG-installationer.
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.
UAGs offentligt betroede TLS-servercertifikat bruger serverAuth. 2606-guiden siger, at det ikke må indeholde clientAuth, og advarer om browsertillid efter 15. marts 2026. Et ekstra keyEncipherment-KU-krav er ikke angivet i de kontrollerede UAG-kilder.
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.
API-importen bruger PEM-kæde med matchende privat nøgle eller base64-PFX/PKCS#12. DER/JKS er ikke dokumenterede direkte API-formater. PFX-krypteringsaccept for AES, 3DES og RC2 er ikke angivet; et legacy-eksempel er ikke et AES-forbud. Agentens lokale PFX-kontrol kræver OpenSSL eller PowerShells PKCS#12-støtte.
PEM-kæden skal stå servercertifikat først, derefter mellemcertifikater op mod roden, og rod hvis den medfølger. API-tekstens fulde kæde gør ikke en manglende rod til et ekstra obligatorisk felt. Nøglen skal matche servercertifikatet.
PFX-alias kræves til valg, når keystoren indeholder flere certifikater, og er valgfrit ved ét certifikat. Producentens maksimumlængde og tegnregler er ikke angivet. Windows friendly name vdm bruges ikke til valg af UAG-interface.
Certifikatet skal være gyldigt på aktiveringstidspunktet. UAG-kilderne angiver ikke en minimum/maksimum-levetid for udstedte certifikater. Recovery kan gendanne en kendt tidligere udløbet identitet.