On Thu, Jul 19, 2018 at 12:38 AM Andy LoPresto <alopre...@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. > I would highlight that in that case you should use the original authorizers.xml that do not contain any nodes, not even the initial admin identity. This way new nodes can figure to accept authorizers information from the cluster instead of having a conflict and failing to start. (This failure scenario happened to me when tried to spin up new nodes with the same authorizers.xml that I used for the inital cluster.) > * 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 > alopre...@apache.org > *alopresto.apa...@gmail.com <alopresto.apa...@gmail.com>* > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Jul 18, 2018, at 2:49 PM, Jon Logan <jmlo...@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 < > pierre.villard...@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 <josef.zahn...@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/ > > > >
