Hello,
We are working on implementing OpenZiti for our Web application. At this stage, we are setting up the environment on a local test server using OpenZiti with Docker. Following the documentation, we successfully deployed the default controller, edge router, edge router policies, and ZAC. As expected, the Web application is now accessible only through OpenZiti, confirming that the configuration is functioning as intended.
The main issue arises when attempting to replicate the same process using an FQDN (e.g., zc.forexample.com). Specifically, challenges occur while configuring and running the controller and edge router with FQDNs using the following commands:
Running controller container:
Edge router policies:
Edge router
Also created services, policies and configurations in ZAC gui as per Openziti docs, After this I hoped to access the wazuh using Custom address which i put in intercept.v1 configuration. But it was not working.
Following are the error logs:
[2025-09-30T06:09:29.719Z] INFO ziti-sdk:ziti_ctrl.c:180 ctrl_resp_cb() ctrl[https://ziti-edge-controller:1280] attempting to switch endpoint
[2025-09-30T06:09:29.719Z] WARN ziti-sdk:ziti_ctrl.c:602 ctrl_next_ep() ctrl[https://ziti-edge-controller:1280] no controllers are online
[2025-09-30T06:09:29.719Z] WARN ziti-sdk:ziti.c:644 ext_jwt_singers_cb() ztx[4] failed to get external auth providers: unknown node or service
[2025-09-30T06:09:29.846Z] ERROR tlsuv:engine.c:863 openssl: handshake was terminated: error:0A000086:SSL routines::certificate verify failed
[2025-09-30T06:09:29.846Z] ERROR tlsuv:tls_link.c:113 TLS(00000249d2378c80) handshake error certificate verify failed
[2025-09-30T06:09:29.846Z] ERROR tlsuv:http.c:192 handshake failed status[3]: certificate verify failed
I see you're using our quickstart containers which is fine. There are other containers available without bash etc as well the doc for them is at Deploying with Docker | NetFoundry Documentation You might try those.
Looking at the logs you provided, my guess is that your PKI is not configured correctly. It's pretty hard to know what went wrong where and how from just what you shared.
There's a ziti cli command to try to run to see if things are setup for succes. Try running:
ziti ops verify traffic --mode both --username $ZITI_USER --password $ZITI_PWD
example of success:
$ ziti ops verify traffic --mode both --username $ZITI_USER --password $ZITI_PWD
Using controller url: https://ec2-3-18-113-172.us-east-2.compute.amazonaws.com:8441/edge/management/v1 from identity 'default' in config file: /home/clint/.config/ziti/ziti-cli.json
Token: f90d5a27-9c61-4edc-851f-9c34efbd72a1
Saving identity 'default' to /home/clint/.config/ziti/ziti-cli.json
INFO generating P-384 EC key
INFO generating P-384 EC key
INFO waiting 10s for terminator for service: 2025-09-30-0812.traffic
INFO successfully bound service: 2025-09-30-0812.traffic.
INFO Server is listening for a connection and will exit when one is received.
INFO new service session session token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjBmN2F......
INFO found terminator for service: 2025-09-30-0812.traffic
INFO found service named: 2025-09-30-0812.traffic
INFO Server has accepted a connection and will exit soon.
INFO successfully dialed service: 2025-09-30-0812.traffic.
INFO traffic test successfully detected
INFO Server complete. exiting
INFO client complete
If that doesn't succeed, let's see what it returns as an error. My GUESS is that maybe you need to remove that persistent folder/volume and start again because maybe you've initialized it twice? it's hard to know...
As advised, we started again from scratch for the FQDN deployment, deleting all previous networks and volumes, using below commands:
COMMANDS
docker volume create myPersistentZitiFiles
docker network create myFirstZitiNetwork
Controller
Running the Controller
docker run
--name ziti-controller
-e ZITI_CTRL_ADVERTISED_ADDRESS=zc.forexample.com
--network myFirstZitiNetwork
--network-alias ziti-controller
--network-alias ziti-edge-controller
-p 1280:1280
-it
-v myPersistentZitiFiles:/persistent
openziti/quickstart
/var/openziti/scripts/run-controller.sh
Create Edge Router Policies
docker run
--network myFirstZitiNetwork
--network-alias ziti-controller-init-container
-it
--rm
-v myPersistentZitiFiles:/persistent
openziti/quickstart
/var/openziti/scripts/run-with-ziti-cli.sh /var/openziti/scripts/access-control.sh
EDGE ROUTER
docker run --name ziti-edge-router-1 --network myFirstZitiNetwork -e ZITI_ROUTER_NAME=r1.forexample.com -e ZITI_ROUTER_ADVERTISED_ADDRESS=r1.forexample.com -e ZITI_ROUTER_ROLES=public -p 4022:4022 -it -v myPersistentZitiFiles:/persistent openziti/quickstart /var/openziti/scripts/run-router.sh edge
We are getting the below error after running the docker run command for ziti-edge-router-1
Errors:
[ 0.037] ERROR ziti/router/env.(*networkControllers).connectToControllerWithBackoff.func2: {endpoint=[tls:zc.forexample.com:6262] error=[error connecting ctrl (dial tcp: lookup zc.forexample.com on 127.0.0.11:53: no such host)]} unable to connect controller
[ 0.100] ERROR ziti/router/env.(*networkControllers).connectToControllerWithBackoff.func2: {endpoint=[tls:zc.forexample.com:6262] error=[error connecting ctrl (dial tcp: lookup zc.forexample.com on 127.0.0.11:53: no such host)]} unable to connect controller
[ 0.244] ERROR ziti/router/env.(*networkControllers).connectToControllerWithBackoff.func2: {endpoint=[tls:zc.forexample.com:6262] error=[error connecting ctrl (dial tcp: lookup zc.forexample.com on 127.0.0.11:53: no such host)]} unable to connect controller
[ 0.362] ERROR ziti/router/env.(*networkControllers).connectToControllerWithBackoff.func2: {endpoint=[tls:zc.forexample.com:6262] error=[error connecting ctrl (dial tcp: lookup zc.forexample.com on 127.0.0.11:53: no such host)]} unable to connect controller
[ 0.511] ERROR ziti/router/env.(*networkControllers).connectToControllerWithBackoff.func2: {error=[error connecting ctrl (dial tcp: lookup zc.forexample.com on 127.0.0.11:53: no such host)] endpoint=[tls:zc.forexample.com:6262]} unable to connect controller
The error is very clear. Your router cannot route to zc.forexample.com. You need to fix your routing or DNS.
It seems that the certificate is binded to previously made variables. how can I delete the certificate?
Because everytime i fully delete files related to OpenZiti and start again, I still get this error.
I try to delete .ziti folder and when i install OpenZiti, it fetches earlier made PKI cert details.
RESTY 2025/10/03 15:05:11 ERROR Get "https://zc.forexample.com:8441/version": tls: failed to verify certificate: x509: certificate is valid for integratedubuntu, localhost, not zc.forexample.com, Attempt 5.
Note: i am now trying to deploy Openziti without using docker, it seems there are some issues related to my docker.
There's some persistent store you will need to delete. Possibly in a docker volume. Look at your router and controller config files and they'll point to the paths to find and remove.
this makes it sound like maybe you have a different path referenced? The .ziti folder makes it sound like you ran a quickstart not a deployment. That's fine but do know the deployments are availalble for non-docker too.
I would guess that you have some env vars set. There's a helper function called unsetZitiEnv if you have sourced the ziti-cli-function.sh helper script that you could call first. Or just exit your shell and open it back up, I'd image that'd clear them too.
it really is better for the community to make a separate post when the topic changes. In the future, please open a new toplevel post.
OpenZiti doesn't operate on IP addresses, really. Certainly not for security concerns like an allow list of IPs.
Your premise has many flaws I just don't understand:
if he uses untrusted network to connect to our application outside of our organisation
You should just not allow this? That's the point of OpenZiti? I feel like I don't understand what you're trying to convey.
The bad actor has compromised the underlay network where the user is? That will have no effect on OpenZiti's security posture and your app won't be accessible still. If the Bad Actor compromises the user's machine (laptop/desktop/phone) that's a whole different story because tunnelers are specifically designed to bridge underlay network to overlay network. ANY tunneler would be sucseptible to a localhost attack in this way (any VPN, wireguard, openziti etc). OpenZiti DOES have a solution to this though, which is to use an OpenZiti SDK and bake it into the application itself. If you do that, then the app becomes totally invisible to the underlay network entirely and compromising the underlay network itself is not enough to allow a bad actor to attack the application.
If you deploy it yourself, there are no limits other than your ability to scale and support the solution... That's why NetFoundry offers OpenZiti as a service/NaaS so we can do that for you. 
1 Like
noted and I apologize for it.
Understood, right now we just have 5 people in our small startup.
Nevermind, I had too many unrelated questions in my mind.
Thanks for helping tho. the main issue was wrong FDQN entry from my side on cloud dns, once that was resolved, it started working.
