Can you clarify a little bit how are you using cert-manager here?

I guess that when it was implemented it was done on purpose.
If the user is managing the certificates, they should know when rotation is going to happen or they are anyway in control of it. Anyway I can see your point because cert-manager is going to rotate for you when it's needed but maybe you don't want to do the upgrade yet.
Actually the code which is in charge of renewal by taking into account the maintainance window is here:

https://github.com/strimzi/strimzi-kafka-operator/blob/main/operator-common/src/main/java/io/strimzi/operator/common/model/Ca.java#L542

The maintenanceWindowSatisfied is totally ignored when CA certificate is handled by the user so that the renewal type is never RenewalType.POSTPONED.

@katheris because you are working on supporting cert-manager as well, I would be interested to know your opinion as well.

Cert-manager has an intermediate CA so it can create certificates for kafka instances. We are still migrating to kubernetes and a lot of services still run outside kubernetes clusters, so injecting the strimzi-generated CA into the clients is quite a bit harder. Therefore, having cert-manager create certificates whose chain goes to a root CA (company-wide) we have already added to all machines is much easier.

We have simply created Certificate resources with the corresponding dnsNames, and added the generated secret to the Kafka listener spec. The certificates have an expiry of several months and we have weekly maintenance periods, so it is very unlikely strimzi would be unable to restart the kafka pods before the current cert expires.

For now we have added a 1-year duration on the cert-manager Certificate resource that is calculated to happen during a maintenance period, so we should be good until the start of 2027. Strimzi will probably have some support for cert-manager or this issue by that point.

Hey, I agree with what @ppatierno said that it is intentional that the maintenance windows are only taken into account when Strimzi is managing certificate renewal. The docs state Schedule certificate renewal updates by the Cluster Operator to Kafka or ZooKeeper clusters for minimal impact on client applications.

That being said, I do think it's a valid point that the future cert-manager integration should allow users to specify maintenance periods.

@bh-tt it would be great if you could take a look at this proposal and see if that makes sense to you for how you use cert-manager. Any feedback you have would be greatly appreciated.

The proposal doesn't include mention of maintenance periods, but I think we should take that into account. @ppatierno do you think it is reasonable to include it directly in the implementation, or should I write a short proposal covering it to allow for discussion?

Proposal looks good, a few small points:

• cacert.secretName/cacert.certificate settings are not quite clear. Is cacert.certificate the key in the secret containing the certificate? Then I'd suggest using secretName and key like a standard SecretKeySelector. Additionally, it could be common for users to put a CA in a configmap (since it is public information), so it would be nice if strimzi supports that. Trust-manager is mentioned, which also only outputs to ConfigMaps?
• I cannot find a mention whether strimzi will request certificates with isCA: true. That would likely be blocked in most organizations, including ours, since intermediate cA often have the same signing capabilities as their parent. Will strimzi request this for the cluster CA or will it use the given CA?
• might be nice to simply accept a Certificate resource spec as an argument, that way users can kustomize all settings (where strimzi adds a few settings like dnsNames)?

Rest is good with how we use kafka.

The proposal doesn't include mention of maintenance periods, but I think we should take that into account. @ppatierno do you think it is reasonable to include it directly in the implementation, or should I write a short proposal covering it to allow for discussion?

@katheris I would go for an update on the proposal with ... another proposal. It's anyway going to have an impact on the overall process I think.

Hey @bh-tt on your qns:

Is cacert.certificate the key in the secret containing the certificate?

Yes, this follows the naming conventions we have elsewhere in Strimzi configuration

I cannot find a mention whether strimzi will request certificates with isCA: true.

In the example of the Certificate resource I set isCA to be false, and that is my intention for the implementation.

might be nice to simply accept a Certificate resource spec as an argument

Are there particular fields you expect you would need to override? As far as I can tell most of the fields are already accounted for in the Strimzi API or we wouldn't expect users to change. That being said we do provide a template option for other resources, so we could consider it for the Certificate resource if there were enough fields that a user might need to override.

I've created the pull request for the proposal around maintenance time windows, please take a look when you get time to make sure this would satisfy your requirements: strimzi/proposals#153

Looks good to me @katheris . This would work exactly as I thought it should, and reusing the existing maintenanceTimeWindows is likely the correct option.

Fields I'd expect to override sometimes:

• duration/renewBefore: plenty of users may have very strict maintenance windows, so the default of cert-manager (90 days?) may be too short for some
• private key size: some people may have requirements on the minimum key size
• setting subject organization/country etc. may be required as well
• I probably won't set URIs or emailAddresses, but someone with public kafka's may decide to?

At this point about half of the certificate resource is configurable already, so then a template may be the correct thing to do, if only to reduce future maintenance burden (can strimzi support field X on certificates?-like features).

@bh-tt thanks that list is useful. For info the duration/renewBefore is already in the Strimzi API. There is also an issue open that would address the private key size, since that is something that was requested for the Strimzi certificates. I'll make sure that feature is applied to the cert-manager implementation

@katheris @bh-tt This is completely unrelated to the issue and should not be discussed here. This issue does not seem to be even about a custom CA but a custom listener certificate.

Triaged on 6.3.2025: let's leave this open for more thoughts to be discussed in the next community call.

@ppatierno when you are considering this I forgot to mention that as Jakub stated above this particular issue is for custom listener certificates, but I think the same thing we discussed in the call stands which is that it would be hard to implement this since the Secrets are being mounted to the Kafka pods directly the next time the pods are rolled for any reason they would pick up the new values. I think it is an opportunity for us to be clear about how the maintenance time windows apply to any certificate updates though and make sure the documentation is also clear on this.

@katheris yeah I see your point. So I guess we should just try to make it clearer in the doc.

Triaged on 15.5.2025: We should update the documentation to make it clearer that this only applies to certificates that Strimzi generates. There is a separate discussion happening about cert-manager and whether it should apply once that is supported by Strimzi, but we will keep that discussion separate.