8.3 Browser Access (Clientless ZTNA)
Key Takeaways
- Browser Access enables secure, clientless Zero Trust Network Access to internal web applications without installing Zscaler Client Connector.
- ZPA Public Service Edges act as an authenticated reverse proxy, terminating external user TLS sessions and stitching mTLS connections to internal App Connectors.
- Public Web Server SSL certificates signed by recognized public Certificate Authorities must be uploaded to ZPA to avoid browser trust warnings.
- External DNS CNAME records delegate application FQDNs to Zscaler canonical endpoints (<tenant>.zpa-app.net).
- Browser Access is strictly restricted to HTTP and HTTPS web applications; non-web protocols require ZCC or Privileged Remote Access (PRA).
8.3 Browser Access (Clientless ZTNA)
Core Principle: Enforcing corporate agent installation (Zscaler Client Connector) is standard practice for managed enterprise laptops and mobile devices. However, modern business ecosystems rely extensively on third-party contractors, external auditors, supply-chain vendors, and unmanaged BYOD (Bring Your Own Device) endpoints. Mandating software installation or Mobile Device Management (MDM) enrollment on external devices creates operational friction and liability. ZPA Browser Access delivers secure, clientless Zero Trust Network Access (ZTNA) directly through any modern HTML5-compliant web browser without client software, administrative privileges, or browser extensions.
1. Browser Access Architectural Mechanics & Traffic Flow
In a Browser Access deployment, the Zscaler Public Service Edge functions as a secure, globally distributed Reverse Proxy Gateway. The user interacts with the application as if it were a public SaaS portal, while the underlying internal server remains completely invisible and inaccessible to direct network connections.
+-----------------------------------------------------------------------------------+
| BROWSER ACCESS CLIENTLESS TRANSACTION FLOW |
+-----------------------------------------------------------------------------------+
Unmanaged Contractor Laptop Zscaler Public Service Edge Internal App Connector Internal Web Server
┌─────────────────────────┐ ┌───────────────────────────┐ ┌────────────────────┐ ┌──────────────────┐
│ 1. Navigates to │───────────>│ 2. Public DNS CNAME │ │ │ │ │
│ jira.partner.corp.com│ (TLS) │ Resolves to ZPA Edge │ │ │ │ │
└─────────────────────────┘ │ │ │ │ │ │
│ │ 3. Redirects to IdP │ │ │ │ │
▼ │ (SAML 2.0 / MFA) │ │ │ │ │
┌─────────────────────────┐ │ │ │ │ │ │
│ Authenticates to IdP │───────────>│ 4. Validates SAML & │ │ │ │ │
│ (Okta / Entra ID) │ │ Evaluates Access Policy│ │ │ │ │
└─────────────────────────┘ │ │ │ │ │ │
│ 5. Stitches mTLS Tunnel │──────────>│ 6. Outbound mTLS │───────>│ 7. HTTP/HTTPS │
│ to App Connector │ (mTLS) │ Connection to │ (LAN) │ Response to │
│ │ │ Internal Server │ │ Connector │
└─────────────┬─────────────┘ └────────────────────┘ └──────────────────┘
│
▼
[ 8. Proxies Rendered Web ]
[ Stream to Browser ]
Step-by-Step Architectural Lifecycle:
- DNS Resolution: The external user navigates to
https://jira.partner.corp.com. The public DNS query resolves a CNAME record pointingjira.partner.corp.comto the customer's dedicated ZPA canonical domain (e.g.,acmeweb.zpa-app.net). - TLS Termination & Authentication Challenge: The nearest ZPA Public Service Edge terminates the client TLS connection using a pre-uploaded public SSL certificate. Because no active session cookie exists, ZPA redirects the user's browser to the enterprise Identity Provider (IdP) for SAML 2.0 / OIDC authentication and multi-factor authentication (MFA).
- Policy Evaluation: Upon receiving a successful SAML assertion, ZPA evaluates its configured Access Policies. It verifies that the user matches the authorized SAML groups and that the rule explicitly permits Client Type = Web Browser.
- Microtunnel Stitching: The ZPA Service Edge signals the on-premises App Connector (which maintains an outbound persistent control connection to the cloud). The App Connector establishes an outbound data microtunnel over TLS/DTLS to the Service Edge.
- Internal Proxy & Web Delivery: The App Connector establishes a standard TCP connection (HTTP on port 80 or HTTPS on port 443) to the internal web server, retrieves the application data, and streams it back through the ZPA Cloud to the user's browser.
2. Public Web Server SSL Certificates & ZPA CA Integration
Because the ZPA Public Service Edge acts as a reverse proxy directly facing end-user browsers on the public internet, SSL/TLS Certificate Architecture is paramount.
+-----------------------------------------------------------------------------------+
| BROWSER ACCESS PUBLIC SSL/TLS CERTIFICATE TRUST CHAIN |
+-----------------------------------------------------------------------------------+
End-User Web Browser (Unmanaged PC)
│
▼ Encrypted Session: https://jira.partner.corp.com (TCP 443)
┌─────────────────────────────────────────────────────────────────┐
│ Zscaler Public Service Edge (Reverse Proxy) │
│ │
│ * Public Certificate: CN = jira.partner.corp.com │
│ (or Wildcard: CN = *.partner.corp.com) │
│ * Issuer: Globally Trusted CA (DigiCert, Let's Encrypt, etc.) │
│ * Private Key: Securely stored in ZPA Cloud Vault │
└─────────────────────────────────────────────────────────────────┘
Certificate Requirements and Best Practices:
- Public CA Signed Certificates: The certificate uploaded to ZPA for a Browser Access application must be signed by a globally recognized public Certificate Authority (e.g., DigiCert, Sectigo, Let's Encrypt, GoDaddy). If an internal private enterprise PKI certificate is used, unmanaged contractor browsers will display untrusted SSL warning banners.
- Subject Alternative Names (SAN) & Wildcards: ZPA supports both specific FQDN certificates (
jira.partner.corp.com) and wildcard certificates (*.partner.corp.com). When using a wildcard certificate, multiple Browser Access applications sharing the same domain suffix can leverage a single certificate configuration in ZPA. - Certificate and Private Key Upload: The certificate chain (server certificate, intermediate CA, root CA) and the unencrypted RSA/ECDSA private key (PEM format) must be uploaded to the ZPA Admin Portal > Configuration & Control > Certificate Management.
3. Wildcard Domains vs. Explicit Application Segments
While wildcard SSL certificates simplify public certificate management, ZPA enforces strict definitions for Application Segments configured for Browser Access.
| Configuration Construct | Support in Browser Access | Operational Behavior & Constraints |
|---|---|---|
Wildcard Domain in App Segment (e.g., *.corp.internal) | Supported for standard ZCC, Restricted for BA | Browser Access requires each application FQDN to be explicitly declared so the reverse proxy can route incoming HTTP Host headers accurately. |
Explicit FQDN in App Segment (e.g., portal.corp.internal) | Fully Supported (Standard) | Allows specific mapping of external public FQDNs to internal target hostnames, ports, and App Connector groups. |
Wildcard SSL Certificate (e.g., *.apps.acme.com) | Fully Supported | Can be bound to multiple explicit Browser Access Application Segments. |
[!IMPORTANT] Exam Key Point: In Browser Access, you cannot simply define
*.corp.comas a catch-all Browser Access segment and expect automatic reverse proxying. Each distinct web portal accessed via a browser must be registered as an explicit Browser Access application segment with its own CNAME routing definition.
4. Protocol Scope & Limitations of Browser Access
Understanding what Browser Access can and cannot do is a frequent topic on the ZDTA exam:
+-----------------------------------------------------------------------------------+
| BROWSER ACCESS PROTOCOL CAPABILITIES |
+-----------------------------------------------------------------------------------+
SUPPORTED IN BROWSER ACCESS: UNSUPPORTED IN BROWSER ACCESS:
[+] HTTP (TCP Port 80) [-] Native SSH / Telnet CLI Clients
[+] HTTPS (TCP Port 443) [-] Native RDP (mstsc.exe) Clients
[+] WebSockets (WS / WSS) [-] Database Connections (SQL, Oracle)
[+] Modern Single-Page Web Apps (SPAs) [-] Thick Client Enterprise Apps (SAP GUI)
[+] REST / JSON Web APIs [-] Raw TCP / UDP Socket Streams
[-] ICMP Ping / Network Traceroute
Note: While native SSH, RDP, and VNC cannot run through standard Browser Access, they are fully supported without client agents via Privileged Remote Access (PRA) (covered in Section 8.4).
5. Practical Configuration Scenario: Deploying a Contractor Portal
Scenario: An enterprise needs to grant external accounting contractors access to an internal financial web portal (https://ledger.finance.corp.com) hosted in an on-premises data center on internal IP 10.50.20.100:443.
Step-by-Step Implementation Workflow:
+-----------------------------------------------------------------------------------+
| BROWSER ACCESS STEP-BY-STEP DEPLOYMENT WORKFLOW |
+-----------------------------------------------------------------------------------+
STEP 1: Enroll Public Web Server Certificate in ZPA
Upload 'finance_corp_com.crt' (DigiCert) & Private Key to Certificate Management.
STEP 2: Configure Application Segment with Browser Access
* Domain: ledger.finance.corp.com
* Web Server Ports: TCP 443
* Enable 'Browser Access' Toggle = ON
* Select Public Certificate = 'finance_corp_com.crt'
* Assign App Connector Group = 'DataCenter-Connectors'
STEP 3: Configure External Public DNS CNAME Record
In Public DNS (Cloudflare/Route 53):
ledger.finance.corp.com CNAME tenant-name.zpa-app.net.
STEP 4: Configure Access Policy Rule
* Rule: 'Allow Contractors to Ledger Web App'
* Criteria - Application Segment: 'ledger.finance.corp.com'
* Criteria - SAML Group: 'External-Contractors'
* Criteria - Client Type: 'Web Browser'
* Action: ALLOW
6. Exam Tips & High-Frequency Traps
[!WARNING] Exam Trap (Client Type Matching in Policy): If an administrator configures Browser Access for an internal portal but the Access Policy rule specifies
Client Type = Zscaler Client Connector, contractors attempting to connect via their web browser will be denied access with a 403 / policy block error. The Access Policy rule must includeClient Type = Web Browser.
[!IMPORTANT] Exam Key Point (DNS CNAME Requirement): For Browser Access to function, the enterprise must create an external public DNS CNAME pointing the application FQDN to ZPA's canonical domain (
<tenant>.zpa-app.net). If the public DNS record is missing or misconfigured, the client browser will fail to reach the ZPA reverse proxy.
[!TIP] Security Insight (Certificate Placement): In Browser Access, the public SSL certificate uploaded to ZPA is presented to the client's browser. The App Connector's subsequent connection to the internal web server is a separate TLS leg; the internal server can use an internal enterprise PKI certificate.
A third-party auditing firm needs temporary access to an internal accounting web application. The auditors use unmanaged laptops where corporate software agents cannot be installed. What ZPA technology should be deployed?
Why must an organization upload a publicly trusted SSL certificate (e.g., from DigiCert or Let's Encrypt) to the ZPA portal when configuring Browser Access for an internal web application?
Which of the following protocols is supported for delivery to end users via standard ZPA Browser Access?
An administrator configures Browser Access for an internal portal and creates a public DNS CNAME record pointing to ZPA. However, when external contractors attempt to access the URL, they receive an HTTP 403 Forbidden error. What is the most likely policy misconfiguration?