This time i've got a question about CA certificate expiration.
I'm using Controllers in HA mode, v1.5.4.
When the intermediate CA certificate or root CA is renewed how does the ZET client configuration get updated with the new CA certificate bundle ? Is there an automated process or is it expected to be handled outside of Ziti ?
Are you able to tell me how often ZET periodically requests /.well-known/est/cacerts ? I've just been testing the process for rolling certs with short cert lifetimes so perhaps I've not waited long enough. Is it triggered in any other way ?
Must the old intermediates also be kept in the CA bundle when they are rolled too ?
If the intermediate expires and ZET fails to auth, is ZET still able to request an up to date bundle from /.well-known/est/cacerts ?
you shouldn't need to have intermediates in the CA bundle (.well-known/est/cacerts). Instead Controller API and ER endpoints should present intermediates during TLS handshake.
That way, if your intermediate expires you just need to reissue it along with requires leaf certs and SDK would connect fine.
SDK downloads a new bundle every time API session is acquired or refreshed
ZET identity contains leaf+intermediate certs, so rotating intermediate on the controller won't affect client authentication as long as root stays in the bundle. (see my comment about old roots)
Leaf cert expiration should be within the expiration of the intermediate that signed it.
We had recently implemented a few things to deal with expiring certificates:
ZET will extend(really just get a new certificate chain) within 30 days of its current one expiring.
these is also a setting to allow expired identity certificates
If you want to rotate your intermediate, you can do it without affecting current identities.
Then you can request that they roll their certs -- and they'll be issued by the new intermediate.
And of course, let us know if you see anything different or not working correctly
In my tests i have been using short renewal/expiry settings of 1/2hours for the Intermediate CAs and Controller leaf certs but I found ZET does not renew its client cert because its expiry is 1y. Is it possible to configure the expiry of ZET client cert ? I cant see anything about this in docs.
In any case , if ZET client is offline during its own client cert renewal AND the intermediate that signed that cert also expires, then ZET will be unable to auth. Is that correct ?
Do you use a single intermediate or two? one for identities and one for fabric components(controller and ERs)?
In general the leaf certificate should not be valid past the NotAfter of the singing/intermediate cert. Maybe @andrew.martinez can chime in here.
As far as I can tell only the leaf cert is checked for expiration. If leaf is expired and your auth policy disallows expired certs then it won't be able to auth.
The default AuthPolicy allows expired leafs to be valid. This is a legacy hold over as we slowly rolled out the ability to have clients extend their certificates. I think all SDKs and our apps properly extend.
It should be safe enough for any installed network with recent controller/er/sdk/apps to change the default auth policy to not allow expired client certificate authentication. Or to add a new auth policy with allowing expired leafs to be false. Custom apps that don't support extending certs would obviously have issues but we can't control those.
It does raise the question if we should change the default as it is a security gotcha and we currently don't have a hardening guide. Changing the default would only affect new installations and not old ones.
I'm currently using a single intermediate CA per HA Controller for signing both the identity and fabric component certs.
At the moment, i've been testing my CA certificate rolling processes using short renewal and expiry date settings.
My problem is that client certs created for ZET always have an expiry of 1 year regardless of the expiry of the CA that created it. I am hoping to be able to configure the expiry of ZET client certs. Is it possible ?
I understand the policy to allow expired client certificates, this works fine.