ZPA Browser Access, End to End — Certificates, Domains & the Clientless Path

Picture a video-KYC with your bank. You finish the whole thing inside your phone's browser — the bank installs nothing on your device, never lets you walk into the branch back-office, and you only ever see your account screen. That is exactly what Browser Access does for an internal web app: a contractor on an unmanaged laptop reaches one private app from a plain browser, sees only that app, and never touches your network.

It sounds like “ZPA minus the agent”. It isn't. Browser Access is a reverse proxy: the browser does a real TLS handshake against a certificate you supply, reached through a public DNS name you publish. Get the certificate or the DNS wrong and the app is dead before any access policy is ever evaluated. That is why, for years, the No.1 Browser Access support ticket was never the policy — it was the certificate.

① How a browser with no agent reaches a private app

Start with the journey, because every later decision hangs off it. The user's browser talks to the Zscaler cloud, never to your network. Think of the App Connector as a concierge: you hand your request at the front desk, the concierge fetches the file from a back room you are never allowed to enter, and brings it to you at reception.

🏛 Architect note. Between the broker and the App Connector the session rides a Microtunnel inside a TLS tunnel to the Zero Trust Exchange. An optional double_encrypt flag adds a second encryption layer across the ZPA fabric — but it is mutually exclusive with Browser Access on the same segment (more on that in §4).

The words you need first

Four ideas carry the whole lesson. Tap each card.

② The application domain and the public CNAME

Here is the part people skip and then spend an afternoon debugging. The browser resolves the Browser Access URL over the public internet — it has no tunnel and no agent to hand it an internal answer. So every BA app needs a publicly-resolvable name, and you must point that name at Zscaler yourself.

When you save a BA app, ZPA generates a Canonical Name (CNAME). You copy it and create a public DNS CNAME record: your external FQDN (e.g. apps.acme-ext.com) → that Zscaler host. That record is what makes the URL resolve for the user on the open internet.

dig +short apps.acme-ext.com CNAME
dig +short apps.acme-ext.com

bba-12ab34.private.zscaler.com.
bba-12ab34.private.zscaler.com.
165.225.xx.xx

If the first line is empty, the CNAME was never published — that is an NXDOMAIN for every external user, no matter how perfect the policy is. On the App Connector side it is the opposite mistake: the Connector must use internal DNS that resolves wiki.corp.local to its real private IP. Point it at public DNS and the internal name resolves back to the Zscaler address — a loop.

③ The certificate — the No.1 Browser Access support ticket

At TLS leg 1 the browser validates a certificate, and there is no Zscaler client on the device to quietly trust anything. So the cert ZPA presents must chain to a CA the browser already trusts. Three knobs decide whether it works.

1. Public CA vs internal CA

You can upload a cert signed by a public CA, or a self-signed / internal-CA cert. For unmanaged and BYOD users the internal root simply isn't on their device, so the real-world rule is: use a publicly-trusted certificate unless every device that will ever use the app has your private root pre-installed.

2. The full chain, not just the leaf

Upload the leaf + all intermediates. The classic “works for some users, not others” bug is a missing intermediate: managed laptops got the root via GPO and paper over it; BYOD machines don't, so they fail. The error is the same on both — NET::ERR_CERT_AUTHORITY_INVALID.

3. Wildcard vs SAN

A wildcard *.acme.com covers apps.acme.com but not apps.eu.acme.com — wildcards match one level only. For multi-level or specific hostnames, use a SAN certificate.

Two more cert gotchas worth memorising. First, generate the CSR inside the ZPA portal (Administration → Certificates). ZPA only holds the private key for CSRs it generated; bring an externally-minted cert and the upload fails with “A matching CSR was not found or a private key was not present.”

Second — and this is the big 2025 change — turn on Zscaler-Managed Certificates. Announced June 2025, it auto-generates and auto-renews the BA cert and auto-publishes the public CNAME. That single switch removes most of the war stories in this section — expired certs, missing intermediates, and forgotten DNS records all disappear.

echo | openssl s_client -connect apps.acme-ext.com:443 -servername apps.acme-ext.com -showcerts 2>/dev/null \
  | openssl x509 -noout -subject -issuer

subject=CN = apps.acme-ext.com
issuer=C = US, O = DigiCert Inc, CN = DigiCert Global G2 TLS RSA SHA256 2020 CA1

④ Build the app — then survive the five failures

The build is short once the cert and DNS are sorted. Five steps:

1. Certificate — pick Zscaler-Managed, or generate a CSR in Administration → Certificates, get it signed, upload the full chain.
2. Enable Browser Access on the application segment; set the Domain, Application Protocol (HTTP/HTTPS only), Port, and the Certificate.
3. Publish DNS — copy the Canonical Name and add the public CNAME (skipped automatically with Managed certs).
4. Access policy + IdP — a default-deny access policy with a SAML IdP so the user can authenticate clientlessly.
5. Internal DNS — point the App Connector at internal DNS that resolves the app's real IP.

Now the part that fills support queues. Here are the five failures, each as a symptom you'll actually see in the wild.

🔧 Engineer note. Two more boundaries bite teams late. Double Encryption is mutually exclusive with Browser Access on the same segment — enable it for compliance and BA on that segment goes dead silently; keep them on separate segments. And BA serves web only (HTTP/HTTPS); clientless RDP/SSH/VNC is Privileged Remote Access (PRA), and anything non-web needs the full ZCC tunnel.

One screen to remember it all