-
Notifications
You must be signed in to change notification settings - Fork 332
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for custom truststore at Connector level #546
Comments
Created a PR to support the custom keystore #547 |
Why not add to the parent project in Also, why can't you use |
Hi! Sorry to drag an older one back up but we ran into this problem today, it seemed worth if it could get picked up again since I am sure it will not be just me who is having this problem currently. I can report that at least in 7.3.0 (edit: and My working assumption is that it is because this property is for "consuming" the message from Kafka which is already working fine and configured at the server level, and the underlying AWS libraries for writing to S3 don't seem to be reading from this truststore property anyway. For kicks I tried |
The override prefix is not specific to any connector. It's a base feature of the Connect API and has been available since around 2.3, I want to say - https://kafka.apache.org/documentation/#connect_running You do need to set the override policy on the worker first, otherwise, no the override will not apply |
hi @ OneCricketeer, circling back to this issue: The overall goal is use setting I understand that you suggest support for custom keystore could make more sense to be added on Can you share documentation on how to target a custom S3 endpoint and trust a custom TLS certifcate using
|
The mentioned override settings have no connection to S3, or Connector, only kafka client settings, so for TLS / SASL connection to the brokers, for example |
Would be great to have support at the S3-Sink connector level to use additional truststore, so that private CA and self-sgined certificates can be trusted.
For instance, using the property
store.url
to store in a S3 compatible server over https. Nowadays if the S3 compatible server is setup with a private CA or selft-signed certificates in a airgap environment, the S3-SInk connector fails the SSL verification.The way how some user have been working around this is by adding the private CA or self-signed certificates to the default java cacerts, however that requieres root acces to the container/machine running the java process, and this is not always available.
The text was updated successfully, but these errors were encountered: