Hey guys,
We’ve been running a clustered OpenZiti network for a while now, and we started wondering whether any parts of the deployment can actually expire, or if OpenZiti handles all certificate lifecycle tasks automatically.
From what I understand, components like routers and SDK clients can extend their certificates automatically as long as they stay connected, but leaf certificates can still expire in some situations. Is there a recommended way to check when those certificates are set to expire — especially in a multi‑controller clustered setup? Also what about the root CA and intermediate CA, do we need to worry about those?
Basically:
- Which parts of a clustered OpenZiti network are able to auto‑renew?
- Which ones can expire unexpectedly?
- Is there a simple command or API call to check certificate expiry dates across controllers/edge/API certificates?
Thanks in advance — just making sure we’re not caught off guard by a cert aging out 
Hi @montwepa,
It will depend on how you deploy but the only certs you should have to really be worried about are controller certs. The first cert that will expire will be the server cert for the overlay and / or the API. By default those certs are valid for one year. The linux deployment were originally created and configured to roll these certs automatically for you when you restart the process but if you don't restart the process then that won't happen. So you need to watch the certs at the controllers and that's it. All the other stuff handles cert rolling/lifecycles.
Is there a simple command or API call to check certificate expiry dates across controllers/edge/API certificates?
the go-to command is always openssl for this. openssl s_client -connect host:port. An example from my controller right now where i'm rolling the cert every 30 days:
openssl s_client -connect ec2-3-18-113-172.us-east-2.compute.amazonaws.com:8441 </dev/null 2>&1 | grep -i after
v:NotBefore: Mar 26 13:32:24 2026 GMT; NotAfter: Apr 26 13:33:24 2026 GMT
v:NotBefore: Feb 16 22:14:56 2025 GMT; NotAfter: Feb 14 22:15:49 2035 GMT
v:NotBefore: Feb 16 22:14:43 2025 GMT; NotAfter: Feb 14 22:15:38 2035 GMT
10 years from the start you'll have to deal with rolling out the CA as well so you may want to plan for that in 9 years? 
Thanks for the response!
Couple things I was wondering still.
You mentioned that "originally created and configured to roll these certs automatically for you when you restart the process" and we have restarted the controller but it doesn't seem that the certificates have been re-rolled (last restart being 20h ago) so is that something you can enable? I take it that the linux deployment you are referring to has a external automation script and it's not built into the controller?
Also you said that you are rolling the cert every 30 days. Have you automated that and if so how?
Thanks
I did some testing on that and it seems like it's the docker container that's doing that automatic rolling every restart. I should have been more specific.
I roll my certs with a script that me and my favorite agent vibed together. I have an ancient quickstart that I've kept running for dev-related work. It leverages environment variables that the quickstart left behind and I just keep sourcing them. I also use the ZITI_PKI folder from that and run a ziti pki command:
ziti pki create server \
--pki-root "$ZITI_PKI" \
--ca-name "$ZITI_PKI_CTRL_EDGE_INTERMEDIATE_NAME" \
--key-file "$ZITI_CONTROLLER_HOSTNAME-server" \
--ip 127.0.0.1,::1 \
--dns localhost,mgmt,mgmt.ziti,mgmt-addressable-terminators,cdaws.controller,controller-cdaws,cdaws-controller,"$ZITI_CONTROLLER_HOSTNAME" \
--server-file "$new_cert" \
--expire-limit 31
Then I backup the file and finally use sed to find/replace the file and restart the controller.
"how"? On linux a classic way would be to use cron but it's reasonable to just roll them as you need them if you dont' want to use cron. I think the v2 linux deployment that's coming out soon might have that sort of option built into it assume I am remembering correctly. it's not released yet but should be soon.