[
https://issues.apache.org/jira/browse/NIFI-5370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16537851#comment-16537851
]
ASF GitHub Bot commented on NIFI-5370:
--------------------------------------
Github user alopresto commented on the issue:
https://github.com/apache/nifi/pull/2869
This PR is to resolve the user-reported issue in
[NIFI-5370](https://issues.apache.org/jira/browse/NIFI-5370) where a secure
cluster with nodes using wildcard certificates would not allow UI login. The
issue was because the introduced `NiFiHostnameVerifier` did not evaluate
wildcard entries properly. This patch fixes the immediate issue.
**However**, wildcard certificates are not officially supported and are
**not recommended** for use in a secure cluster environment. There are numerous
disadvantages to using wildcard certificates, they have been actively
discouraged in the past, and have worked to this point only out of luck. The
Admin Guide will be updated to state this explicitly
[NIFI-5399](https://issues.apache.org/jira/browse/NIFI-5399).
Disadvantages of wildcard certificates for cluster:
* we use certificate identities many times throughout the codebase to
identify a node, and if the certificate simply presents a wildcard DN, that
doesn’t resolve to anything (see
[NIFI-5398](https://issues.apache.org/jira/browse/NIFI-5398))
* you need to provide a custom node identity in your `authorizers.xml` for
`*.whatever.com` because all proxy actions only resolve to the cert DN
* no traceability into which node performed an action because they all
resolve to the same DN
* if you’re running multiple instances on the same machine using different
ports to identify them, and you accidentally put `node1` hostname with `node2`
port, it will resolve fine because it’s using the same certificate, but the
host header handler will block it because the `node1` hostname is not listed as
an acceptable `host` for `node2` instance (correctly)
* if the cert is compromised, all nodes are compromised
Advantages of wildcard certificates for cluster:
* nominally faster to deploy in dynamically-scaled clusters, however the
NiFi TLS Toolkit automates the process of generating correctly-signed,
uniquely-identified certificates in the proper format. The deployment script or
process for adding a node should leverage this tool rather than use a repeated
wildcard certificate. Using a wildcard in the SAN is fine as long as a unique
value exists in the SAN as well.
> Cluster request replication failing with wildcard certs
> -------------------------------------------------------
>
> Key: NIFI-5370
> URL: https://issues.apache.org/jira/browse/NIFI-5370
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.7.0
> Reporter: Andy LoPresto
> Assignee: Andy LoPresto
> Priority: Major
> Labels: certificate, cluster, security, tls, wildcard
>
> From the users mailing list:
> {quote}
> Team,
>
> NiFi secured cluster throws below error with wildcarded self-signed
> standalone certificate. Just a brief background, we are deploying nifi in
> Kubernetes where we have to use wildcarded certificates. Till nifi 1.6.0, it
> was working fine.
> Also I tried bringing up NiFi in linux VM in secured cluster mode with
> wildcarded certs, I am getting same error.
>
> Toolkit command to generate certs:
> bin/tls-toolkit.sh standalone -n
> '*.mynifi-nifi-headless.default.svc.cluster.local’ -C 'CN=admin, OU=NIFI' -o
> <targetfolder>
>
> Logs:
> 2018-07-02 12:40:32,369 WARN [Replicate Request Thread-1]
> o.a.n.c.c.h.r.ThreadPoolRequestReplicator Failed to replicate request GET
> /nifi-api/flow/current-user to
> mynifi-nifi-1.mynifi-nifi-headless.default.svc.cluster.local:8443 due to
> javax.net.ssl.SSLPeerUnverifiedException: Hostname
> mynifi-nifi-1.mynifi-nifi-headless.default.svc.cluster.local not verified:
> certificate: sha256/########################################
> DN: CN=*.mynifi-nifi-headless.default.svc.cluster.local, OU=NIFI
> subjectAltNames: [*.mynifi-nifi-headless.default.svc.cluster.local]
> 2018-07-02 12:40:32,370 WARN [Replicate Request Thread-1]
> o.a.n.c.c.h.r.ThreadPoolRequestReplicator
> javax.net.ssl.SSLPeerUnverifiedException: Hostname
> mynifi-nifi-1.mynifi-nifi-headless.default.svc.cluster.local not verified:
> certificate: sha256/########################################
> DN: CN=*.mynifi-nifi-headless.default.svc.cluster.local, OU=NIFI
> subjectAltNames: [*.mynifi-nifi-headless.default.svc.cluster.local]
> at
> okhttp3.internal.connection.RealConnection.connectTls(RealConnection.java:316)
>
> Please help me in resolving this.
>
> Note: Same certificates is working for single mode setup.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
