[
https://issues.apache.org/jira/browse/NIFI-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18033674#comment-18033674
]
David Handermann commented on NIFI-15146:
-----------------------------------------
Thanks for the reply [~wpkinzel].
As mentioned, the requirements for the Client Authentication EKU are built into
the standard Java validator for mutual TLS. As the name implies, mutual TLS
means that any NiFi node could be considered a server or a client, depending on
the operation being performed.
As this is standard behavior for mutual TLS exchanges, it sounds like the only
viable option is to plan on shifting to a private CA to support control over
certificate extensions for NiFi nodes.
> Cluster Security: TLS Client Authentication Deprecated (EKU)
> -------------------------------------------------------------
>
> Key: NIFI-15146
> URL: https://issues.apache.org/jira/browse/NIFI-15146
> Project: Apache NiFi
> Issue Type: Bug
> Components: Security
> Affects Versions: 2.6.0
> Reporter: Bill Kinzel
> Priority: Major
>
> We operate a three-node cluster using a publicly-trusted CA (DigiCert).
> We’ve learned that many public CAs are phasing out inclusion of the _Client
> Authentication_ EKU (Extended Key Usage) in publicly-trusted TLS
> certificates. Are there any plans underway to support node auth under this
> new paradigm? I know a private CA is an alternative, but not an option for
> us right now.
> For more detailed information, you can visit our [knowledge
> article|https://knowledge.digicert.com/alerts/sunsetting-client-authentication-eku-from-digicert-public-tls-certificates].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
