RE: Replacing Wildcard certs in secure cluster

["V, Prashanth (Nokia - IN/Bangalore)" <pr...@nokia.com>]

Thanks Andy for the detailed explanation.

* run the TLS toolkit as a server and have each node connect to it to obtain a valid cert. All of these will be signed by the same CA and each node will be able to communicate with all others. Add a new user with the node CN and RW on /proxy resource via the UI/API of the existing nodes. You should not need to modify authorizers.xml directly.                                                                                                                        -  I tested this procedure. Everything works fine.
* same permissions steps but use the toolkit in standalone mode. In this case, you must run it from the same directory every time (so it uses the same CA key to sign).       -  I created  2 node cluster. I generated certs for node1. Then I copied nifi-cert.pem & nifi-key.key file to node2 and  generated certs for it. With these certs, I can see nifi inter-cluster communication works fine. Now, I created client cert(P12 file) from different machine using the same CA key, that certificate can't able to open GUI. It is giving
ThreadPoolRequestReplicator - javax.ws.rs.ProcessingException: java.net.ConnectException: Connection refused (Connection refused)
Would you please tell me what goes wrong with this approach?

Thanks & Regards,
Prashanth
From: Andy LoPresto [mailto:alopresto@apache.org]
Sent: Thursday, July 19, 2018 4:25 AM
To: dev@nifi.apache.org
Subject: Re: SSLPeerUnverifiedException Hostname "xyz" not verified

Just to add on, we are not saying that the current state is acceptable or the easiest to use. NIFI-5398 and NIFI-5443 exist to improve this experience.

[1] https://issues.apache.org/jira/browse/NIFI-5398
[2] https://issues.apache.org/jira/browse/NIFI-5443


Andy LoPresto
alopresto@apache.org<ma...@apache.org>
alopresto.apache@gmail.com<ma...@gmail.com>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 18, 2018, at 3:37 PM, Andy LoPresto <al...@apache.org>> wrote:

Hi Jon,

There are automatable, scalable, and non-restart-required ways to horizontally scale a secure cluster without requiring wildcard certificates. I should collect the various instructions / notes together into an article and people can reference that, but until that time, the Admin Guide [1] and the conversation Prashanth and I had on the ticket [2] are the best documentation for this.

Basically:

* run the TLS toolkit as a server and have each node connect to it to obtain a valid cert. All of these will be signed by the same CA and each node will be able to communicate with all others. Add a new user with the node CN and RW on /proxy resource via the UI/API of the existing nodes. You should not need to modify authorizers.xml directly.
* same permissions steps but use the toolkit in standalone mode. In this case, you must run it from the same directory every time (so it uses the same CA key to sign).
* same permissions steps but run toolkit in standalone on each node. In this case, you must import the generated CA into existing node truststores (requires restart).

[1] https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#tls-generation-toolkit
[2] https://issues.apache.org/jira/browse/NIFI-5370




Andy LoPresto
alopresto@apache.org<ma...@apache.org>
alopresto.apache@gmail.com<ma...@gmail.com>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 18, 2018, at 2:49 PM, Jon Logan <jm...@buffalo.edu>> wrote:

I saw this in the release notes...specifically that wildcard certs are not
supported. How do most people handle this in practice? We can run a cert
server or get them from other means (AWS cert manager, etc) but am not sure
how to overcome the authorizers.xml issue -- would we need to have a
provisioning script register each new server certificate with NiFi before
it can actually do anything useful? Will new servers then have issues
joining because their authorizers will not match the rest of the cluster?

On Thu, Jul 5, 2018 at 8:04 AM, Pierre Villard <pi...@gmail.com>>
wrote:


Hi Josef,

I don't have a solution for you but it seems it has already been reported
and a JIRA has been opened:
https://issues.apache.org/jira/browse/NIFI-5370

Andy might be able to give more insights about it.

Pierre

2018-07-05 13:19 GMT+02:00 Josefz <jo...@swisscom.com>>:


Hi expert

I've just done an upgrade from NiFi 1.5.0 to 1.7.0 in a SSL secured
cluster

with LDAP authentication. Now I'm not anymore able to login into the
webgui.
After I have entered the login/password I'm getting the following
message:




And nifi-app.log reports the following error messages:



I'm having a wildcard SSL certificate and I'm using the same
keystore/truststore combination for three usecases:
- for cluster connectivity (in nifi.properties)
- in "authorizer.xml"
- in "login-identity-providers.xml".

The keystore.jks (private/public) keypair has been signed by our internal
root CA and the root CA cert has been imported into the truststore.jks.
As

the ldap login works with certificates I'm more or less sure that the
certs

in general are fine. Has anybody an idea if wildcard CN and SAN names
should
work in a cluster or where the problem could be? I've tried the same
certs

as well in standalone mode, no issue at all.

The following parameters in nifi.properties are enabled:
nifi.security.needClientAuth=true
nifi.cluster.protocol.is.secure=true

Thanks in advance




--
Sent from: http://apache-nifi-developer-list.39713.n7.nabble.com/