[
https://issues.apache.org/jira/browse/NIFI-7333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17107555#comment-17107555
]
Andy LoPresto commented on NIFI-7333:
-------------------------------------
I discussed this with [~markap14] and our proposal is:
* Add a new property in {{nifi.properties}} for an OIDC-specific truststore
path and password
* If this value is not populated, continue using the JVM {{cacerts}} which will
work with public OIDC providers like Google & Microsoft out of the box
* If the desired OIDC provider is not trusted by the JVM, a new truststore can
be provided via these properties. It can be a standalone truststore which only
trusts the OIDC provider, or the OIDC provider public certificate can be added
to the NiFi truststore, and that file can be referenced here as well
There is another discussion about possibly allowing multiple "framework-level"
keystore/truststores, which would be named and referenced by name in
application behavior, which would obviate this need.
> OIDC provider should use NiFi keystore & truststore
> ---------------------------------------------------
>
> Key: NIFI-7333
> URL: https://issues.apache.org/jira/browse/NIFI-7333
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework, Security
> Affects Versions: 1.11.4
> Reporter: Andy LoPresto
> Assignee: Troy Melhase
> Priority: Major
> Labels: keystore, oidc, security, tls
>
> The OIDC provider uses generic HTTPS requests to the OIDC IdP, but does not
> configure these requests to use the NiFi keystore or truststore. Rather, it
> uses the default JVM keystore and truststore, which leads to difficulty
> debugging PKIX and other TLS negotiation errors. It should be switched to use
> the NiFi keystore and truststore as other NiFi framework services do.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
