[
https://issues.apache.org/jira/browse/KUDU-3392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17733214#comment-17733214
]
ASF subversion and git services commented on KUDU-3392:
-------------------------------------------------------
Commit 4734d6f167333e67483d45bbeaf7509180641414 in kudu's branch
refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=4734d6f16 ]
[util] KUDU-3392: add validator for --trusted_certificate_file
While testing/troubleshooting the newly introduced JWT-based client
authentication, I found that setting the flag to a non-existing file
hadn't been handled as I expected.
This patch addresses the issue, adding a validator for the flag.
I didn't add any test to cover the newly added validator, but I have
verified that it worked as expected in various scenarios w.r.t. the
current value of the --trusted_certificate_file flag.
This is a follow-up to 152211658ef9d33e0ad727ccba46f8af24cd45b0.
Change-Id: I0d9d816a821a93037293d3985a2f577711d64ef2
Reviewed-on: http://gerrit.cloudera.org:8080/20075
Tested-by: Kudu Jenkins
Reviewed-by: Attila Bukor <abu...@apache.org>
> Support custom certificate when Kudu acts as a client
> -----------------------------------------------------
>
> Key: KUDU-3392
> URL: https://issues.apache.org/jira/browse/KUDU-3392
> Project: Kudu
> Issue Type: Improvement
> Reporter: Attila Bukor
> Assignee: Attila Bukor
> Priority: Major
> Fix For: 1.17.0
>
>
> Kudu connects to Ranger KMS when encryption is enabled using libcurl, and if
> the certificate is not trusted on the OS-level, it fails to connect. It
> should be possible to trust a certificate file by providing it in the CLI.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
