I’ve just updated to the newest ZAC version and hat a VERY strange thing happen.
Here’s how I updated: cp -r path/ziti-console /tmp/ziti-console.bak
```git clone GitHub - openziti/ziti-console “${ZITI_HOME}/ziti-console”``
… then created the symlinks and ran npm install.
I have ZAC running on the same host as the controller itself and I have a service intercepting port 443 of zac.censored.com, and a host config to let the traffic out on port 8443 with the respective policies.
After I updated I noticed that I got an error implying making an HTTPS connection to an HTTP server. After some troubleshooting I could confirm this was the case. I formerly had the NPM server running via HTTP on 1408 instead of 8443 and thereafter changed the service config accordingly to access on the TLS port.
I suppose something about the service config was cached or do you have an idea how this could happen? When checking the service config, it was still correctly set to 8443 but ACTUALLY letting out the traffic on 1408. Simply changing the config again to set port 8443 again seemed to solve the problem.
Do you think the problem was with ZAC or the controller itself? I didn’t touch any files outside of the ziti-console directory…
the quickstart sets up both TLS and non-TLS endpoints for ZAC. ZAC only serves TLS if it finds a certain cert/key in the ‘current working folder’. See this block of code: ziti-console/server.js at master · openziti/ziti-console · GitHub
if (fs.existsSync("./server.key")&&fs.existsSync("./server.chain.pem")) {
You need a file and a key named server.key and server.chain.pem. Are you sure those files are there?
It’s easiest to debug this in a console (not via a systemd service) with node server.js -d if you add -d to the end it should start in ‘debug’ mode and give more details.
My guess is that the cert/key files are not named quite the same?
Yep, both files are there, and I verified there was a listener behind port 1408 and 8443.
I could also successfully do a
curl -k https://localhost:8443
However the traffic going trough the Ziti tunnel exited on the formerly set port 1408. This was changed later to 8443 and worked flawlessly. Only after updating the ZAC it seems that the config has changed somehow…
So you’re saying that both port 1408 and 8443 are listening, and yet somehow BOTH are returning HTTP not one HTTP the other HTTPS? That sounds really bizarre if that’s the situation…
if you run ss -lntp | grep -E '1408|8443' (or the equivalent) can you verify both ports are owned by the same pid?
Can you provide the verbose curl? curl -skv https://localhost:8443?
No, the ZAC node application is exactly doing what it should be.
The controller somehow made a mistake. The service config is set to “host on port 8443” but it actually did “host on port 1408”. After editing the config, doing no change and saving, everything works as expected.
Formerly I had set this exact config to “host on port 1408”, then changed to 8443.
After updating ZAC on the same host, it switched again to 1408 but whilst displaying it would host on 8443 - but didn’t.
Hope that makes it more clear.
oooh you're accessing ZAC via ziti, right? is that what I'm missing here? Oh, ok, I think I'm understanding... You're accessing ZAC via ziti, but the service configuration is mismatched now...
If that's the case, you want to look at the intercept.v1 and the host.v1 configs. I bet there's a mismatch.
In my own personal history withOpenZiti, it's much more likely that I have made the mistake 
so I don't think it's the controller.
Assuming I understand what's going on, I bet you just have a mismatch in your configs.
Can you double check those and make sure everything maps out correctly?