# After updating ZAC, service policy modified **URL:** \ **Category:** Ziti Overlay\ **Created:** [June 20, 2023, 6:22pm UTC](https://openziti.discourse.group/t/after-updating-zac-service-policy-modified/1335 "2023-06-20T18:22:40Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![dmuensterer](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/dmuensterer/32/2451_2.png) [@dmuensterer](https://openziti.discourse.group/u/dmuensterer)\ **Post date:** [June 20, 2023, 6:22pm UTC](https://openziti.discourse.group/t/after-updating-zac-service-policy-modified/1335/1 "2023-06-20T18:22:40Z")
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](https://github.com/openziti/ziti-console.git) “${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](http://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… ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [June 20, 2023, 6:41pm UTC](https://openziti.discourse.group/t/after-updating-zac-service-policy-modified/1335/2 "2023-06-20T18:41:06Z")
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](https://github.com/openziti/ziti-console/blob/master/server.js#L1908) ```auto 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? ---
**Author:** ![dmuensterer](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/dmuensterer/32/2451_2.png) [@dmuensterer](https://openziti.discourse.group/u/dmuensterer)\ **Post date:** [June 20, 2023, 7:05pm UTC](https://openziti.discourse.group/t/after-updating-zac-service-policy-modified/1335/3 "2023-06-20T19:05:18Z")
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](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… ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [June 20, 2023, 8:14pm UTC](https://openziti.discourse.group/t/after-updating-zac-service-policy-modified/1335/4 "2023-06-20T20:14:40Z")
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`? ---
**Author:** ![dmuensterer](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/dmuensterer/32/2451_2.png) [@dmuensterer](https://openziti.discourse.group/u/dmuensterer)\ **Post date:** [June 20, 2023, 8:54pm UTC](https://openziti.discourse.group/t/after-updating-zac-service-policy-modified/1335/5 "2023-06-20T20:54:36Z")
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. ---
**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\ **Post date:** [June 20, 2023, 9:00pm UTC](https://openziti.discourse.group/t/after-updating-zac-service-policy-modified/1335/6 "2023-06-20T21:00:34Z")
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. > [@dmuensterer](#): > > The controller somehow made a mistake. 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?