Hoppa till innehåll
Dokumentation sslbrain sslbrain.com

Omnissa Unified Access Gateway

Kopiera länk till sidan “Omnissa Unified Access Gateway”

← Alla integrationer

Identitet och fjärråtkomst · Lagring och virtualisering

Förnyar certifikatet på valt UAG-gränssnitt och kontrollerar den serverade TLS-identiteten.

Appliancen kör paketet och ansluter till Omnissa Unified Access Gateway genom UAG REST API över HTTPS på port 9443. Ingen agent installeras på Omnissa Unified Access Gateway.

Så går det till

  1. Appliancen ansluter till Omnissa Unified Access Gateway genom UAG REST API på port 9443.
  2. Discovery matchar det faktiskt serverade SHA-256-fingeravtrycket med API-arkivet för end_user eller admin. Kunden väljer ett gränssnitt; oklar identitet ändras inte.
  3. Före import sparas det gamla certifikatet och matchande nyckel i en skyddad lokal backup. Om API-exporten bara innehåller offentlig kedja används en matchande tidigare agentpost eller skyddat återställningsmaterial. När export saknas skapas en ägarskyddad JSON med certChainPem och privateKeyPem på executorn, och PREVIOUS_MATERIAL_FILE pekar på filen; materialet kontrolleras mot det serverade certifikatet. Om det misslyckas: Utan matchande återställningsmaterial ändras inte gränssnittet. En offentlig kedja ensam kan inte återställa den gamla nyckeln.
  4. Agenten tar över valt certifikats destination genom UAG:s PEM/PFX-import utan ytterligare tillval. UAG aktiverar certifikatet; agenten återansluter vid förlorat svar utan global omstart.
  5. API-identiteten och certifikatet som faktiskt serveras kontrolleras över TLS med SNI. Vid aktiveringsfel försöks automatisk återställning, och det gamla serverade fingeravtrycket kontrolleras. När SERVE_NAME är valt måste det nya certifikatet täcka namnet före import; kontroll utan valt klientnamn rapporterar detta separat. Om det misslyckas: Om management visar en okänd tredje identitet skickas inga credentials till den. Återställning anges som genomförd först efter bekräftad gammal TLS-identitet; annars behålls återställningspaketet för lokal återställning.

Tekniska detaljer

Anslutning
Paketet körs på appliancen, som ansluter över HTTPS till UAG REST API, port 9443. Ingen agent installeras.
Tjänstens portar
9443
Ni behöver
UAG-administratör med API-behörighet för läsning och import av certifikatet. Appliancen måste nå management-HTTPS på 9443 och valt TLS-gränssnitt med rätt SNI-namn. Management använder systemtillit, privat CA eller SHA-256-certifikatpin; credentials levereras skyddat.
Plattform
VMware/Omnissa Unified Access Gateway; ECC från 2606
Åtgärder
Discovery, Installation, Kontroll, Rollback
Paket
vmware-uag-api
Observera
  • Bara valt gränssnitt ändras. Andra gränssnitt och konkurrerande konfiguration behålls. Import bevisar inte att en extern certifikatskrivare är avstängd; ingen dokumenterad pauskontroll är etablerad för dessa UAG-endpoints.
  • Admin-certifikatet kan användas för SAML-signering. Discovery visar konkret koppling; IdP-tillit måste samordnas separat. Agenten ändrar inte IdP, lastbalanserare eller andra UAG-noder.
  • Ett avbrutet executor-jobb kan lämna ett lås i CERTOPS_BACKUP_DIR. Bekräfta lokalt att ingen installation eller rollback längre kör för gränssnittet innan den tomma lock-<SHA-256>-mappen tas bort. Behåll state.json och tidigare återställningsmaterial; ett lås tas aldrig automatiskt bort som gammalt.
  • Paketet vmware-uag-api 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. ECC TLS-identiteter tillkommer i UAG 2606; äldre versioner använder RSA, och okänd version rapporteras med destinationens observerade acceptans. Tillverkarens generella RSA-minimum/maximum och exakta ECC-kurvstorlekar anges inte i kontrollerade källor. FedRAMPs krav på RSA 2048+ gäller det läget, inte alla UAG-installationer.

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.

UAG:s offentligt betrodda TLS-servercertifikat använder serverAuth. 2606-guiden säger att det inte får innehålla clientAuth och varnar för webbläsartillit efter 15 mars 2026. Ytterligare keyEncipherment-KU-krav anges inte i kontrollerade UAG-källor.

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.

API-importen använder PEM-kedja med matchande privat nyckel eller base64-PFX/PKCS#12. DER/JKS är inte dokumenterade direkta API-format. PFX-krypteringsacceptans för AES, 3DES och RC2 anges inte; ett legacy-exempel är inget AES-förbud. Agentens lokala PFX-kontroll kräver OpenSSL eller PowerShells PKCS#12-stöd.

PEM-kedjan ordnas servercertifikat först, sedan mellanliggande certifikat mot roten, och rot om den ingår. API-textens fullständiga kedja gör inte en saknad rot till ett extra obligatoriskt fält. Nyckeln måste matcha servercertifikatet.

PFX-alias krävs för val när keystoren innehåller flera certifikat och är valfritt vid ett certifikat. Tillverkarens maximala längd och teckenregler anges inte. Windows friendly name vdm används inte för val av UAG-gränssnitt.

Certifikatet måste vara giltigt vid aktivering. UAG-källorna anger inte en minimum/maximum-livslängd för utfärdade certifikat. Återställning kan återställa en känd tidigare utgången identitet.

Kom igång