[
https://issues.apache.org/jira/browse/OOZIE-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16982579#comment-16982579
]
Mate Juhasz commented on OOZIE-3549:
------------------------------------
Uploading a new patch, tested in a deployment. Please see the diff in
SSLServerConnectorFactory#setKeystorePass.
Some explanation on the relation of KeyManagerPassword and KeyStorePassword
from the eclipse docs:
https://www.eclipse.org/jetty/documentation/9.3.27.v20190418/configuring-ssl.html#configuring-sslcontextfactory
I would say that using a PKCS12 keystore requires the
sslContextFactory.KeyStorePassword to be set instead (or besides) of
KeyManagerPassword. If jetty's KeyManagerPassword is not set the
KeyStorePassword will be used for that as well.
> 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)
