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 [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jul 18, 2018, at 3:37 PM, Andy LoPresto <[email protected]> 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 > > <https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#tls-generation-toolkit> > [2] https://issues.apache.org/jira/browse/NIFI-5370 > <https://issues.apache.org/jira/browse/NIFI-5370> > > > > > Andy LoPresto > [email protected] <mailto:[email protected]> > [email protected] <mailto:[email protected]> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> On Jul 18, 2018, at 2:49 PM, Jon Logan <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> >> 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 >>> <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 <[email protected]>: >>> >>>> 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/ >>>> >>> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
