Strimzi
Replies: 7 comments 8 replies
-
|
To be honest, it is really hard to understand what the problem you are experiencing really is without the full configurations, full logs from the operator, and all components etc. So sharing that would be a good start. As for your questions:
I'm not sure what exactly you mean with this. The
No. But there were other things that changed how certificates are mounted and used which happened in recent versions.
Not really. One thing to keep in mind is that the certificates you provide should be in the PKCS#8 format. In older versions, PKCS#1 worked fine pretty much by coincidence, but they do not work in the newer versions. Could that be related? The correct ones - PKCS#8 - start with |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Thank you @scholzj, for the quicky response. The cluster-ca and client-ca keys are PKCS#8 version. So I don't think this the issue. Here it the logs of the strimzi operator: |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Kafka Broker Logs |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Application logs |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Is there any secure channel to share this kind of information? |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
There is no secure channel. You are asking for free help from an open source community. So it is important that everything is shared here publicly in open so that everyone can learn from it. If you can't share stuff from your environment, the easiest thing to so is to reproduce the issue in some test environment from which you can share everything. |
Beta Was this translation helpful? Give feedback.
-
|
From what you shared, I think the error suggests wrong trusstore. So that might be something to check. What do you have in it, how did you created it, etc. |
Beta Was this translation helpful? Give feedback.
-
|
Well, the config seems to use |
Beta Was this translation helpful? Give feedback.
-
|
Saying that it works for you with 0.47 is great. But without understanding your configuration and what do you do, it does not give us much stuff to work with, |
Beta Was this translation helpful? Give feedback.
-
|
Let me try and add some context to this. Only working part-time in proximity to this, but I am well acquainted with the setup. In v0.47.0, the init scripts added both the broker certificate from the broker secret and the cert-chain from the cluster-ca secret to the p12 store. The brokers present the full chain up to the root certificate and since that is what the clients trust, it works. In v0.49.0 the default behavior seems to be to read the contents of the broker secret directly into the Is this the expected behavior? |
Beta Was this translation helpful? Give feedback.
3 replies
-
|
Ok, that is a very good point. TBH, I'm not sure if this is expected or unexpected behavior. I do not think the way it worked before was a result of any intentional decision and design. I'm not sure if the system tests we have for custom CAs use a multi-stage CA. But, for example, when I use it myself from time to time, I always trust the Leaf-CA rather than the Root-CA. We are definitely not moving back to JKS/PKCS12 stores because of this. But I can see why the original behavior might have been prefered by some users. And obviously, there is value in not breaking things if possible. But I'm not sure if this can be fixed by passing the whole chain in the The easiest way to test it would probably be through a custom listener certificate, as that would not need any code change, I guess. Can you please open a Bug issue for this? And someone can try to have a look at it and fix it if possible. |
Beta Was this translation helpful? Give feedback.
-
|
Kudos to the impressively quick response. Completely agree with not going back to JKS/PKCS12. Perhaps my assumption that including the chain in the property would solve the problem is wrong, but it would be rather neat if it could be done that way. As you already concluded it is probably best to, at least for now, go with a custom listener certificate. Regardless, will make sure we open a Bug issue. Thanks for the help! |
Beta Was this translation helpful? Give feedback.
-
|
Hi both, chiming in having also hit this change in behaviour. Few examples of why a chain is valuable:
I agree, custom listener certificates is a workaround because you can ensure the chain is there. But I believe you lose the value of having Strimzi automatically renew certs using your CA? |
Beta Was this translation helpful? Give feedback.
-
|
I have opened the bug report for it #12364. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Issue has been fixed in the following PR #12390. Thank you for all the support on this issue. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
After upgrading the Strimzi Kafka Operator from 0.47.0 to 0.49.1, all applications connecting via internal DNS services (e.g., my-kafka-bootstrap.kafka.svc.cluster.local) started failing with TLS SSL_HANDSHAKE errors.
Our Kafka deployment does not use Strimzi‑managed CAs:
We supply our own certificates via Kubernetes Secrets.
All KafkaUsers are already in API version v1 and correctly use .spec.authorization.acls[].operations.
The issue appears only after upgrading the operator — no changes were made to certificates or KafkaUser resources. When we rollback to version 0.47.0 the issue disappears
Expected behavior
TLS clients connecting internally using Kubernetes DNS (e.g.,
my-kafka-bootstrap.kafka.svc.cluster.local:9093) should successfully authenticate.
No certificate regeneration should occur because Strimzi CA generation is disabled.
Internal brokers should continue presenting SANs matching:
Actual behavior
Immediately after the upgrade:
This began exactly when the operator reconciled after upgrading to 0.49.1.
Environment
Cluster Operator version:
Kafka version: 4.0.0
Kubernetes/OpenShift version: (Kubernetes 1.27+ required by Strimzi 0.48+)
CAs: Provided externally, not generated by Strimzi
Listeners:
What we need help from Strimzi maintainers with
Beta Was this translation helpful? Give feedback.
All reactions