[
https://issues.apache.org/jira/browse/OOZIE-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16959011#comment-16959011
]
Mate Juhasz commented on OOZIE-3549:
------------------------------------
Thanks [~asalamon74] for the summary. However it turned out, that the issue
might be somewhere else... there is this function
SSLServerConnectorFactory#setKeystorePass where we call
sslContextFactory.KeyManagerPassword(keystorePass) instead of
setKeyStorePassword.
The patch is working if we change this part, which I could not understand well,
so I would like to test it out better in a deployment.
> Add back support for truststore passwords
> -----------------------------------------
>
> Key: OOZIE-3549
> URL: https://issues.apache.org/jira/browse/OOZIE-3549
> Project: Oozie
> Issue Type: Improvement
> Affects Versions: trunk
> Reporter: Andras Salamon
> Assignee: Mate Juhasz
> Priority: Major
> Attachments: OOZIE-3549.patch
>
>
> OOZIE-3157 removed {{oozie.https.truststore.pass}} property, because we
> (Oozie + Jetty) don't write the truststore and the password is not required
> for reading.
> This is no longer true, Java 11's keytool now defaults to creating PKCS12
> keystores instead of JKS, and according to
> [this|https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1771363]
> bug description "A JKS keystore can be read without supplying a password (or
> by supplying an empty one) while a PKCS12 keystore requires a password to be
> set."
> We should reintroduce this property and allow the it again to specify this
> password and pass it to jetty.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
