Browzer Setup - Error 1014 - OriginTrial subdomain mismatch

I've got an OpenZiti VPS running with a controller and edge-router installed and working. I have another edge router in a private network which is connected and also working. I added ZAC in a docker and that's working. I've been going through the steps to setup Browzer on the VPS to access a service hosted in the private network. It's been slow and steady but I hit an error and I'm not sure what I've done to break it.

When I point any web browser to the BrowZer target I get a giant whole-page error that says...

BrowZer Runtime error code: 1014

OriginTrial subdomain mismatch for feature [WebAssemblyJSPromiseIntegration]

Expected origin [*] but is accessed from [*]

It seems like maybe I left some environment variable out and it defaulted to the cloudziti stuff. This is not a cloud ziti instance in any way. I've started reading the BrowZer code but the NodeJS stuff is not my cup of tea.

version: "3.3"

    restart: always

      - /opt/ziti/log:/home/node/ziti-http-agent/log
      - /opt/ziti:/ziti

      - "443:443"

      NODE_ENV: production
      ZITI_BROWZER_BOOTSTRAPPER_LOG_PATH: /home/node/ziti-http-agent/log/browzer-bs.log
      ZITI_BROWZER_BOOTSTRAPPER_KEY_PATH: /ziti/tls/privkey.pem
            "targetArray": [
                      "vhost": "",
                      "service": "myapp",
                      "path": "/",
                      "scheme": "http",
                      "idp_issuer_base_url": "",
                      "idp_client_id": "00000000-0000-0000-0000-000000000000"


Hi @ghibsch, welcome to the community and to OpenZiti!

Have you previously tried brozer maybe? Have you tried a private window to rule out any browser-based caching?

One thing that is sometimes necessary when doing BrowZer work is to clear the site data and service worker (if needed but clearing all the site data usually takes care of that, I believe)

You may need to enable JSPI in your browser (I believe it's enabled by default as part of origin trials for origin * You can enable it by navigating to chrome://flags in Chrome browser, and scrolling down to Experimental WebAssembly JavaScript Promise Integration (JSPI)

A couple months ago I was playing with the CloudZiti trial but I never enabled BrowZer in that. I also cleared site data, tried private window, and tried 2 other browsers and another laptop. Same result in all. JSPI is set to default. Changing it to enabled made no difference.

Had another random thought this morning. I setup the JWT signer and auth policy with the ZAC. Could that have defaulted something to the CloudZiti domain?

I don't think so, no. I have an entire set of scripts that redeploys a whole browzer network. I ran it just now and I am also getting this error:

I'll poke at my instance but we might need @curt to have a look.

I'm guessing I'm missing a configuration item that's new. I'll read the changelogs and see if I can figure out what/where/how it went wrong.

@ghibsch A couple of days ago, we released a BrowZer enhancement that was urgently needed to unblock one of our CloudZiti customers. I haven't yet updated the OpenZiti docs to reflect the need for a new BrowZer Bootstrapper env config var that you now require, and I apologize for that gap.

I will post here again shortly with the info you need (so watch for that), and I will update our docs in the next day or two.

Well that at least makes me feel better that it's been identified. Thanks for the quick look at this, guys. Really appreciate OpenZiti and all the work you do to support it.

Thanks @curt . If it matters, as an example, my domain is * I doubt you need it, but I figured I'd give you a 'for example'...

I'll do a more thorough write-up/blog soon, and even though this post might get a little long, the TL;DR is that BrowZer leverages JSPI.

Until JSPI is finalized (and it is always present/enabled in the browser), it needs to be externally enabled in the browser somehow.

JSPI can be enabled in multiple ways, including:

  • by the end-user of the browser, by enabling the flag (down in chrome://flags), or...
  • via what is known as an "Origin Trial"

Since some browsers (like Edge) have recently stopped making the JSPI flag available in the edge://flags UI (even though JSPI is available in Edge), enabling JSPI via an Origin Trial is the only way to get JSPI enabled.

I also assert that the Origin Trial approach is far better for end-users of a browZer-protected web app because they never need to manually enable JSPI, or even know JSPI exists. Origin Trials will transparently enable the JSPI flag for the end-user of your BrowZer-protected web app.


If you are using CloudZiti, we take care of the Origin Trial config for you.

If you are self-hosting your own OpenZiti BrowZer stack, you will need to acquire your own Origin Trial token (it's easy) that is appropriate for your domain /origin, and then provide that token to the BrowZer Bootstrapper.

To acquire your Origin Trial token:

Using the token you just received, provide it to the BrowZer Bootstrapper via the following env var:


This should get you up and running.

Let us know how it goes.

Thanks @curt. I can confirm my "browzer based ziti admin console" (my "brozac") works again!

Is a separate token required for the other web browsers (Firefox, Edge, Safari, Brave) or they all respect the token from Google?

It sounds like you've got customers on the CloudZiti side using BrowZer with JSPI. Any concerns deploying this for limited-scale production use?

The same Origin Trial token will work with Chrome, Brave, and Edge.

Note that BrowZer does not yet support Firefox or Safari at all.

Yes, we currently have the same token in use for all of our * networks.