Skip to content
Docs sslbrain sslbrain.com

Omnissa Unified Access Gateway

Copy link to the page “Omnissa Unified Access Gateway”

← All integrations

Identity and remote access · Storage and virtualisation

Renews the certificate on the selected UAG interface and checks the served TLS identity.

The appliance runs the package and connects to Omnissa Unified Access Gateway through UAG REST API over HTTPS on port 9443. No agent is installed on Omnissa Unified Access Gateway.

What happens

  1. The appliance connects to Omnissa Unified Access Gateway through UAG REST API on port 9443.
  2. Discovery matches the actually served SHA-256 fingerprint to API storage for end_user or admin. The customer selects one interface; ambiguous identity is left unchanged.
  3. Before import, the old certificate and matching key are saved in a protected local backup. If the API export contains only the public chain, a matching previous agent record or protected recovery material is used. When export is unavailable, create owner-protected JSON with certChainPem and privateKeyPem on the executor and point PREVIOUS_MATERIAL_FILE to it; material is checked against the served certificate. If it fails: Without matching recovery material the interface is left unchanged. A public chain alone cannot restore the old key.
  4. The agent takes over the selected certificate destination through UAG PEM/PFX import without another opt-in. UAG activates the certificate; the agent reconnects after a lost response without a global restart.
  5. API identity and the certificate actually served are checked over TLS with SNI. Activation failure triggers automatic recovery and a check of the old served fingerprint. When SERVE_NAME is selected, the new certificate must cover that name before import; checks without a selected client name report that separately. If it fails: If management serves an unknown third identity, no credentials are sent to it. Recovery is reported as complete only after confirming the old TLS identity; otherwise the recovery packet is retained for local recovery.

Technical details

Connection
The package runs on the appliance, which connects over HTTPS to UAG REST API, port 9443. No agent is installed.
Service ports
9443
You need
A UAG administrator with API permission to read and import certificates. The appliance must reach management HTTPS on 9443 and the selected TLS interface with the correct SNI name. Management uses system trust, a private CA or a SHA-256 certificate pin; credentials use protected inputs.
Platform
VMware/Omnissa Unified Access Gateway; ECC from 2606
Actions
Discovery, Installation, Verification, Rollback
Packages
vmware-uag-api
Note
  • Only the selected interface changes. Other interfaces and competing configuration are preserved. Import does not prove that an external certificate writer is disabled; no documented pause control is established for these UAG endpoints.
  • The admin certificate can participate in SAML signing. Discovery reports concrete coupling; IdP trust must be coordinated separately. The agent does not change the IdP, load balancer or other UAG nodes.
  • An interrupted executor job can leave a lock in CERTOPS_BACKUP_DIR. Confirm locally that no deploy or rollback is still running for the interface before removing its empty lock-<SHA-256> directory. Preserve state.json and earlier recovery material; a lock is never automatically reclaimed as stale.
  • Package vmware-uag-api 1.0.0 requires signing and installation through the sslbrain catalogue before use.

Certificate requirements

The agent’s accepted_key_types are RSA 2048/3072/4096 bits and ECDSA P-256/P-384. ECC TLS identities are added in UAG 2606; older versions use RSA, while an unknown version is reported with observed destination acceptance. Manufacturer-wide RSA minimum/maximum and exact ECC curve sizes are not stated in the checked sources. The FedRAMP RSA 2048+ requirement applies to that mode, not all UAG installations.

Names must cover client FQDNs and relevant load balancer names. CN appears in the manufacturer’s CSR example; that does not prove CN is mandatory. SAN-only profiles without CN, such as Let’s Encrypt tlsserver and Google minimal, have no explicit acceptance rule in the checked manufacturer sources.

UAG’s publicly trusted TLS server certificate uses serverAuth. The 2606 guide says it must not include clientAuth and warns about browser trust after 15 March 2026. An additional keyEncipherment KU requirement is not stated in the checked UAG sources.

A single-level DNS wildcard is documented. The manufacturer recommends FQDNs over IP addresses and simple names; the recommendation does not prove structural rejection of IP SANs. IP SAN acceptance and maximum SAN count are not stated. Unknown does not mean unlimited.

API import uses a PEM chain with a matching private key or base64 PFX/PKCS#12. DER/JKS are not documented direct API formats. PFX encryption acceptance for AES, 3DES and RC2 is not stated; a legacy example is not an AES prohibition. Local PFX checks require OpenSSL or PowerShell PKCS#12 support.

PEM chain order is server certificate first, then intermediates toward the root, and the root if supplied. The API’s full-chain wording does not make an absent root an extra mandatory field. The key must match the server certificate.

A PFX alias selects the identity when a keystore has multiple certificates and is optional for one certificate. Manufacturer maximum length and character rules are not stated. Windows friendly name vdm does not select a UAG interface.

The certificate must be valid at activation. UAG sources do not state minimum/maximum lifetimes for issued certificates. Recovery can restore a known previously expired identity.

Get started