[
https://issues.apache.org/jira/browse/NIFI-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15328810#comment-15328810
]
ASF GitHub Bot commented on NIFI-1981:
--------------------------------------
Github user alopresto commented on a diff in the pull request:
https://github.com/apache/nifi/pull/508#discussion_r66900373
--- Diff:
nifi-commons/nifi-security-utils/src/test/groovy/org/apache/nifi/security/util/CertificateUtilsTest.groovy
---
@@ -272,4 +275,179 @@ class CertificateUtilsTest extends GroovyTestCase {
assert convertedCertificate instanceof X509Certificate
assert convertedCertificate == EXPECTED_NEW_CERTIFICATE
}
+
+ @Test
+ void testShouldDetermineClientAuthStatusFromSocket() {
+ // Arrange
+ SSLSocket needSocket = [getNeedClientAuth: { -> true }] as
SSLSocket
--- End diff --
Discussed with Matt offline, but these are standard Groovy map coercions,
not lambdas. Running a local check against Java 7 to ensure no Java 8 features
were introduced.
> Cluster communication requires client certificates even if needClientAuth set
> to false
> --------------------------------------------------------------------------------------
>
> Key: NIFI-1981
> URL: https://issues.apache.org/jira/browse/NIFI-1981
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 0.6.1
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Priority: Critical
> Labels: certificate, client-auth, cluster, ssl, tls
> Fix For: 1.0.0, 0.7.0
>
>
> A user reported having issues with "peer not authenticated" errors appearing
> in the NCM app log when a node tried to connect. Upon debugging, it was
> discovered that the certificates issues to the client specifically prohibited
> being used as a client certificate ({{Extended Key Usage}} was set to
> {{serverAuth}} only). Setting {{nifi.security.needClientAuth}} to {{false}}
> in {{nifi.properties}} did not solve the problem because while the TLS
> handshake negotiation is successful without the client certificate, cluster
> communication in {{SocketProtocolListener}} still attempts to resolve the DN
> of the node requestor regardless of the {{needClientAuth}} setting.
> The error message should be improved and the requestor DN extraction should
> respect the {{needClientAuth}} setting rather than throwing an unnecessary
> exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
