I just discovered OpenZiti and followed the deployment guide because I know I want to make this a reality for my network and so decided to skip the quick start.
I've successfully started and logged into the ZAC service using my public DNS and really just wanted to get rid of the annoying "Potential Security Risk" warnings.
So using certbot's cloudflare plugin, successfully generated my Alternative Server Certificates and configured the console as per this document: Console Configuration | OpenZiti
Still no luck. It seems that ZAC is persistent in serving its self signed certificate. I've spent many hours trying to figure it out with no luck. I will appreciate any help as I'm eager to move on to setup the rest of my network!!
Congrats on getting your Ziti instance up and running. Let's figure out this next piece about the cert.
I assume you encountered a browser warning that was triggered by an unknown certificate. Were you able to confirm which unknown certificate you encountered? You can match the cert's subject to those you have on the host where you're running the Ziti controller.
You found the recommended approach: set an alternative cert for the console.
Here are some things to check that might be misconfigured.
Ziti chooses which cert to use based on the server name (SNI). Ensure each name appears on exactly one server certificate. For example, you may encounter the wrong cert if the same DNS name appears in the subject alternative names (SANs) of multiple server certificates.
Ensure the "zac" binding in your Ziti controller config.yml is on the same web listener as the "edge-management" binding.
Ensure the known server certificate requested by CertBot is configured on the "web" listener shared by "zac" and "edge-management." If you have only one "identity" section in your config then it's used for everything, but you might have one or more "identity" sections if you're using separate certificates for each "web" listener.
Ensure the files created by CertBot are readable by the user account that's running Ziti controller. To test, first identify the Ziti controller's user ID, then ensure it can read those files. Here's a one-liner that tries to read a file by running as the owner of the ziti controller process.
# modify the file path
pgrep -f 'ziti controller run' | xargs -r ps -o user -h | xargs -rIUSER sudo -u USER sh -c 'echo "$(whoami) $(if test -r /etc/letsencrypt/live/console.ziti.example.com/privkey.pem; then echo can; else echo cannot; fi) read the file"'
gets
ziti-controller can read the file
Are the key/cert files on a mountpoint? If so, it's conceivable that Ziti's file handle watcher couldn't "see" that they were updated while the controller was running, in which case it could be necessary to restart the controller to load the new versions of those files created by CertBot.
Wow! thank you very much for the detailed troubleshooting guide qrkcourier!
I was able to identify the problem: It was always serving the self signed certificate because the dns name I was using was overlapping with the FQDN I used when setting up the controller.
All I had to do was include an extra subdomain to eliminate the overlap and sure enough it started serving the alternate certificates.
Now I have two exposed endpoints for the controller ZAC service and realized how beautiful it is to just eliminate all my cloudflare proxies and have endpoint to endpoint encryption for all my services without the need for cloudflare.
I'm currently in the process of migrating all my networking needs to use my newly created OpenZiti zero trust network
Thank you for enabling developers to take control of their networking needs with this simple and beautiful self hosted setup!
