[
https://issues.apache.org/jira/browse/NIFI-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606863#comment-15606863
]
Andy LoPresto commented on NIFI-2943:
-------------------------------------
I agree. PKCS12 is a format designed for storing private keys alongside the
public certificates, and this is unnecessary for truststores. I think NiFi
should default to handling JKS for keystore and truststore and the TLS toolkit
should only be concerned with generating JKS for the same. I don't think we
would lose any functionality, and if users receive keystores/truststores in
PKCS12 format from internal organizational security teams, they can be
converted to JKS format using the {{keytool}} and {{openssl}} command line
tools.
If we make this change, it might make sense to deprecate the
{{nifi.security.keystoreType}} and {{nifi.security.truststoreType}} properties
in {{nifi.properties}} as they will be unnecessary. This would also impact
{{SSLContextFactory}} and {{StandardSSLControllerService}} configuration.
> tls-toolkit pkcs12 truststore 0 entries
> ---------------------------------------
>
> Key: NIFI-2943
> URL: https://issues.apache.org/jira/browse/NIFI-2943
> Project: Apache NiFi
> Issue Type: Bug
> Reporter: Bryan Rosander
> Assignee: Bryan Rosander
> Priority: Minor
>
> When pkcs12 is used by the tls-toolkit, the resulting truststore has no
> entries when inspected by the keytool and the tls-toolkit certificate
> authority certificate is not trusted by NiFi.
> This seems to be due to the Java pkcs12 provider not supporting certificate
> entries:
> http://stackoverflow.com/questions/3614239/pkcs12-java-keystore-from-ca-and-user-certificate-in-java#answer-3614405
> The Bouncy Castle provider does seem to support certificates but we may not
> want to explicitly use that provider from within NiFi.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
